Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > On Wed, 2013-06-05 at 16:53 -0500, Anthony Liguori wrote: > >> A smart BIOS can also use MMIO to program virtio. > > Indeed :-) > > I see no reason why not providing both access path though. Have the PIO > BAR there for compatibility/legacy/BIOS/x86 purposes and *also* have the > MMIO window which I'd be happy to favor on power. > > We could even put somewhere in there a feature bit set by qemu to > indicate whether it thinks PIO or MMIO is faster on a given platform if > you really think that's worth it (I don't).
That's okay, but what I'm most concerned about is compatibility. A virtio PCI device that's a "native endpoint" needs to have a different device ID than one that is a "legacy endpoint". The current drivers have no hope of working (well) with virtio PCI devices exposed as native endpoints. I don't care if the native PCI endpoint also has a PIO bar. But it seems silly (and confusing) to me to make that layout be the "legacy" layout verses a straight mirror of the new layout if we're already changing the device ID. In addition, it doesn't seem at all necessary to have an MMIO bar to the legacy device. If the reason you want MMIO is to avoid using PIO, then you break existing drivers because they assume PIO. If you are breaking existing drivers then you should change the device ID. If strictly speaking it's just that MMIO is a bit faster, I'm not sure that complexity is worth it without seeing performance numbers first. Regards, Anthony Liguori > > Cheers, > Ben. > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
