On Thu, Aug 23, 2018 at 06:08:55PM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > > > On Wed, Aug 22, 2018 at 01:26:01PM +0100, Daniel P. Berrangé wrote: > >> On Wed, Aug 22, 2018 at 09:01:35AM -0300, Eduardo Habkost wrote: > >> > On Wed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote: > >> > > On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote: > >> > > > On 08/17/2018 06:35 AM, Andrea Bolognani wrote: > >> > > > > If we decide we want to explicitly spell out the options instead > >> > > > > of relying on QEMU changing behavior based on the slot type, which > >> > > > > is probably a good idea anyway, I think we should have > >> > > > > > >> > > > > virtio-0.9 => disable-legacy=no,disable-modern=no > >> > > > > virtio-1.0 => disable-legacy=yes,disable-modern=no > >> > > > > > >> > > > > There's basically no reason to have a device legacy-only rather > >> > > > > than transitional, and spelling out both options instead of only > >> > > > > one of them just seems more robust. > >> > > > > >> > > > I agree with both of those, but the counter-argument is that "virtio" > >> > > > already describes a transitional device like your proposal for > >> > > > virtio-0.9 (at least today), and it makes the versioned models less > >> > > > orthogonal. In the end, I could go either way... > >> > > > >> > > Yeah, Dan already made that argument and convinced me that we > >> > > should use virtio-0.9 for legacy only, virtio-1.0 for modern only > >> > > and plain virtio for no enforced behavior / transitional. > >> > > >> > I don't understand why we are optimizing the new system for the > >> > less useful use cases: > >> > > >> > I don't see a use case where virtio-0.9 (legacy-only) would be > >> > more useful than virtio-transitional. I don't see why anybody > >> > would prefer a legacy-only device instead of a transitional > >> > device. Even if your guest has only legacy drivers, it might be > >> > upgraded and get new drivers in the future. > >> > > >> > I don't see a use case where virtio-1.0 (modern-only) would be > >> > more useful than "virtio". If you are running i440fx, you get a > >> > transitional device with "virtio", and I don't see why anybody > >> > would prefer a modern-only device. If you are running Q35, you > >> > already get a modern-only device with "virtio". > >> > > >> > The most useful feature users need is the ability to ask for a > >> > transitional virtio device on Q35, and this use case is > >> > explicitly being left out of the proposal. Why? > >> > >> You can already get a transitional device on Q35, albeit with manual > >> placement. Adding flags for magic placement for the existing devices > >> is not something that is suitable for the XML. The ability to get > >> legacy-only, or modern-only doesn't exist today in any way, so that > >> would be a valid new feature. > > > > Transitional devices and modern-only devices are different kinds > > of devices. Making the guest see a different type of device > > depending on where it's plugged is why we got into this mess, > > Every time we make -device FOO result in a different device depending on > context, device configuration or placement, it eventually joins our > collection of Very Bad Ideas. Different PCI device IDs are a clear > indicator of device difference. > > Instances of this class of Very Bad Ideas I've addressed myself: > > * I deprecated "ivshmem" in favor of "ivshmem-plain" and > "ivshmem-doorbell". > > * I split "ide-drive" into of "ide-hd" and "ide-cd" (deprecation wasn't > fashionable back then) > > * I split "scsi-disk" into "scsi-hd" and "scsi-cd" (likewise) > > One time pain, long term gain. The pain in those three cases was largely non-existant and/or hidden. Almost no one ever used ivshmem, so by extension almost no one was impacted by need to use different names. It was also not migratable, so there was no need to care about compatibility with older versions. For ide-drive/scsi-disk, the change was completely hidden inside libvirt and wasn't ABI sensitive so didn't affect apps or migration. > We should consider addressing virtio devices, too: deprecate the > chameleon device models an adequate grace period. The change discussed here would have major impact by comparison as it would be telling every single app to change what they do, and the change would prevent their guests being compatible with older libvirt. I don't think the gain outweighs the costs of making the changes across every mgmt app, even ignoring the cost of the backcompatibility problems > >> 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 strenously disagree. This is first and foremost about correcting a > design mistake we made. > > > 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. > > I would be willing to listen a reasoned argument why correcting the > design mistake is not worthwhile. I'm unwilling to listen to more > downstream blaming. Please stop it. There are countless mistakes in both QEMU & libvirt, but only some of them are worth the cost of changing. I'm not seeing a compelling reason why this change is worthwhile. The impact of the design mistake is narrow and only raised because of downstream desire to change even legacy OS to use Q35 when there's no benefit to those OS of such a change. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
