Re: [Qemu-ppc] [PATCH 01/58] spapr: proper qdevification

[David Gibson]

On Thu, Sep 15, 2011 at 09:01:38AM +0200, Paolo Bonzini wrote:
> On 09/15/2011 05:14 AM, David Gibson wrote:
> >Under PAPR, there is generally only
> >supposed to be one SCSI target (disk / cd / whatever) per virtual scsi
> >bus.  But the generic qdev code will, by default, keep assigning
> >devices to the existing bus until it's full.  Any thoughts on how to
> >sanely change that behaviour on a per-machine basis?
> 
> You could change the if_max_devs array in blockdev.c to something
> provided by the machines.
> 
> However, I'm not sure about this, for two reasons:
> 
> 1) do you mean, in Linux terms, one target per SCSI _host_ or one
> target per SCSI _channel_?  i.e. if you looks at
> /sys/bus/scsi/devices, right now it looks like
> 
>    0:0:0:0    0:0:1:0     (two targets on the same host and channel)
> 
> Should it be?
> 
>    0:0:0:0    0:1:0:0     (one target per channel)
> 
> or
> 
>    0:0:0:0    1:0:0:0     (one target per host)
> 
> If it is the former, then you are simply hitting a limitation of the
> SCSI layer in QEMU and I do have patches to make assignment more
> flexible.  Based on the Linux VSCSI driver, and based on what SLOF
> does, I'd guess that's what you mean.


Well, now I'm confused.  I had a look at a pHyp machine, and Linux
seemed to see it as multiple targets on a single channel, but I'm sure
the PAPR spec says you shouldn't have that.  So I'm going to have to
look closer now.

> 2) does this matter at all?  First, when doing "real world"
> virtualization you won't use the legacy options (neither -hda/-cdrom
> nor "-drive ...,if=scsi"), you would use -device to manually assign
> the devices to their buses.

Well, perhaps, but I really prefer to have sane defaults, rather than
having to build the machine myself on the command line.

>  Second, why should you care in the case
> of SCSI?  It seems like a very hard limitation to me, and unlike the
> PCI case it doesn't buy you anything in terms of isolation.

Ah, there is a good reason on this side.  I forget the exact details,
but due to the protocol it uses there's some blocksize limit that is
only advertised per vscsi adaptor, whereas it should really be a
per-target quantity (and is different in practice for cdroms and
disks).  Of course that's arguably a bug in the vscsi protocol, but we
can't fix that.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson