[PATCH v2 0/1] Fixing RngDxe error for ARM/AARCH64

[PATCH v2 0/1] Fixing RngDxe error for ARM/AARCH64

[Kun Qin]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4491

This patch series is a follow-up of previous submission:
https://edk2.groups.io/g/devel/message/91995

The main changes between v1 and v2 patches are:
  - Removed a fix which is a duplicate effort of
    https://edk2.groups.io/g/devel/message/104347
  - Added reviewed-by tag

This change is verified on QEMU based ARM SBSA system.

Patch v2 branch: https://github.com/kuqin12/edk2/tree/fix_rng_edk2_v2

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>

Kun Qin (1):
  SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

 SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c | 2 +-
 SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.41.0.windows.1

[PATCH v2 1/1] SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

[Kun Qin]

From: Kun Qin <kuqin@microsoft.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4491

mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX"
number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM".

This change fixed the buffer allocation logic by allocating a proper size
of buffer before referencing.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>

Signed-off-by: Kun Qin <kuqin@microsoft.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
---

Notes:
    v2:
    - Added reviewed-by tag [Sami]

 SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c | 2 +-
 SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
index e8be217f8a8c..e7107a0b7039 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
@@ -33,7 +33,7 @@ GetAvailableAlgorithms (
   UINT16  MinorRevision;
 
   // Rng algorithms 2 times, one for the allocation, one to populate.
-  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
+  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * sizeof (EFI_RNG_ALGORITHM));
   if (mAvailableAlgoArray == NULL) {
     return EFI_OUT_OF_RESOURCES;
   }
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
index 4b24f5c4a69b..5e621df601fb 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
@@ -32,7 +32,7 @@ GetAvailableAlgorithms (
   UINT16  MinorRevision;
 
   // Rng algorithms 2 times, one for the allocation, one to populate.
-  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
+  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * sizeof (EFI_RNG_ALGORITHM));
   if (mAvailableAlgoArray == NULL) {
     return EFI_OUT_OF_RESOURCES;
   }
-- 
2.41.0.windows.1

[edk2-devel] Does RedfishPkg support BMC Chip's lan over usb feature?

[Yoshinoya]

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

Hi,
The communication between BIOS and BMC usually is IPMI over LPC interface.
The communication also supports with IPMI over IP.


BMC chip has ability to emulate itself as a usb network card, and connected with motherboard's usb physical port.
So, current redfishpkg supports BMC chip's lan over usb feature?


Thanks


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

Re: [edk2-devel] Does RedfishPkg support BMC Chip's lan over usb feature?

[Chang, Abner]

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

[AMD Official Use Only - General]

Yes, edk2 Redfish does support BMC exposed USB NIC, as RedfishPkg relies on RestEx protocol for discovering Redfish service. The current RestEx implementation is network based, which means USB NIC would be used as the transport interface for Redfish communications between host and BMC.

Abner

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yoshinoya via groups.io
Sent: Friday, June 30, 2023 11:13 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] Does RedfishPkg support BMC Chip's lan over usb feature?

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

Hi,
The communication between BIOS and BMC usually is IPMI over LPC interface.
The communication also supports with IPMI over IP.

BMC chip has ability to emulate itself as a usb network card, and connected with motherboard's usb physical port.
So, current redfishpkg supports BMC chip's lan over usb feature?

Thanks



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

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

[Kun Qin]

Hi Sami,

Would you prefer to have input from Jiewen or Jian to review this patch 
as well?

Otherwise, would you mind helping me to merge the change?

Thanks in advance!

Regards,
Kun

On 6/29/2023 4:59 PM, Kun Qin via groups.io wrote:
> From: Kun Qin <kuqin@microsoft.com>
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4491
>
> mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX"
> number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM".
>
> This change fixed the buffer allocation logic by allocating a proper size
> of buffer before referencing.
>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Sami Mujawar <Sami.Mujawar@arm.com>
> Cc: Pierre Gondois <pierre.gondois@arm.com>
>
> Signed-off-by: Kun Qin <kuqin@microsoft.com>
> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
> ---
>
> Notes:
>      v2:
>      - Added reviewed-by tag [Sami]
>
>   SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c | 2 +-
>   SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c         | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
> index e8be217f8a8c..e7107a0b7039 100644
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
> @@ -33,7 +33,7 @@ GetAvailableAlgorithms (
>     UINT16  MinorRevision;
>
>   
>
>     // Rng algorithms 2 times, one for the allocation, one to populate.
>
> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>
> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * sizeof (EFI_RNG_ALGORITHM));
>
>     if (mAvailableAlgoArray == NULL) {
>
>       return EFI_OUT_OF_RESOURCES;
>
>     }
>
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
> index 4b24f5c4a69b..5e621df601fb 100644
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
> @@ -32,7 +32,7 @@ GetAvailableAlgorithms (
>     UINT16  MinorRevision;
>
>   
>
>     // Rng algorithms 2 times, one for the allocation, one to populate.
>
> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>
> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * sizeof (EFI_RNG_ALGORITHM));
>
>     if (mAvailableAlgoArray == NULL) {
>
>       return EFI_OUT_OF_RESOURCES;
>
>     }
>

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

[Sami Mujawar]

Hi Kun,

This patch and Pierre's series at 
https://edk2.groups.io/g/devel/message/106711 are both required to fix 
the RNG implementation for Arm.

I will wait for the MdePkg and SecurityPkg maintainers for any feedback 
by end of next week. If there are no futher comments, I will merge both 
this patch and the series at https://edk2.groups.io/g/devel/message/106711.

Regards,

Sami Mujawar

On 03/07/2023 09:09 pm, Kun Qin wrote:
> Hi Sami,
>
> Would you prefer to have input from Jiewen or Jian to review this 
> patch as well?
>
> Otherwise, would you mind helping me to merge the change?
>
> Thanks in advance!
>
> Regards,
> Kun
>
> On 6/29/2023 4:59 PM, Kun Qin via groups.io wrote:
>> From: Kun Qin <kuqin@microsoft.com>
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4491
>>
>> mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX"
>> number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM".
>>
>> This change fixed the buffer allocation logic by allocating a proper 
>> size
>> of buffer before referencing.
>>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Sami Mujawar <Sami.Mujawar@arm.com>
>> Cc: Pierre Gondois <pierre.gondois@arm.com>
>>
>> Signed-off-by: Kun Qin <kuqin@microsoft.com>
>> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
>> ---
>>
>> Notes:
>>      v2:
>>      - Added reviewed-by tag [Sami]
>>
>>   SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c | 2 +-
>>   SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c 
>> b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> index e8be217f8a8c..e7107a0b7039 100644
>> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> @@ -33,7 +33,7 @@ GetAvailableAlgorithms (
>>     UINT16  MinorRevision;
>>
>>
>>     // Rng algorithms 2 times, one for the allocation, one to populate.
>>
>> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>>
>> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * 
>> sizeof (EFI_RNG_ALGORITHM));
>>
>>     if (mAvailableAlgoArray == NULL) {
>>
>>       return EFI_OUT_OF_RESOURCES;
>>
>>     }
>>
>> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c 
>> b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> index 4b24f5c4a69b..5e621df601fb 100644
>> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> @@ -32,7 +32,7 @@ GetAvailableAlgorithms (
>>     UINT16  MinorRevision;
>>
>>
>>     // Rng algorithms 2 times, one for the allocation, one to populate.
>>
>> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>>
>> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * 
>> sizeof (EFI_RNG_ALGORITHM));
>>
>>     if (mAvailableAlgoArray == NULL) {
>>
>>       return EFI_OUT_OF_RESOURCES;
>>
>>     }
>>

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

[Sami Mujawar]

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

For some reason the reply to this thread were not linked. Please see the discussion at https://edk2.groups.io/g/devel/message/106720

Regards,

Sami Mujawar

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

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocator

[Kun Qin]

Hi Sami, Jiewen & Jian,

Just a gentle ping on this.

Could you please provide further feedback on this patch and/or merge the 
patch?

Thanks in advance!

Regards,
Kun

On 7/3/2023 1:09 PM, Kun Qin via groups.io wrote:
> Hi Sami,
>
> Would you prefer to have input from Jiewen or Jian to review this 
> patch as well?
>
> Otherwise, would you mind helping me to merge the change?
>
> Thanks in advance!
>
> Regards,
> Kun
>
> On 6/29/2023 4:59 PM, Kun Qin via groups.io wrote:
>> From: Kun Qin <kuqin@microsoft.com>
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4491
>>
>> mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX"
>> number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM".
>>
>> This change fixed the buffer allocation logic by allocating a proper 
>> size
>> of buffer before referencing.
>>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Sami Mujawar <Sami.Mujawar@arm.com>
>> Cc: Pierre Gondois <pierre.gondois@arm.com>
>>
>> Signed-off-by: Kun Qin <kuqin@microsoft.com>
>> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
>> ---
>>
>> Notes:
>>      v2:
>>      - Added reviewed-by tag [Sami]
>>
>>   SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c | 2 +-
>>   SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c 
>> b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> index e8be217f8a8c..e7107a0b7039 100644
>> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
>> @@ -33,7 +33,7 @@ GetAvailableAlgorithms (
>>     UINT16  MinorRevision;
>>
>>
>>     // Rng algorithms 2 times, one for the allocation, one to populate.
>>
>> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>>
>> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * 
>> sizeof (EFI_RNG_ALGORITHM));
>>
>>     if (mAvailableAlgoArray == NULL) {
>>
>>       return EFI_OUT_OF_RESOURCES;
>>
>>     }
>>
>> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c 
>> b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> index 4b24f5c4a69b..5e621df601fb 100644
>> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
>> @@ -32,7 +32,7 @@ GetAvailableAlgorithms (
>>     UINT16  MinorRevision;
>>
>>
>>     // Rng algorithms 2 times, one for the allocation, one to populate.
>>
>> -  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
>>
>> +  mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX * 
>> sizeof (EFI_RNG_ALGORITHM));
>>
>>     if (mAvailableAlgoArray == NULL) {
>>
>>       return EFI_OUT_OF_RESOURCES;
>>
>>     }
>>
>
>
> 
>
>

[edk2-devel] Question about OvmfPackage cxl emulation support

[Yoshinoya]

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

Hi,
I findd qemu supports cxl emulation, but it uses seabios as virtual machine firmware.


Does UEFI OvmfPackage have a plan to support CXL device enumeration and declaration?


Thanks

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

Re: [edk2-devel] Question about OvmfPackage cxl emulation support

[Laszlo Ersek]

On 10/19/23 03:51, Yoshinoya wrote:
> Hi,
> I findd qemu supports cxl emulation, but it uses seabios as virtual
> machine firmware.
> 
> Does UEFI OvmfPackage have a plan to support CXL device enumeration and
> declaration?

I expect MdeModulePkg would have to add some generic CXL device driver,
which we could perhaps include in OVMF.

Some register definitions were added to core edk2 under
<https://bugzilla.tianocore.org/show_bug.cgi?id=2611>, but I can't
easily find any CXL driver.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109798): https://edk2.groups.io/g/devel/message/109798
Mute This Topic: https://groups.io/mt/102052612/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 OvmfPackage cxl emulation support

[Yoshinoya]

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

Hi, Lersek:
Got it!


Thanks

















At 2023-10-19 19:58:52, "Laszlo Ersek" <lersek@redhat.com> wrote:
>On 10/19/23 03:51, Yoshinoya wrote:
>> Hi,
>> I findd qemu supports cxl emulation, but it uses seabios as virtual
>> machine firmware.
>> 
>> Does UEFI OvmfPackage have a plan to support CXL device enumeration and
>> declaration?
>
>I expect MdeModulePkg would have to add some generic CXL device driver,
>which we could perhaps include in OVMF.
>
>Some register definitions were added to core edk2 under
><https://bugzilla.tianocore.org/show_bug.cgi?id=2611>, but I can't
>easily find any CXL driver.
>
>Laszlo
>
>
>
>
>


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

Re: [edk2-devel] Question about OvmfPackage cxl emulation support

[Yoshinoya]

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

Hi, Lersek:
I have a question about acpi tables in OvmfPkg.


Does qemu create acpi tables template for Ovmf BIOS ?



I could not find any acpi tables template(asl files) for x86 platform in OvmfPkg. 







best wishes,




At 2023-10-21 11:50:01, "Yoshinoya" <yoshinoyatoko@163.com> wrote:

Hi, Lersek:
Got it!


Thanks

















At 2023-10-19 19:58:52, "Laszlo Ersek" <lersek@redhat.com> wrote:
>On 10/19/23 03:51, Yoshinoya wrote:
>> Hi,
>> I findd qemu supports cxl emulation, but it uses seabios as virtual
>> machine firmware.
>> 
>> Does UEFI OvmfPackage have a plan to support CXL device enumeration and
>> declaration?
>
>I expect MdeModulePkg would have to add some generic CXL device driver,
>which we could perhaps include in OVMF.
>
>Some register definitions were added to core edk2 under
><https://bugzilla.tianocore.org/show_bug.cgi?id=2611>, but I can't
>easily find any CXL driver.
>
>Laszlo
>
>
>
>
>


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

Re: [edk2-devel] Question about OvmfPackage cxl emulation support

[Gerd Hoffmann]

On Tue, Oct 24, 2023 at 02:48:33PM +0800, Yoshinoya wrote:
> Hi, Lersek:
> I have a question about acpi tables in OvmfPkg.
> 
> 
> Does qemu create acpi tables template for Ovmf BIOS ?

Yes, qemu generates the acpi tables (not just templates).
The same is true for the smbios tables.

take care,
  Gerd



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

Re: [edk2-devel] Question about OvmfPackage cxl emulation support

[Yoshinoya]

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

Hi, Gerd:
Got it!


Thanks














At 2023-10-24 16:05:06, "Gerd Hoffmann" <kraxel@redhat.com> wrote:
>On Tue, Oct 24, 2023 at 02:48:33PM +0800, Yoshinoya wrote:
>> Hi, Lersek:
>> I have a question about acpi tables in OvmfPkg.
>> 
>> 
>> Does qemu create acpi tables template for Ovmf BIOS ?
>
>Yes, qemu generates the acpi tables (not just templates).
>The same is true for the smbios tables.
>
>take care,
>  Gerd
>
>
>
>
>


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