Re: [RFC] virtio-blk PCI backend

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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.

>   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.

Regards,

Anthony Liguori

> (kvm could advertise all four, or maybe just the first two)
>
>   


-------------------------------------------------------------------------
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/