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-... http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-...
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