Re: virtio & hypercall interface?

[Dor Laor <dor.laor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Anthony Liguori wrote:
> Dor Laor wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
>>>  
>>>> Dor Laor wrote:
>>>>     
>>>>>> Hi all,
>>>>>>
>>>>>>     I've finally started looking at Dor's git tree, and it struck me
>>>>>>                   
>>>>> that
>>>>>           
>>>>>> it conflicts with Anthony's hypercall patches.  FWIW I like 
>>>>>> Anthony's
>>>>>> patching thing, and don't really care about arg order.  It'd be 
>>>>>> nice if
>>>>>> we could pull in the same direction tho 8)
>>>>>>
>>>>>> Thanks,
>>>>>> Rusty.
>>>>>>                   
>>>>> Good news you're looking at my tree, since the forum I didn't do much
>>>>> since I had to catch up some gazlion other tasks, never the less
>>>>> starting on Sunday I'm back again.
>>>>>
>>>>> Actually, I wanted to rebase my hypercalls over Anhtony's too (except
>>>>> for allowing userspace handling).
>>>>>           
>>>> I thought we discussed just providing a signaling message to 
>>>> userspace for virtio?  It's not strictly necessary to expose 
>>>> hypercalls to userspace in order to implement a virtio backend in 
>>>> userspace.
>>>>
>>>>       
>>>
>>> Yes, that's what I'd like to see too.  Signal a channel.
>>>
>>>   
>> First, I though that this 
>> http://www.mail-archive.com/kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg06230.html 
>>
>> was your latest opinion.
>> Second, regardless of the channel signal notification, there are 
>> still real necessities for userspace hypercall handling:
>> 1. For virtio drivers there is also registration hypercall for 
>> passing the shared memory pfns.
>>    Sure there are other possibilities, but why limit ourselves?
>
> Can you elaborate here?  Using a PCI discover mechanism, you've got 
> your memory already.  Not point in reinventing PCI with hypercalls.
In this case I agree that it should be done using pci/other_bus config 
space.
>
>>
>> 2. For other purposes such as a balloon driver, a deflate/inflate 
>> hypercalls are needed.
>>    Although for x86 mmio/pio can be used but this is not compatible 
>> with other architectures.
>
> Isn't a balloon driver just another virtio device?  Rather, it might 
> be interesting to build a simple RPC mechanism on top of virtio and do 
> things like balloon on top of that.
Currently the balloon driver is not a virtio device but it will become 
one, nevertheless, not all devices must be virtio, and we cannot predict 
all sort
of usages. Even if a device can work over virtio it shouldn't be a 
perquisite.

I have another two new points in favor of userspace hypercall handling:
1. Hypercalls needed for pci pass through devices.
    We have an home grown implementation for pci pass through devices 
that will soon be merged.
     It allows redirecting a physical pci device into a guest.
     The guest kernel issues hypercalls to know whether a device is 
physical or not. It's much more easy to let
     userspace catch them since it is aware of all devices, unlike the 
kernel.

2. Vmexit speeds
   Theoretically, vmcall should be faster than pio/mmio for the bare 
hardware.
   When implementing PV driver, the guest implementation is agnostic to 
the host implementation. For maximum performance
   the host side will use kernel modules while for flexibility a 
userspace implementation will do the job.
   So although vmcall efficiency is neglectable comparing to context 
switch to user, there will be occasions were the host has a PV driver 
backend.

Does it help changing your minds?
Dor

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/