Re: virtio & hypercall interface?

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

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

The 'signal a channel' method has two sub-options when talking to a
userspace implementation: exit immediately to userspace or signal some
other thread asynchronously.  The second option turned out to be not so
good so we won't be implementing it.  But the first option is still valid.


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

That should be done via the device condig space, either pci or virtbus.

>     Sure there are other possibilities, but why limit ourselves?
> 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.
>   

It can be just a signal on the balloon's channel.  This is better than
the current hypercall implementation since it allows the guest to
proceed while the host is allocating memory, a potentially time
consuming operation.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


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