On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote: > On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote: > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > > >> To help libvirt in the transition, a x86-cpu-model-dump script is > > >> provided, > > >> that will generate a config file that can be loaded using -readconfig, > > >> based on > > >> the -cpu and -machine options provided in the command-line. > > > > > > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU > > > configuration data to libvirt, but now I think it actually makes sense. > > > We already have a partial copy of CPU model definitions in libvirt > > > anyway, but as QEMU changes some CPU models in some machine types (and > > > libvirt does not do that) we have no real control over the guest CPU > > > configuration. While what we really want is full control to enforce > > > stable guest ABI. > > > > That sounds like FUD to me. Any concrete data points where QEMU does not > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines > > for. > > QEMU provides stable ABI for x86 CPUs only if you use -cpu ...,enforce. > Without enforce the CPU may change everytime a domain is started or > migrated. A small example: let's say a CPU model called "Model" includes > feature "xyz"; when QEMU is started with -cpu Model (no enforce) on a > host which supports xyz, the guest OS will see a CPU with xyz, but when > you migrate it to a host which does not support xyz, QEMU will just > silently drop xyz. In other words, we need to use enforce to make sure > CPU ABI does not change.
Are there really many examples like this? Could someone supply some examples? Eduardo gave examples of CPU changes across machine types but I haven't seen examples where we would break runnability. > But the problem is we can't use enforce because we don't know how a > specific CPU model looks like for a given machine type. Remember, while > libvirt allows users to explicitly ask for a specific CPU model and > features, it also has a mode when libvirt itself computes the right CPU > model and features. And this is impossible with enforce without us > knowing all details about CPU models. > > So there are two possible ways to address this: > 1. enhance QEMU to give us all we need > - either by providing commands that would do all the computations > (CPU model comparison, intersections or denominator, something > like -cpu best) > - or provide a way to probe for all (currently 700+) combinations of > a CPU model and a machine type without actually having to start > QEMU with each CPU and a machine type separately > > 2. manage CPU models in libvirt (aka -cpu custom) > > During the past several years Eduardo tried to do (1) without getting > anywhere close to something that QEMU would be willing to accept. And the reason, presumably, is because it's a hard problem to solve. Why is it easier to solve at the libvirt level? > On the > other hand (2) is a pretty minimal change to QEMU and is more flexible > than (1) because it allows CPU model versions to be decoupled from > machine types (but this was already discussed a lot in the other emails > in this thread). > > Jirka I'm fine with the change itself, it's useful e.g. for testing. But how is it a solution for libvirt's problems? What is libvirt going to do in the above cases? -- MST