Re: [Qemu-devel] virtio-scsi spec, first public draft

[Paolo Bonzini <pbonzini@redhat.com>]

On 05/06/2011 02:31 PM, Stefan Hajnoczi wrote:
> Okay, this explains how you plan to handle targets appearing - you
> want to set a maximum number of targets.  I was wondering how we would
> add virtqueues dynamically (and why the control vqs are placed last at
> n,n+1 instead of 0,1).

You don't, it's not in the spec.  On the other hand, I don't think a 
limit on the number of targets is imposing, and the limit that virtio 
places is more theoretical than practical.

(Control virtqueues are last simply to avoid +2 and -2 all over the place).

> I'm really not sure I understand the win of creating lots of
> virtqueues.  I just want a pipe out onto the SCSI bus so I can talk to
> all devices in the SCSI domain.  Creating separate virtqueues
> increases complexity in the driver and emulation IMO.

In the driver, probably.  Emulation shouldn't change much, there's so 
little to do in the end in a PV HBA emulation if you have a proper SCSI 
subsystem and the protocol is a simple transport or reasonably close.

> What is the MSI-X win you mentioned?  I guess if an application on
> vcpu0 is accessing target0 a lot then interrupt handling can be
> handled on vcpu0 while other vcpus handle interrupts for other SCSI
> targets?

Yes, possibly.  But I think the main benefit is in resiliency.  If one 
target malfunctions and timeouts, other targets still work normally 
until the SCSI layer decides to reset that target.

> I remember VMware pv scsi has a trick here, each request can
> contain the vcpu number which influences interrupt routing somehow.

I don't think it works under Linux though, it depends on how the OS sets 
up the APICs.

Paolo