Re: virtio & hypercall interface?

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Dor Laor wrote:
>> 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.
>   

It's really hard to say here without seeing the code but if you really 
need to use a hypercall, then I think the better thing to do is define 
an higher level interface (like an exit reason) and do the translation 
from hypercall to this exit reason.  There's no performance difference 
doing this.

My thinking is that there will be other userspace other than QEMU.  The 
hypercall interface is static and needs to be treated as the host=>guest 
ABI.  By allowing hypercalls to be interpreted by userspace, you are now 
making the host=>guest ABI depend on userspace too instead of just 
kernel space.

The only argument I can see for passing through hypercalls:

1) you may want two separate userspaces to define the same hypercall 
number in two different ways

2) it's easier to just pass through the hypercall by default than it is 
to translate to a higher level exit reason

I think #1 is fundamentally a bad thing to do allow.  I think #2 is not 
justified because you're just making the hypercall interface part of the 
kernel/userspace interface anyway.

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

Whether to use hypercalls vs. PIO is a separate issue from whether 
hypercalls should be handled in userspace.  I think we should always 
handle hypercalls in kernel space and that the hypercall interface ought 
to be defined within the kernel.  Now, this doesn't mean that the result 
of a hypercall can't be dropping down to userspace but I don't think we 
should do it blindly.

> Does it help changing your minds?
>   

No, but I'm hoping that I can change yours :-)

Regards,

Anthony Liguori

> 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/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


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