Public bug reported:
If I run qemu-system-aarch64 with "-device usb-net,...", the resulting
USB device will be seen in the guest as class 0x2, subclass 0x2,
protocol 0xFF, instead of the expected class 0xe0, subclass 0x1,
protocol 0x3. This prevents Windows' in-box class driver from binding to
the
I know it won't work in KVM. I'm arguing that something not working in
KVM is not grounds for removal from the UEFI image, since qemu != KVM.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1717708
Tit
hey aren't compatible with KVM (I
don't quite get it - UEFI for aarch64 virt is supposed to be for qemu in
general, not exclusive to KVM...), however I actually have a fork with
these features restored, available at
https://github.com/Googulator/edk2/releases. This is able to boot the
leaked
Public bug reported:
In an effort to get Windows 10 for ARM64 (which is supposed to boot on
SBSA/SBBR-compliant platforms) to boot inside qemu, I tried to run the
SBSA ACS test suite. I used the UEFI image from the latest Linaro
snapshot, and built the SBSA ACS UEFI application from
https://github
Public bug reported:
Qemu doesn't currently emulate the correct value of the "register level
programming interface" field in the PCI config space of USB host
controllers. As a result, some guest operating systems (most notably
Windows) fail to load e.g. generic xHCI drivers, and instead ask for a
