From: "Dhaval Sharma" <dhaval@rivosinc.com>
To: "Warkentin, Andrei" <andrei.warkentin@intel.com>, devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features
Date: Wed, 1 Nov 2023 22:35:29 +0530 [thread overview]
Message-ID: <CAAxYnhRbFDD3QaMba7DgkhzmKaKwQ8A=pFe7MiKDx5TmytLbbg@mail.gmail.com> (raw)
In-Reply-To: <PH8PR11MB685618B80ED798FE1FB19ED983A0A@PH8PR11MB6856.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
Hi Andrei,
Are you suggesting:
1. We have a generic PCD to store the address of RVFeatures bitfield.
2. It gets populated at some point during initialization with let's say
some kind of global variable address which keeps this bitfield.
3. SEC/DXE phases deref this address and use where needed?
Is there a reference I can take a look at?
Assuming my above understanding is correct, the whole idea was to keep
implementation based on simple PCD such that it can be used easily as an
override mechanism. The reason to keep it "enabled" by default in MDE is
that if m-mode decides to keep it disabled it is anyways going to remain
that way. So practically this PCD is going to be useful only in cases where
the user wants to "Override Disable". LMK if you still think we should
modify the implementation.
=D
On Tue, Oct 31, 2023 at 10:31 PM Warkentin, Andrei <
andrei.warkentin@intel.com> wrote:
> I think I misunderstood the intent. Reviewing the full patchset, it seems
> this is necessary to avoid using the new CMO path in the Virt platform
> (since the default value is all FFs). Shouldn’t the default Pcd value here
> be all 0’s – i.e. CMO or any other feature use becomes “opt in” instead of
> “opt out”?
>
>
>
> It also seems that encoding the meaning inside the bit positions is a bit…
> obscure. Have you considered storing a pointer to a struct with bitfields
> instead? You could then change the logic to be something like “If
> PcdPtrValue != NULL && ((struct cast *) PcdPtrValue)->LegibleFieldName”. I
> think this would do wonders for code maintainability. The cost of course is
> in having to initialize the Pcd now at runtime, and the additional
> dereference, but that seems like a low cost all things considered.
>
>
>
> *From:* Dhaval Sharma <dhaval@rivosinc.com>
> *Sent:* Tuesday, October 31, 2023 1:13 AM
> *To:* Warkentin, Andrei <andrei.warkentin@intel.com>; devel@edk2.groups.io
> *Subject:* Re: [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override
> for RV CPU Features
>
>
>
> Thanks. This PCD is for Virt platform only. Or maybe I am missing the
> point.
>
--
Thanks!
=D
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110487): https://edk2.groups.io/g/devel/message/110487
Mute This Topic: https://groups.io/mt/102256471/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
[-- Attachment #2: Type: text/html, Size: 4313 bytes --]
next prev parent reply other threads:[~2023-11-01 17:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-29 14:46 [edk2-devel] [PATCH v7 0/5] Cache Management Operations Support For RISC-V Dhaval Sharma
2023-10-29 14:46 ` [edk2-devel] [PATCH v7 1/5] MdePkg: Move RISC-V Cache Management Declarations Into BaseLib Dhaval Sharma
2023-10-29 14:46 ` [edk2-devel] [PATCH v7 2/5] MdePkg: Rename Cache Management Function To Clarify Fence Based Op Dhaval Sharma
2023-10-29 14:46 ` [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations Dhaval Sharma
2023-10-29 19:12 ` Pedro Falcato
2023-10-30 9:38 ` Laszlo Ersek
2023-10-30 11:33 ` Sunil V L
2023-10-30 16:37 ` Pedro Falcato
2023-10-31 9:55 ` Dhaval Sharma
2023-10-31 15:37 ` Laszlo Ersek
2023-10-31 19:19 ` Pedro Falcato
2023-11-01 8:03 ` Jingyu Li via groups.io
2023-10-30 10:55 ` Sunil V L
2023-10-31 6:45 ` Jingyu Li via groups.io
2023-10-29 14:46 ` [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V Dhaval Sharma
2023-10-29 19:07 ` Pedro Falcato
2023-10-30 9:40 ` Laszlo Ersek
2023-10-30 11:18 ` Sunil V L
2023-10-30 11:22 ` Sunil V L
2023-10-31 10:42 ` Laszlo Ersek
2023-10-31 6:18 ` Dhaval Sharma
2023-10-31 6:24 ` Dhaval Sharma
2023-10-31 7:36 ` Sunil V L
2023-10-31 10:41 ` Laszlo Ersek
2023-10-29 14:46 ` [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features Dhaval Sharma
2023-10-31 4:13 ` Andrei Warkentin
2023-10-31 6:12 ` Dhaval Sharma
2023-10-31 17:01 ` Andrei Warkentin
2023-11-01 17:05 ` Dhaval Sharma [this message]
2023-11-01 20:27 ` Andrei Warkentin
2023-10-29 19:15 ` [edk2-devel] [PATCH v7 0/5] Cache Management Operations Support For RISC-V Pedro Falcato
2023-10-31 4:16 ` Andrei Warkentin
2023-10-31 5:13 ` Dhaval Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAxYnhRbFDD3QaMba7DgkhzmKaKwQ8A=pFe7MiKDx5TmytLbbg@mail.gmail.com' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox