> 2. Move device specific features into the device specific region. > Currently the features field is a mix between virtio-pci and device > specific features. A single feature field with bits partitioned to transport specific and device specific fields is a generic virtio thing. So there's relatively little to be gained from moving the device bits out. > I did more similar things in the spec suggestion I've sent, What lacked there is the motivation. I am aware of several issues that need to be addressed, as they block extending virtio going forward: - There's no place to put more transport registers. For MSIX I hacked around that with moving device config when a feature bit is set, but in hindsight this setup is fragile and is panful to extend any further. Splitting out device and transport helps. - PIO space is limited. We are wasting it on non data path configuration. There might also be a wish to have largish data in configuration space, like a 1024 byte ID field. - PIO is faster than MMIO on x86 KVM so we need to keep using it for data path on that architecture - Support architectures which have host/guest at different endian-ness. I addressed the first 3 and added capability infrastructure which we can use in the future to support the last one (by nature of using little endian format for capabilities). > could you > look at the second part for more ideas please? I saw the per-queue features - but I don't see how it will work really or what is the issue they solve. Any more ideas I missed? > -- > > Sasha. -- 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
