On Tue, 2008-04-01 at 16:03 -0500, Anthony Liguori wrote: > Benjamin Herrenschmidt wrote: > > On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote: > > > > > >> It's the unfortunate side-effect of using PCI config space without > >> passing it's semantics through to the virtio devices. Right now, you do > >> a config_get which is basically a memcpy. If we didn't do accesses with > >> ioread8(), you could potentially have a caller than did a config_get() > >> of size 4 that didn't intend on having endian conversion applied. > >> > >> The other option would have been to provide config_get() and > >> config_get8/16/32/64() the later performing endian conversion. > >> > > > > Config space should be 8/16/32. Is that ever bridged to real PCI config > > space anyway ? Or only virtio ? And it should be endian swapped at the > > low level, either by your HV calls or by the low level kernel. Always. > > That's how PCI config space is supposed to work.
Virtio accesses will not be bridged to real PCI space. > I guess the point is, is that virtio config space is an abstraction with > the implementation that is based on PCI converting all accesses to a > series of 8-bit accesses. The virtio config space happens to be little > endian just like the PCI config space. The point is that a virtio device appears as a PCI device. Like all other PCI devices, it has config space. Unlike all other PCI devices, its config space is accessed with 1-byte reads. -- 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
