Date   

Re: [EXTERNAL] Re: [edk2-discuss] [EXTERNAL] Re: [edk2-discuss] ESRT in OVMF

Tomas Pilar (tpilar)
 

HI Sandeep,

The EsrtDxe provides an API to add ESRT entries manually, you could
instrument that in SfcNicDriver actually - during controller binding check
if gEsrtManagementProtocolGuid is installed and if so, use the protocol to
add an entry for the FMP that you just installed. The EsrtFmpDxe is a
driver that enumerates all FMP instances and automatically generates ESRT
entries based on that. If it hangs there is a good chance that the
EsrtFmpDxe driver is hanging at the point when an FMP instance has been
just installed and an ESRT entry is being generated. The hang might have
something to do with the specific instance of the FMP. You could test this
by running OVMF with EsrtFmpDxe included but not passing in any devices
that install FMP instances.

Cheers,
Tom

On Thu, Jul 30, 2020 at 12:55 PM Sandeep Dhanvada <
sandeep.dhanvada@...> wrote:

Hi Tom,

I tried MdeModulePkg/Universal/EsrtFmpDxe, but booting hanged at selecting
Boot option.
I then used, MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf. There are no
issues observed in boot, but, still i am not able to update capsule.
CapsuleApp.efi was complaining that update image failed with status as
"Not Ready". Looks like QueryCapsule succeeded, but, UpdateCapsule failed.

Thanks,
Sandeep


Re: About HTTP boot

Laszlo Ersek
 

On 07/30/20 09:05, Juliana Rodrigueiro wrote:
Hi all!

I would like to ask the community about a way to automatically use HTTP
boot in a QEMU VM using OVMF.

Currently I can set the network interface to be the first in the boot
order, then when booting the machine I manually trigger the firmware
setup and change the network boot options positioning HTTP ipv4 in the
first position. In the next boot, the machine goes straight to HTTP boot
(No PXE boot was triggered, as desired).

Could anyone tell me if it is possible to perform such actions in the
command line (maybe with qemu-system-x86_64)? Or with the libvirt xml
description?

Please let me know if this is the wrong mailing list to ask.
This is certainly the right mailing list to ask on; sorry about the
delay (I didn't get a notification email about your message pending
moderation -- but now further messages from you should go through directly).

So, two points:


(1) Use the "bootindex" device property for placing the virtual NIC at
the front of the UEFI boot order. Do not use the "-boot order" option;
instead use:

-device virtio-net-pci,...,bootindex=1

the "bootindex=1" property is relevant (the value 1 is not critical,
just make sure nothing else has a lower bootindex value).

In the libvirt domain XML, this is handled automatically; just use the
<boot order='1'/> child element in the <interface type='network'> element.


(2) For prioritizing HTTP(S) boot over PXE boot, we have rudimentary
support at this moment. It is currently available on the QEMU command
line, and not integrated well into libvirt.

(You can still use it with the <qemu:arg> element in the domain XML of
course, like some other QEMU swithes. Just know that <qemu:arg> causes
some virt vendors to taint your domain as "unsupportable".)

So, the feature was implemented in:

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

The idea is to disable both PXEv4 and PXEv6, while keeping the NIC at
the front of the UEFI boot order. This will effectively let you attempt
HTTP boot at once. The QEMU options are (use both at the same time):

-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=n \
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=n \

In the domain XML, this amounts to:

<domain type='kvm'
xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<qemu:commandline>
<qemu:arg value='-fw_cfg'/>
<qemu:arg value='name=opt/org.tianocore/IPv4PXESupport,string=n'/>
<qemu:arg value='-fw_cfg'/>
<qemu:arg value='name=opt/org.tianocore/IPv6PXESupport,string=n'/>
</qemu:commandline>
</domain>


Important: do not forget adding the "xmlns:qemu" namespace definition to
the root element of the XML (that is, to <domain>):

xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'

otherwise the <qemu:commandline> and <qemu:arg> elements will have no
meaning, and libvirt will strip them immediately and silently (as soon
as "virsh edit" or "virsh define" completes).

Hope this helps,
Laszlo


Re: OptionROM driver update failing in UEFI 2.4 but works on UEFI 2.3.1

Laszlo Ersek
 

+Andrew:

On 07/27/20 11:57, UdayS via groups.io wrote:
Hi All,
SW Revision updates to my Option Rom/Driver is handled properly during the EntryPoint i.e., using component name to get the revision info and if existing version is older than current, then UninstallMultipleProtocolInterfaces and unloadImage.
This seem to work in UEFI 2.3.1 but when I test the same SW in UEFI 2.4 based system, it goes for a hang.
I have been banging my around this for last couple for days and now I am in need of some expert advice.
All suggestions are welcome..
Andrew, do you recall changes related to driver dispatch between 2.3.1
and 2.4? Not necessarily in the spec, but maybe in edk2.

Thanks
Laszlo


Re: Help on ACPI events reported to OS

Laszlo Ersek
 

+Igor, some comments below

On 07/27/20 10:15, Kumar G wrote:
Hi Experts,

I am moving from device tree world to acpi. I found the event notification
feature of acpi table interesting.

I have some questions over notification
- Is some hardware can generate events and notify OS by its own ?(if yes ,
please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to
execution of Notify function of acpi table
My (rusty) understanding is that hardware signals the OS with "general
purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General
Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE
handlers in ACPI parse the event, and invoke the proper OS functionality
via Notify().

So basically the hardware only tells the OS via SCI that "something ACPI
happened". The OS passes this to ACPI for handling (GPE handlers), which
in turn dispatch the event back to the proper OS handler, via Notify().

- Is this correct acpi tables are static piece of code, having no
thread/execution context, All execution in done from OS
No, this is not correct. AML methods can run in parallel, they can (and
need to) do explicit locking (there are ASL primitives for this). AML
methods have local variables, but they also operate on global objects in
the ACPI namespace (operation regions, device registers, ...) so
serialization in ACPI is important, if multiple hardware events can
occur concurrently.

Thanks
Laszlo



Thanks
Kumar G




sorry about delayed moderation

Laszlo Ersek
 

Hi Discuss List,

I'm *still* not getting moderation requests (notification emails) for
edk2-discuss, only edk2-devel. That's the reason some messages to
edk2-discuss have been stuck for a few days again. Sorry.

Laszlo


Re: [EXTERNAL] Re: [edk2-discuss] ESRT in OVMF

Sandeep Dhanvada
 

Hi Tom,

I tried MdeModulePkg/Universal/EsrtFmpDxe, but booting hanged at selecting Boot option.
I then used, MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf. There are no issues observed in boot, but, still i am not able to update capsule.
CapsuleApp.efi was complaining that update image failed with status as "Not Ready". Looks like QueryCapsule succeeded, but, UpdateCapsule failed.

Thanks,
Sandeep


About HTTP boot

Juliana Rodrigueiro <juliana.rodrigueiro@...>
 

Hi all!

I would like to ask the community about a way to automatically use HTTP
boot in a QEMU VM using OVMF.

Currently I can set the network interface to be the first in the boot
order, then when booting the machine I manually trigger the firmware
setup and change the network boot options positioning HTTP ipv4 in the
first position. In the next boot, the machine goes straight to HTTP boot
(No PXE boot was triggered, as desired).

Could anyone tell me if it is possible to perform such actions in the
command line (maybe with qemu-system-x86_64)? Or with the libvirt xml
description?

Please let me know if this is the wrong mailing list to ask.

Thank you!
Juliana.


Re: Help on ACPI events reported to OS

Kumar G <kumarg27061979@...>
 

Help please
Thanks


On Mon, 27 Jul 2020 at 13:45, Kumar G <kumarg27061979@...> wrote:
Hi Experts,

I am moving from device tree world to acpi. I found the event notification feature of acpi table interesting.

I have some questions over notification
-  Is some hardware can generate events and notify OS by its own ?(if yes , please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to execution of Notify function of acpi table

- Is this correct acpi tables are static piece of code, having no thread/execution context, All execution in done from OS 


Thanks
Kumar G


Re: ESRT in OVMF

Peter Jones <pjones@...>
 

On Wed, Jul 29, 2020 at 11:52:42AM +0200, Laszlo Ersek wrote:
Hello Sandeep,

On 07/29/20 05:03, Sandeep Dhanvada wrote:
Hi,

I am trying to test capsule based FMP device upgrade in OVMF.
This is out of scope for the current OvmfPkg platforms.

Clearly I'm not saying that capsule updates "should not" be supported by
OVMF "ever", all I'm saying is that for such use cases, a new OvmfPkg
platform DSC will be necessary.

(If the intent with the capsule update is to upgrade the firmware add-on
devices *only*, that is, not the platform firmware itself, then *maybe*
the current OVMF DSC files could accommodate that, introducing a new
(default-off) build feature flag. I'm not sure.)

Mike Kinney and Peter Jones have done some work around capsule updates
in OVMF; I'm CC'ing them. Perhaps you can use their results for your
experiments.
I have a couple of ancient branches in various states of disrepair that
were used as part of an API tester at one point. It's from before FMP
was really driving anything and before the ESRT data structures were
fully pushed to edk2, and such they are clearly well unmaintained and
have totally rotted, but if there's any chance they help at all, they're
at:

https://github.com/vathpela/edk2/tree/fake-capsule
https://github.com/vathpela/edk2/tree/fake-capsule-0
https://github.com/vathpela/edk2/tree/fake-capsule-1

Thanks
Laszlo

I have a PCI NIC Adapter with PCI Passthrough enabled and need to
upgrade firmware for this NIC in ovmf. I generated capsule file with
embedded driver as FMP driver and payload as option ROM image.

I tried CapsuleApp.efi from OVMF Shell and also fwupdate tool from
Linux.

Below is the observation with CapsuleApp.efi:
1. "CapsuleApp.efi -E" command from ovmf shell, but, it is not displaying any entries.
2. "CapsuleApp.efi -D <CapsuleFile>" is showing Capsule Header, Fmp Header and Fmp Payload Image Header properly.

Below is the observation with fwupdate tool in Linux:
1. CONFIG_EFI_ESRT is enabled in Kernel Config.
2. /sys/firmware/efi sysfs entry is created, but, there is no esrt entry under this.
3. Since there is no esrt sysfs entry, "fwupdate -s" command is showing that firmware updates are not supported.

Please let me know how to add ESRT table in OVMF so that i can upgrade device firmware.
--
Peter


OptionROM driver update failing in UEFI 2.4 but works on UEFI 2.3.1

udai sharma <udai16787@...>
 

Hi Team,
I have developed a UEFI Bus Driver, loaded it as an PCI Option ROM on PCI adapter.

Issue I am facing is with the during version updates.
In DriverSupported, SW update logic present looks for existing driver using componentname, gets its
version number and compares with the version number of current driver. If Current driver version is
better, UninstallMultipleProtocolInterfaces and UnloadImage using the HandleBuffer[index]. After
unload, EfiLibInstallAllDriverProtocols on new image handle and InstallMultipleProtocolInterfaces for
other protocols.

This update logic seem to work fine on 2.3.1 based system, but when I tested the same on 2.4 system, it
goes for a hang.

Steps followed to verify from Shell:
1. 'loadpcirom MyRom.rom' with version 1.0.
2. verify the 'dh '
3. Now try to upgrade image, 'loadpcirom MyRom.rom' with version 2.0. UnloadImage, because it is already present in the SW update logic.>
4. At this point I see DriverSupported and DriverStart logic getting called. But after that system goes
for a hang.

I am unable to figure where is the issue. Can you please guide me here.

Thanks in advance.
-US


About HTTP boot

Juliana Rodrigueiro <juliana.rodrigueiro@...>
 

Hi all!

I would like to ask the community about a way to automatically use HTTP
boot in a QEMU VM using OVMF.

Currently I can set the network interface to be the first in the boot
order, then when booting the machine I manually trigger the firmware
setup and change the network boot options positioning HTTP ipv4 in the
first position. In the next boot, the machine goes straight to HTTP boot
(No PXE boot was triggered, as desired).

Could anyone tell me if it is possible to perform such actions in the
command line (maybe with qemu-system-x86_64)? Or with the libvirt xml
description?

Please let me know if this is the wrong mailing list to ask.

Thank you!
Juliana.


OptionROM driver update failing in UEFI 2.4 but works on UEFI 2.3.1

UdayS <udai16787@...>
 

Hi All,
SW Revision updates to my Option Rom/Driver is handled properly during the EntryPoint i.e., using component name to get the revision info and if existing version is older than current, then UninstallMultipleProtocolInterfaces and unloadImage.
This seem to work in UEFI 2.3.1 but when I test the same SW in UEFI 2.4 based system, it goes for a hang.
I have been banging my around this for last couple for days and now I am in need of some expert advice.
All suggestions are welcome..

Thanks
US


Help on ACPI events reported to OS

Kumar G <kumarg27061979@...>
 

Hi Experts,

I am moving from device tree world to acpi. I found the event notification feature of acpi table interesting.

I have some questions over notification
-  Is some hardware can generate events and notify OS by its own ?(if yes , please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to execution of Notify function of acpi table

- Is this correct acpi tables are static piece of code, having no thread/execution context, All execution in done from OS 


Thanks
Kumar G


Re: ESRT in OVMF

Michael D Kinney
 

Sandeep,

I agree with Laszlo that a new DSC/FDF file would be required.

Adding full set of UEFI feature to a new DSC/FDF file would
also enable more platform tests in EDK II CI as well, so it
would be valuable for more than just the use case described
here.

It is not a large change to add ESRT/FMP support. You can look
at edk2-platforms/Platform/Intel/Vlv2TbltDevicePkg for a
working platform example.

Best regards,

Mike

-----Original Message-----
From: Peter Jones <pjones@...>
Sent: Wednesday, July 29, 2020 8:36 AM
To: Laszlo Ersek <lersek@...>
Cc: sandeep.dhanvada@...; discuss@edk2.groups.io;
Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-discuss] ESRT in OVMF

On Wed, Jul 29, 2020 at 11:52:42AM +0200, Laszlo Ersek
wrote:
Hello Sandeep,

On 07/29/20 05:03, Sandeep Dhanvada wrote:
Hi,

I am trying to test capsule based FMP device upgrade
in OVMF.

This is out of scope for the current OvmfPkg
platforms.

Clearly I'm not saying that capsule updates "should
not" be supported by
OVMF "ever", all I'm saying is that for such use
cases, a new OvmfPkg
platform DSC will be necessary.

(If the intent with the capsule update is to upgrade
the firmware add-on
devices *only*, that is, not the platform firmware
itself, then *maybe*
the current OVMF DSC files could accommodate that,
introducing a new
(default-off) build feature flag. I'm not sure.)

Mike Kinney and Peter Jones have done some work around
capsule updates
in OVMF; I'm CC'ing them. Perhaps you can use their
results for your
experiments.
I have a couple of ancient branches in various states of
disrepair that
were used as part of an API tester at one point. It's
from before FMP
was really driving anything and before the ESRT data
structures were
fully pushed to edk2, and such they are clearly well
unmaintained and
have totally rotted, but if there's any chance they help
at all, they're
at:

https://github.com/vathpela/edk2/tree/fake-capsule
https://github.com/vathpela/edk2/tree/fake-capsule-0
https://github.com/vathpela/edk2/tree/fake-capsule-1

Thanks
Laszlo

I have a PCI NIC Adapter with PCI Passthrough
enabled and need to
upgrade firmware for this NIC in ovmf. I generated
capsule file with
embedded driver as FMP driver and payload as option
ROM image.

I tried CapsuleApp.efi from OVMF Shell and also
fwupdate tool from
Linux.

Below is the observation with CapsuleApp.efi:
1. "CapsuleApp.efi -E" command from ovmf shell, but,
it is not displaying any entries.
2. "CapsuleApp.efi -D <CapsuleFile>" is showing
Capsule Header, Fmp Header and Fmp Payload Image Header
properly.

Below is the observation with fwupdate tool in
Linux:
1. CONFIG_EFI_ESRT is enabled in Kernel Config.
2. /sys/firmware/efi sysfs entry is created, but,
there is no esrt entry under this.
3. Since there is no esrt sysfs entry, "fwupdate -s"
command is showing that firmware updates are not
supported.

Please let me know how to add ESRT table in OVMF so
that i can upgrade device firmware.

--
Peter


Re: [EXTERNAL] Re: [edk2-discuss] ESRT in OVMF

Tomas Pilar (tpilar)
 

Hi Sandeep,

I suspect that if you include MdeModulePkg/Universal/EsrtFmpDxe module in
the .dsc and .fdf file that you use to build the OVMF binaries, it might
Just Work™.

Cheers,
Tom

On Wed, Jul 29, 2020 at 11:41 AM Sandeep Dhanvada <
sandeep.dhanvada@...> wrote:

Hello Laszlo,

Thanks for your inputs. I will wait for updates from Mike Kinney and Peter
Jones.

In DSC, i made the change mentioned in below patch, but still i am not
able to see ESRT table.
https://www.redhat.com/archives/edk2-devel-archive/2019-July/msg00167.html

Thanks,
Sandeep




Re: ESRT in OVMF

Sandeep Dhanvada
 

Hello Laszlo,

Thanks for your inputs. I will wait for updates from Mike Kinney and Peter Jones.

In DSC, i made the change mentioned in below patch, but still i am not able to see ESRT table.
https://www.redhat.com/archives/edk2-devel-archive/2019-July/msg00167.html

Thanks,
Sandeep


Re: ESRT in OVMF

Laszlo Ersek
 

Hello Sandeep,

On 07/29/20 05:03, Sandeep Dhanvada wrote:
Hi,

I am trying to test capsule based FMP device upgrade in OVMF.
This is out of scope for the current OvmfPkg platforms.

Clearly I'm not saying that capsule updates "should not" be supported by
OVMF "ever", all I'm saying is that for such use cases, a new OvmfPkg
platform DSC will be necessary.

(If the intent with the capsule update is to upgrade the firmware add-on
devices *only*, that is, not the platform firmware itself, then *maybe*
the current OVMF DSC files could accommodate that, introducing a new
(default-off) build feature flag. I'm not sure.)

Mike Kinney and Peter Jones have done some work around capsule updates
in OVMF; I'm CC'ing them. Perhaps you can use their results for your
experiments.

Thanks
Laszlo

I have a PCI NIC Adapter with PCI Passthrough enabled and need to upgrade firmware for this NIC in ovmf. I generated capsule file with embedded driver as FMP driver and payload as option ROM image.

I tried CapsuleApp.efi from OVMF Shell and also fwupdate tool from Linux.

Below is the observation with CapsuleApp.efi:
1. "CapsuleApp.efi -E" command from ovmf shell, but, it is not displaying any entries.
2. "CapsuleApp.efi -D <CapsuleFile>" is showing Capsule Header, Fmp Header and Fmp Payload Image Header properly.

Below is the observation with fwupdate tool in Linux:
1. CONFIG_EFI_ESRT is enabled in Kernel Config.
2. /sys/firmware/efi sysfs entry is created, but, there is no esrt entry under this.
3. Since there is no esrt sysfs entry, "fwupdate -s" command is showing that firmware updates are not supported.

Please let me know how to add ESRT table in OVMF so that i can upgrade device firmware.


ESRT in OVMF

Sandeep Dhanvada
 

Hi,

I am trying to test capsule based FMP device upgrade in OVMF. I have a PCI NIC Adapter with PCI Passthrough enabled and need to upgrade firmware for this NIC in ovmf. I generated capsule file with embedded driver as FMP driver and payload as option ROM image.

I tried CapsuleApp.efi from OVMF Shell and also fwupdate tool from Linux.

Below is the observation with CapsuleApp.efi:
1. "CapsuleApp.efi -E" command from ovmf shell, but, it is not displaying any entries.
2. "CapsuleApp.efi -D <CapsuleFile>" is showing Capsule Header, Fmp Header and Fmp Payload Image Header properly.

Below is the observation with fwupdate tool in Linux:
1. CONFIG_EFI_ESRT is enabled in Kernel Config.
2. /sys/firmware/efi sysfs entry is created, but, there is no esrt entry under this.
3. Since there is no esrt sysfs entry, "fwupdate -s" command is showing that firmware updates are not supported.

Please let me know how to add ESRT table in OVMF so that i can upgrade device firmware.

Thanks,
Sandeep


FileExplorer volume descriptions

Tim Crawford
 

Hi all,

I'm looking to modify FileExplorer to provide a more useful description of the available volumes. It currently displays the volume label and ACPI UID to identify volumes. My problem with this is:

- Volume label typically isn't set, so all volumes are listed as "NO VOLUME LABEL"
- The ACPI UID is not useful for normal end users, since they are likely not going to know which device the device path portion corresponds to, or the partition UUID for GPT disks

I'd like to modify it to include the device description, similar to how UefiBootManagerLib does for BootManagerUiLib (BmBootDescription.c). However, I haven't found any code for getting the block device for a volume. Does such a thing exist?

If not, my alternative then would seem to be to enumerate the block devices to get the descriptions and then enumerate the volumes for each block device.

Thanks,
Tim


Re: [MemoryInitPeiLib] Reason for splitting the Memory resource descriptor HOB

Pankaj Bansal
 

+ OSS email id

-----Original Message-----
From: Pankaj Bansal
Sent: Sunday, July 19, 2020 7:06 AM
To: discuss@edk2.groups.io; 'Ard Biesheuvel' <ard.biesheuvel@...>; 'Leif
Lindholm' <leif.lindholm@...>
Subject: [MemoryInitPeiLib] Reason for splitting the Memory resource
descriptor HOB

Hi Ard/Leif et al.,

I am looking into the code for declaring available system memory (RAM) from PI
phase to DXE phase.
I am not able to understand this piece of code and comments :

https://github.com/tianocore/edk2/commit/44d2e8d7cab3ee1be0cf02f604d83
3e6b75b04b2

Why do we need to split the Memory resource descriptor ?
Moreover, this doesn't affect the system because the GCD service coalesces the
adjacent entries in GCD memory map:

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gc
d/Gcd.c#L453

This would render the splitting of Memory resource descriptor of no use.
Why can't we just declare the FV region as Memory allocation Hob without
splitting ?

Regards,
Pankaj Bansal

841 - 860 of 1159