On 1/19/24 05:43, Nhi Pham wrote:
> On 1/18/2024 9:49 PM, Laszlo Ersek wrote:
> but I'd prefer to just remove this
> optimization from standalone MM, given that not only a) it shouldn't
> have to deal with a large number of protocol GUIDs, but also b) the
> driver dispatch is much
On 1/18/2024 9:49 PM, Laszlo Ersek wrote:
but I'd prefer to just remove this
optimization from standalone MM, given that not only a) it shouldn't
have to deal with a large number of protocol GUIDs, but also b) the
driver dispatch is much more straight-forward. (Typically, StMM
drivers can be
On 1/18/24 07:00, Nhi Pham wrote:
> Hi Laszlo,
>
> On 1/16/2024 2:00 AM, Laszlo Ersek wrote:
>> On 1/15/24 15:04, Ard Biesheuvel wrote:
>>> On Mon, 15 Jan 2024 at 14:07, Nhi Pham
>>> wrote:
On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
> (Independently: I think that's a valid thing to
Hi Laszlo,
On 1/16/2024 2:00 AM, Laszlo Ersek wrote:
On 1/15/24 15:04, Ard Biesheuvel wrote:
On Mon, 15 Jan 2024 at 14:07, Nhi Pham wrote:
On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
(Independently: I think that's a valid thing to do for *SMM* drivers,
because the entry point functions of
On 1/15/24 15:04, Ard Biesheuvel wrote:
> On Mon, 15 Jan 2024 at 14:07, Nhi Pham wrote:
>>
>> On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
>>> (Independently: I think that's a valid thing to do for *SMM* drivers,
>>> because the entry point functions of those drivers are permitted to use
>>> both
On Mon, 15 Jan 2024 at 14:07, Nhi Pham wrote:
>
> On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
> > (Independently: I think that's a valid thing to do for *SMM* drivers,
> > because the entry point functions of those drivers are permitted to use
> > both SMM and DXE/UEFI protocols. But whether the
On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
> (Independently: I think that's a valid thing to do for *SMM* drivers,
> because the entry point functions of those drivers are permitted to use
> both SMM and DXE/UEFI protocols. But whether the same is valid for the
> *standalone* MM drivers -- that
nney, Michael D
>
> Cc: pedro.falc...@gmail.com; Laszlo Ersek ;
> n...@os.amperecomputing.com; ardb+tianoc...@kernel.org
> Subject: Re: [edk2-devel] Memory Attribute for depex section
>
>
>
>
> On Jan 12, 2024, at 8:37 AM, Michael D Kinney <mailto:michael.d.kin...@
D
Cc: pedro.falc...@gmail.com; Laszlo Ersek ;
n...@os.amperecomputing.com; ardb+tianoc...@kernel.org
Subject: Re: [edk2-devel] Memory Attribute for depex section
On Jan 12, 2024, at 8:37 AM, Michael D Kinney
mailto:michael.d.kin...@intel.com>> wrote:
Hi Pedro,
Thank you for eval
oups.io <mailto:devel@edk2.groups.io>;
>> n...@os.amperecomputing.com <mailto:n...@os.amperecomputing.com>;
>> ardb+tianoc...@kernel.org <mailto:ardb+tianoc...@kernel.org>; Andrew Fish
>> mailto:af...@apple.com>>
>> Subject: Re: [edk2-devel] Memo
> On Jan 12, 2024, at 6:46 AM, Pedro Falcato wrote:
>
> On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek wrote:
>>
>> On 1/12/24 03:10, Pedro Falcato wrote:
>>> My idea was to make each handle an index - like a file descriptor -
>>> AFAIK there's no reason why it *needs* to be an actual
; From: devel@edk2.groups.io On Behalf Of Pedro Falcato
> Sent: Friday, January 12, 2024 6:47 AM
> To: Laszlo Ersek
> Cc: devel@edk2.groups.io; n...@os.amperecomputing.com;
> ardb+tianoc...@kernel.org; Andrew Fish
> Subject: Re: [edk2-devel] Memory Attribute for depex section
>
On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek wrote:
>
> On 1/12/24 03:10, Pedro Falcato wrote:
> > My idea was to make each handle an index - like a file descriptor -
> > AFAIK there's no reason why it *needs* to be an actual pointer.
> > We'd allocate indices when creating a handle, and return
On 1/12/24 03:44, Andrew (EFI) Fish wrote:
> Sorry need some more time to digest this…. First thoughts.
>
> 1) The actual performance issue we hit was the explosion
> of CoreValidateHandle() calls as the number of protocols got large for
> some diags. The newer handles tended to be at the end of
On 1/12/24 03:10, Pedro Falcato wrote:
> On Thu, Jan 11, 2024 at 8:46 AM Laszlo Ersek wrote:
>>
>> On 1/10/24 22:50, Pedro Falcato wrote:
>>> FWIW, can we do better than an RB tree? They're notoriously cache
>>> unfriendly...
>>
>> Sure, if someone contributes a different data structure that is
Sorry need some more time to digest this…. First thoughts.
1) The actual performance issue we hit was the explosion of
CoreValidateHandle() calls as the number of protocols got large for some diags.
The newer handles tended to be at the end of the list if I remember correctly.
a) It looks
On Thu, Jan 11, 2024 at 8:46 AM Laszlo Ersek wrote:
>
> On 1/10/24 22:50, Pedro Falcato wrote:
> > On Wed, Jan 10, 2024 at 1:45 PM Laszlo Ersek
> > wrote:
> >>
> >> (+ Andrew)
> >>
> >> On 1/10/24 14:09, Laszlo Ersek wrote:
> >>
> >>> I think that keeping the depex section read-only is valuable,
On 1/11/24 09:46, Laszlo Ersek wrote:
> On 1/10/24 22:50, Pedro Falcato wrote:
>> For the protocol database, you'd replace the linked list with a simple
>> hashtable, hashed by protocol. Something as simple as LIST_ENTRY
>> mProtocolHashtable[64]; would probably be enough to fan out most of
>>
On 1/10/24 22:50, Pedro Falcato wrote:
> On Wed, Jan 10, 2024 at 1:45 PM Laszlo Ersek
> wrote:
>>
>> (+ Andrew)
>>
>> On 1/10/24 14:09, Laszlo Ersek wrote:
>>
>>> I think that keeping the depex section read-only is valuable, so I'd
>>> rule out #2. I'd also not start with option #1 -- copying the
On Wed, Jan 10, 2024 at 1:45 PM Laszlo Ersek wrote:
>
> (+ Andrew)
>
> On 1/10/24 14:09, Laszlo Ersek wrote:
>
> > I think that keeping the depex section read-only is valuable, so I'd
> > rule out #2. I'd also not start with option #1 -- copying the depex to
> > heap memory, just so this
(+ Andrew)
On 1/10/24 14:09, Laszlo Ersek wrote:
> I think that keeping the depex section read-only is valuable, so I'd
> rule out #2. I'd also not start with option #1 -- copying the depex to
> heap memory, just so this optimization can succeed. I'd simply start by
> removing the optimization,
Hi,
On 1/8/24 11:11, Nhi Pham via groups.io wrote:
> Hi Ard, all,
>
> Could you please help explain how the depex section in an image is
> mapped in terms of memory attribute?
>
> As my observation, dispatcher locates[1] the depex section inside the
> module image and write[2] an evaluated data
++ disc...@edk2.groups.io
On 1/8/2024 5:11 PM, Nhi Pham wrote:
> Hi Ard, all,
>
> Could you please help explain how the depex section in an image is
> mapped in terms of memory attribute?
>
> As my observation, dispatcher locates[1] the depex section inside the
> module image and write[2] an
Hi Ard, all,
Could you please help explain how the depex section in an image is
mapped in terms of memory attribute?
As my observation, dispatcher locates[1] the depex section inside the
module image and write[2] an evaluated data to the depex if necessary
for scheduled boot order. The
24 matches
Mail list logo
