Paolo Bonzini <pbonz...@redhat.com> writes: > On 24/01/2017 13:56, Markus Armbruster wrote: >> So, what do we want to deprecate? >> >> I think the onboard SCSI HBA adopting if=scsi drives should stay, >> because it matches what we do for other interface types. Unless we >> wanted to deprecate interface types other than none entirely. > > Yes, of course. > >> What about realview and versatile auto-creating lsi53c895a? > > That should go.
Peter, do you agree? >> What about pseries auto-creating spapr-vscsi? > > That should stay I think. The discriminant being that spapr-vscsi > devices actually are likely to have drivers in the guests. Okay. >> What about cold-plug of HBAs auto-creating SCSI devices? You proposed >> deprecating it for PC types, but it's currently independent of the >> machine type. Deprecate it for all types? If not, add a flag to >> MachineClass so we can deprecate it just for PC types? > > I need --verbose for this, sorry. No problem! Let me explain how SCSI auto-creation works, and how it differs from the other interface types. Actually, let me start with the other ones. When a machine supports some if=T, T other than scsi or none, its initialization code retrieves the drives of interface type T with supported bus and unit numbers, creates suitable frontends, and wires them up. We commonly don't bother to check whether there are drives with unsupported bus and unit numbers. Example: within terrier_init(), spitz_microdrive_attach() runs and calls drive_get(IF_IDE, 0, 0). If it gets something back, it creates a dscm1xxxx device model. Example: pc_q35_init() calls ide_drive_get() to retrieve the IF_IDE drives with bus=0..5, unit=0. It creates ide-cd or ide-hd device models for the ones it gets back. Example: within machvirt_init(), create_one_flash() runs two times and calls drive_get_next(IF_PFLASH) to retrieve bus=0, unit=0..1. It creates cfi.pflash01 device models unconditionally, and backs them with the drives it gets back, if any. I hate the drive_get_next() interface, because it uses execution order to encode unit numbers. if=scsi works differently. SCSI HBA device models commonly call scsi_bus_legacy_handle_cmdline() during realize() for their SCSI bus(es). A SCSI bus gets assigned a bus number on creation, counting up from zero. The SCSI HBA device model declares the maximum unit number it supports (SCSIBusInfo member max_target). scsi_bus_legacy_handle_cmdline() calls drive_get(IF_SCSI, bus->busnr, unit) to retrieve the IF_SCSI drives, and creates scsi-generic or scsi-disk device models. When a machine has an onboard SCSI HBA whose realize() calls scsi_bus_legacy_handle_cmdline(), then machine initialization code doesn't have to do anything to support if=scsi. Example: mips_jazz_init() simply calls esp_init(), which then adopts the if=scsi,bus=0,unit=0..7. Note that blockdev.c rejects unit>7. Example: sun4m_hw_init() does the same, but also checks for and rejects drives with bus>0. This check becomes redundant when we make orphaned drives an error. A few machines don't have onboard SCSI HBA, but their initialization code creates N default ones, where N is the largest bus number of any if=scsi drive. Again, nothing else needs to be done to create the actual SCSI devices. Example: before my patch, PC machine initialization calls pc_pci_device_init(), which creates lsi53c895a device models in a loop. If a machine doesn't create default SCSI HBAs, the user can do it himself with -device, and as long as the HBA's realize() calls scsi_bus_legacy_handle_cmdline(), if=scsi works. Example: after my patch, PC machine initialization doesn't create SCSI HBAs. Options "-drive media=cdrom,if=scsi,bus=1 -device megasas,id=scsi0 -device megasas,id=scsi1" create two megasas device models, and one scsi-disk device model plugged into the second one. My question is: do we want to deprecate "-device of a SCSI HBA auto-creates SCSI devices for the HBA's bus number(s), with unit numbers up to max_target"? For all machine types, or just for PC? If for all machine types, we need work a little harder for if=scsi in machine initialization, exactly like we do for the other interface types. Clear as mud now?
