CVE-2018-12126, CVE-2018-12127, CVE-2018-12130

The bit is set when microcode provides the mechanism to invoke a flush
of various exploitable CPU buffers by invoking the VERW instruction.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 538d8735)

Conflicts:
	src/cpu_map/x86_features.xml
            - no CPU map split downstream

	tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-guest.xml
	tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-host.xml
            - test data missing downstream

	tests/cputestdata/x86_64-cpuid-Xeon-E3-1225-v5-guest.xml
	tests/cputestdata/x86_64-cpuid-Xeon-E3-1225-v5-host.xml
            - intel-pt feature is missing downstream
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 5cd9db3a)

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091

Conflicts:
	tests/cputestdata/x86_64-cpuid-Xeon-E3-1225-v5-guest.xml
	tests/cputestdata/x86_64-cpuid-Xeon-E3-1225-v5-host.xml
            - intel-pt feature is missing
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

My earlier commit be46f613 was incomplete. It removed caching of
microcode version in the CPU driver, which means the capabilities XML
will see the correct microcode version. But it is also cached in the
QEMU capabilities cache where it is used to detect whether we need to
reprobe QEMU. By missing the second place, the original commit
be46f613 made the situation even worse since libvirt would report
correct microcode version while still using the old host CPU model
(visible in domain capabilities XML).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit 673c62a3)

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130

Conflicts:
	src/qemu/qemu_capabilities.c
            - virQEMUCapsCacheLookupByArch refactoring (commits
              7948ad41 and 1a3de670) are missing
            - commit a7424faf "Force QMP capability probing" is
              missing downstream
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Sometimes we don't regenerate QEMU capabilities replies using QEMU
binary but we simply add a new entry manually.  In that case you need
to manually fix all the replies ids.  This helper will do that for you.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The libvirt_storage_backend_sheepdog_priv.la library depends on symbols
provided in the libvirt_driver_storage_impl.la library. As such the
latter must be listed 2nd when passed to the linker to avoid symbol
resolution problems. This mistake is being masked by the sheepdog
driver linking in a second copy of the storage driver code. Remove
this duplicate linkage of backend source and fix the test link order.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Let's use virPortAllocatorRelease instead of virPortAllocatorSetUsed(false).
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

This flag is only used for tests. Let's instead overload bind syscall
in mocks where it is not done yet.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Range check in virPortAllocatorSetUsed is not useful anymore
when we manage ports for entire unsigned short range values.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Range check in virPortAllocatorSetUsed is not useful anymore
when we manage ports for entire unsigned short range values.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Host tcp4/tcp6 ports is a global resource thus we need to make
port accounting also global or we have issues described in [1] when
port allocator ranges of different instances are overlapped (which
is by default for qemu for example).

Let's have only one global port allocator object that take care
of the entire ports range (0 - 65535) and introduce port range object
for clients to specify desired auto allocation band.

[1] https://www.redhat.com/archives/libvir-list/2017-December/msg00600.htmlSigned-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

libxl supports setting the domain real time clock to local time or
UTC via the localtime field of libxl_domain_build_info. Adjustment
of the clock is also supported via the rtc_timeoffset field. The
libvirt libxl driver has never supported these settings, instead
relying on libxl's default of a UTC real time clock with adjustment
set to 0.

There is at least one user that would like the ability to change
the defaults

https://www.redhat.com/archives/libvirt-users/2018-February/msg00059.html

Add support for specifying a local time clock and for specifying an
adjustment for both local time and UTC clocks. Add a test case to
verify the XML to libxl_domain_config conversion.

Local time clock and clock adjustment is already supported by the
XML <-> xl.cfg converter. What is missing is an explicit test for
the conversion. There are plenty of existing tests that all use UTC
with 0 adjustment. Hijack test-fullvirt-tsc-timer to test a local
time clock with 1 hour adjustment.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This file was modified in an editor buffer but not saved prior to
commit e62cb4a9 (which removed virMacAddr::generated), so the bhyve
build would fail.
Signed-off-by: NLaine Stump <laine@laine.org>

Commit 7e62c4cd (first appearing in libvirt-3.9.0 as a resolution
to rhbz #1343919) added a "generated" attribute to virMacAddr that was
set whenever a mac address was auto-generated by libvirt. This
knowledge was used in a single place - when trying to match a NetDef
from the Domain to Delete with user-provided XML. Since the XML parser
always auto-generates a MAC address for NetDefs when none is provided,
it was previously impossible to make a search where the MAC address
isn't significant, but the addition of the "generated" attribute made
it possible for the search function to ignore auto-generated MACs.

This implementation had a problem though - it was adding a field to a
"low level" struct - virMacAddr - which is used in other places with
the assumption that it contains exactly a 6 byte MAC address and
nothing else. In particular, virNWFilterSnoopEthHdr uses virMacAddr as
part of the definition of an ethernet packet header, whose layout must
of course match an actual ethernet packet. Adding the extra bools into
virNWFilterSnoopEthHdr caused the nwfilter driver's "IP discovery via
DHCP packet snooping" functionality to mysteriously stop working.

In order to fix that behavior, and prevent potential future similar
odd behavior, this patch moves the "generated" member out of
virMacAddr (so that it is again really is just a MAC address) into
virDomainNetDef, and sets it only when virDomainNetGenerateMAC() is
called from virDomainNetDefParseXML() (which is the only time we care
about it).

Resolves: https://bugzilla.redhat.com/1529338

(It should also be applied to any maintenance branch that applies
commit 7e62c4cd and friends to resolve
https://bugzilla.redhat.com/1343919)
Signed-off-by: NLaine Stump <laine@laine.org>

It is very difficult while reading the migration code trying to
understand whether a particular function is being called on the src side
or the dst side, or either. Putting "Src" or "Dst" in the method names will
make this much more obvious. "Any" is used in a few helpers which can be
called from both sides.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Further cleanup from

  commit 0c63c117
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Fri Feb 9 15:08:53 2018 +0000

    conf: reimplement virDomainNetResolveActualType in terms of public API
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The qemuxml2argvtest does not need to link to the network driver
after this commit:

  commit 0c63c117
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Fri Feb 9 15:08:53 2018 +0000

    conf: reimplement virDomainNetResolveActualType in terms of public API
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When setting up graphics, we sometimes need to resolve networks,
requiring the caller to pass in a virConnectPtr, except sometimes they
pass in NULL. Use virGetConnectNetwork() to acquire the connection to
the network driver when it is needed.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

During domain startup there are many places where we need to acquire
secrets. Currently code passes around a virConnectPtr, except in the
places where we pass in NULL. So there are a few codepaths where ability
to start guests using secrets will fail. Change to acquire a handle to
the secret driver when needed.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Rather than expecting callers to pass a virConnectPtr into the
virDomainDiskTranslateSourcePool() method, just acquire a connection
to the storage driver when needed.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

There is a long standing hack to pass a virConnectPtr into the
qemuMonitorStartCPUs method, so that when the text monitor prompts
for a disk password, we can lookup virSecretPtr objects. This causes
us to have to pass a virConnectPtr around through countless methods
up the call chain....except some places don't have any virConnectPtr
available so have always just passed NULL. We can finally fix this
disastrous design by using virGetConnectSecret() to open a connection
to the secret driver at time of use.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Now that we have the ability to easily open connections to secondary
drivers, eg network:///system,  it is possible to reimplement the
virDomainNetResolveActualType method in terms of the public API. This
avoids the need to have the network driver provide a callback for it.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This wires up the previously added Chassis strings XML schema to be able to
generate comamnd line args for QEMU. This requires QEMU >= 2.1 release
containing this patch:

SMBIOS: Build aggregate smbios tables and entry point
https://git.qemu.org/?p=qemu.git;a=commit;h=c97294ec1b9e36887e119589d456557d72ab37b5Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This type of information defines attributes of a system
chassis, such as SMBIOS Chassis Asset Tag.

access inside VM (for example)
Linux:   /sys/class/dmi/id/chassis_asset_tag.
Windows: (Get-WmiObject Win32_SystemEnclosure).SMBIOSAssetTag
          wirhin Windows PowerShell.

As an example, add the following to the guest XML

    <chassis>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='version'>2.12</entry>
      <entry name='serial'>65X0XF2</entry>
      <entry name='asset'>40000101</entry>
      <entry name='sku'>Type3Sku1</entry>
    </chassis>
Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We can't really detect all the authentication data in a sane manner for
disk backing chains. Since the old RBD parser parses it in some cases as
the argv->XML convertor requires it, we can't just drop it.

Instead clear any detected authentication data in the code paths related
to disk backing chain lookup and fix the tests to cope with the change.

https://bugzilla.redhat.com/show_bug.cgi?id=1544659Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Use the new syntax which uses the 'UnixSocket' type in qemu.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

virshtest execves the virsh binary. Make sure that it finds the binary's
location independent of the current working directory by specifying the
absolute path as determined by the build environment.
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Give them better names and remove some redundancy.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When no GIC version is specified, we currently default to GIC v2;
however, that's not a great default, since guests will fail to
start if the hardware only supports GIC v3.

Change the behavior so that a sensible default is chosen instead.
That basically means using the same algorithm whether the user
didn't explicitly enable the GIC feature or they explicitly
enabled it but didn't specify any GIC version.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Account for the fact that the default might change based on what
GIC versions are supported by QEMU. That's not the case at the
moment, but it will be soon.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Keep them along with other arch/machine type checks for
features instead of waiting until command line generation
time.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The previous commit:

  commit a455d41e
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Jan 25 09:35:50 2018 +0000

    conf: expand network device callbacks to cover resolving NIC type

mistakenly dropped qemuxml2argvtest from the tests due to a typo.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently the QEMU driver will call directly into the network driver
impl to modify resolve the atual type of NICs with type=network. It
has todo this before it has allocated the actual NIC. This introduces
a callback system to allow us to decouple the QEMU driver from the
network driver.

This is a short term step, as it ought to be possible to achieve the
same end goal by simply querying XML via the public network API. The
QEMU code in question though, has no virConnectPtr conveniently
available at this time.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The QEMU driver loadable module needs to be able to resolve all ELF
symbols it references against libvirt.so. Some of its symbols can only
be resolved against the storage_driver.so loadable module which creates
a hard dependancy between them. By moving the storage file backend
framework into the util directory, this gets included directly in the
libvirt.so library. The actual backend implementations are still done as
loadable modules, so this doesn't re-add deps on gluster libraries.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a @detach parameter to the API in order allow running the QEMU
code as a thread.

Reviewed-by: Jiri Denemark <jdenemar redhat com>

The function only reduces the size of the bitmap thus we can use the
appropriate shrinking function which also does not have any return
value.

Since virBitmapShrink now does not return any value callers need to be
fixed as well.

Add the DUMP_COMPLETED check to the capabilities. This is the
mechanism used to determine whether the dump-guest-memory command
can support the "-detach" option and thus be able to wait on the
event and allow for a query of the progress of the dump.
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Move the qemuCaps checks over to qemuDomainControllerDefValidatePCI.

This requires two test updates in order to set the correct capability
bit for an xml2xml test as well as setting up the similar capability
for the pseries memlocktest.

Cachetune for unavailable vCPUs should be cleared the same way vcpupin and other
things do, so let's add tests for it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Some of the other functions depend on the fact that unused bits and longs are
always zero and it's less error-prone to clear it than fix the other functions.
It's enough to zero out one piece of the map since we're calling realloc() to
get rid of the rest (and updating map_len).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1540817Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Validate that the virNetServer(Client) RPC APIs are processing the
private data callbacks correctly by passing in non-NULL pointers.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>