Remove the installation instructions from README.rst, and
add the link to compiling.html.
Signed-off-by: NLiao Pingfang <liao.pingfang@zte.com.cn>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The qemu.conf change broke our augeas test:

qemu/test_libvirtd_qemu.aug:96.3-203.1:exception thrown in test
qemu/test_libvirtd_qemu.aug:96.8-.34:exception: Iterated lens matched less than it should
    Lens: ../../src/qemu/libvirtd_qemu.aug:170.13-.43:
      Last match: ../../src/qemu/libvirtd_qemu.aug:18.52-.113:
      Not matching: ../../src/qemu/libvirtd_qemu.aug:12.19-.31:
    Error encountered at 48:27 (1615 characters into string)
    <\n    "/dev/ptmx", "/dev/kvm"|=|,\n]\nsave_image_format = "raw>

Fixes: ab5ba570Signed-off-by: NJán Tomko <jtomko@redhat.com>

The RTC and HPET modes for the QEMU emulation tick have been dropped
almost 9 years ago, in commit 25f3151ece1d5881826232bebccc21b588d4e03e.
Do not allow them in the devices cgroup policy.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Although the original patches to support controllers with
hotplug='off' were checking during hotplug/attach requests that the
device was being plugged into a PCI controller that didn't have
hotplug disabled, but I forgot to do the same for device detach (the
main impetus for adding the feature was to prevent unplugs originating
from within the guest, so it slipped my mind). So although the guest
OS was ultimately unable to honor the unplug request, libvirt could
still be used to make such a request, and since device attach/detach
are asynchronous operations, the caller to libvirt would receive a
success status back (the device would stubbornly/correctly remain in
the domain status XML however)

This patch remedies that, by looking at the controller for the device
in the detach request, and immediately failing the operation if that
controller has hotplug=off.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

If the mirror destination is not a file but a NVMe disk, then
call qemuHostdevReAttachOneNVMeDisk() to reattach the NVMe back
to the host.

This would be done by blockjob code when the job finishes, but in
this case the job won't finish - QEMU is killed meanwhile.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1825785Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

In v5.10.0-rc1~42 (which was later fixed in v6.0.0-rc1~487) I am
removing XATTRs for a file that QEMU is mirroring a disk into but
it is killed meanwhile. Well, we can call
qemuSecurityRestoreImageLabel() which will not only remove XATTRs
but also use them to restore the original owner of the file.

This would be done by blockjob code when the job finishes, but in
this case the job won't finish - QEMU is killed meanwhile
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Use g_new0 to allocate and remove NULL checks from callers
and the lock will release properly
Signed-off-by: NYi Li <yili@winhong.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In previous commit we started tracking whether QEMU supports
'-numa mem='. This is tied to the machine type because migration
from '-numa mem=' to '-numa memdev' is impossible (or vice
versa). But since it's tied to a machine type (where migration
from one to another is also unsupported) we can allow QEMU to get
rid of the deprecated command line.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1783355Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When building -numa command line there is a for() loop that
builds '-numa memdev=' for each guest NUMA node. And also
records in a local variable whether any of memory-object-*
backends must be used to satisfy desired config. Well, instead of
checking in each iteration whether corresponding capabilities are
set, we can do swap if() and for() and check only once.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

There is 'numa-mem-supported' machine attribute which specifies
whether '-numa mem=' is supported. Store it in our capabilities
as it will be used in later commits when building the command
line.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The AppArmor secdriver does not use labels to grant access to
resources. Therefore, it doesn't use XATTRs and hence it lacks
implementation of .domainMoveImageMetadata callback. This leads
to a harmless but needless error message appearing in the logs:

  virSecurityManagerMoveImageMetadata:476 : this function is not
  supported by the connection driver: virSecurityManagerMoveImageMetadata

Closes: https://gitlab.com/libvirt/libvirt/-/issues/25Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

s/enther/enter/ in the function documentation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The documented enum and its values do not exits. The real enum has
slightly different name.
Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Introduce vendors and some commonly used models
for ARM arch, these will be used for virConnectionGetCapabilities
for ARM CPUs.
Signed-off-by: NZhenyu Zheng <zheng.zhenyu@outlook.com>
Message-Id: <TY2PR01MB3113973DDB36C7A5E18F451299BF0@TY2PR01MB3113.jpnprd01.prod.outlook.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Introduce getHost support for ARM CPU driver,
read CPU vendor_id, part_id and flags from
registers directly. These codes will only be
compiled on aarch64 hardware.
Signed-off-by: NZhenyu Zheng <zheng.zhenyu@outlook.com>
Message-Id: <TY2PR01MB311380AFE294266B4E87B85699BF0@TY2PR01MB3113.jpnprd01.prod.outlook.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Add helper functions to parse vendor and model for
ARM CPUs, and use them as callbacks when load cpu
maps.
Signed-off-by: NZhenyu Zheng <zheng.zhenyu@outlook.com>
Message-Id: <TY2PR01MB3113C158B8C2822E75DB5EAE99BF0@TY2PR01MB3113.jpnprd01.prod.outlook.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Introduce virCPUarmData to virCPUData and related
structs to cpu_arm.c for ARM cpus.
Signed-off-by: NZhenyu Zheng <zheng.zhenyu@outlook.com>
Message-Id: <TY2PR01MB31130D12A95144FF88C1E32499BF0@TY2PR01MB3113.jpnprd01.prod.outlook.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The structure is not specific to x86 and thus its cleanup function
should be defined in cpu.h and be available to all users.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

==179663== 35 (24 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 205 of 461
==179663==    at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==179663==    by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==179663==    by 0x190C79: qemuDomainObjPrivateXMLParseBlockjobDataCommit (qemu_domain.c:3295)
==179663==    by 0x190DF7: qemuDomainObjPrivateXMLParseBlockjobDataSpecific (qemu_domain.c:3331)
==179663==    by 0x19157D: qemuDomainObjPrivateXMLParseBlockjobData (qemu_domain.c:3469)
==179663==    by 0x1918E8: qemuDomainObjPrivateXMLParseBlockjobs (qemu_domain.c:3498)
==179663==    by 0x193841: qemuDomainObjPrivateXMLParse (qemu_domain.c:3944)
==179663==    by 0x4A1BA9D: virDomainObjParseXML (domain_conf.c:22306)
==179663==    by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429)
==179663==    by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443)
==179663==    by 0x1431E1: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:61)
==179663==    by 0x177722: virTestRun (testutils.c:142)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

==156803== 58 (40 direct, 18 indirect) bytes in 1 blocks are definitely lost in loss record 306 of 463
==156803==    at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==156803==    by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==156803==    by 0x48F60DC: virAlloc (viralloc.c:48)
==156803==    by 0x18DD74: qemuStorageSourcePrivateDataAssignSecinfo (qemu_domain.c:2384)
==156803==    by 0x18DFD5: qemuStorageSourcePrivateDataParse (qemu_domain.c:2433)
==156803==    by 0x49EC884: virDomainStorageSourceParse (domain_conf.c:9857)
==156803==    by 0x49ECBA3: virDomainDiskBackingStoreParse (domain_conf.c:9909)
==156803==    by 0x49F129D: virDomainDiskDefParseXML (domain_conf.c:10785)
==156803==    by 0x4A1804E: virDomainDefParseXML (domain_conf.c:21543)
==156803==    by 0x4A1B60C: virDomainObjParseXML (domain_conf.c:22254)
==156803==    by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429)
==156803==    by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

A failure in qemuProcessLaunch would lead to qemuExtDevicesStop
being called twice - once in the cleanup section and then again
in qemuProcessStop.

However, the first one is called while the QEMU process is
still running, which is too soon for the swtpm process, because
the swtmp_ioctl command can lock up:

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

Remove the first call and only leave the one in qemuProcessStop,
which is called after the QEMU process is killed.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The @tmpIfname is a pointer into a const string. To avoid
mistakenly changing the const string via the pointer, make the
pointer const too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function returns nothing else than zero. Make it void.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is not yet supported by virtiofsd.

Fixes #23 a.k.a. https://gitlab.com/libvirt/libvirt/-/issues/23Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

It was never used since commit 57b5e27d introduced it.
Signed-off-by: NYan Wang <wangyan122@huawei.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NChris Jester-Young <cky@cky.nz>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NChris Jester-Young <cky@cky.nz>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Availability of the vmpvscsi controller model is gated by the pvscsi
capability.
Signed-off-by: NChris Jester-Young <cky@cky.nz>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

This capability flags support for `-device pvscsi`, which provides the
VMware paravirtual SCSI controller.
Signed-off-by: NChris Jester-Young <cky@cky.nz>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

'blockdev-mirror' requires the write permission internally to do the
copy. This means that we have to force the image to be read-write for
the duration of the copy and can fix it after the copy is done.

https://bugzilla.redhat.com/show_bug.cgi?id=1832204Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

With -blockdev or when reusing externally created images and thus
without the need for formatting the image we actually can support
snapshots of read-only disks. Arguably it's not very useful so they are
not done by default but users of libvirt such as oVirt are actually
using this.

https://bugzilla.redhat.com/show_bug.cgi?id=1832204Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We need qemu to be able to write the newly created images so that it can
format them to the specified storage format.

Force write access by relabelling the images when formatting.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>