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/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
