On 20.10.2017 13:09, Marc Hartmayer wrote: > On Thu, Oct 12, 2017 at 02:07 PM +0200, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: >> On Mon, Oct 09, 2017 at 10:16:48 +0200, Marc Hartmayer wrote: >>> On Thu, Oct 05, 2017 at 02:11 PM +0200, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: >>>> But it's going to be a bit complicated because we ask QEMU what the >>>> host CPU is and the interface we used would need to be enhanced to >>>> give us different results for all supported machine types so that we >>>> can select the right one when a domain is started. >>> >>> So how do we deal with this? >> >> I think we need to start discussing this on qemu-devel list. If I >> remember correctly, David Hildenbrand is the original author of the >> query-cpu-model-expansion QMP command. >> >> Please, Cc me so that the thread is more visible to me. >> >> Thanks, >> >> Jirka >> > > Hi all, > > we recently encountered the problem that the 'host-model' [1] has to be > related to the machine type of a domain. We have following problem: > > Let's assume we've a z13 system with a QEMU 2.9 and we define a > domain using the default s390-virtio-ccw machine together with the > host-model CPU mode [1]. The definition will have the machine > expanded to s390-virtio-ccw-2.9 but retain the host-model CPU mode > in the domain definition. In a next step we upgrade to QEMU 2.10 > (first version to recognize z14). Everything is still fine, even > though the machine runs in 2.9 compatibility mode. Finally we > upgrade to a z14. As a consequence it is not possible to start the > domain anymore as the machine type doesn't support our CPU host > model (which is expanded at start time of the domain). Yes, the host model may vary depending on QEMU version and to some degree also on compatibility machines (although I always try to push people to not introduce any new such stuff). Quoting for the libvirt documentation: https://libvirt.org/formatdomain.html "host-model The host-model mode is essentially a shortcut to copying host CPU definition from capabilities XML into domain XML. Since the CPU definition is copied just before starting a domain, exactly the same XML can be used on different hosts while still providing the best guest CPU each host supports." You're telling me that that copying does not happen, which seems to be the problematic part about this in my opinion. So I am not sure if probing anything else (as you noted below) is the correct thing to do. Copy it and you have a migration_safe and even static version of the _current_ host CPU. > > For determining the actual host-model the QMP command > 'query-cpu-model-expansion' is used. This is done once per QEMU binary > and the result of it is cached by libvirt. The problem with that is > that libvirt queries with the newest machine type of the QEMU binary > for the host CPU model. But now we realized that we have to consider > the machine type of each domain for the determination of the host CPU > model of a domain. > > We could now either probe the host CPU model for each QEMU binary + > machine type combination and for this we've to start a new QEMU > process each time. Or we can add a QMP command/parameter that allows > us to determine the host CPU model(s) with respect to the passed > machine type and/or all supported machine types. > > The QMP command query-cpu-model-expansion is currently described in > qapi-schema.json as follows: > > <quotation> > ## > # @query-cpu-model-expansion: > # > # Expands a given CPU model (or a combination of CPU model + additional options) > # to different granularities, allowing tooling to get an understanding what a > # specific CPU model looks like in QEMU under a certain configuration. > # > # This interface can be used to query the "host" CPU model. > # > # The data returned by this command may be affected by: > # > # * QEMU version: CPU models may look different depending on the QEMU version. > # (Except for CPU models reported as "static" in query-cpu-definitions.) > # * machine-type: CPU model may look different depending on the machine-type. > # (Except for CPU models reported as "static" in query-cpu-definitions.) > # * machine options (including accelerator): in some architectures, CPU models > # may look different depending on machine and accelerator options. (Except for > # CPU models reported as "static" in query-cpu-definitions.) > # * "-cpu" arguments and global properties: arguments to the -cpu option and > # global properties may affect expansion of CPU models. Using > # query-cpu-model-expansion while using these is not advised. > # > # Some architectures may not support all expansion types. s390x supports > # "full" and "static". > # > # Returns: a CpuModelExpansionInfo. Returns an error if expanding CPU models is > # not supported, if the model cannot be expanded, if the model contains > # an unknown CPU definition name, unknown properties or properties > # with a wrong type. Also returns an error if an expansion type is > # not supported. > # > # Since: 2.8.0 > ## > { 'command': 'query-cpu-model-expansion', > 'data': { 'type': 'CpuModelExpansionType', > 'model': 'CpuModelInfo' }, > 'returns': 'CpuModelExpansionInfo' } > > 4:46:25 PM > ◄ > qapi-schema.json > </quotation> > > What do you think? > > Thank you. > > Marc > > > > [1] https://libvirt.org/formatdomain.html#elementsCPU > > -- > Beste Grüße / Kind regards > Marc Hartmayer > > IBM Deutschland Research & Development GmbH > Vorsitzende des Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > -- Thanks, David -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
