Re: [RFC] virtio-blk PCI backend

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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.
>
> There's no reason that the PIO operations couldn't be handled in the 
> kernel.  You'll already need some level of cooperation in userspace 
> unless you plan on implementing the PCI bus in kernel space too.  It's 
> easy enough in the pci_map function in QEMU to just notify the kernel 
> that it should listen on a particular PIO range.

With my new  understanding of what this is all about, I suggest each 
virtqueue having an ID filled in by the host.  This ID is globally 
unique, and is used as an argument for kick.  It would map into a Xen 
domain id + event channel number, a number to be written into a pio port 
for kvm-lite or non-hypercall kvm, the argument for a kick hypercall on 
kvm, or whatever.

This is independent of virtio-pci, which is good.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/