On Mon, 2008-01-14 at 19:30 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > > On Sun, 2008-01-13 at 11:42 +0200, Avi Kivity wrote: > > > > > >> Do we really need to propagate endianness all the way to the user? > >> Perhaps libkvm could call the regular mmio functions and do the > >> transformation itself. > >> > >> Or maybe even the kernel can do this by itself? > >> > > > > The kernel *already* does this by itself, and I'm attempting to explain > > why that is not sufficient. > > > > My point is precisely that the endianness information must be propagated > > to the user, otherwise the user may not have all the information it > > needs to emulate it. > > > > Here is the concrete example: > > * guest writes to MMIO > > * KVM passes MMIO information (physical address, number of bytes, > > value) to qemu > > * Qemu knows from the address that this access is for a passthough > > device, a special case the administrator has pre-configured > > * Qemu does mmap(/dev/mem), and writes "length" bytes of "value" > > at offset "address". > > > > Now here's the catch: what endianness does qemu use when doing the > > write? If qemu only does BE, then a LE access from the guest will be > > byte-reversed when presented to the real hardware. > > > > Right, I forgot that bit when replying. > > So, the data is always in natural endianness? If so, we can add an > endianness indicator to the mmio callbacks, which qemu will mostly > ignore, and only examine it on passthrough.
"Natural endianness" is not a well-defined term, since many architectures can do both, and change on the fly. The data will be the contents of a guest register, so I guess you could say it is in "guest endianness" (as determined by a guest control register). Of course, there's no necessary connection between guest endianness and qemu endianness. We always need to know if the data requires byteswapping or not, regardless of passthrough. MMIO accesses can be issued in either endianness to an emulated device too. > btw, isn't passthrough better handled through the tlb? i.e. actually > let the guest access the specially-configured memory? You can have qemu > mmap /dev/mem and install it as a memslot, and things should work, no? > (well, you might need to set some cachablility flag or other). Hmm, yes you're right. Of course, qemu offers greater flexibility than MMUs (which are limited to page-sized granularity, for example), so it might still be useful to have qemu intercede. Since we're defining a stable ABI, I'd rather have the information present than miss it in the future... -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
