Hi Am 07.09.20 um 13:45 schrieb Gerd Hoffmann: >> -device nec-usb-xhci,id=xhci \ >> -device usb-bot,id=scsi0,bus=xhci.0 \ >> -device >> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-1-format,id=scsi0-0-0-0,bootindex=1 >> \ >> -device >> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=libvirt-1-format,id=scsi0-0-0-1 >> \ >> >> which starts, but gives me a "Synchronous Exception" from the TianoCore >> firmware, which I often saw with PCI enumeration problems. > > Hmm, firmware bug? Does seabios work? I don't know, but AFAIK Windows Arm64 requires EFI, so that isn't an option. But I'll check later, just for curiosity. Maybe in the case of usb-bot with multiple devices, you get an USB EP with multiple devices? >> Also "info usb" just shows a single device. I just copied these lines >> from a normal libvirt SCSI setup with two cdroms. > > That is normal, it actually is only one usb device after all ;) I was referring to the posted usb-bot example, where "your" docs (<qemu>/docs/usb-storage.txt) says it supports multiple LUNs, so I was wondering, how these would be exposed on the USB bus. >> But compared to my small patch with the usb-storage based USB CDROM, >> this looks like a much larger change and a lot of work implement. > > Yes. > > As far I know libvirt wants move away from the old syntax and shift to > use -blockdev more, not the other way around. I'm aware of it. Didn't realize I could use usb-bot instead of usb-storage, when I looked into this back then. The following variants are about a solution using usb-bot together with blockdev. My simple usb-storage already works. >> 1. doing this transparently with a controller per device, just like the >> usb-storage controller does internally (ok - it's just a scsi-cd there), >> even if the usb-bot supports multiple LUNs. Guess multiple LUNs would >> act like an USB hub? > > usb-storage simply doesn't support multiple LUNs, so when going that > route you can completely ignore the multiple LUN case. > >> 2. invalidating the cdrom with USB addresses configurations and exposing >> the controller in the XML. This seems easier from the libvirt code POV, >> like: >> >> <controller type='scsi' model='usb-bot'> >> <address type='usb' port='1'/> >> </controller> > > Yep, that is the other obvious approach. > >> So I still would like to see my much simpler solution merged. > > See above, but I'm not a libvirt maintainer so that's not for me to > judge. I'm just pointing out that this can be fixed without switching > back to the old -drive syntax. All fine. I've spent my time on this. I just want to fix my LibreOffice Windows Arm64 cross-build and need an install to debug my obviously existing errors, but the current Windows installer ISOs even break somewhere in the initial ramdisk setup in QEMU and the older versions have timeouts, if current uup-based images are even correctly generated on Linux, which I have no way to verify. I don't know if there will be fixes, after the QEMU upstream bug was closed as invalid (https://bugs.launchpad.net/qemu/+bug/1717708), but currently fixing the LibreOffice Windows Arm64 cross build needs more work, just to get it compiled and the MSI generated. So I'll probably test this again later and hope future versions of the QEMU + edk2 will work better :-) This all is just some personal, private side project, and I simply didn't expect this many problems, after reading about Windows Arm64 in QEMU in year old blog posts. Jan-Marek
