On Tue, 13 Mar 2018 09:21:54 +0000 Daniel P. Berrangé <berra...@redhat.com> wrote:
>The subject line says to expect 30 patches, but you've only sent 18 to >the list here. I eventually figured out that the first 12 patches were >in Xen code and so not sent to qemu-devel. > >For future if you have changes that affect multiple completely separate >projects, send them as separate series. ie just send PATCH 00/18 to >QEMU devel so it doesn't look like a bunch of patches have gone >missing. OK, we'll do for next versions. >> A new domain config option was implemented: device_model_machine. >> It's a string which has following possible values: >> - "i440" -- i440 emulation (default) >> - "q35" -- emulate a Q35 machine. By default, the storage interface >> is AHCI. > >Presumably this is mapping to the QEMU -machine arg, so it feels >desirable to keep the same naming scheme. ie allow any of the >versioned machine names that QEMU uses. eg any of "pc-q35-2.x" >versioned types, or 'q35' as an alias for latest, and use >"pc-i440fx-2.x" versioned types of 'pc' as an alias for latest, rather >than 'i440' which is needlessly divering from the QEMU machine type. Yes, it is translated into the '-machine' argument. A direct mapping between the Xen device_model_machine option and QEMU '-machine' argument won't be accepted by Xen maintainers I guess. The main problem with this approach is a requirement to have a match between Xen/libxl and QEMU versions. If, for example, device_model_machine tells something like "pc-q35-2.11" and later we downgrade QEMU to some older version we'll likely have a problem without changing anything in the domain config. So I guess the "use the latest available" approach for machine selection (pc, q35, etc) is the only possible option. Perhaps having the way to specify the exact QEMU machine name and version in a separate domain config parameter (for advanced use) might be feasible. Also, parameter names do not speak for themselves I'm afraid. This way we'll have, for example, device_model_machine="pc" vs device_model_machine="q35"... a bit unclear I think. This may be obvious for a QEMU user, but many Xen users didn't get used to QEMU machines and there might be some wondering why "q35" is not "pc" and why "pc" is an i440 system precisely. Another obstacle here is xen_platform_device option which indirectly selects QEMU machine type for i440 at the moment (pc/xenfv), but this may be addressed by controlling the Xen platform device independently via a separate machine property or '-device xen-platform' like Eduardo Habkost suggested.