From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: virtio & hypercall interface? Date: Sun, 16 Sep 2007 19:35:24 +1000 Message-ID: <1189935324.7262.120.camel@localhost.localdomain> References: <1189664514.32322.14.camel@localhost.localdomain> <64F9B87B6B770947A9F8391472E032160DA17EF2@ehost011-8.exch011.intermedia.net> <46E9A17D.5040205@us.ibm.com> <46EABAD0.40300@qumranet.com> <46EB0BD8.6040000@qumranet.com> <1189825560.7262.77.camel@localhost.localdomain> <46EB9245.4010005@qumranet.com> <1189845153.7262.94.camel@localhost.localdomain> <46EBA806.6070507@qumranet.com> <1189929012.7262.105.camel@localhost.localdomain> <46ECEFEE.6000208@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <46ECEFEE.6000208-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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/