Re: virtio & hypercall interface?

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

On Sun, 2007-09-16 at 10:57 +0200, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Sat, 2007-09-15 at 12:38 +0300, Avi Kivity wrote:
> >   
> >> I don't see why there is a difference.  With mmio, the host tells the
> >> guest where the ring is.  With dma, the guest tells the host where the
> >> ring is.  In both cases, you need some form of communication (read-only
> >> for mmio, write-only for dma).
> >>
> >> For mmio, the mechanism is standardized within pci; for dma it is not,
> >> but it is still just as simple, write to some word in pci config space
> >> and you're done.
> >>     
> >
> > No, you already need a r/o, whatever you use.  That's because you need
> > to describe the features of the device (eg disk size).
> >
> >   
> 
> I don't get your point (I agree with everthing you said except the 
> "No,", so maybe I'm not understanding something).

You said "In both cases, you need some form of communication".  True,
but we already need host -> guest.  dma-style adds guest -> host, which
is new.

It is not the simplest solution, and this is a standard we're creating.

> >> If early printk can't handle pci, we can provide a pio port that does
> >> byte-at-a-time output.
> >>     
> >
> > It's not that it can't handle PCI, it's that it now needs to find a page
> > to use.  That's less trivial than using an already-existing page.
> >   
> 
> static char a_page[PAGE_SIZE] __aligned(PAGE_SIZE);

We don't want to waste two pages in a driver which might not be used at
all.

> > As for making suspend/resume more complex, I can't see it.  Make the
> > guest memory a few pages bigger, and don't tell the guest about those
> > extra pages (that's waht lguest does today: those mmio pages are just
> > above top of "normal" RAM).
> >   
> 
> That's annoying for memory or device hotplug  (though not insurmountable).

Sure, and we can get more sophisticated when those happen.

> The vga framebuffer handles this by allocating a separate memory slot; 
> the right way if we go to mmio device memory is to have one slot per 
> device.  But I still think that if e1000 can allocate the ring in system 
> memory, so can virtio.

We *can*, but adding complexity needs justification.  For the e1000,
it's performance.  For virtio, it's "might simplify modifications to
existing kvm-qemu", which is far weaker IMHO.

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