The UEFI shim will modify the LoadImage, StartImage, Exit, and ExitBootServices pointers in SystemTable->BootServices: https://github.com/rhboot/shim/blob/main/replacements.c#L154-L183 In certain debu

From the way that your patch uses SMBIOS data, I'm assuming that your use case involves a pre-existing SMBIOS table structure that is constructed by something (e.g. coreboot) before UEFI starts up, an

Could you not avoid code duplication by exposing the SMBIOS table via EFI_SMBIOS_PROTOCOL? This would provide a much more general solution that would not be specific to UiApp/Frontpage.c. Michael

PCI_BASE_ADDRESSREG_OFFSET is an offset within PCI configuration space. It looks as though you are trying to use an MMIO access to read from PCI configuration space, which is not a valid thing to do.

A quick experiment shows that gcc won't generate a warning but clang will. Can be fixed by adding extra parentheses around FALSE: #define ASSERT(Expression) do { \ if ((FALSE)) { \ (VOID) (Expression)

I would very strongly recommend having the non-debug version of the macro use something like: #define ASSERT(Expression) do { \ if (FALSE) { \ (VOID) (Expression); \ } \ } while (FALSE) Without the "i

I very strongly agree with this. It's always a bad sign when a project requires installation of a custom version of a widely used tool. Michael

At a first glance, it looks as though if the caller does not already hold the lock, then the result from CoreValidateHandle() may be invalid by the time that control returns to the caller. Under what

That doesn't immediately make sense to me in the context of reading sections 5.2.1.2 and 5.2.2.2.2 of the audio spec, but feel free to post the whole wireshark capture (off-list!) and I can take a loo

When there is no fundamental limitation, i.e. when a future version of the hypervisor may be able to support the feature with no changes to the firmware, then it would be good practice to leave the dr

BTW, in case you aren't already aware of this: wireshark is pretty good at dissecting USB traffic. You can capture it by doing a "modprobe usbmon", after which you'll see a number of usbmonN devices s

I have no idea what higher-level utility library functions exist within EDK2 that you might be able to use. Based on skimming through the USB audio spec, at the raw protocol level you would need to us

Do you mean that you can't figure out how to retrieve the descriptors via the UEFI APIs, or that you don't know how to interpret the descriptors after retrieval? Thanks, Michael

Is that a detail of the current implementation, or a fundamental limitation in the bhyve architecture? Thanks, Michael

FWIW, I strongly agree with Marvin on this: having ParseStatus in its current form is a bad idea since it adds no value but does incur a cost. Thanks, Michael

QEMU also has good support for passing through a real USB device, which might be useful if you ever suspect that the QEMU device implementation is behaving incorrectly. (This is not implausible: I sti

Do you mean that you can't find a way to get QEMU to create a Virtio audio device visible to the guest, or that you can't find a way to get QEMU to connect this Virtio device to the host-side audio ou

Secure Boot defines a security boundary between the firmware and the operating system: the operating system is not permitted to make arbitrary changes to firmware variables. It sounds as though you ha

The "one binary" decision isn't relevant here, is it? It would make more sense to implement 5-level paging within the base EDK2 architecture. This would allow that feature to be tested in isolation fr

Out of interest: does Intel TDX provide any security benefits beyond the (much simpler) Intel SGX? As far as I can tell from the various papers, the fundamental difference between TDX and SGX seems to