Commit Graph

26258 Commits

Author SHA1 Message Date
Erik Skultety
2739a983f2 util: mdev: Use a local variable instead of a direct pointer access
Use a local variable to hold data, rather than accessing the pointer
after calling virMediatedDeviceListAdd (therefore VIR_APPEND_ELEMENT).
Although not causing an issue at the moment, this change is a necessary
prerequisite for tweaking virMediatedDeviceListAdd in a separate patch,
which will take a reference for the source pointer (instead of pointer
value) and will clear it along the way.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-04 07:54:42 +02:00
Michal Privoznik
2f0b3b103b qemuDomainDetachDeviceUnlink: Don't unlink files we haven't created
Even though there are several checks before calling this function
and for some scenarios we don't call it at all (e.g. on disk hot
unplug), it may be possible to sneak in some weird files (e.g. if
domain would have RNG with /dev/shm/some_file as its backend). No
matter how improbable, we shouldn't unlink it as we would be
unlinking a file from the host which we haven't created in the
first place.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
2017-05-03 17:23:03 +02:00
Michal Privoznik
b3418f36be qemuDomainAttachDeviceMknodRecursive: Don't try to create devices under preserved mount points
Just like in previous commit, this fixes the same issue for
hotplug.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
2017-05-03 17:23:03 +02:00
Michal Privoznik
e30dbf35a1 qemuDomainCreateDeviceRecursive: Don't try to create devices under preserved mount points
While the code allows devices to already be there (by some
miracle), we shouldn't try to create devices that don't belong to
us. For instance, we shouldn't try to create /dev/shm/file
because /dev/shm is a mount point that is preserved. Therefore if
a file is created there from an outside (e.g. by mgmt application
or some other daemon running on the system like vhostmd), it
exists in the qemu namespace too as the mount point is the same.
It's only /dev and /dev only that is different. The same
reasoning applies to all other preserved mount points.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
2017-05-03 17:23:03 +02:00
Michal Privoznik
26c14be8d6 qemuDomainCreateDeviceRecursive: pass a structure instead of bare path
Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to
take given @device, get all kinds of info on it (major & minor numbers,
owner, seclabels) and create its copy at a temporary location @path
(usually /var/run/libvirt/qemu/$domName.dev), if @device live under
/dev. This is, however, very loose condition, as it also means
/dev/shm/* is created too. Therefor, we will need to pass more arguments
into the function for better decision making (e.g. list of mount points
under /dev). Instead of adding more arguments to all the functions (not
easily reachable because some functions are callback with strictly
defined type), lets just turn this one 'const char *' into a 'struct *'.
New "arguments" can be then added at no cost.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
2017-05-03 17:23:03 +02:00
Michal Privoznik
a7cc039dc7 qemuDomainBuildNamespace: Move /dev/* mountpoints later
When setting up mount namespace for a qemu domain the following
steps are executed:

1) get list of mountpoints under /dev/
2) move them to /var/run/libvirt/qemu/$domName.ext
3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
4) move the mountpoint of the new device tree to /dev
5) restore original mountpoints from step 2)

Note the problem with this approach is that if some device in step
3) requires access to a mountpoint from step 2) it will fail as
the mountpoint is not there anymore. For instance consider the
following domain disk configuration:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/dev/shm/vhostmd0'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>

In this case operation fails as we are unable to create vhostmd0
in the new device tree because after step 2) there is no /dev/shm
anymore. Leave aside fact that we shouldn't try to create devices
living in other mountpoints. That's a separate bug that will be
addressed later.

Currently, the order described above is rearranged to:

1) get list of mountpoints under /dev/
2) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
3) move them to /var/run/libvirt/qemu/$domName.ext
4) move the mountpoint of the new device tree to /dev
5) restore original mountpoints from step 3)

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cedric Bosdonnat <cbosdonnat@suse.com>
2017-05-03 17:23:03 +02:00
Andrea Bolognani
624bc92661 news: Add more v3.3.0 entries
These entries cover a number of features, improvements and
bug fixes that had not been documented during the development
cycle.
2017-05-03 17:13:48 +02:00
Andrea Bolognani
0d30981344 news: Tweak existing v3.3.0 entries
Some of the content was not following the (loosely established)
style, and some of the XML was not aligned properly.
2017-05-03 17:13:48 +02:00
Jiri Denemark
42faf316ec client: Report proper close reason
When we get a POLLHUP or VIR_EVENT_HANDLE_HANGUP event for a client, we
still want to read from the socket to process any accumulated data. But
doing so inevitably results in an error and a call to
virNetClientMarkClose before we get to processing the hangup event (and
another call to virNetClientMarkClose). However the close reason passed
to the second virNetClientMarkClose call is ignored because another one
was already set. We need to pass the correct close reason when marking
the socket to be closed for the first time.

https://bugzilla.redhat.com/show_bug.cgi?id=1373859

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-05-02 18:53:24 +02:00
Jiri Denemark
59307fade8 qemu: Fix persistent migration of transient domains
While fixing a bug with incorrectly freed memory in commit
v3.1.0-399-g5498aa29a, I accidentally broke persistent migration of
transient domains. Before adding qemuDomainDefCopy in the path, the code
just took NULL from vm->newDef and used it as the persistent def, which
resulted in no persistent XML being sent in the migration cookie. This
scenario is perfectly valid and the destination correctly handles it by
using the incoming live definition and storing it as the persistent one.

After the mentioned commit libvirtd would just segfault in the described
scenario.

https://bugzilla.redhat.com/show_bug.cgi?id=1446205

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-05-02 18:53:19 +02:00
Daniel P. Berrange
71890992da Fix padding of encrypted data
If we are encoding a block of data that is 16 bytes in length,
we cannot leave it as 16 bytes, we must pad it out to the next
block boundary, 32 bytes. Without this padding, the decoder will
incorrectly treat the last byte of plain text as the padding
length, as it can't distinguish padded from non-padded data.

The problem exhibited itself when using a 16 byte passphrase
for a LUKS volume

  $ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \
       $(echo -n 1234567812345678 | base64)
  Secret value set

  $ virsh start demo
  error: Failed to start domain demo
  error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16
  2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \
    secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\
    keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \
    Incorrect number of padding bytes (56) found on decrypted data

Notice how the padding '56' corresponds to the ordinal value of
the character '8'.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-05-02 17:27:13 +01:00
Jiri Denemark
fc48fc7930 qemu: Don't reset "events" migration capability
When creating v3.2.0-77-g8be3ccd04 commit, I completely forgot that one
migration capability is very special. It's the "events" capability which
tells QEMU to report "MIGRATION" events. Since libvirt always wants the
events, it is enabled in qemuConnectMonitor and the rest of the code
should not touch it.

https://bugzilla.redhat.com/show_bug.cgi?id=1439841
https://bugzilla.redhat.com/show_bug.cgi?id=1441165

Messed-up-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-05-02 12:26:35 +02:00
Julio Faracco
4b9af8625a virsh-domain-monitor: add human readable output for 'domblkinfo'.
https://bugzilla.redhat.com/show_bug.cgi?id=1330940

The virsh command 'domblkinfo' returns the capacity, allocation and phisycal
size of the devices attached in a domain. Usually, this sizes are very big
and hard to understand and calculate. This commits introduce a human readable
support to check the size of each field easilly.

For example, the command before:

virsh # domblkinfo my_domain hda
Capacity:       21474836480
Allocation:     14875545600
Physical:       21474836480

and after this patch:

virsh # domblkinfo my_domain hda --human
Capacity:       20.000G
Allocation:     13.900G
Physical:       20.000G

Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-02 09:36:31 +02:00
Jim Fehlig
2fdfe0c98e news: Document libxl nested HVM support
Nested HVM support in the libxl driver is a news-worthy
improvement for libvirt 3.3.0.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2017-04-28 07:55:10 -06:00
Laine Stump
30e672301d util: rename/move VIR_NET_GENERATED_PREFIX to be consistent
... with VIR_NET_GENERATED_MACV???_PREFIX, which is defined in
util/virnetdevmacvlan.h.

Since VIR_NET_GENERATED_PREFIX is used for plain tap devices, it is
renamed to VIR_NET_GENERATED_TAP_PREFIX and moved to virnetdev.h
2017-04-28 09:43:52 -04:00
Laine Stump
9cb891141c conf: don't ignore <target dev='blah'/> for macvtap interfaces
The parser had been clearing out *all* suggested device names for
type='direct' (aka macvtap) interfaces. All of the code implementing
macvtap allows for a user-specified device name, so we should allow
it. In the case that an interface name starts with "macvtap" or
"macvlan" though, we do still clear it out, just as we do with "vnet"
(which is the prefix used for automatically generated tap device
names), since those are the prefixes for the names we autogenerate for
macvtap and macvlan devices.

Resolves: https://bugzilla.redhat.com/1335798
2017-04-28 09:43:52 -04:00
Laine Stump
a05400ef55 util: make macvtap/macvlan generated name #defines available to other files
MACVTAP_NAME_PREFIX and MACVLAN_NAME_PREFIX could be useful to other
files if they were defined in virnetdevmacvlan.h instead of
virnetdevmacvlan.c, so do that (while slightly renaming them and also
adding yet another #define that chooses between macvlan/macvtap based
on flags).

This is a prerequisite to fix: https://bugzilla.redhat.com/1335798
2017-04-28 09:43:52 -04:00
Laine Stump
7949de960e network: better log message when network is inactive during reconnect
If the network isn't active during networkNotifyActualDevice(), we
would log an error message stating that the bridge device didn't
exist. This patch adds a check to see if the network is active, making
the logs more useful in the case that it isn't.

Partially resolves: https://bugzilla.redhat.com/1442700
2017-04-28 09:41:46 -04:00
Laine Stump
cb182eb11d qemu: don't kill qemu process on restart if networkNotify fails
Nothing that could happen during networkNotifyActualDevice() could
justify unceremoniously killing the qemu process, but that's what we
were doing.

In particular, new code added in commit 85bcc022 (first appearred in
libvirt-3.2.0) attempts to reattach tap devices to their assigned
bridge devices when libvirtd restarts (to make it easier to recover
from a restart of a libvirt network). But if the network has been
stopped and *not* restarted, the bridge device won't exist and
networkNotifyActualDevice() will fail.

This patch changes networkNotifyActualDevice() and
qemuProcessNotifyNets() to return void, so that qemuProcessReconnect()
will soldier on regardless of what happens (any errors will still be
logged though).

Partially resolves: https://bugzilla.redhat.com/1442700
2017-04-28 09:41:34 -04:00
Pavel Hrdina
2b7d516434 conf: format only relevant attributes for graphics based on listen type
This patch changes following output:

    ...
    <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='none'/>
    </graphics>
    ...

into this output:

    ...
    <graphics type='vnc'>
      <listen type='none'/>
    </graphics>
    ...

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-28 14:24:05 +02:00
Michal Privoznik
d111f52c35 iohelper: Remove unused mode
After 1eb6647979 nobody calls the iohelper with 6 arguments.
Everybody uses the other mode. Well, the only user of iohelper
after the previous commit is virFileWrapperFd really.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Michal Privoznik
d1a60f4c3b virfdstream: Drop iohelper in favour of a thread
Currently we use iohelper for virFDStream implementation. This is
because UNIX I/O can lie sometimes: even though a FD for a
file/block device is set as unblocking, actual read()/write() can
block. To avoid this, a pipe is created and one end is kept for
read/write while the other is handed over to iohelper to
write/read the data for us. Thus it's iohelper which gets blocked
and not our event loop.

This approach has two problems:
1) we are spawning a new process.
2) any exchange of information between daemon and iohelper can be
done only through the pipe.

Therefore, iohelper is replaced with an implementation in thread
which is created just for the stream lifetime. The data are still
transferred through pipe (for now), but both problems described
above are solved.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Michal Privoznik
585eb46920 virFDStreamData: Turn into virObjectLockable
While this is no functional change, it makes the code look a bit
nicer. Moreover, it prepares ground for future work.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Michal Privoznik
58667ddd5b fdstream: s/struct virFDStreamData */virFDStreamDataPtr/
There is really no reason why we should have to have 'struct'
everywhere.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Michal Privoznik
b8ef4758f3 fdstreamtest: Print more info on read failure
It helps with debugging if we know what's the return value of
saferead().

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Michal Privoznik
1cb23be2a5 fdstreamtest: Rename tempdir
Because of copy-paste the temporary directory used for this test
is called "fakesysdir". That's probably misleading.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-04-28 14:17:10 +02:00
Pavel Hrdina
568887a32f qemu: use qemu-xhci USB controller by default for ppc64 and aarch64
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 10:47:12 +02:00
Pavel Hrdina
278e70f8f8 qemu: add support for qemu-xhci USB controller
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 10:44:36 +02:00
Pavel Hrdina
5237a74d4a qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 10:44:03 +02:00
Pavel Hrdina
233f8d0bd4 qemu: use nec-usb-xhci as a default controller for aarch64 if available
This is a USB3 controller and it's a better choice than piix3-uhci.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 10:42:26 +02:00
Pavel Hrdina
e69001b464 qemu: change the logic of setting default USB controller
The new logic will set the piix3-uhci if available regardless of
any architecture and it will be updated to better model based on
architecture and device existence.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 10:41:53 +02:00
Peter Krempa
ef0bb841c9 tests: genericxml2xml: Add test case for HTTP based disk 2017-04-28 10:22:40 +02:00
Peter Krempa
326c0d4196 conf: Extract formatting of network disk source into separate function 2017-04-28 10:22:40 +02:00
Peter Krempa
d2e6bef305 docs: schemas: Split up definitions for NBD and gluster
NBD does not mandate a "filename". Gluster can have more servers. Split
them so that we can tighten the schema.
2017-04-28 10:22:22 +02:00
Peter Krempa
3240b8324c docs: schemas: Split out simple network protocols
ftp/tftp/sheepdog have a mandatory filename and support only one host.
There are no additional options for them.
2017-04-28 09:48:26 +02:00
Peter Krempa
bde5c2f532 docs: schemas: Extract HTTP disk source specification
Make the schema more strict for HTTP disks requiring a name and
mandating exactly one source host.

ftp/tftp entries were not moved here, since http transport also will
support cookies and other options, which will be added later.
2017-04-28 09:48:26 +02:00
Peter Krempa
9030fab20c docs: schemas: Extract RBD-specific data
RBD driver supports specifying a snapshot image name or config file.
Create a define for RBD and move the specifics there.
2017-04-28 09:48:26 +02:00
Peter Krempa
1779e378f8 docs: schemas: Move the interleave definition into network disk source
Move it to the place where actually interleaving elements can be placed.
2017-04-28 09:48:26 +02:00
Peter Krempa
47b947a0a3 docs: schemas: Extract disk source host specification
'diskSourceNetwork' schema define was rather big and it would be hard to
simplify it. Split out the host portion subelement into a separate
define.
2017-04-28 09:48:26 +02:00
Peter Krempa
8a99095cc6 docs: schemas: Remove <interleave> from file/block/dir/volume disks
They don't contain any elements to interleave.
2017-04-28 09:48:26 +02:00
Peter Krempa
9f16bb7386 qemu: Don't fail if physical size can't be updated in qemuDomainGetBlockInfo
Since commit c5f6151390 qemuDomainBlockInfo tries to update the
"physical" storage size for all network storage and not only block
devices.

Since the storage driver APIs to do this are not implemented for certain
storage types (RBD, iSCSI, ...) the code would fail to retrieve any data
since the failure of qemuDomainStorageUpdatePhysical is fatal.

Since it's desired to return data even if the total size can't be
updated we need to ignore errors from that function and return plausible
data.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442344
2017-04-28 09:44:25 +02:00
Peter Krempa
44f8e00b6b qemu: Move freeing of PCI address list to qemuProcessStop
Rather than freeing the list before starting a new VM clear it after
stopping the old instance when the data becomes invalid.
2017-04-28 09:26:24 +02:00
Peter Krempa
8c1fee5f12 qemu: process: Clean up priv->migTLSAlias
The alias would be leaked, since it's not freed on the vm stop path.
2017-04-28 09:26:24 +02:00
Peter Krempa
3ab802d689 qemu: process: Don't leak priv->usbaddrs after VM restart
Since the private data structure is not freed upon stopping a VM, the
usbaddrs pointer would be leaked:

==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019
==15388==    at 0x4C2CF55: calloc (vg_replace_malloc.c:711)
==15388==    by 0x54BF64A: virAlloc (viralloc.c:144)
==15388==    by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608)
==15388==    by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458)
==15388==    by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515)
==15388==    by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398)
==15388==    by 0x144F51FF: qemuProcessStart (qemu_process.c:5979)
[...]
2017-04-28 09:26:24 +02:00
Peter Krempa
1730cdc665 qemu: process: Clean automatic NUMA/cpu pinning information on shutdown
Clean the stale data after shutting down the VM. Otherwise the data
would be leaked on next VM start. This happens due to the fact that the
private data object is not freed on destroy of the VM.
2017-04-28 09:26:24 +02:00
Wim ten Have
5ade0ff905 xlconfigtest: add tests for 'nestedhvm' support
Testing various configuration schemas targeting postive and negative
nestedhvm under libvirt <cpu mode="host-passthrough"> configuration.

Mode "host-passthrough" generates nestedhvm=1 in/from xl format where

Intel virtualization (VT-x):
<feature policy='disable' name='vmx'/>

    or

AMD virtualization (AMD-V):
<feature policy='disable' name='svm'/>

disables virtualization mode under guest domains.

Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2017-04-27 15:05:44 -06:00
Wim ten Have
8659e7ffe3 xenconfig: add conversions for xen-xl
Per xen-xl conversions from and to native under host-passthrough
mode we take care for Xen (nestedhvm = mode) applied and inherited
settings generating or processing correct feature policy:

[On Intel (VT-x) architectures]
<feature policy='disable' name='vmx'/>

or

[On AMD (AMD-V) architectures]
<feature policy='disable' name='svm'/>

It will then generate (or parse) for nestedhvm=1 in/from xl format.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
2017-04-27 15:05:44 -06:00
Wim ten Have
c268b9eaeb libxl: set nestedhvm for mode host-passthrough
Xen feature nestedhvm is the option on Xen 4.4+ which enables
nested virtualization when mode host-passthrough is applied.

nested HVM is enabled by adding below on the target domain;
<cpu mode='host-passthrough'/>

Virtualization on target domain can be disabled by specifying
such under feature policy rule on target name;

[On Intel (VT-x) architecture]
<feature policy='disable' name='vmx'/>

or:

[On AMD (AMD-V) architecture]
<feature policy='disable' name='svm'/>

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
2017-04-27 15:05:44 -06: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
Jiri Denemark
a646a6016a Add support for CPU cache specification
This patch introduces

    <cache level='N' mode='emulate'/>
    <cache mode='passthrough'/>
    <cache mode='disable'/>

sub element of /domain/cpu. Currently only a single <cache> element is
allowed.

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