Date   

Re: Refresh currently displayed form

Tomas Pilar (tpilar)
 

Hi,

You can add a 'refreshguid' property to a number of VFR objects. Then,
whenever you signal the event group with that guid, the object should be
refreshed by the HII Browser.

Cheers,
Tom

On Wed, Oct 28, 2020 at 1:04 PM Tim Crawford <crawfxrd@gmail.com> wrote:

Hi all,

How can I refresh the currently displayed form?

The problem I'm trying to solve is that when on the BootManager page,
insertion or removal of a device does not update the form, leaving the list
of boot options in an invalid state.

Right now I'm trying to hack in an event to accomplish this, but someone
said there may be a mechanism to do this.

Thanks,
Tim






Refresh currently displayed form

Tim Crawford
 

Hi all,

How can I refresh the currently displayed form?

The problem I'm trying to solve is that when on the BootManager page, insertion or removal of a device does not update the form, leaving the list of boot options in an invalid state.

Right now I'm trying to hack in an event to accomplish this, but someone said there may be a mechanism to do this.

Thanks,
Tim


Re: Issues with PatchCheck script

Sandeep Dhanvada
 

No. I am using Python 2.7.5.
But, in any case, the script is issuing "git show --nopatch" command and git is complaining about --no-patch


Re: Issues with PatchCheck script

Tomas Pilar (tpilar)
 

Are you using Python 3?

On Wed, Oct 28, 2020 at 11:45 AM Sandeep Dhanvada <
sandeep.dhanvada@xilinx.com> wrote:

Hi,

I have 2 local commits in EDK-II repo. As per the steps mentioned in
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
,
I am executing PatchCheck.py, but, the execution of this script is giving
below error. I see that the command used is "git show --pretty=%cn <%ce>,
--no-patch, --no-use-mailmap, <CommitID>, but, as git complains that there
is no --no-patch option for git show and also format for --pretty should be
in quotes. I tried on git version 1.8.3.1 and 2.1.1. Is there any specific
git version needed to execute this script ?

==========
python BaseTools/Scripts/PatchCheck.py -1
Checking git commit: HEAD
Traceback (most recent call last):
File "BaseTools/Scripts/PatchCheck.py", line 770, in <module>
sys.exit(PatchCheckApp().retval)
File "BaseTools/Scripts/PatchCheck.py", line 733, in __init__
self.process_one_arg('HEAD')
File "BaseTools/Scripts/PatchCheck.py", line 747, in process_one_arg
self.ok &= CheckOneArg(arg, self.count).ok
File "BaseTools/Scripts/PatchCheck.py", line 714, in __init__
checker = CheckGitCommits(param, max_count)
File "BaseTools/Scripts/PatchCheck.py", line 650, in __init__
self.ok &= EmailAddressCheck(email, 'Committer').ok
File "BaseTools/Scripts/PatchCheck.py", line 36, in __init__
self.error('Email address is missing!')
File "BaseTools/Scripts/PatchCheck.py", line 47, in error
print('The ' + self.description + ' email address is not valid:')
AttributeError: EmailAddressCheck instance has no attribute 'description'

==========


Thanks,
Sandeep






Issues with PatchCheck script

Sandeep Dhanvada
 

Hi,

I have 2 local commits in EDK-II repo. As per the steps mentioned in https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process,
I am executing PatchCheck.py, but, the execution of this script is giving below error. I see that the command used is "git show --pretty=%cn <%ce>, --no-patch, --no-use-mailmap, <CommitID>, but, as git complains that there is no --no-patch option for git show and also format for --pretty should be in quotes. I tried on git version 1.8.3.1 and 2.1.1. Is there any specific git version needed to execute this script ?

==========
python BaseTools/Scripts/PatchCheck.py -1
Checking git commit: HEAD
Traceback (most recent call last):
File "BaseTools/Scripts/PatchCheck.py", line 770, in <module>
sys.exit(PatchCheckApp().retval)
File "BaseTools/Scripts/PatchCheck.py", line 733, in __init__
self.process_one_arg('HEAD')
File "BaseTools/Scripts/PatchCheck.py", line 747, in process_one_arg
self.ok &= CheckOneArg(arg, self.count).ok
File "BaseTools/Scripts/PatchCheck.py", line 714, in __init__
checker = CheckGitCommits(param, max_count)
File "BaseTools/Scripts/PatchCheck.py", line 650, in __init__
self.ok &= EmailAddressCheck(email, 'Committer').ok
File "BaseTools/Scripts/PatchCheck.py", line 36, in __init__
self.error('Email address is missing!')
File "BaseTools/Scripts/PatchCheck.py", line 47, in error
print('The ' + self.description + ' email address is not valid:')
AttributeError: EmailAddressCheck instance has no attribute 'description'

==========


Thanks,
Sandeep


Re: [edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk

Laszlo Ersek
 

On 10/27/20 14:26, Laszlo Ersek wrote:

Now, another option (on Linux anyway) is to loop-mount a "raw" virtual
disk image. This is not recommended, as it directly exposes the host
kernel's filesystem driver(s) to metadata produced by the guest. It
could trigger security issues in the host kernel.

(This is exactly what guestfish avoids, by running a separate Linux
guest -- called the "libguestfs appliance" -- on top of the virtual disk
image. The guestfish command interpreter on the host side exchanges
commands and data with the appliance over virtio-serial. If the metadata
on the disk image is malicious, it will break / exploit the *guest*
kernel in the appliance. The host-side component, the guestfish command
interpreter, only has to sanity-check the virtio-serial exchanges.)
If you trust your guest 100%, you *might* try the following:

- use a disk image file with "format=vhdx" on the QEMU command line,

- when QEMU is not running, I think you might be able to "loop-mount"
the VHDX file directly, on Windows.

Mutual exclusion remains just as important, of course.

... A reference about vhdx support:
<https://www.qemu.org/docs/master/system/images.html#cmdoption-image-formats-arg-vhdx>.

... A reference about the pitfalls with vvfat:
<https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images>.

Thanks,
Laszlo


Re: [edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk

Laszlo Ersek
 

On 10/22/20 20:55, Sean wrote:
Laszlo and others familiar with QEMU,

I am trying to write automation that boots QEMU/OVMF and then runs EFI
applications and those efi applications then use the UEFI shell apis to
write back to the disk their state.  I am seeing very inconsistent
results with sometimes it working fine while other times the disk
contents are invalid.  If i run multiple tests it seems like the first
two work while the 3rd seems to start failing but overall it seems random.

Failing means:
    Disk contents corrupted but present.
    Disk contents wrong size (short).
    Files that show written in UEFI shell never show up on host.

I am trying to determine if this is a known limitation with QEMU or a
bug i need to track down in the unit test code.

My setup:

This is on a Windows 10 x64 host.  I am running current 5.1 version of
QEMU.

My script creates a folder in the Windows NTFS file system.  Copies the
EFI executables and startup.nsh files to it.  Then starts QEMU with the
following additional parameter.

 -drive file=fat:rw:{VirtualDrive},format=raw,media=disk
This is the problem. Don't use the fat / vvfat block driver for anything
meaningful.

I don't even have to look at particulars; as "fat" ("vvfat") is known to
be a hack. In particular write operations should not be relied on
(either guest->host or host->guest directions). Don't expect this QEMU
feature to work as a "semihosting" (esp. "live semihosting") solution.

What's important to understand about "vvfat" is that it attempts to
*re-compose* a filesystem view from block-level operations.
*De-composing* file operations into block operations is an everyday
occurrence (that's what filesystem drivers do everywhere). But the write
direction of vvfat attempts to do the *inverse* -- it seeks to recognize
block operations and to synthesize file operations from them. If you get
lucky, it sometimes even works.


Instead, please use a regular virtual disk image in the QEMU
configuration. This disk image should not be accessed concurrently by
QEMU (= the guest) and other host-side utilities. In other words, first
format / populate the disk image on the host side, then launch QEMU.
Then in the guest UEFI shell, terminate the guest with the "reset -s"
command. Finally, once QEMU has exited, use host-side utilities to fetch
the results from the virtual disk image.

On the host side (on a Linux installation anyway), I tend to use the
"mtools" package (such as "mcopy" etc), for manipulating the contents of
disk image files. Or, more frequently, the "guestfish" program (which is
extremely capable).

https://libguestfs.org/guestfish.1.html

I don't know if equivalents exist on Windows.

Now, another option (on Linux anyway) is to loop-mount a "raw" virtual
disk image. This is not recommended, as it directly exposes the host
kernel's filesystem driver(s) to metadata produced by the guest. It
could trigger security issues in the host kernel.

(This is exactly what guestfish avoids, by running a separate Linux
guest -- called the "libguestfs appliance" -- on top of the virtual disk
image. The guestfish command interpreter on the host side exchanges
commands and data with the appliance over virtio-serial. If the metadata
on the disk image is malicious, it will break / exploit the *guest*
kernel in the appliance. The host-side component, the guestfish command
interpreter, only has to sanity-check the virtio-serial exchanges.)


... Earlier I've looked into "virtio-fs" support for OVMF:

https://virtio-fs.gitlab.io/
https://www.redhat.com/archives/virtio-fs/2019-August/msg00349.html

however, it's very complex, and the wire format (the opcodes) are
extremely low-level and Linux specific. To the point where they directly
mirror Linux VFS system calls, and (due to lack of documentation) I
don't even understand what a big bunch of the opcodes *do*.

Earlier I had given some thought to a mapping between
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL / EFI_FILE_PROTOCOL and the virtio-fs
opcodes, but when I did that, it looked like a bad fit. Virtio-fs seems
to aim at serializing *Linux guest* filesystem operations as tightly as
possble for host-side processing, and that seemed like a big obstacle
for a *UEFI guest* mapping.

In particular, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL / EFI_FILE_PROTOCOL don't
really expect data and/or meta-data to change "under their feet" (-> due
to asynchronous host-side modifications). For a while I was hopeful to
expose such changes via the EFI_MEDIA_CHANGED return value. But -- alas,
I forget the details -- it seemed to turn out that the virtio-fs
interfaces wouldn't really let the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
driver, to be provided by OVMF, even *detect* the situations when it
should return EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.

So, the virtio-fs driver for OVMF has been postponed indefinitely, and
the best I can recommend at the moment is to use a regular virtual disk
image file. Remember that QEMU (= guest), and the other (host-side)
utilities for manipulating the disk image, should be strictly serialized
(they should mutually exclude each other).

Thanks
Laszlo


VirtualDrive is the Windows file path of the said mentioned folder.


If interested you should be able to reproduce the results by pulling my
branch and/or you can review the above.

You can see the operations here:

PR: https://github.com/microsoft/mu_tiano_platforms/pull/1

My Branch:
https://github.com/spbrogan/mu_tiano_platforms/tree/personal/sebrogan/shellunittests


Or if interested you can reproduce it by following steps defined here:

https://github.com/spbrogan/mu_tiano_platforms/blob/personal/sebrogan/shellunittests/Platforms/QemuQ35Pkg/Docs/building.md


and more details here
https://github.com/spbrogan/mu_tiano_platforms/blob/personal/sebrogan/shellunittests/Platforms/QemuQ35Pkg/Plugins/QemuRunner/ReadMe.md


After building qemu with the right parameters for your environment you
can run <your stuart_build cmd> --flashonly MARK_STARTUP_NSH=TRUE
RUN_UNIT_TESTS=TRUE

For example in my environment it looks like
stuart_build -c Platforms\QemuQ35Pkg\PlatformBuild.py
TOOL_CHAIN_TAG=VS2019 --flashonly RUN_UNIT_TESTS=TRUE MAKE_STARTUP_NSH=TRUE


Anyway if i recall correctly last year when we talked briefly about
automation there was some concern that this would happen. Any
information and/or ideas would be greatly appreciated.

Thanks
Sean












Newbie question about EFI_BOOT_SERVICES_MEMORY

Vestigial Bidya <vestigialdev@...>
 

Hi, this question is about the UEFI PDFs rather than the Tianocore implementation. I'm writing my DXE Foundation, and the documentation states 
" Allocate the UEFI Boot Services Table from EFI_BOOT_SERVICES_MEMORY"

The way the term  EFI_BOOT_SERVICES_MEMORY is formatted makes it look like a defined Protocol or EFI_GUID, but its not mentioned anywhere else in the docs (or on Google). Is the author trying to convey just that these allocations should be from memory that will be released after calling EXIT_BOOT_SERVICES ? Or is  EFI_BOOT_SERVICES_MEMORY an actual term in the spec that I just can't find?


OVMF/QEMU shell based unit tests and writing to a virtual disk

Sean
 

Laszlo and others familiar with QEMU,

I am trying to write automation that boots QEMU/OVMF and then runs EFI applications and those efi applications then use the UEFI shell apis to write back to the disk their state. I am seeing very inconsistent results with sometimes it working fine while other times the disk contents are invalid. If i run multiple tests it seems like the first two work while the 3rd seems to start failing but overall it seems random.

Failing means:
Disk contents corrupted but present.
Disk contents wrong size (short).
Files that show written in UEFI shell never show up on host.

I am trying to determine if this is a known limitation with QEMU or a bug i need to track down in the unit test code.

My setup:

This is on a Windows 10 x64 host. I am running current 5.1 version of QEMU.

My script creates a folder in the Windows NTFS file system. Copies the EFI executables and startup.nsh files to it. Then starts QEMU with the following additional parameter.

-drive file=fat:rw:{VirtualDrive},format=raw,media=disk

VirtualDrive is the Windows file path of the said mentioned folder.


If interested you should be able to reproduce the results by pulling my branch and/or you can review the above.

You can see the operations here:

PR: https://github.com/microsoft/mu_tiano_platforms/pull/1

My Branch: https://github.com/spbrogan/mu_tiano_platforms/tree/personal/sebrogan/shellunittests

Or if interested you can reproduce it by following steps defined here:

https://github.com/spbrogan/mu_tiano_platforms/blob/personal/sebrogan/shellunittests/Platforms/QemuQ35Pkg/Docs/building.md

and more details here
https://github.com/spbrogan/mu_tiano_platforms/blob/personal/sebrogan/shellunittests/Platforms/QemuQ35Pkg/Plugins/QemuRunner/ReadMe.md

After building qemu with the right parameters for your environment you can run <your stuart_build cmd> --flashonly MARK_STARTUP_NSH=TRUE RUN_UNIT_TESTS=TRUE

For example in my environment it looks like
stuart_build -c Platforms\QemuQ35Pkg\PlatformBuild.py TOOL_CHAIN_TAG=VS2019 --flashonly RUN_UNIT_TESTS=TRUE MAKE_STARTUP_NSH=TRUE


Anyway if i recall correctly last year when we talked briefly about automation there was some concern that this would happen. Any information and/or ideas would be greatly appreciated.

Thanks
Sean


Re: Communicating with usb devices

Guomin Jiang
 

You can locate UsbIo protocol, the prototype is described in UEFI Spec.

You can check it first.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
alireza0101sadeghpour@gmail.com
Sent: Monday, October 19, 2020 7:57 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Communicating with usb devices

Hi All,
I am a newbie in EFI development. Currently I have a requirement of
enumerating attached USB devices, communicating with them and etc.

However, after spending a day, I could not able to crack this thing. i can see
that in MdePkg and MdeModulePkg exists some driver for communicating
with usb devices but i can't figure out how should i use them.

I appreciate it if anyone could give me an example code or something like
that for communicating with usb devcies.

thanks




Communicating with usb devices

alireza0101sadeghpour@...
 

Hi All,
I am a newbie in EFI development. Currently I have a requirement of enumerating attached USB devices, communicating with them and etc.

However, after spending a day, I could not able to crack this thing. i can see that in MdePkg and MdeModulePkg exists some driver for communicating with usb devices but i can't figure out how should i use them.

I appreciate it if anyone could give me an example code or something like that for communicating with usb devcies.

thanks


Re: Retrieving USB device vendorID and productID

Andrew Fish
 

What error did you get?

On Oct 15, 2020, at 4:07 AM, Ali Shirvani <aj.shirvani@gmail.com> wrote:

Regards,


Retrieving USB device vendorID and productID

aj.shirvani@...
 

Hi,

I've located a handle to the USB device with
`gEfiSimpleFileSystemProtocolGuid.` Now I want to retrieve vendorID and
productID with `gEfiUsbIoProtocolGuid,` and I got an error when trying to
get the appropriated handle with this function:

// UsbHandle is an EFI_HANDLE located by gEfiSimpleFileSystemProtocolGuid
gBS->HandleProtocol(UsbHandle, &gEfiUsbIoProtocolGuid, (VOID**)&UsbIo);

Would you please help me to get the vendorID and productID of that USB
device?

Regards,
Ali


Re: Come One, Come All to the Project Mu UEFI Talkbox

Bret Barkelew
 

Reminder that the first Talkbox Office Day will be happening today! Here’s a new link in case the one below has expired!

https://discord.gg/feYRkxz

- Bret

From: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Sent: Friday, October 9, 2020 11:26 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Cc: Microsoft Core UEFI Team<mailto:MsCoreUefi@microsoft.com>
Subject: Come One, Come All to the Project Mu UEFI Talkbox

The Project Mu team is trying something a little new and different! In light of the limited involvement in UEFI and Tianocore community calls of late, we’re piloting a new idea for community engagement. We’ve set up a Discord server and are going to hosting “office hours” every Wednesday until Thanksgiving! This is an opportunity to connect, ask questions, bat around ideas, and just generally get to know the EDK2 community a little better. There is no planned content, and we can’t promise answers to every question, but we are highly knowledgeable and eager to see more energy in FW development.

This is the link to join the Discord:
https://discord.gg/DrmDQAv

This pilot is for the Wednesdays between 2020-10-14 and 2020-11-25. We’re a US-based, west-coast team, so expect the greatest availability between 10AM and 4PM Pacific (UTC-7). However, we’ll try to be around as much as possible those days (even in the off-hours), and may even be around on non-Wednesdays.

We should emphasize that this is NOT a Microsoft-sponsored event, or in any way related to Microsoft business. It’s not even REALLY a Project Mu event. It’s a bunch of interested folks attempting to be interesting. Who knows, maybe we’ll even figure out ways to engage with each other that don’t revolve around work.😉

- Bret


Re: Question about NonDiscoverablePciDeviceDxe

Jeff Brasen
 

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Thursday, October 8, 2020 7:26 AM
To: Jeff Brasen <jbrasen@nvidia.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Question about NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/07/20 17:53, Jeff Brasen wrote:


-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 7, 2020 8:01 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Subject: Re: [edk2-discuss] Question about
NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/06/20 23:52, Jeff Brasen wrote:
We have a use case where we would want to expose PciIO protocols for
a
device that doesn't match any of the guids that it supports.

What do you mean by "guids"? Did you mean "vendor id / device id"
perhaps?
[JMB] Sorry, should have been clearer

I was referring to the variable STATIC CONST EFI_GUID * CONST
SupportedNonDiscoverableDevices[] = {

That both guards the supported function in the binding protocol as well as
the selection of the right values in InitializePciIoProtocol.
The vendor/device ids are one of the things we will need to set based on
any extension to this.

Thanks for the explanation, I got it now.

Could you simply contribute the code to edk2 that you need in
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe?

If you add a new GUID and new branches in the driver that depend on that
GUID, that won't bother other consumers of the driver.

You mention "edk2-platforms area" below, so I assume you don't mind
open-sourcing the logic itself. My suggestion would be to simply extend
NonDiscoverablePciDeviceDxe right where it lives, in edk2.
[JMB] That works for me, just wasn't sure if there was a desire to keep the stuff in this driver to generic standard supported stuff.

Thanks,
Jeff

Thanks
Laszlo


Before we go and implement support for this wanted to get a feeling
from
the community on what to do.


1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area
for
support for this (Doesn't seem ideal)
2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the
supported
function and the configuration space setup code

Any thoughts?

Thanks,
Jeff









Come One, Come All to the Project Mu UEFI Talkbox

Bret Barkelew
 

The Project Mu team is trying something a little new and different! In light of the limited involvement in UEFI and Tianocore community calls of late, we’re piloting a new idea for community engagement. We’ve set up a Discord server and are going to hosting “office hours” every Wednesday until Thanksgiving! This is an opportunity to connect, ask questions, bat around ideas, and just generally get to know the EDK2 community a little better. There is no planned content, and we can’t promise answers to every question, but we are highly knowledgeable and eager to see more energy in FW development.

This is the link to join the Discord:
https://discord.gg/DrmDQAv

This pilot is for the Wednesdays between 2020-10-14 and 2020-11-25. We’re a US-based, west-coast team, so expect the greatest availability between 10AM and 4PM Pacific (UTC-7). However, we’ll try to be around as much as possible those days (even in the off-hours), and may even be around on non-Wednesdays.

We should emphasize that this is NOT a Microsoft-sponsored event, or in any way related to Microsoft business. It’s not even REALLY a Project Mu event. It’s a bunch of interested folks attempting to be interesting. Who knows, maybe we’ll even figure out ways to engage with each other that don’t revolve around work.😉

- Bret


Re: Question about NonDiscoverablePciDeviceDxe

Laszlo Ersek
 

On 10/07/20 17:53, Jeff Brasen wrote:


-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 7, 2020 8:01 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Subject: Re: [edk2-discuss] Question about NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/06/20 23:52, Jeff Brasen wrote:
We have a use case where we would want to expose PciIO protocols for a
device that doesn't match any of the guids that it supports.

What do you mean by "guids"? Did you mean "vendor id / device id"
perhaps?
[JMB] Sorry, should have been clearer

I was referring to the variable STATIC
CONST EFI_GUID * CONST
SupportedNonDiscoverableDevices[] = {

That both guards the supported function in the binding protocol as well as the selection of the right values in InitializePciIoProtocol.
The vendor/device ids are one of the things we will need to set based on any extension to this.
Thanks for the explanation, I got it now.

Could you simply contribute the code to edk2 that you need in
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe?

If you add a new GUID and new branches in the driver that depend on that
GUID, that won't bother other consumers of the driver.

You mention "edk2-platforms area" below, so I assume you don't mind
open-sourcing the logic itself. My suggestion would be to simply extend
NonDiscoverablePciDeviceDxe right where it lives, in edk2.

Thanks
Laszlo


Before we go and implement support for this wanted to get a feeling from
the community on what to do.


1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area for
support for this (Doesn't seem ideal)
2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the supported
function and the configuration space setup code

Any thoughts?

Thanks,
Jeff









Re: Question about NonDiscoverablePciDeviceDxe

Jeff Brasen
 

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 7, 2020 8:01 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Subject: Re: [edk2-discuss] Question about NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/06/20 23:52, Jeff Brasen wrote:
We have a use case where we would want to expose PciIO protocols for a
device that doesn't match any of the guids that it supports.

What do you mean by "guids"? Did you mean "vendor id / device id"
perhaps?
[JMB] Sorry, should have been clearer

I was referring to the variable STATIC
CONST EFI_GUID * CONST
SupportedNonDiscoverableDevices[] = {

That both guards the supported function in the binding protocol as well as the selection of the right values in InitializePciIoProtocol.
The vendor/device ids are one of the things we will need to set based on any extension to this.

Thanks,
Jeff


Thanks
Laszlo

Before we go and implement support for this wanted to get a feeling from
the community on what to do.


1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area for
support for this (Doesn't seem ideal)
2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the supported
function and the configuration space setup code

Any thoughts?

Thanks,
Jeff









Re: Question about NonDiscoverablePciDeviceDxe

Laszlo Ersek
 

On 10/06/20 23:52, Jeff Brasen wrote:
We have a use case where we would want to expose PciIO protocols for a device that doesn't match any of the guids that it supports.
What do you mean by "guids"? Did you mean "vendor id / device id" perhaps?

Thanks
Laszlo

Before we go and implement support for this wanted to get a feeling from the community on what to do.


1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area for support for this (Doesn't seem ideal)
2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the supported function and the configuration space setup code

Any thoughts?

Thanks,
Jeff






Question about NonDiscoverablePciDeviceDxe

Jeff Brasen
 

We have a use case where we would want to expose PciIO protocols for a device that doesn't match any of the guids that it supports. Before we go and implement support for this wanted to get a feeling from the community on what to do.


1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area for support for this (Doesn't seem ideal)
2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the supported function and the configuration space setup code

Any thoughts?

Thanks,
Jeff

421 - 440 of 834