On Wed, Aug 21, 2024 at 02:20:22PM +0200, Peter Krempa wrote:
On Wed, Aug 21, 2024 at 14:02:50 +0200, Martin Kletzander wrote:On Fri, Aug 16, 2024 at 04:42:33PM +0200, Peter Krempa wrote: > Attempting to start qemu with or hotplug an empty 'usb-storage' based > disk results in the following error: > > qemu-system-x86_64: -device {"driver":"usb-storage","bus":"usb.0","port":"2","id":"usb-disk1","removable":true}: drive property not set > > Reject such config at validation step and adjust tests. > It's weird that we even support usb cdrom as qemu cannot even emulate that, at least to my knowledge. Other than that the patch looks fine, but I cannot shake off the feeling of fishiness with this one. Could you bring me up to speed how this even happened to be "supported"?IIRC the change in behaviour of USB cdroms might be an oversight/fallout of conversion from '-drive' to '-blockdev' which wasn't originally caught for a rather long time. (Might even have been pre-existing but I don't care digging that far back). Now as this config "mostly works" for most media/situations we shouldn't really just forbid it completely so that we don't break the working situations. AFAIK the fix for this is to switch the USB device handling to use 'uas' instead of 'usb-storage' which becomes basically a SCSI controller and you can then connect a proper SCSI-cdrom device to it. That obviously requires a complete rewrite of the USB disk handling and might not even be ABI compatible (I didn't check because I don't really care). As of this situation, qemu simply fails to start with taht config so there's no harm in forbidding it for now.
Yeah, that makes sense. Thanks for elaborating on that. Reviewed-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
