From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by mx.groups.io with SMTP id smtpd.web11.26500.1677857913461784381 for ; Fri, 03 Mar 2023 07:38:33 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=AeJPoA9G; spf=pass (domain: rivosinc.com, ip: 209.85.160.173, mailfrom: dhaval@rivosinc.com) Received: by mail-qt1-f173.google.com with SMTP id z6so3316524qtv.0 for ; Fri, 03 Mar 2023 07:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1677857912; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e0fI3PzzHtW2yjqhUc/nOEoHvWu1PqGtxtYjsGmSt6s=; b=AeJPoA9GLw+CmlUR/xsj1SbHvkRstNthUf1Rn1Xcu5/BjbZHFGMVUnlDaI/wAqxkmD KREt0Kiat0p7ynRMFs+UuT/bOnxFsnLNvZ0n7+wpUFw9Duak0TG3JM6CRL9QAlJ2E/F6 JW0ASyIVv94MSwHtd5kDDHRXzbUigq4vdbOS4ArZCX4RyPzHuSFejB2qlhQj8NP8D1Rp 9AmBfVlG+2H2ZWtOg/WKh9RDizuv8Ei+hpk07swtZsZufkK987mjyJT4aviYZVBIiD1Z kRlrgp3vBUZ7VS5Y182+3n5MBc0ktiaCYl1CN0ulkIoRX3tPkgzyT8K5jMDm7GICoKf+ uMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677857912; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=e0fI3PzzHtW2yjqhUc/nOEoHvWu1PqGtxtYjsGmSt6s=; b=pRGQmFIoHfMP6FTx3w6PLu+brtDwv2enRH7xn6vWqfKe5ShwGTSzNeku8kXoIyPlFR XgreB5IO23KQlp3cVRakf60Pd7sKX422Hvo5NRp7IdW4eUPF+SG9jcSiczExDJEzRaC6 Ia46Mpoj1nXsIGB1eWP0Cb4h76ICUxVD0it5C6BpssDCnVejQfNoGGNqwBQGvgKuz9Wz pIPPz3gJr9kql0lpeU6EzTBfhydla3yDtbUl/RcOCqQFcTFk0zEk42YU3CGF6xXrLSMD 5Q1oDg2U/Bn1Ku55SD6ozQ+puGxYx0JmS4cz+jvgDzWgrwP05Xc/vEOH3HGKHakDGb0S jhGw== X-Gm-Message-State: AO0yUKUepyF0Zp5g4CVeMvEJc9V0geJ/uYH4MRWAtgfmoETMRAbYLjb6 V5pctUQCu0cClQO21SbxHfZzlmDPRuw3OJchSFXaCKdbDjP3f7dt X-Google-Smtp-Source: AK7set9CYjnZD5KfQcuJ6/A7f65QodUfjZblt7fBWuK8c4Ku2FrZRvmTx8EQS8yNaFJaWFodH2D7XRGm+i3IPfDCB7g= X-Received: by 2002:ac8:1cd:0:b0:3bf:b844:ffc7 with SMTP id b13-20020ac801cd000000b003bfb844ffc7mr657585qtg.12.1677857912394; Fri, 03 Mar 2023 07:38:32 -0800 (PST) MIME-Version: 1.0 References: <20230302181228.325312-1-dhaval@rivosinc.com> In-Reply-To: From: "Dhaval Sharma" Date: Fri, 3 Mar 2023 21:08:21 +0530 Message-ID: Subject: Re: [PATCH v1 0/1] Remove FP Init in UPL Entry To: "Guo, Gua" Cc: "devel@edk2.groups.io" Content-Type: multipart/alternative; boundary="000000000000da301905f600bc3f" --000000000000da301905f600bc3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 3, 2023 at 6:05=E2=80=AFAM Guo, Gua wrote: > What's the issue you encounter ? > I will add this context in the next patchset. But primarily I am enabling UPL for RiscV and during the process I found a few sequences which I believe are arch specific and showing up in the common boot path. While RV has a similar FP enabling concept, in my understanding this enabling is required to automate (HW based) FP save/restore during process context switches at OS runtime. Also OS (at least I confirmed with Linux) have their own enabling process for FP. And I do not see any instance in UPL/BDS that is making use of this feature. Also it appears that UPL spec suggests BL performs this step. > > -----Original Message----- > From: Dhaval Sharma > Sent: Friday, March 3, 2023 2:12 AM > To: devel@edk2.groups.io > Cc: Guo, Gua > Subject: [PATCH v1 0/1] Remove FP Init in UPL Entry > > Remove floating point initialization from UPL entry point > > Cc: Gua guo > Dhaval Sharma (1): > UefiPayloadPkg: Remove FP Init from UPL entryfunc > > UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c | 3 --- > 1 file changed, 3 deletions(-) > > -- > 2.40.0.rc0.57.g454dfcbddf > > --=20 Thanks! =3DD --000000000000da301905f600bc3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 3, 2023 at 6:05=E2=80=AFA= M Guo, Gua <gua.guo@intel.com&g= t; wrote:
What&#= 39;s the issue you encounter ?
I will add this context= in the next patchset. But primarily I am enabling UPL for RiscV and during= the process I found a few sequences which I believe are arch specific and = showing up in the common boot path.
While RV has a similar FP ena= bling concept, in my understanding this enabling is required to automate (H= W based) FP save/restore during process context switches at OS runtime. Als= o OS (at least I confirmed
with Linux) have their own enabling pr= ocess for FP. And I do not see any instance in UPL/BDS that is making use o= f this feature. Also it appears that UPL spec suggests BL performs this ste= p.

-----Original Message-----
From: Dhaval Sharma <dhaval@rivosinc.com>
Sent: Friday, March 3, 2023 2:12 AM
To: devel@edk2.gr= oups.io
Cc: Guo, Gua <gua= .guo@intel.com>
Subject: [PATCH v1 0/1] Remove FP Init in UPL Entry

Remove floating point initialization from UPL entry point

Cc: Gua guo <gua.= guo@intel.com>
Dhaval Sharma (1):
=C2=A0 UefiPayloadPkg: Remove FP Init from UPL entryfunc

=C2=A0UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c | 3 ---
=C2=A01 file changed, 3 deletions(-)

--
2.40.0.rc0.57.g454dfcbddf



--
Thanks!
=3DD
--000000000000da301905f600bc3f--