Hello Christian, > But yes, I totally agree that since we can't change the current old types (to keep them migratable) we might need to introduce new variants in the Ubuntu LTSes that need this fix. Introducing a new variable which can change the behavior of the code to behave the fixed way. And then need to maintain this type as long as we want to be able to migrate it into future releases.
Right. > Ubuntu's names are like pc-i440fx-noble or pc-q35-noble and just like we've done for e.g. host physical bits where we created `...-hpb` suffixed we'd need to create something like pc-i440fx-noble-amdnoarchcap / pc-q35-noble-amdnoarchcap (and the same for all still active release prior to most recent qemu). Please feel free to tell me if I'm overlooking something or if you agree to that so far. Not quite - I suggest something based on your dot-releases or quarterly releases. E.g.: for qemu launched w/o any parameters, it takes the current default machine type. The current default is pc-q35-noble. That maintains the current behaviour. For your next dot-release, call the new machine type pc-q35-noble.5 (for example - w/o looking up how your dot-releases are named). That's your new default. All VMs launched in the future will then get the fix. For migration compat with VMs started on current/older qemus, you will continue to maintain pc-q35-noble.4 (which is an alias to the current default, w/o the fix). Then, from some higher-level control plane software (virt- manager/openstack/etc.), you launch qemu on the newer releases with the older / non-default machine type only if live-migrating from the previous Ubuntu release. This way, you maintain backwards compatibility (old release -> new release live migration support) in each new dot-release. Forwards compat (launch on newer release, live migrate to older) is not guaranteed, and you update documentation to mention that if it's not there presently. I hope I've broken down the complexity enough to help you see it's not really very complex, just a matter of doing it the first time, and building that muscle. You'll have to write some dedicated test cases to ensure your compat matrix for old->new live migrations keep working as well. Oh, as a bonus, I had written vmstate-static-checker script in the upstream qemu repo that you can also exercise to verify you're not breaking LM compatibility by checking the machine types. Saves a bunch of actual testing time, and you find out whether you're breaking LM in a few seconds each iteration! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2131822 Title: Known Windows 11 KVM Issue AMD KMODE Exception To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
