[edk2-devel] question about cxl device enumeration in pci bus driver

[edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

Hi,
CXL devices are more polular.
Is there any plan to add cxl device enumeration in pci bus driver?


Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110016): https://edk2.groups.io/g/devel/message/110016
Mute This Topic: https://groups.io/mt/102173204/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: 1074 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

I think CXL device enumeration doesn't require extra logic in today's pci bus driver.
But I might be wrong. Can you list any missing logic in pci bus driver?


Thanks,
Ray
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Yoshinoya <yoshinoyatoko@163.com>
Sent: Wednesday, October 25, 2023 2:01 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Subject: [edk2-devel] question about cxl device enumeration in pci bus driver

Hi,
CXL devices are more polular.
Is there any plan to add cxl device enumeration in pci bus driver?

Thanks



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110032): https://edk2.groups.io/g/devel/message/110032
Mute This Topic: https://groups.io/mt/102173204/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3182 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Hi, Ray:
For example:
CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.


Thanks


















At 2023-10-25 18:13:57, "Ni, Ray" <ray.ni@intel.com> wrote:

I think CXL device enumeration doesn't require extra logic in today's pci bus driver.
But I might be wrong. Can you list any missing logic in pci bus driver?




Thanks,
Ray
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Yoshinoya <yoshinoyatoko@163.com>
Sent: Wednesday, October 25, 2023 2:01 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Subject: [edk2-devel] question about cxl device enumeration in pci bus driver
 
Hi,
CXL devices are more polular.
Is there any plan to add cxl device enumeration in pci bus driver?


Thanks


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110069): https://edk2.groups.io/g/devel/message/110069
Mute This Topic: https://groups.io/mt/102173204/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: 3813 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Gerd Hoffmann]

On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:

> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.

Point being?  Can or should the firmware do anything useful with
the CXL hardware?  If so, what exactly and why?

Current state of affairs is that the PCI stack does the usual PCI
initialization (enumerate, assign resources to PCI bars) and leaves
everything else to the OS.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110081): https://edk2.groups.io/g/devel/message/110081
Mute This Topic: https://groups.io/mt/102173204/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Laszlo Ersek]

On 10/26/23 10:33, Gerd Hoffmann wrote:
> On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
> 
>> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.
> 
> Point being?  Can or should the firmware do anything useful with
> the CXL hardware?  If so, what exactly and why?
> 
> Current state of affairs is that the PCI stack does the usual PCI
> initialization (enumerate, assign resources to PCI bars) and leaves
> everything else to the OS.

(I don't know what "HDM Config" stands for.)

The only utility for driving CXL devices from the firmware could be, AFAICT:

- booting off of such a device (or at least "supporting OS boot" in some
manner)

- using such a device for UEFI console purposes

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110085): https://edk2.groups.io/g/devel/message/110085
Mute This Topic: https://groups.io/mt/102173204/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Jonathan Cameron via groups.io]

On Thu, 26 Oct 2023 11:49:28 +0200
"Laszlo Ersek" <lersek@redhat.com> wrote:

> On 10/26/23 10:33, Gerd Hoffmann wrote:
> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
> >   
> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
> > 
> > Point being?  Can or should the firmware do anything useful with
> > the CXL hardware?  If so, what exactly and why?
> > 
> > Current state of affairs is that the PCI stack does the usual PCI
> > initialization (enumerate, assign resources to PCI bars) and leaves
> > everything else to the OS.  
> 
> (I don't know what "HDM Config" stands for.)
> 
> The only utility for driving CXL devices from the firmware could be, AFAICT:
> 
> - booting off of such a device (or at least "supporting OS boot" in some
> manner)
> 
> - using such a device for UEFI console purposes

There are different models for how to use CXL devices and what's possible depends on the
version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
EDK2 platform logic basically has to do everything.

The one mostly expected for early CXL servers, for backwards compatibility, makes
setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
components in the path to memory + locking them down an EDK2 problem.  They are then
presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
Idea being that an old OS will be fine with that and doesn't have to be CXL aware
at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
config space to get the magic numbers needed to compute HMAT.

The other model is to do very little in EDK2 and make entirely a problem for the OS.
The logic is necessary anyway if you want to support hotplug etc, so use it for the
cold plug paths 2.  That's all we've currently supported on QEMU.

There was a presentation at Linux Plumbers last year on some out of tree support
from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
https://lpc.events/event/16/contributions/1254/
But I guess it never went upstream.
https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3

+CC Sayanta

Jonathan
> 
> Laszlo
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110100): https://edk2.groups.io/g/devel/message/110100
Mute This Topic: https://groups.io/mt/102173204/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 3450 bytes --]

Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could match these describes with standard UEFI BIOS Boot flow, such as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks
















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" <jonathan.cameron=huawei.com@groups.io> wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek" <lersek@redhat.com> wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>components in the path to memory + locking them down an EDK2 problem.  They are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110162): https://edk2.groups.io/g/devel/message/110162
Mute This Topic: https://groups.io/mt/102173204/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: 5837 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]




Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks
















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" <jonathan.cameron=huawei.com@groups.io> wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek" <lersek@redhat.com> wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>components in the path to memory + locking them down an EDK2 problem.  They are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110163): https://edk2.groups.io/g/devel/message/110163
Mute This Topic: https://groups.io/mt/102173204/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: 6060 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]

I am not sure which driver is responsible for producing the ACPI tables.

+ Foster


Thanks,
Ray
________________________________
From: Yoshinoya <yoshinoyatoko@163.com>
Sent: Friday, October 27, 2023 9:29 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: jonathan.cameron@huawei.com <jonathan.cameron@huawei.com>; Laszlo Ersek <lersek@redhat.com>; kraxel@redhat.com <kraxel@redhat.com>; Ni, Ray <ray.ni@intel.com>; Sayanta Pattanayak <sayanta.pattanayak@arm.com>
Subject: Re:Re: [edk2-devel] question about cxl device enumeration in pci bus driver



Hi,
Thanks for reply!

I download code from this git https://github.com/SayantaP-arm/edk2-platforms/

For this ARM edk2 sample package, it provided cxldxe driver which being executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.

Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.

Thanks






At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" <jonathan.cameron=huawei.com@groups.io> wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek" <lersek@redhat.com> wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.
>> >
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> >
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.
>>
>> (I don't know what "HDM Config" stands for.)
>>
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>>
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>>
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>components in the path to memory + locking them down an EDK2 problem.  They are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>>
>> Laszlo
>>
>>
>>
>>
>>
>>
>
>
>
>
>





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110191): https://edk2.groups.io/g/devel/message/110191
Mute This Topic: https://groups.io/mt/102173204/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 8130 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 3900 bytes --]

Hi,
I have a question about cxl memory device hot-plug.


For example:
1. When cold boot, the platform has only 512GB cxl type-3 memory
2. During OS runtime, user hot-plug another cxl type-3  memory device expanding to 1TB.


So, how did OS identify another 512GB space newly added without a reboot?


Could anyone help to explain the procedure draftly?



Thanks










在 2023-10-27 09:29:31，"Yoshinoya" <yoshinoyatoko@163.com> 写道：




Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks
















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" <jonathan.cameron=huawei.com@groups.io> wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek" <lersek@redhat.com> wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>components in the path to memory + locking them down an EDK2 problem.  They are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110747): https://edk2.groups.io/g/devel/message/110747
Mute This Topic: https://groups.io/mt/102173204/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: 7241 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Brian J. Johnson]

[-- Attachment #1: Type: text/plain, Size: 5786 bytes --]

I see a long discussion on lore.kernel.org:

https://lore.kernel.org/linux-cxl/BYAPR12MB3336F5ADDEDBB6245BC2B48DBD489@BYAPR12MB3336.namprd12.prod.outlook.com/T/

This document also has some info on how CXL hotplug is handled:

https://cdrdv2-public.intel.com/643805/643805_CXL%20Memory%20Device%20SW%20Guide_Rev1p0.pdf

*Brian J. Johnson
*Enterprise X86 Lab

Hewlett Packard Enterprise

------------------------------------------------------------------------
*From:* Yoshinoya [mailto:yoshinoyatoko@163.com]
*Sent:* Monday, November 6, 2023 at 5:20 AM
*To:* devel@edk2.groups.io
*Cc:* jonathan.cameron@huawei.com, Laszlo Ersek <lersek@redhat.com>, 
kraxel@redhat.com, Ni, Ray <ray.ni@intel.com>, Sayanta Pattanayak 
<sayanta.pattanayak@arm.com>
*Subject:* [edk2-devel] question about cxl device enumeration in pci bus 
driver

> Hi,
> I have a question about cxl memory device hot-plug.
>
> For example:
> 1. When cold boot, the platform has only 512GB cxl type-3 memory
> 2. During OS runtime, user hot-plug another cxl type-3  memory device 
> expanding to 1TB.
>
> So, how did OS identify another 512GB space newly added without a reboot?
>
> Could anyone help to explain the procedure draftly?
>
> Thanks
>
>
>
>
> 在 2023-10-27 09:29:31，"Yoshinoya" <yoshinoyatoko@163.com> 写道：
>
>
>         Hi,
>         Thanks for reply!
>
>         I download code from this git
>         https://github.com/SayantaP-arm/edk2-platforms/
>
>         For this ARM edk2 sample package, it provided cxldxe driver
>         which being executed after UEFI DXE PciBus enumeration finishes.
>         This ppt (https://lpc.events/event/16/contributions/1254/
>         <https://lpc.events/event/16/contributions/1254/>)
>         describes good.
>
>         Intel also provied a CXL Type 3 memory device software guide.
>         This guide also describes system firmware boot sequence and
>         uefi boot sequence.
>         But i could not match these describes with standard UEFI BIOS
>         Boot flow, such as dxe phase's standard pci enumeration driver.
>         It sees needing add some cxl discovery code into dxe pci bus
>         driver.
>
>         Thanks
>
>
>
>
>
>         At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io"<jonathan.cameron=huawei.com@groups.io>  wrote:
>         >On Thu, 26 Oct 2023 11:49:28 +0200
>         >"Laszlo Ersek" <lersek@redhat.com>  wrote:
>         >
>         >> On 10/26/23 10:33, Gerd Hoffmann wrote:
>         >> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>         >> >   
>         >> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
>         >> > 
>         >> > Point being?  Can or should the firmware do anything useful with
>         >> > the CXL hardware?  If so, what exactly and why?
>         >> > 
>         >> > Current state of affairs is that the PCI stack does the usual PCI
>         >> > initialization (enumerate, assign resources to PCI bars) and leaves
>         >> > everything else to the OS.  
>         >> 
>         >> (I don't know what "HDM Config" stands for.)
>         >> 
>         >> The only utility for driving CXL devices from the firmware could be, AFAICT:
>         >> 
>         >> - booting off of such a device (or at least "supporting OS boot" in some
>         >> manner)
>         >> 
>         >> - using such a device for UEFI console purposes
>         >
>         >There are different models for how to use CXL devices and what's possible depends on the
>         >version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>         >EDK2 platform logic basically has to do everything.
>         >
>         >The one mostly expected for early CXL servers, for backwards compatibility, makes
>         >setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>         >components in the path to memory + locking them down an EDK2 problem.  They are then
>         >presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>         >Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>         >at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>         >config space to get the magic numbers needed to compute HMAT.
>         >
>         >The other model is to do very little in EDK2 and make entirely a problem for the OS.
>         >The logic is necessary anyway if you want to support hotplug etc, so use it for the
>         >cold plug paths 2.  That's all we've currently supported on QEMU.
>         >
>         >There was a presentation at Linux Plumbers last year on some out of tree support
>         >from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>         >https://lpc.events/event/16/contributions/1254/  <https://lpc.events/event/16/contributions/1254/>
>         >But I guess it never went upstream.
>         >https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>         >
>         >+CC Sayanta
>         >
>         >Jonathan
>         >> 
>         >> Laszlo
>         >> 
>         >> 
>         >> 
>         >> 
>         >> 
>         >> 
>         >
>         >
>         >
>         >
>         >
>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110877): https://edk2.groups.io/g/devel/message/110877
Mute This Topic: https://groups.io/mt/102173204/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: 12817 bytes --]

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]

Hi, Brian:
Thanks.
That is helpful.


It seems cxl device hot-plug feature depends on pcie bus native hot plug feature.
Not need bios asl code or smm handler code attends it.
OS kernel will cover all procedure.
















At 2023-11-08 05:54:01, "Brian J. Johnson" <brian.johnson@hpe.com> wrote:

I see a long discussion on lore.kernel.org:


https://lore.kernel.org/linux-cxl/BYAPR12MB3336F5ADDEDBB6245BC2B48DBD489@BYAPR12MB3336.namprd12.prod.outlook.com/T/


This document also has some info on how CXL hotplug is handled:


https://cdrdv2-public.intel.com/643805/643805_CXL%20Memory%20Device%20SW%20Guide_Rev1p0.pdf



Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise



From: Yoshinoya [mailto:yoshinoyatoko@163.com]
Sent: Monday, November 6, 2023 at 5:20 AM
To:devel@edk2.groups.io
Cc:jonathan.cameron@huawei.com, Laszlo Ersek <lersek@redhat.com>, kraxel@redhat.com, Ni, Ray <ray.ni@intel.com>, Sayanta Pattanayak <sayanta.pattanayak@arm.com>
Subject: [edk2-devel] question about cxl device enumeration in pci bus driver


Hi,
I have a question about cxl memory device hot-plug.


For example:
1. When cold boot, the platform has only 512GB cxl type-3 memory
2. During OS runtime, user hot-plug another cxl type-3  memory device expanding to 1TB.


So, how did OS identify another 512GB space newly added without a reboot?


Could anyone help to explain the procedure draftly?



Thanks










在 2023-10-27 09:29:31，"Yoshinoya" <yoshinoyatoko@163.com> 写道：




Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" <jonathan.cameron=huawei.com@groups.io> wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek" <lersek@redhat.com> wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
>components in the path to memory + locking them down an EDK2 problem.  They are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111333): https://edk2.groups.io/g/devel/message/111333
Mute This Topic: https://groups.io/mt/102173204/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: 13348 bytes --]

[edk2-devel] Use dynamic pcd in smm mode

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Hi, All:
Could dynamic PCD be used in smm driver code?


It seems pcd has pei/dxe drivers, but not have smm related infrastructur drivers.


Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110842): https://edk2.groups.io/g/devel/message/110842
Mute This Topic: https://groups.io/mt/102440663/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: 1149 bytes --]

Re: [edk2-devel] Use dynamic pcd in smm mode

[Laszlo Ersek]

On 11/7/23 12:31, Yoshinoya wrote:
> Hi, All:
> Could dynamic PCD be used in smm driver code?
> 
> It seems pcd has pei/dxe drivers, but not have smm related infrastructur
> drivers.

Dynamic PCDs (or more generally, DXE protocols) can be used in the entry
point functions of DXE_SMM_DRIVER modules, to my understanding. Dynamic
PCDs can't be used in any SMM services (callbacks, protocol member
functions, SMI handlers, etc) that those modules provide (i.e., dynamic
PCDs can't be used after the entry point function has returned).

I'm not sure about MM_STANDALONE modules. The PI spec probably explains
the environment in which the entry points of those modules are invoked.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110848): https://edk2.groups.io/g/devel/message/110848
Mute This Topic: https://groups.io/mt/102440663/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Use dynamic pcd in smm mode

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Hi, Laszlo:
Got it.


Thanks a lot!


I study the udk code, and find there are no smm pcd drivers, so can't use dynamic pcd in smm code.

















At 2023-11-07 20:45:16, "Laszlo Ersek" <lersek@redhat.com> wrote:
>On 11/7/23 12:31, Yoshinoya wrote:
>> Hi, All:
>> Could dynamic PCD be used in smm driver code?
>> 
>> It seems pcd has pei/dxe drivers, but not have smm related infrastructur
>> drivers.
>
>Dynamic PCDs (or more generally, DXE protocols) can be used in the entry
>point functions of DXE_SMM_DRIVER modules, to my understanding. Dynamic
>PCDs can't be used in any SMM services (callbacks, protocol member
>functions, SMI handlers, etc) that those modules provide (i.e., dynamic
>PCDs can't be used after the entry point function has returned).
>
>I'm not sure about MM_STANDALONE modules. The PI spec probably explains
>the environment in which the entry points of those modules are invoked.
>
>Laszlo
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110950): https://edk2.groups.io/g/devel/message/110950
Mute This Topic: https://groups.io/mt/102440663/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: 2248 bytes --]

[edk2-devel] question about PrmPkg

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

Hi,
I find there is a PrmPkg in udk source code.
Based on its Readme.md, its goal is to offload smm code to sci os mechanisms.


So, is there any actual use case on real platform now?


It seems it's just a conceptional prototype.


Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111334): https://edk2.groups.io/g/devel/message/111334
Mute This Topic: https://groups.io/mt/102640402/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: 1331 bytes --]

Re: [edk2-devel] question about PrmPkg

[Laszlo Ersek]

On 11/17/23 03:15, Yoshinoya wrote:
> Hi,
> I find there is a PrmPkg in udk source code.
> Based on its Readme.md, its goal is to offload smm code to sci os
> mechanisms.
> 
> So, is there any actual use case on real platform now?
> 
> It seems it's just a conceptional prototype.

It's way too big for it to be unused.

The original BZ was <https://bugzilla.tianocore.org/show_bug.cgi?id=3812>.

I'm sure Microsoft uses it in production. Client code for this
infrastructure may be present in Project Mu (I didn't try to check), or
in proprietary repositories. Perhaps Michael (CC'd) can share some details.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111341): https://edk2.groups.io/g/devel/message/111341
Mute This Topic: https://groups.io/mt/102640402/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] question about PrmPkg

[Michael Kubacki]

On 11/17/2023 3:42 AM, Laszlo Ersek wrote:
> On 11/17/23 03:15, Yoshinoya wrote:
>> Hi,
>> I find there is a PrmPkg in udk source code.
>> Based on its Readme.md, its goal is to offload smm code to sci os
>> mechanisms.
>>
>> So, is there any actual use case on real platform now?
>>
>> It seems it's just a conceptional prototype.
> 
> It's way too big for it to be unused.
> 
> The original BZ was <https://bugzilla.tianocore.org/show_bug.cgi?id=3812>.
> 
> I'm sure Microsoft uses it in production. Client code for this
> infrastructure may be present in Project Mu (I didn't try to check), or
> in proprietary repositories. Perhaps Michael (CC'd) can share some details.
> 
I can't speak to how it is being used everywhere but it is used in 
production. Other vendors have been involved (at least at various points 
in time).

The ACPI 6.4 spec reserved the PRMT table signature. The ACPI 6.5 spec 
defined the _SB._OSC bit for an OS to declare PRM compatibility and 
define a PRM OpRegion identifier. Support has been in iasl since 20200528.

The PRM spec is on uefi.org. I believe this was ultimately pushed there 
by Intel.

https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf

It was added to edk2 to provide code for specifications on uefi.org, 
make it available to vendors that do not use Mu but use it, and 
similarly, in response to interest from others.

The Code in PrmPkg is infrastructure to support loading custom handlers 
so it is not expected to receive a large amount of churn.

> Laszlo
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111401): https://edk2.groups.io/g/devel/message/111401
Mute This Topic: https://groups.io/mt/102640402/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] question about PrmPkg

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

Hi, Michael:
Got it.


It seems linux kernel has introduced PRMT support default.
And ARM vendors usually use this PRMT mechnism.


So how aout x86 platform?
Does Win11 have supported PRMT on any X86 platform?




best wishes,











At 2023-11-18 00:04:26, "Michael Kubacki" <mikuback@linux.microsoft.com> wrote:
>On 11/17/2023 3:42 AM, Laszlo Ersek wrote:
>> On 11/17/23 03:15, Yoshinoya wrote:
>>> Hi,
>>> I find there is a PrmPkg in udk source code.
>>> Based on its Readme.md, its goal is to offload smm code to sci os
>>> mechanisms.
>>>
>>> So, is there any actual use case on real platform now?
>>>
>>> It seems it's just a conceptional prototype.
>> 
>> It's way too big for it to be unused.
>> 
>> The original BZ was <https://bugzilla.tianocore.org/show_bug.cgi?id=3812>.
>> 
>> I'm sure Microsoft uses it in production. Client code for this
>> infrastructure may be present in Project Mu (I didn't try to check), or
>> in proprietary repositories. Perhaps Michael (CC'd) can share some details.
>> 
>I can't speak to how it is being used everywhere but it is used in 
>production. Other vendors have been involved (at least at various points 
>in time).
>
>The ACPI 6.4 spec reserved the PRMT table signature. The ACPI 6.5 spec 
>defined the _SB._OSC bit for an OS to declare PRM compatibility and 
>define a PRM OpRegion identifier. Support has been in iasl since 20200528.
>
>The PRM spec is on uefi.org. I believe this was ultimately pushed there 
>by Intel.
>
>https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf
>
>It was added to edk2 to provide code for specifications on uefi.org, 
>make it available to vendors that do not use Mu but use it, and 
>similarly, in response to interest from others.
>
>The Code in PrmPkg is infrastructure to support loading custom handlers 
>so it is not expected to receive a large amount of churn.
>
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111433): https://edk2.groups.io/g/devel/message/111433
Mute This Topic: https://groups.io/mt/102640402/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: 4081 bytes --]

Re: [edk2-devel] question about PrmPkg

[Michael Kubacki]

On 11/19/2023 9:09 PM, Yoshinoya wrote:
> Hi, Michael:
> Got it.
> 
> It seems linux kernel has introduced PRMT support default.
> And ARM vendors usually use this PRMT mechnism.
> 
> So how aout x86 platform?
> Does Win11 have supported PRMT on any X86 platform?
> 
Yes, support is available in Windows 11 and Windows Server 2022.

I requested open source Windows driver sample code to be made available 
here https://github.com/microsoft/Windows-driver-samples/issues/921.

> 
> best wishes,
> 
> 
> 
> 
> 
> At 2023-11-18 00:04:26, "Michael Kubacki" <mikuback@linux.microsoft.com> wrote:
>>On 11/17/2023 3:42 AM, Laszlo Ersek wrote:
>>> On 11/17/23 03:15, Yoshinoya wrote:
>>>> Hi,
>>>> I find there is a PrmPkg in udk source code.
>>>> Based on its Readme.md, its goal is to offload smm code to sci os
>>>> mechanisms.
>>>>
>>>> So, is there any actual use case on real platform now?
>>>>
>>>> It seems it's just a conceptional prototype.
>>> 
>>> It's way too big for it to be unused.
>>> 
>>> The original BZ was <https://bugzilla.tianocore.org/show_bug.cgi?id=3812>.
>>> 
>>> I'm sure Microsoft uses it in production. Client code for this
>>> infrastructure may be present in Project Mu (I didn't try to check), or
>>> in proprietary repositories. Perhaps Michael (CC'd) can share some details.
>>> 
>>I can't speak to how it is being used everywhere but it is used in 
>>production. Other vendors have been involved (at least at various points 
>>in time).
>>
>>The ACPI 6.4 spec reserved the PRMT table signature. The ACPI 6.5 spec 
>>defined the _SB._OSC bit for an OS to declare PRM compatibility and 
>>define a PRM OpRegion identifier. Support has been in iasl since 20200528.
>>
>>The PRM spec is on uefi.org. I believe this was ultimately pushed there 
>>by Intel.
>>
>>https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf
>>
>>It was added to edk2 to provide code for specifications on uefi.org, 
>>make it available to vendors that do not use Mu but use it, and 
>>similarly, in response to interest from others.
>>
>>The Code in PrmPkg is infrastructure to support loading custom handlers 
>>so it is not expected to receive a large amount of churn.
>>
>>> Laszlo
>>> 
>>> 
>>> 
>>> 
>>> 
>>
>>
>>
>>
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111481): https://edk2.groups.io/g/devel/message/111481
Mute This Topic: https://groups.io/mt/102640402/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Question about SMM code privilege switch

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hi,I found smm code privilege switch sample code in project mu.For example : switch ring0 to ring3 through tss gate call.So, is there any plan to introduce it to udk smm sample code?

Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116017): https://edk2.groups.io/g/devel/message/116017
Mute This Topic: https://groups.io/mt/104600076/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: 1288 bytes --]

[edk2-devel] Question about SMM code privilege switch

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hi,I found smm code privilege switch sample code in project mu.For example : switch ring0 to ring3 through tss gate call.So, is there any plan to introduce it to udk smm sample code?

Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116296): https://edk2.groups.io/g/devel/message/116296
Mute This Topic: https://groups.io/mt/104600076/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: 1497 bytes --]

[edk2-devel] What PTSS abbreviation means

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Hello

I find some data struct's name has PTSS abbreviation in KabylakeOpenBoardPkg.

So, what does PTSS mean?




Thanks




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119125): https://edk2.groups.io/g/devel/message/119125
Mute This Topic: https://groups.io/mt/106255754/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: 2595 bytes --]

[edk2-devel] sctpackage failed to be compile with new udk codebase

[Yoshinoya]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Hi,
I tried to compile sctpkg with latest udk codebase, but failed.


Has somebody meet same question?


Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115112): https://edk2.groups.io/g/devel/message/115112
Mute This Topic: https://groups.io/mt/104173023/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: 1113 bytes --]