Hi, >> So we could have for virtio something like this: >> >> Capabilities: [??] virtio-regs: >> legacy: BAR=0 offset=0 >> virtio-pci: BAR=1 offset=1000 >> virtio-cfg: BAR=1 offset=1800 > > This would be a vendor specific PCI capability so lspci wouldn't > automatically know how to parse it. Sure, would need a patch to actually parse+print the cap, /me was just trying to make my point clear in a simple way. >>>> 2) ISTR an argument about mapping the ISR register separately, for >>>> performance, but I can't find a reference to it. >>> >>> I think the rationale is that ISR really needs to be PIO but everything >>> else doesn't. PIO is much faster on x86 because it doesn't require >>> walking page tables or instruction emulation to handle the exit. >> >> Is this still a pressing issue? With MSI-X enabled ISR isn't needed, >> correct? Which would imply that pretty much only old guests without >> MSI-X support need this, and we don't need to worry that much when >> designing something new ... > > It wasn't that long ago that MSI-X wasn't supported.. I think we should > continue to keep ISR as PIO as it is a fast path. No problem if we allow to have both legacy layout and new layout at the same time. Guests can continue to use ISR @ BAR0 in PIO space for existing virtio devices, even in case they want use mmio for other registers -> all fine. New virtio devices can support MSI-X from day one and decide to not expose a legacy layout PIO bar. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
