Commit Graph

2 Commits

Author SHA1 Message Date
Cole Robinson
56540950e7 qemu: command: always use -chardev for monitor config
AFAIK there aren't any cases where we will/should hit the old code
path for our supported qemu versions, so drop the old code.

Massive test suite churn follows

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2017-07-10 16:59:38 -04:00
Jiri Denemark
df13c0b477 qemu: Add support for guest CPU cache
This patch maps /domain/cpu/cache element into -cpu parameters:

- <cache mode='passthrough'/> is translated to host-cache-info=on
- <cache level='3' mode='emulate'/> is transformed into l3-cache=on
- <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off

Any other <cache> element is forbidden.

The tricky part is detecting whether QEMU supports the CPU properties.

The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480,
earlier QEMU releases enabled host-cache-info by default and had no way
to disable it. If the property is present, it defaults to 'off' for any
QEMU until at least 2.9.0.

The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa.
Earlier versions worked as if l3-cache=off was passed. For any QEMU
until at least 2.9.0 l3-cache is 'off' by default.

QEMU 2.9.0 was the first release which supports probing both properties
by running device-list-properties with typename=host-x86_64-cpu. Older
QEMU releases did not support device-list-properties command for CPU
devices. Thus we can't really rely on probing them and we can just use
query-cpu-model-expansion QMP command as a witness.

Because the cache property probing is only reliable for QEMU >= 2.9.0
when both are already supported for quite a few releases, we let QEMU
report an error if a specific cache mode is explicitly requested. The
other mode (or both if a user requested CPU cache to be disabled) is
explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case
the QEMU defaults change. Any older QEMU already turns them off so not
doing so explicitly does not make any harm.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-27 22:41:10 +02:00