Re: virtio & hypercall interface?

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>]

On Sat, 2007-09-15 at 11:05 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Sat, 2007-09-15 at 01:31 +0300, Dor Laor wrote:
> >   
> >> 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?
> >>     
> >
> > I really prefer doing this the more "hardware-like" way and having the
> > device description say where the pages are.  Surely this is simpler from
> > the qemu side, too?
> >   
> 
> This is mmio style (device provides memory).  DMA style (guest provides
> memory, device dmas it) is easier for kvm: we don't need to allocate a
> new memory slot, and migration is easier.
> 
> Most current hardware place the descriptor ring in guest memory, not the
> device, since mmio is slower for the cpu than RAM.

But for virtual devices it seems unnecessarily convoluted: we'd have
some mmio space (or PCI config space?) to tell the device where the ring
buffer is.  That's a little nasty for lguest early printk, too.

I'm looking now at getting lguest to present a PCI bus implementation
(probably changing virtbus to a series of PCI id plus bytes for "config
space").  That's easier with a "device mem" model, since no config info
needs to go back to the host.

OTOH, with the guest memory model, guest can potentially choose size of
ring.  I don't know if that's an actual advantage (but I have code now
which makes the ring size variable).

Rusty.


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