Gerd Hoffmann <kra...@redhat.com> writes: > 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.
I think having BAR1 be an MMIO mirror of the registers + a BAR2 for virtio configuration space is probably not that bad of a solution. Regards, Anthony Liguori > > cheers, > Gerd > > -- > 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