On 08.03.2018 07:58, Hervé Poussineau wrote:
> Le 07/03/2018 à 10:08, Thomas Huth a écrit :
>> The global hack for creating SCSI devices has recently been removed,
>> but this apparently broke SCSI devices on some boards that were not
>> ready for this change yet. For the 40p machine you now get:
>> $ ppc64-softmmu/qemu-system-ppc64 -M 40p -cdrom x.iso
>> qemu-system-ppc64: -cdrom x.iso: machine type does not support
>> if=scsi,bus=0,unit=2
>> Fix it by providing a lsi53c810_create() function that takes care
>> of calling scsi_bus_legacy_handle_cmdline() after creating the
>> corresponding SCSI controller.
>> Fixes: 1454509726719e0933c800fad00d6999752688ea
>> Signed-off-by: Thomas Huth <th...@redhat.com>
> Why is it required?
> - because SCSI adapter is not up to date to QEMU standards (QOM, ...)?
> - because board is not up to date to QEMU standards (QOM, ...)?
> - because board is using SCSI devices by default?
> (mc->block_default_type = IF_SCSI) ?
> In 2 first cases, what is missing?
> In third case, maybe it may be better to put it in generic code?

It's the third case. The "generic" code was just removed with commit
1454509726719e0933 since it was considered as a big hack. The generic
code should not have to guess to which SCSI adapter a SCSI drive should
be attached to. That's the job of the board init code, and this is what
this patch is doing now for the 40p machine.

Other boards like the "pseries" machine were doing this since a long
time already (see the spapr_vscsi_create() function in
hw/scsi/spapr_vscsi.c for example).

> You just fixed 40p and MIPS Jazz machines, but sparc/SS-10 (and other)
> also have the same problem...

I also posted a patch for the Sparc machines, you can find it here:



Reply via email to