[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device supp
From: |
Alexey G |
Subject: |
Re: [Qemu-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35 |
Date: |
Tue, 13 Mar 2018 06:56:37 +1000 |
On Mon, 12 Mar 2018 16:44:06 -0300
Eduardo Habkost <address@hidden> wrote:
>On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote:
>> Current Xen/QEMU method to control Xen Platform device on i440 is a
>> bit odd -- enabling/disabling Xen platform device actually modifies
>> the QEMU emulated machine type, namely xenfv <--> pc.
>>
>> In order to avoid multiplying machine types, use a new way to
>> control Xen Platform device for QEMU -- "xen-platform-dev" machine
>> property (bool). To maintain backward compatibility with existing
>> Xen/QEMU setups, this is only applicable to q35 machine currently.
>> i440 emulation still uses the old method (i.e. xenfv/pc machine
>> selection) to control Xen Platform device, this may be changed later
>> to xen-platform-dev property as well.
>>
>> This way we can use a single machine type (q35) and change just
>> xen-platform-dev value to on/off to control Xen platform device.
>>
>> Signed-off-by: Alexey Gerasimenko <address@hidden>
>> ---
>[...]
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 6585058c6c..cee0b92028 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -38,6 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
>> " dump-guest-core=on|off include guest memory in
>> a core dump (default=on)\n" " mem-merge=on|off
>> controls memory merge support (default: on)\n" "
>> igd-passthru=on|off controls IGD GFX passthrough support
>> (default=off)\n"
>> + " xen-platform-dev=on|off controls Xen Platform
>> device (default=off)\n" " aes-key-wrap=on|off
>> controls support for AES key wrapping (default=on)\n"
>> " dea-key-wrap=on|off controls support for DEA key
>> wrapping (default=on)\n" " suppress-vmdesc=on|off
>> disables self-describing migration (default=off)\n"
>
>What are the obstacles preventing "-device xen-platform" from
>working? It would be better than adding a new boolean option to
>-machine.
I guess the initial assumption was that changing the
xen_platform_device value in Xen's options may cause some additional
changes in platform configuration besides adding (or not) the Xen
Platform device, hence a completely different machine type was chosen
(xenfv).
At the moment pc,accel=xen/xenfv selection mostly governs
only the Xen Platform device presence. Also setting max_cpus to
HVM_MAX_VCPUS depends on it, but this doesn't applicable to a
'pc,accel=xen' machine for some reason.
If applying HVM_MAX_VCPUS to max_cpus is really necessary I think it's
better to set it unconditionally for all 'accel=xen' HVM machine
types inside xen_enabled() block. Right now it's missing for
pc,accel=xen and q35,accel=xen.
I'll check if supplying the Xen platform device via the '-device' option
will be ok for all usage cases.
[Qemu-devel] [RFC PATCH 18/30] xen/pt: XenHostPCIDevice: provide functions for PCI Capabilities and PCIe Extended Capabilities enumeration, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 19/30] xen/pt: avoid reading PCIe device type and cap version multiple times, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 20/30] xen/pt: determine the legacy/PCIe mode for a passed through device, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 21/30] xen/pt: Xen PCIe passthrough support for Q35: bypass PCIe topology check, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 22/30] xen/pt: add support for PCIe Extended Capabilities and larger config space, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 23/30] xen/pt: handle PCIe Extended Capabilities Next register, Alexey Gerasimenko, 2018/03/12
[Qemu-devel] [RFC PATCH 24/30] xen/pt: allow to hide PCIe Extended Capabilities, Alexey Gerasimenko, 2018/03/12