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 m
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 disp
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 d
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 tho
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 SMM
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 sam
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 look
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 evaluatin
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 pointer.
; 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 th
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 t
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 s
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 lik
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
>> the
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 optimizat
(+ 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, a
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 to
++ 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 eva
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 probl
24 matches
Mail list logo
