On Wed, Aug 22, 2018 at 03:57:20PM +0100, Daniel P. Berrangé wrote: > On Wed, Aug 22, 2018 at 11:18:28AM -0300, Eduardo Habkost wrote: > > On Wed, Aug 22, 2018 at 02:44:40PM +0100, Daniel P. Berrangé wrote: [...] > > > An explicit virtio-transitional device is still two separate > > > devices pretending to be the same thing, but magically changing > > > their identity at runtime. We've already got that situation with > > > existing device models, and I'm loathe to see us add 2nd device > > > model with that same behaviour, just for sake of having a slightly > > > different PCI bus placement strategy to support outdated guest OS. > > > > Your seem to be describing what the current "virtio" device is: > > it becomes a non-transitional (modern-only) Virtio device on some > > cases, and becomes a transitional Virtio device on other cases. > > It is two devices pretending to be the same thing. That's > > exactly what I would like applications to get rid of. > > > > Now, the above is really not an accurate description of > > transitional Virtio devices. A transitional Virtio device is > > something clearly specified in the Virtio spec, and it just means > > a device that supports two types of drivers. It's not different > > from a x86_64 CPU that can run 32-bit OSes. > > > > See: > > http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-60001 > > http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-3090004 > > When I say a device pretending to be 2 different devices, I'm > generally referring to the fact that a single QEMU device model > can expose two different PCI device IDs depending on how it is > configured and/or placed. Understood. Then you are not describing transitional Virtio, you are just describing QEMU's disable-legacy=auto behavior (which is the default). > > > > > > Honestly though, the longer this discussion goes on, the more I think > > > > > the answer is just "do nothing". All this time spent on discussion, > > > > > and future time spent on implementing new logic in apps, is merely > > > > > to support running RHEL-6 on Q35. I think we should just say that > > > > > RHEL-6 should use i440fx forever and be done with it. > > > > > > > > I'm not sure if you are saying that we (Red Hat) shouldn't spend > > > > time implementing it, or that the libvirt upstream project should > > > > reject the patches if somebody implements it. I would understand > > > > the former, but not the latter. > > > > > > Even if someone is willing to implement it in libvirt, we have to > > > consider the cost of supporting it in both libvirt and applications > > > using libvirt and the complexity it adds to our story about the > > > docs / best practices for configuring guests. > > > > > > Even though I do kind of like the virtio-0.9/virtio-1.0 device model > > > as concepts, I'm yet to be convinced that implementing them in libvirt > > > and then also in all the downstream applications (oVirt, OpenStack, > > > virt-manager, cockpit, etc) is actually worth the cost. > > > > > > There's little compelling reason to care about running outdated OS > > > like RHEL-6 on Q35 in general. The motivation behind it is just > > > coming from an artifically created problem downstream, by wishing > > > to drop the i440fx machine at some still undeteremined point in the > > > future. By the time that future comes, RHEL-6 may well even be > > > end of life making the entire exercise a pointless. > > > > I'm all for making a cost/benefit analysis, but I don't think you > > are taking into account the costs of keeping the confusing > > semantics of existing "virtio" devices. > > > > If you still want to refuse to provide a sane way to configure > > transitional Virtio devices, I really won't care. But I believe > > the interface you are trying to keep is actually the one you are > > criticizing ("two separate devices pretending to be the same > > thing, but magically changing their identity at runtime"). > > Yeah, I guess I should make a distinction between what I would > do if it was a clean slate, and what we should do given our existing > practice. > > If we had a clean slate I would not like to see our current impl > done. Given that it already exists, however, we're stuck with > that forever. So the question is whether implementing any of > the alternative options is a net benefit for libvirt & mgmt apps > overall. My gut feeling is that despite the downsides of the > current impl, it is not worth trying todo something different. Fair enough. > > The thing that has really tipped my mind this way is that even > if we provide new device models, mgmt apps will be loathe to > actually use them because it will prevent live migration of > those guests to hosts with older libvirt. This might be an issue for some apps, but is it going to happen in practice? Don't they all need mechanisms to flip a switch and enable features that require newer host software, already? > > So my feeling is we should do the work to enable use of Q35 > by default in mgmt apps, for guest OS where it is known to > work correctly today. Every other OS should just stick with > i440fx as we already know that works for them today and Q35 > doesn't offer legacy OS compelling enough benefits to switch. I'd still prefer if libvirt provided a saner configuration mechanism, and let libosinfo and management apps decide what works best for them. If it helps, I can send QEMU patches to make virtio-0.9/virtio-1.0-non-transitional/virtio-1.0-transitional appear as different device types. libvirt would then be able to check if the device type implements "pci-express-device" or "conventional-pci-device", instead of adding device-specific placement logic. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
