- 15 5月, 2020 1 次提交
-
-
由 Jiri Denemark 提交于
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>
-
- 14 5月, 2020 3 次提交
-
-
由 Michal Privoznik 提交于
==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>
-
由 Michal Privoznik 提交于
==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>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 13 5月, 2020 13 次提交
-
-
由 Daniel P. Berrangé 提交于
Reviewed-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Ján Tomko 提交于
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>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
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>
-
由 Michal Privoznik 提交于
This function returns nothing else than zero. Make it void. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
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>
-
由 Yan Wang 提交于
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>
-
由 Chris Jester-Young 提交于
Signed-off-by: NChris Jester-Young <cky@cky.nz> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Chris Jester-Young 提交于
Signed-off-by: NChris Jester-Young <cky@cky.nz> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Chris Jester-Young 提交于
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>
-
由 Chris Jester-Young 提交于
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>
-
- 12 5月, 2020 23 次提交
-
-
由 Peter Krempa 提交于
'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>
-
由 Peter Krempa 提交于
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>
-
由 Peter Krempa 提交于
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>
-
由 Peter Krempa 提交于
The 'Create' API of the two storage file backends is used only on code-paths where we need to format the image after creating an empty file. Since the DAC security driver only modifies the owner of the file and not the mode we need to create all files which are going to be formatted with the write bit set for the user. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Remember the preferred placement of <auth> and <encryption> for a disk source across libvirtd restarts. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Modern way to store <auth> and <encryption> of a <disk> is under <source>. This was added to mirror how <backingStore> handles these and in fact they are relevant to the source rather than to any other part of the disk. Historically we allowed them to be directly under <disk> and we need to keep compatibility. This wasn't a problem until introduction of -blockdev in qemu using of <auth> or <encryption> plainly wouldn't work with backing chains. Now that it works in backing chains and can be moved back and forth using snapshots/block-commit we need to ensure that the original placement is properly kept even if the source changes. To achieve the above semantics we need to store the preferred placement with the disk definition rather than the storage source definitions and also ensure that the modern way is chosen when the VM started with <source/encryption> only in the backing store. https://bugzilla.redhat.com/show_bug.cgi?id=1822878Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Any non-raw block layer feature will not work with raw SCSI command passthrough via 'scsi-block'. Explicitly refuse use of luks encryption, storage slices and copy on read. https://bugzilla.redhat.com/show_bug.cgi?id=1820040Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Historically the virtio-blk frontend by default enabled SCSI emulation and tried to do SCSI command passthrough. As this was enabled by default there's a fallback mechanism in place in cases when the backend doesn't support SCSI for any reason. This is not the case when disk type=lun is used with 'scsi-block' via 'virtio-scsi'. We did not restrict configurations when the user picks 'qcow2' or any other format as format of the disk, in which case the emulation is disabled as such configuration doesn't make sense. This patch unifies the approach so that 'raw' is required both when used via 'virtio-blk' and 'virtio-scsi' so that the user is presented with the expected configuration. Note that use of <disk type='lun'> is already very restrictive as it requires a block device or iSCSI storage. Additionally the scsi emulation is now deprecated by qemu with virtio-blk as it conflicts with virtio-1 and the alternative is to use 'virtio-scsi' which performs better and is along for a very long time. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The property was deprecated. Don't format it based on the new capability if the user didn't explicitly request it. https://bugzilla.redhat.com/show_bug.cgi?id=1829550Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Historically the 'scsi' passthrough feature of virtio-blk-pci was enabled by default. Libvirt was disabling it due to security implications outlined in libvirt commit v0.9.9-4-g177db087 if it was not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the default value was changed to disabled in preparation for virtio-1. Starting from QEMU-5.0 the 'scsi' property was also deprecated. There replacement for the functionality is to use 'virtio-scsi' for the purpose. This isn't a direct replacement though. Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which allows us to stop formatting the 'scsi=' property if it's disabled by default and not requested so that we don't use deprecated features. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Create a hash table of device property names which also stores the corresponding JSON object so that the detection code can look at the recently added 'default-value' field and possibly others. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Use automatic cleanup of variables and current style of header. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
virQEMUCapsProbeQMPGenericProps is used only in one place now. Move the code directly to virQEMUCapsProbeQMPObjectTypes. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Reimplement device property detection directly rather than using virQEMUCapsProbeQMPGenericProps in preparation for changes to the detection code. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Help QEMU in deprecation of -drive if=none without the need to refactor all old boards. Stop masking out -blockdev support when -drive if=sd needs to be used. We achieve this by forbidding blockjobs and special-casing all other code paths. Blockjobs are sacrificed in this case as SD cards are a corner case for some ARM boards and are thus not used commonly. https://bugzilla.redhat.com/show_bug.cgi?id=1821692Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
SD cards need to be instantiated via -drive if=sd. This means that all cases where we use the blockdev path need to be special-cased for SD cards. Note that at this point QEMU_CAPS_BLOCKDEV is still cleared if the VM config has a SD card. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Use the drive alias for all cases when we can't generate qomName. This is meant to handle disks on 'sd' bus which are instantiated via -drive if=sd as there isn't any specific QOM name for them. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
We still have to use -drive to instantiate sd disks. Combining that with the new logic for blockjobs would be very complicated and not worth it given that 'sd' cards work only on few rarely used machine types of non-common architectures and libvirt didn't implement support for 'sd' bus controllers. This will allow us to use -blockdev for other kinds on such machines while sacrificing block jobs. Note: this is currently no-op as we mask-out the QEMU_CAPS_BLOCKDEV capability if any of the disks has bus='sd'. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
We can't set the type of the device on the 'sd' bus and realistically a cdrom doesn't even make sense there. Forbid it. Note that the output of in disk-cdrom-bus-other.x86_64-latest.args switched to blockdev as it's no longer locked out due to use of a disk on 'sd' bus. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The 'vexpress-a9' ARM board supports the native 'sd' bus as well as virtio. Add a test case for proving that upcoming changes to handling of 'sd' work. This config was also tested with real qemu and the qemu process starts correctly. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
In case of 'sd' cards we'll use pre-blockdev code also if qemu supports blockdev. In that specific case we'll need to mask out blockdev support for 'sd' disks. Plumb in a boolean to allow it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-