Re: [libvirt] [PATCH v2] Close the source fd if the destination qemu exits during tunnelled migration
by John Ferlan
On 09/29/2015 10:06 AM, Shivaprasad bhat wrote:
[...]
>> Perhaps I should clarify my query-migrate has no timeout comment... It
>> seems based on what I've read so far, the 'query-migrate' command
>> started successfully, because if it hadn't we would have received a
>> failure (as shown below). Thus libvirt has sent the command via the
>> monitor and is waiting for a response (e.g. the virCondWait after the
>> qemuMonitorSend in the trace below). The response isn't coming because
>> either "A" qemu didn't send it back or "B" libvirt missed it - that
>> should be determinable.
>>
>> There's a way to turn on debugging so the monitor dialog can be seen -
>> via changes to /etc/libvirt/libvirtd.conf. I use :
>>
>> log_level = 1
>> log_filters="3:remote 4:event 3:json 3:rpc"
>> log_outputs="1:file:/var/log/libvirt/libvirtd.log"
>>
>> But you may need to remove the "3:json" in order to see the dialog since
>> that where it "feels like" the issue might be. Then start libvirtd in
>> the debugger again. Once it's hung - you should be able to scan (eg,
>> edit) the libvirtd.log file and search for the "query-migrate" command
>> being sent and then follow the copious output looking for the presence
>> of a returned command. If there is none, then something in qemu isn't
>> returning the failure correctly and it would need to be fixed there I
>> would think as opposed to throwing down the big hammer of closing the fd.
>
> Had a chance to run with your log settings. The query-migrate doesn't seem to
> have a corresponding "return" in the logs. So as you say, there may be
> a qemu bug
> that is not returning a response when the fd is still open(as libvirt
> didnt close it) but
> no read actually happening there. I felt qemu can't sense the failure as the fd
> is open, so posted this patch. Though, the qemu should return with the
> current state
> of migration as it sees instead of not returning at all. Hope we are
> on the same page.
>
> Thanks,
> Shivaprasad
>
Meant to respond yesterday but got wrapped up in other things. OK - so
at least now it makes a bit more sense why purely adding a stream_abort
didn't work - we're not getting a reply from the monitor.
So there's perhaps 3 ways to "resolve" this issue (that come to my mind)
1. As you've done with the close() in the error path of
qemuMigrationIOFunc when the virStream{Send|Finish} fails. Although this
does feel like a work-around, I suppose since the tunnel is a libvirt
created thing and qemu isn't aware of it, then it feels reasonable.
Although that does make me wonder how qemu could be hung up. What would
something like a "virsh qemu-monitor-command $dom
'{"execute":"query-migrate"}' return when the source is hung? Or does it
hang too?
2. Adding some sort of "timeout" logic in qemuMonitorSend (e.g.
virCondWaitUntil instead of virCondWait) to handle when a command
doesn't get a response. Not sure this is right either since it's not
clear to me there is a "time" that "all" commands are guaranteed to be
run in/by, especially async ones.
3. Dig into qemu to figure out why it's not returning anything for a
migrate-status request. Currently a bit beyond what I've done, but I
believe would require attaching into the running qemu process to see if
there was some thread "stuck" somewhere "waiting" on something that
won't return because the stream closed.
Hopefully Jiri (or perhaps Daniel) could provide some other insights.
John
9 years, 2 months
[libvirt] [PATCH v4] qemu: Validate address type when attaching a disk device.
by Ruifeng Bian
Bug fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1257844
Attach-device can hotplug a virtio disk device with any address type now,
it need to validate the address type before the attachment.
Attaching a disk device with --config option need to check address type.
Otherwise, the domain cloudn't be started normally. This patch add a basic
check for address type.
Detaching a disk device with --config also need to check disk options,
add qemuCheckDiskConfig() method in qemuDomainDetachDeviceConfig().
Add virDomainDeviceAddressTypeIsValid method in domain_conf to check disk
address type. Address type should match with disk driver, report error
messages if any mismatch.
Signed-off-by: Ruifeng Bian <rbian(a)redhat.com>
---
src/conf/domain_conf.c | 32 ++++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 7 +++++++
src/qemu/qemu_driver.c | 2 ++
src/qemu/qemu_hotplug.c | 22 ++++++++++++++++++++++
6 files changed, 65 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 6df1618..f86760b 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3200,6 +3200,38 @@ int virDomainDeviceAddressIsValid(virDomainDeviceInfoPtr info,
return 0;
}
+int virDomainDeviceAddressTypeIsValid(virDomainDiskDefPtr disk)
+{
+ if (disk->info.type) {
+ switch (disk->bus) {
+ case VIR_DOMAIN_DISK_BUS_IDE:
+ case VIR_DOMAIN_DISK_BUS_SCSI:
+ case VIR_DOMAIN_DISK_BUS_SATA:
+ case VIR_DOMAIN_DISK_BUS_FDC:
+ if (disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE)
+ return 1;
+ break;
+ case VIR_DOMAIN_DISK_BUS_USB:
+ if (disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_USB)
+ return 1;
+ break;
+ case VIR_DOMAIN_DISK_BUS_VIRTIO:
+ if (disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
+ disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390 &&
+ disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO &&
+ disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+ return 1;
+ break;
+ case VIR_DOMAIN_DISK_BUS_XEN:
+ case VIR_DOMAIN_DISK_BUS_UML:
+ case VIR_DOMAIN_DISK_BUS_SD:
+ /* no address type currently, return false if address provided */
+ return 1;
+ }
+ }
+ return 0;
+}
+
virDomainDeviceInfoPtr
virDomainDeviceGetInfo(virDomainDeviceDefPtr device)
{
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index f043554..337fe51 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2543,6 +2543,7 @@ virDomainDeviceDefPtr virDomainDeviceDefCopy(virDomainDeviceDefPtr src,
virDomainXMLOptionPtr xmlopt);
int virDomainDeviceAddressIsValid(virDomainDeviceInfoPtr info,
int type);
+int virDomainDeviceAddressTypeIsValid(virDomainDiskDefPtr disk);
virDomainDeviceInfoPtr virDomainDeviceGetInfo(virDomainDeviceDefPtr device);
int virDomainDeviceInfoCopy(virDomainDeviceInfoPtr dst,
virDomainDeviceInfoPtr src);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 5b3da83..6cd5b9e 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -229,6 +229,7 @@ virDomainDefPostParse;
virDomainDefSetMemoryInitial;
virDomainDeleteConfig;
virDomainDeviceAddressIsValid;
+virDomainDeviceAddressTypeIsValid;
virDomainDeviceAddressTypeToString;
virDomainDeviceDefCheckUnsupportedMemoryDevice;
virDomainDeviceDefCopy;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 25f57f2..56ba08d 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3606,6 +3606,13 @@ qemuCheckDiskConfig(virDomainDiskDefPtr disk)
goto error;
}
}
+
+ if (virDomainDeviceAddressTypeIsValid(disk)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("disk cannot have an address of type '%s'"),
+ virDomainDeviceAddressTypeToString(disk->info.type));
+ goto error;
+ }
return 0;
error:
return -1;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index fcf86b6..26c1502 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8208,6 +8208,8 @@ qemuDomainDetachDeviceConfig(virDomainDefPtr vmdef,
switch ((virDomainDeviceType) dev->type) {
case VIR_DOMAIN_DEVICE_DISK:
disk = dev->data.disk;
+ if (qemuCheckDiskConfig(disk) < 0)
+ return -1;
if (!(det_disk = virDomainDiskRemoveByName(vmdef, disk->dst))) {
virReportError(VIR_ERR_INVALID_ARG,
_("no target device %s"), disk->dst);
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index e84a78d..6156243 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -336,6 +336,28 @@ qemuDomainAttachVirtioDiskDevice(virConnectPtr conn,
if (!qemuCheckCCWS390AddressSupport(vm->def, disk->info, priv->qemuCaps,
disk->dst))
goto cleanup;
+
+ if (qemuDomainMachineIsS390CCW(vm->def) &&
+ virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VIRTIO_CCW)) {
+ if (!virDomainDeviceAddressIsValid(&disk->info,
+ VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW)) {
+ virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+ _("device cannot be attached without a valid CCW address"));
+ goto cleanup;
+ }
+ } else if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VIRTIO_S390)) {
+ if (!virDomainDeviceAddressIsValid(&disk->info,
+ VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390)) {
+ virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+ _("device cannot be attached without a valid S390 address"));
+ goto cleanup;
+ }
+ } else if (!virDomainDeviceAddressIsValid(&disk->info,
+ VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)) {
+ virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+ _("device cannot be attached without a valid PCI address"));
+ goto cleanup;
+ }
}
for (i = 0; i < vm->def->ndisks; i++) {
--
2.4.3
9 years, 2 months
[libvirt] [PATCH v2 0/6] Fix some Coverity issues
by John Ferlan
This series is based off the review of patch 1 from the series:
http://www.redhat.com/archives/libvir-list/2015-September/msg00841.html
In review of patch 1:
http://www.redhat.com/archives/libvir-list/2015-September/msg00859.html
it was noted that instead of using sa_assert, the proper checks should be
made. During investigation, I found that while the caller could check for
a non-NULL "first" parameter that ends up being used for strtok_r, that
was not "good enough" for Coverity which still needed to consider the
function where the to be first param cannot be NULL.
In any case, I separated out each into their own patch rather than
lumping them together.
Patches 1-4 should be relatively straightforward.
Patch 5 is new - it's one that I had been working on and finally
figured out what the issue is/was. It was a bit more complex and hidden.
Patch 6 was from the original patch 1, but it's review had a comment
regarding using virBitmap* instead of the open coding. This one I
believe I have intoned the magic words to make it better, but since
I don't use xenapi, perhaps extra care would be necessary to make
sure I got it right.
John Ferlan (6):
openvz: Resolve Coverity FORWARD_NULL
openvz: Resolve Coverity FORWARD_NULL
libxl: Resolve Coverity FORWARD_NULL
esx: Resolve Coverity FORWARD_NULL
qemu: Resolve Coverity FORWARD_NULL
xenapi: Resolve Coverity FORWARD_NULL
src/esx/esx_vi.c | 5 +++++
src/libxl/libxl_conf.c | 6 ++++++
src/openvz/openvz_conf.c | 8 ++++----
src/qemu/qemu_process.c | 14 ++++++++++++--
src/xenapi/xenapi_driver.c | 12 +++++++-----
src/xenapi/xenapi_utils.c | 21 ---------------------
src/xenapi/xenapi_utils.h | 2 --
7 files changed, 34 insertions(+), 34 deletions(-)
--
2.1.0
9 years, 2 months
[libvirt] [PATCH 0/3] tests: Drop virtTestResult
by Cole Robinson
virtTestResult poorly duplicates logic from virtTestRun. We could fix it,
but there's really only one legitimate user in eventtest.c, so drop the
improper users, and opencode the legit usage. More justification in the
last patch
Thanks,
Cole
Cole Robinson (3):
tests: sheepdog: Drop use of virtTestResult
tests: eventtest: Open code virtTestResult
testutils: Drop virtTestResult
tests/eventtest.c | 57 ++++++++++++++++++++++++++++------
tests/storagebackendsheepdogtest.c | 63 ++++++++++++++++++++++++++++----------
tests/testutils.c | 38 -----------------------
tests/testutils.h | 2 --
4 files changed, 94 insertions(+), 66 deletions(-)
--
2.5.0
9 years, 2 months
[libvirt] [PATCH 0/2] tests: Add nodeinfo test data utility scripts
by Andrea Bolognani
Both scripts can be useful when adding new test cases to the
nodeinfo test.
Andrea Bolognani (2):
tests: Add script to display nodeinfo test data
tests: Add script to copy nodeinfo test data from host
tests/nodeinfodata/copy-from-host.sh | 170 +++++++++++++++++++++++++++++++++++
tests/nodeinfodata/display.sh | 101 +++++++++++++++++++++
2 files changed, 271 insertions(+)
create mode 100755 tests/nodeinfodata/copy-from-host.sh
create mode 100755 tests/nodeinfodata/display.sh
--
2.4.3
9 years, 2 months
[libvirt] [PATCH] storage: Fix incorrect format for <disk> <auth> XML
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=1256999
When creating a copy of the 'authdef', need to take into account the
slight variation between <disk> and <pool> before blindly copying
the 'authType' field. This ensures virStorageAuthDefFormat will
properly format the <auth> XML for a <disk>.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/util/virstoragefile.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 2aa1d90..0b72cb3 100644
--- a/src/util/virstoragefile.c
+++ b/src/util/virstoragefile.c
@@ -1522,7 +1522,12 @@ virStorageAuthDefCopy(const virStorageAuthDef *src)
/* Not present for storage pool, but used for disk source */
if (VIR_STRDUP(ret->secrettype, src->secrettype) < 0)
goto error;
- ret->authType = src->authType;
+ /* A <disk> uses secrettype, while a <pool> uses authType, so
+ * if we have a secrettype, then don't copy authType; otherwise,
+ * we will format the authType in <disk>
+ */
+ if (!ret->secrettype)
+ ret->authType = src->authType;
ret->secretType = src->secretType;
if (ret->secretType == VIR_STORAGE_SECRET_TYPE_UUID) {
memcpy(ret->secret.uuid, src->secret.uuid, sizeof(ret->secret.uuid));
--
2.1.0
9 years, 2 months
[libvirt] [libvirt-python PATCH 00/23] Cleanup of the libvirt-python C code
by Pavel Hrdina
This patch series tries to cleanup the libvirt-python C code and also make it
more readable. It also fixes places, where we didn't checked for return values
and where we also returned wrong values in case of errors. There are some other
minor issues, that I've found.
Pavel Hrdina (23):
update virDomainGetVcpus xml API description
refactor the function to not override python exceptions
remove useless check for NULL before Py_XDECREF
drop unnecessary goto
Move utils and shared code into libvirt-utils
cleanup functions definition
indent labels by one space
fix indentation
wrap lines to 80 columns
Return NULL if python exception is set
Return correct python object
Return NULL and set an exception if allocation fails
Use VIR_PY_NONE instead
use Py_CLEAR instead of Py_XDECREF followed by NULL assignment
all Py*_New function has to be checked for return value
change the order of some statements
drop unnecessary py_retval variable
improve usage of cleanup paths
utils: introduce new macro helpers for tuple, list and dict objects
use VIR_PY_TUPLE_GOTO
use VYR_PY_LIST_SET_GOTO and VIR_PY_LIST_APPEND_GOTO
use VIR_PY_DICT_SET_GOTO
coverity: resolve dead_error_condition
libvirt-lxc-override.c | 61 +-
libvirt-override-api.xml | 4 +-
libvirt-override.c | 3156 +++++++++++++++++++++-------------------------
libvirt-qemu-override.c | 60 +-
libvirt-utils.c | 422 ++++++-
libvirt-utils.h | 133 ++
typewrappers.c | 65 +-
7 files changed, 2047 insertions(+), 1854 deletions(-)
--
2.5.3
9 years, 2 months
[libvirt] [PATCH] tests: qemu: Add aarch64 virtio pci tests
by Cole Robinson
- qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default
to virtio-mmio even if qemu is new enough to support PCI
- qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
---
.../qemuxml2argv-aarch64-mmio-default-pci.args | 17 ++++++++
.../qemuxml2argv-aarch64-mmio-default-pci.xml | 48 ++++++++++++++++++++++
.../qemuxml2argv-aarch64-virtio-pci.args | 15 +++++++
.../qemuxml2argv-aarch64-virtio-pci.xml | 43 +++++++++++++++++++
tests/qemuxml2argvtest.c | 12 ++++++
5 files changed, 135 insertions(+)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.xml
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.args
new file mode 100644
index 0000000..9720936
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.args
@@ -0,0 +1,17 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-aarch64 -S -M virt -cpu cortex-a53 -m 1024 -smp 1 \
+-nographic -nodefconfig -nodefaults \
+-monitor unix:/tmp/test-monitor,server,nowait -boot c \
+-kernel /aarch64.kernel -initrd /aarch64.initrd \
+-append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \
+-dtb /aarch64.dtb -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
+-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
+-device virtio-serial-device,id=virtio-serial0 -usb \
+-drive file=/aarch64.raw,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0 \
+-device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \
+-net user,vlan=0,name=hostnet0 -serial pty -chardev pty,id=charconsole1 \
+-device virtconsole,chardev=charconsole1,id=console1 \
+-device virtio-balloon-device,id=balloon0 \
+-object rng-random,id=objrng0,filename=/dev/random \
+-device virtio-rng-device,rng=objrng0,id=rng0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.xml
new file mode 100644
index 0000000..ad34615
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-mmio-default-pci.xml
@@ -0,0 +1,48 @@
+<domain type="qemu">
+ <name>aarch64test</name>
+ <uuid>496d7ea8-9739-544b-4ebd-ef08be936e8b</uuid>
+ <memory>1048576</memory>
+ <currentMemory>1048576</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch="aarch64" machine="virt">hvm</type>
+ <kernel>/aarch64.kernel</kernel>
+ <initrd>/aarch64.initrd</initrd>
+ <dtb>/aarch64.dtb</dtb>
+ <cmdline>earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait</cmdline>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <pae/>
+ </features>
+ <cpu match='exact'>
+ <model>cortex-a53</model>
+ </cpu>
+ <clock offset="utc"/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>restart</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-aarch64</emulator>
+ <disk type='file' device='disk'>
+ <source file='/aarch64.raw'/>
+ <target dev='vda' bus='virtio'/>
+ </disk>
+ <interface type='user'>
+ <mac address='52:54:00:09:a4:37'/>
+ <model type='virtio'/>
+ </interface>
+ <console type='pty'/>
+ <console type='pty'>
+ <target type='virtio' port='0'/>
+ </console>
+ <memballoon model='virtio'/>
+ <!--
+ This actually doesn't work in practice because vexpress only has
+ 4 virtio slots available, rng makes 5 -->
+ <rng model='virtio'>
+ <backend model='random'>/dev/random</backend>
+ </rng>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.args
new file mode 100644
index 0000000..3ae6e34
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.args
@@ -0,0 +1,15 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-aarch64 -S -M virt -cpu cortex-a53 -m 1024 -smp 1 \
+-nographic -nodefconfig -nodefaults \
+-monitor unix:/tmp/test-monitor,server,nowait -boot c \
+-kernel /aarch64.kernel -initrd /aarch64.initrd \
+-append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \
+-dtb /aarch64.dtb -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
+-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
+-device virtio-scsi-pci,id=scsi0,bus=pcie.0,addr=0x3 \
+-usb -drive file=/aarch64.raw,if=none,id=drive-scsi0-0-0-0 \
+-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\
+drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
+-device virtio-net-pci,vlan=0,id=net0,\
+mac=52:54:00:09:a4:37,bus=pcie.0,addr=0x2 \
+-net user,vlan=0,name=hostnet0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.xml
new file mode 100644
index 0000000..6a44f19
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci.xml
@@ -0,0 +1,43 @@
+<domain type='qemu'>
+ <name>aarch64test</name>
+ <uuid>496d7ea8-9739-544b-4ebd-ef08be936e8b</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <currentMemory unit='KiB'>1048576</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='aarch64' machine='virt'>hvm</type>
+ <kernel>/aarch64.kernel</kernel>
+ <initrd>/aarch64.initrd</initrd>
+ <cmdline>earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait</cmdline>
+ <dtb>/aarch64.dtb</dtb>
+ <boot dev='hd'/>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <pae/>
+ </features>
+ <cpu mode='custom' match='exact'>
+ <model fallback='allow'>cortex-a53</model>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>restart</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-aarch64</emulator>
+ <disk type='file' device='disk'>
+ <source file='/aarch64.raw'/>
+ <target dev='sda' bus='scsi'/>
+ <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+ </disk>
+ <controller type='scsi' index='0' model='virtio-scsi'>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+ </controller>
+ <interface type='user'>
+ <mac address='52:54:00:09:a4:37'/>
+ <model type='virtio'/>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+ </interface>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index ae67779..ecfee11 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1632,6 +1632,18 @@ mymain(void)
QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB,
QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO,
QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM);
+ DO_TEST("aarch64-mmio-default-pci",
+ QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB,
+ QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO,
+ QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM,
+ QEMU_CAPS_OBJECT_GPEX, QEMU_CAPS_DEVICE_PCI_BRIDGE,
+ QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE);
+ DO_TEST("aarch64-virtio-pci",
+ QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB,
+ QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO,
+ QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM,
+ QEMU_CAPS_OBJECT_GPEX, QEMU_CAPS_DEVICE_PCI_BRIDGE,
+ QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE, QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("aarch64-aavmf-virtio-mmio",
QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB,
QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO,
--
2.5.0
9 years, 2 months
Re: [libvirt] [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration
by Eduardo Habkost
On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote:
> When a vcpu is created in KVM, its TSC rate is initially identical to
> the host TSC rate. If its state is migrated to a vcpu on another
> machine (target machine) which may uses a different host TSC rate, QEMU
> on the target machine should notice KVM of the migrated vcpu's TSC
> rate. In case that KVM on the target machine supports TSC scaling, guest
> programs running on the migrated vcpu will observe the same TSC rate
> before and after the migration.
>
> Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com>
> ---
> kvm-all.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 0be4615..e8de038 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1769,6 +1769,19 @@ void kvm_cpu_synchronize_post_reset(CPUState *cpu)
> static void do_kvm_cpu_synchronize_post_init(void *arg)
> {
> CPUState *cpu = arg;
> + CPUX86State *env = &X86_CPU(cpu)->env;
> + int r;
> +
> + /*
> + * XXX: KVM_SET_TSC_KHZ must be done before kvm_arch_put_registers().
Could you explain where this requirement comes from?
> + */
> + r = kvm_check_extension(cpu->kvm_state, KVM_CAP_TSC_CONTROL);
> + if (r && env->tsc_khz) {
> + r = kvm_vcpu_ioctl(cpu, KVM_SET_TSC_KHZ, env->tsc_khz);
> + if (r < 0) {
> + fprintf(stderr, "KVM_SET_TSC_KHZ failed\n");
> + }
> + }
This is duplicating the existing KVM_SET_TSC_KHZ call at
kvm_arch_init_vcpu(). I wonder if there's a way to avoid this
duplication. Should we set TSC KHz only at
do_kvm_cpu_synchronize_post_init(), and remove the call from
kvm_arch_init_vcpu()?
Or maybe we shouldn't treat this as VM state, but as configuration, and
let management configure the TSC frequency explicitly if the user really
needs it to stay the same during migration.
(CCing libvir-list to see if they have feedback)
--
Eduardo
9 years, 2 months
