Rusty Russell wrote: > 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. >
We already have guest -> host (at least for pci). We'll need guest -> host config anyway, to configure interrupt mitigation, blink the virtual NIC LEDs, and stuff like that. >>>> 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. > > If the host allocates it, it is wasted too. >>> 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. > > When we aim, we should keep away from our feet, so that when we shoot we have a chance to keep them. >> 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. > I don't see read/write pci config as complexity; it is part of the pci spec and we can't choose to implement the parts we like. In any case it is implemented already. A point in favor of host allocation, though, is that you can share that memory with other guests. Not sure there's much point since the host will need to be involved in translating descriptors anyway. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
