Re: [kvm-devel] [RFC] virtio-blk PCI backend

[Avi K. <av...@qu...>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>  
>>> +    case VIRTIO_PCI_QUEUE_NOTIFY:
>>> +    if (val < VIRTIO_PCI_QUEUE_MAX)
>>> +        virtio_ring_kick(vdev, &vdev->vq[val]);
>>> +    break;
>>>       
>>
>> I see you're not using hypercalls for this, presumably for compatibility
>> with -no-kvm.
>
> More than just that.  By stick to PIO, we are compatible with just 
> about any VMM.  For instance, we get Xen support for free.  If we used 
> hypercalls, even if we agreed on a way to determine which number to 
> use and how to make those calls, it would still be difficult to 
> implement in something like Xen.
>

But pio through the config space basically means you're committed to 
handling it in qemu.  We want a more flexible mechanism.

Detecting how to make hypercalls can be left to paravirt_ops.

(for Xen you'd use an event channel; and for kvm the virtio kick hypercall).

>>   Well I think I have a solution: advertise vmcall,
>> vmmcall, pio to some port, and int $some_vector as hypercall feature
>> bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively).  Early
>> setup code could patch the instruction as appropriate (I hear code
>> patching is now taught in second grade).
>>   
>
> That ties our device to our particular hypercall implementation.  If 
> we were going to do this, I'd prefer to advertise it in the device I 
> think.  I really would need to look at the performance though of 
> vmcall and an edge triggered interrupt.  It would have to be pretty 
> compelling to warrant the additional complexity I think. 

vmcall costs will go down, and we don't want to use different mechanisms 
for high bandwidth and low bandwidth devices.



-- 
error compiling committee.c: too many arguments to function