Hi, >> Well, we also want to clean up the registers, so how about: >> >> BAR0: legacy, as is. If you access this, don't use the others. Ok. >> BAR1: new format virtio-pci layout. If you use this, don't use BAR0. >> BAR2: virtio-cfg. If you use this, don't use BAR0. Why use two bars for this? You can put them into one mmio bar, together with the msi-x vector table and PBA. Of course a pci capability describing the location is helpful for that ;) >> BAR3: ISR. If you use this, don't use BAR0. Again, I wouldn't hardcode that but use a capability. >> I prefer the cases exclusive (ie. use one or the other) as a clear path >> to remove the legacy layout; and leaving the ISR in BAR0 leaves us with >> an ugly corner case in future (ISR is BAR0 + 19? WTF?). Ok, so we have four register sets: (1) legacy layout (2) new virtio-pci (3) new virtio-config (4) new virtio-isr We can have a vendor pci capability, with a dword for each register set: bit 31 -- present bit bits 26-24 -- bar bits 23-0 -- offset So current drivers which must support legacy can use this: legacy layout -- present, bar 0, offset 0 new virtio-pci -- present, bar 1, offset 0 new virtio-config -- present, bar 1, offset 256 new virtio-isr -- present, bar 0, offset 19 [ For completeness: msi-x capability could add this: ] msi-x vector table bar 1, offset 512 msi-x pba bar 1, offset 768 > We'll never remove legacy so we shouldn't plan on it. There are > literally hundreds of thousands of VMs out there with the current virtio > drivers installed in them. We'll be supporting them for a very, very > long time :-) But new devices (virtio-qxl being a candidate) don't have old guests and don't need to worry. They could use this if they care about fast isr: legacy layout -- not present new virtio-pci -- present, bar 1, offset 0 new virtio-config -- present, bar 1, offset 256 new virtio-isr -- present, bar 0, offset 0 Or this if they don't worry about isr performance: legacy layout -- not present new virtio-pci -- present, bar 0, offset 0 new virtio-config -- present, bar 0, offset 256 new virtio-isr -- not present > I don't think we gain a lot by moving the ISR into a separate BAR. > Splitting up registers like that seems weird to me too. Main advantage of defining a register set with just isr is that it reduces pio address space consumtion for new virtio devices which don't have to worry about the legacy layout (8 bytes which is minimum size for io bars instead of 64 bytes). > If we added an additional constraints that BAR1 was mirrored except for Why add constraints? We want something future-proof, don't we? >> The detection is simple: if BAR1 has non-zero length, it's new-style, >> otherwise legacy. Doesn't fly. BAR1 is in use today for MSI-X support. > I agree that this is the best way to extend, but I think we should still > use a transport feature bit. We want to be able to detect within QEMU > whether a guest is using these new features because we need to adjust > migration state accordingly. Why does migration need adjustments? [ Not that I want veto a feature bit, but I don't see the need yet ] 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
