Most the callers pass 0 in one form or another, including
vircapstest which used VIR_ARCH_NONE.

The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.

However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.

Avoid it completely, like it's already happening for q35.

Commit 409de00e changed the logic to only match PCI devices
while moving this before Remove*HostDevice calls.

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

There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.

Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.

This is fairly simple. We lookup the device in the array of
devices and remove it. No magic.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is really simple, we just need to append the device into the
domain def and that's it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While we need to know the difference between the total memory stored in
<memory> and the actual size not included in the possible memory modules
we can't pre-calculate it reliably. This is due to the fact that
libvirt's XML is copied via formatting and parsing the XML and the
initial memory size can be reliably calculated only when certain
conditions are met due to backwards compatibility.

This patch removes the storage of 'initial_memory' and fixes the helpers
to recalculate the initial memory size all the time from the total
memory size. This conversion is possible when we also make sure that
memory hotplug accounts properly for the update of the total memory size
and thus the helpers for inserting and removing memory devices need to
be tweaked too.

This fixes a bug where a cold-plug and cold-remove of a memory device
would increase the size reported in <memory> in the XML by the size of
the memory device. This would happen as the persistent definition is
copied before attaching the device and this would lead to the loss of
data in 'initial_memory'.

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

A bug in the code used the value of the first perf event as state for
all the mentioned one rather than extracting individual ones.

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

Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).

This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.

Previously there was no way to have a Q35 domain that didn't have
these two controllers. This patch skips their creation as long as
there are some other kinds of pci controllers at index 1 and 2
(e.g. some pcie-root-port controllers).

I'm hoping that soon we won't add them at all, plugging all devices
into auto-added pcie-*-port ports instead, but in the meantime this
makes it easier to experiment with alternative bus hierarchies.

Best viewed with -w since this is mostly just an indentation patch.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Just create a helper for it and use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Soon at least one of them will need to grab something out of the
qemu config structure
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

It's not used externally anywhere else
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Similarly to commit d294f6b0, if the name is long enough, the
filename can be longer than filesystem's limit.

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

The other two DomainHasBlockJob usage error messages don't contain
'an', so unify things to save translators some effort. Dropping
the 'an' is closer to the sentence structure in the errors from
qemuDomainDiskBlockJobIsActive as well

qemuDomainDiskBlockJobIsActive already checks if a disk has a
blockjob, and if so, raises an error

To allow tightening syntax check.

Refactor the error paths for attaching char device (it's about to be
more complicated).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add the capability flag and checks for the qemu object 'tls-creds-x509'
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the domain is not running, but for example the CPUs are stopped, the
ACPI event gets queued and resume of the domain will just shut it off.

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

Since obtaining a job can wait for another job to finish, the state
might change in the meantime.  And checking it more than once is
pointless.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.

To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

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

We have the code for attaching redirdevs for ages now.
Unfortunately, our monitor code that handles talking to the qemu
process was missing a little piece of code that actually enabled
the feature.

BTW: it really is called "type" on the monitor, even though it's
called "name" on the cmd line. Don't ask.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Move all APIs with a virHostMEM name prefix out into new
util/virhostmem.h & util/virhostmem.c files
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Move all APIs with a virHostCPU name prefix out into new
util/virhostcpu.h & util/virhostcpu.c files
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In preparation for moving all the CPU related APIs out of
the nodeinfo file, give them a virHostCPU name prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In preparation for moving all the memory related APIs out of
the nodeinfo file, give them a virHostMem name prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Nearly all the methods in the nodeinfo file are given a
'const char *sysfs_prefix' parameter to override the
default sysfs path (/sys/devices/system). Every single
caller passes in NULL for this, except one use in the
unit tests. Furthermore this parameter is totally
Linux-specific, when the APIs are intended to be cross
platform portable.

This removes the sysfs_prefix parameter and instead gives
a new method linuxNodeInfoSetSysFSSystemPath for use by
the test suite.

For two of the methods this hardcodes use of the constant
SYSFS_SYSTEM_PATH, since the test suite does not need to
override the path for thos methods.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If you want to set block device I/O tuning values that end with '_max'
and there is nothing else set, libvirt emits an error.  In particular:

  error: internal error: Unexpected error

That's an unknown error.  That is because *_max values depend on their
respective non-_max values.  QEMU even says that in the error message
sent as a response to the monitor command:

  "error": {"class": "GenericError", "desc": "bps_max/iops_max require
  corresponding bps/iops values"}

the problem was that we didn't know that and there was no check for it.
Adding such check makes sure that there will be less confused users.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This new listen type is currently supported only by spice graphics.
It's introduced to make it easier and clearer specify to not listen
anywhere in order to start a guest with OpenGL support.

The old way to do this was set spice graphics autoport='no' and don't
specify any ports.  The new way is to use <listen type='none'/>.  In
order to be able to migrate to old libvirt the migratable XML will be
generated without the listen element and with autoport='no'.  Also the
old configuration will be automatically converted to the this listen
type.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1335832Signed-off-by: NPavel Hrdina <phrdina@redhat.com>