libvirt/tests/qemuxml2xmltest.c

1241 lines
43 KiB
C
Raw Normal View History

#include <config.h>
2007-07-18 21:34:22 +00:00
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
2007-07-18 21:34:22 +00:00
#include <string.h>
#include <sys/types.h>
#include <fcntl.h>
#include "testutils.h"
#ifdef WITH_QEMU
# include "internal.h"
# include "qemu/qemu_domain_address.h"
# include "qemu/qemu_domain.h"
# include "testutilsqemu.h"
# include "virstring.h"
2007-07-18 21:34:22 +00:00
# define VIR_FROM_THIS VIR_FROM_NONE
static virQEMUDriver driver;
2007-07-18 21:34:22 +00:00
enum {
WHEN_INACTIVE = 1,
WHEN_ACTIVE = 2,
WHEN_BOTH = 3,
};
struct testInfo {
char *inName;
char *outActiveName;
char *outInactiveName;
virBitmapPtr activeVcpus;
bool blockjobs;
virQEMUCapsPtr qemuCaps;
};
static int
testXML2XMLActive(const void *opaque)
{
const struct testInfo *info = opaque;
return testCompareDomXML2XMLFiles(driver.caps, driver.xmlopt,
info->inName, info->outActiveName, true,
0,
TEST_COMPARE_DOM_XML2XML_RESULT_SUCCESS);
}
static int
testXML2XMLInactive(const void *opaque)
{
const struct testInfo *info = opaque;
return testCompareDomXML2XMLFiles(driver.caps, driver.xmlopt, info->inName,
info->outInactiveName, false,
0,
TEST_COMPARE_DOM_XML2XML_RESULT_SUCCESS);
}
static int
testCompareStatusXMLToXMLFiles(const void *opaque)
{
const struct testInfo *data = opaque;
virDomainObjPtr obj = NULL;
char *actual = NULL;
int ret = -1;
if (!(obj = virDomainObjParseFile(data->inName, driver.caps, driver.xmlopt,
VIR_DOMAIN_DEF_PARSE_STATUS |
VIR_DOMAIN_DEF_PARSE_ACTUAL_NET |
VIR_DOMAIN_DEF_PARSE_PCI_ORIG_STATES |
VIR_DOMAIN_DEF_PARSE_SKIP_OSTYPE_CHECKS |
VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE |
VIR_DOMAIN_DEF_PARSE_ALLOW_POST_PARSE_FAIL)))
goto cleanup;
if (!(actual = virDomainObjFormat(driver.xmlopt, obj, NULL,
VIR_DOMAIN_DEF_FORMAT_SECURE |
VIR_DOMAIN_DEF_FORMAT_STATUS |
VIR_DOMAIN_DEF_FORMAT_ACTUAL_NET |
VIR_DOMAIN_DEF_FORMAT_PCI_ORIG_STATES |
VIR_DOMAIN_DEF_FORMAT_CLOCK_ADJUST)))
goto cleanup;
if (virTestCompareToFile(actual, data->outActiveName) < 0)
goto cleanup;
ret = 0;
cleanup:
virDomainObjEndAPI(&obj);
VIR_FREE(actual);
return ret;
}
static void
testInfoClear(struct testInfo *info)
{
VIR_FREE(info->inName);
VIR_FREE(info->outActiveName);
VIR_FREE(info->outInactiveName);
virBitmapFree(info->activeVcpus);
info->activeVcpus = NULL;
virObjectUnref(info->qemuCaps);
}
static int
testInfoSetCommon(struct testInfo *info,
int gic)
{
if (!(info->qemuCaps = virQEMUCapsNew()))
goto error;
if (testQemuCapsSetGIC(info->qemuCaps, gic) < 0)
goto error;
if (qemuTestCapsCacheInsert(driver.qemuCapsCache, info->qemuCaps) < 0)
goto error;
return 0;
error:
testInfoClear(info);
return -1;
}
static int
testInfoSet(struct testInfo *info,
const char *name,
int when,
int gic)
{
if (testInfoSetCommon(info, gic) < 0)
return -1;
if (virAsprintf(&info->inName, "%s/qemuxml2argvdata/%s.xml",
abs_srcdir, name) < 0)
goto error;
if (when & WHEN_INACTIVE) {
if (virAsprintf(&info->outInactiveName,
"%s/qemuxml2xmloutdata/%s-inactive.xml",
abs_srcdir, name) < 0)
goto error;
if (!virFileExists(info->outInactiveName)) {
VIR_FREE(info->outInactiveName);
if (virAsprintf(&info->outInactiveName,
"%s/qemuxml2xmloutdata/%s.xml",
abs_srcdir, name) < 0)
goto error;
}
}
if (when & WHEN_ACTIVE) {
if (virAsprintf(&info->outActiveName,
"%s/qemuxml2xmloutdata/%s-active.xml",
abs_srcdir, name) < 0)
goto error;
if (!virFileExists(info->outActiveName)) {
VIR_FREE(info->outActiveName);
if (virAsprintf(&info->outActiveName,
"%s/qemuxml2xmloutdata/%s.xml",
abs_srcdir, name) < 0)
goto error;
}
}
return 0;
error:
testInfoClear(info);
return -1;
2007-07-18 21:34:22 +00:00
}
static const char *statusPath = abs_srcdir "/qemustatusxml2xmldata/";
static int
testInfoSetStatus(struct testInfo *info,
const char *name,
int gic)
{
if (testInfoSetCommon(info, gic) < 0)
return -1;
if (virAsprintf(&info->inName, "%s%s-in.xml", statusPath, name) < 0 ||
virAsprintf(&info->outActiveName, "%s%s-out.xml", statusPath, name) < 0)
goto error;
return 0;
error:
testInfoClear(info);
return -1;
}
# define FAKEROOTDIRTEMPLATE abs_builddir "/fakerootdir-XXXXXX"
2007-07-18 21:34:22 +00:00
static int
tests: simplify common setup A few of the tests were missing basic sanity checks, while most of them were doing copy-and-paste initialization (in fact, some of them pasted the argc > 1 check more than once!). It's much nicer to do things in one common place, and minimizes the size of the next patch that fixes getcwd usage. * tests/testutils.h (EXIT_AM_HARDFAIL): New define. (progname, abs_srcdir): Define for all tests. (VIRT_TEST_MAIN): Change callback signature. * tests/testutils.c (virtTestMain): Do more common init. * tests/commandtest.c (mymain): Simplify. * tests/cputest.c (mymain): Likewise. * tests/esxutilstest.c (mymain): Likewise. * tests/eventtest.c (mymain): Likewise. * tests/hashtest.c (mymain): Likewise. * tests/networkxml2xmltest.c (mymain): Likewise. * tests/nodedevxml2xmltest.c (myname): Likewise. * tests/nodeinfotest.c (mymain): Likewise. * tests/nwfilterxml2xmltest.c (mymain): Likewise. * tests/qemuargv2xmltest.c (mymain): Likewise. * tests/qemuhelptest.c (mymain): Likewise. * tests/qemuxml2argvtest.c (mymain): Likewise. * tests/qemuxml2xmltest.c (mymain): Likewise. * tests/qparamtest.c (mymain): Likewise. * tests/sexpr2xmltest.c (mymain): Likewise. * tests/sockettest.c (mymain): Likewise. * tests/statstest.c (mymain): Likewise. * tests/storagepoolxml2xmltest.c (mymain): Likewise. * tests/storagevolxml2xmltest.c (mymain): Likewise. * tests/virbuftest.c (mymain): Likewise. * tests/virshtest.c (mymain): Likewise. * tests/vmx2xmltest.c (mymain): Likewise. * tests/xencapstest.c (mymain): Likewise. * tests/xmconfigtest.c (mymain): Likewise. * tests/xml2sexprtest.c (mymain): Likewise. * tests/xml2vmxtest.c (mymain): Likewise.
2011-04-29 16:21:20 +00:00
mymain(void)
2007-07-18 21:34:22 +00:00
{
int ret = 0;
char *fakerootdir;
struct testInfo info;
virQEMUDriverConfigPtr cfg = NULL;
if (VIR_STRDUP_QUIET(fakerootdir, FAKEROOTDIRTEMPLATE) < 0) {
fprintf(stderr, "Out of memory\n");
abort();
}
if (!mkdtemp(fakerootdir)) {
fprintf(stderr, "Cannot create fakerootdir");
abort();
}
setenv("LIBVIRT_FAKE_ROOT_DIR", fakerootdir, 1);
memset(&info, 0, sizeof(info));
if (qemuTestDriverInit(&driver) < 0)
return EXIT_FAILURE;
cfg = virQEMUDriverGetConfig(&driver);
# define DO_TEST_FULL(name, when, gic, ...) \
do { \
if (testInfoSet(&info, name, when, gic) < 0) { \
VIR_TEST_DEBUG("Failed to generate test data for '%s'", name); \
return -1; \
} \
virQEMUCapsSetList(info.qemuCaps, __VA_ARGS__, QEMU_CAPS_LAST); \
\
if (info.outInactiveName) { \
if (virTestRun("QEMU XML-2-XML-inactive " name, \
testXML2XMLInactive, &info) < 0) \
ret = -1; \
} \
\
if (info.outActiveName) { \
if (virTestRun("QEMU XML-2-XML-active " name, \
testXML2XMLActive, &info) < 0) \
ret = -1; \
} \
testInfoClear(&info); \
} while (0)
# define NONE QEMU_CAPS_LAST
# define DO_TEST(name, ...) \
DO_TEST_FULL(name, WHEN_BOTH, GIC_NONE, __VA_ARGS__)
/* Unset or set all envvars here that are copied in qemudBuildCommandLine
* using ADD_ENV_COPY, otherwise these tests may fail due to unexpected
* values for these envvars */
setenv("PATH", "/bin", 1);
DO_TEST("minimal", NONE);
DO_TEST("genid", NONE);
DO_TEST("genid-auto", NONE);
DO_TEST("machine-core-on", NONE);
DO_TEST("machine-core-off", NONE);
DO_TEST("machine-loadparm-multiple-disks-nets-s390", NONE);
DO_TEST("default-kvm-host-arch", NONE);
DO_TEST("default-qemu-host-arch", NONE);
DO_TEST("boot-cdrom", NONE);
DO_TEST("boot-network", NONE);
DO_TEST("boot-floppy", NONE);
DO_TEST("boot-floppy-q35",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI);
DO_TEST("bootindex-floppy-q35",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_BOOTINDEX);
DO_TEST("boot-multi", NONE);
DO_TEST("boot-menu-enable-with-timeout", NONE);
DO_TEST("boot-menu-disable", NONE);
DO_TEST("boot-menu-disable-with-timeout", NONE);
DO_TEST("boot-order", NONE);
DO_TEST("reboot-timeout-enabled", NONE);
DO_TEST("reboot-timeout-disabled", NONE);
DO_TEST("clock-utc", NONE);
DO_TEST("clock-localtime", NONE);
DO_TEST("cpu-empty", NONE);
DO_TEST("cpu-kvmclock", NONE);
DO_TEST("cpu-host-kvmclock", NONE);
DO_TEST("cpu-host-passthrough-features", NONE);
DO_TEST("cpu-host-model-features", NONE);
DO_TEST("clock-catchup", NONE);
DO_TEST("kvmclock", NONE);
DO_TEST("clock-timer-hyperv-rtc", NONE);
DO_TEST("cpu-eoi-disabled", NONE);
DO_TEST("cpu-eoi-enabled", NONE);
DO_TEST("eoi-disabled", NONE);
DO_TEST("eoi-enabled", NONE);
DO_TEST("pv-spinlock-disabled", NONE);
DO_TEST("pv-spinlock-enabled", NONE);
DO_TEST("hyperv", NONE);
DO_TEST("hyperv-off", NONE);
DO_TEST("hyperv-panic", NONE);
DO_TEST("kvm-features", NONE);
DO_TEST("kvm-features-off", NONE);
DO_TEST("pmu-feature", NONE);
DO_TEST("pmu-feature-off", NONE);
DO_TEST("hugepages", NONE);
DO_TEST("hugepages-pages", NONE);
DO_TEST("hugepages-pages2", NONE);
DO_TEST("hugepages-pages3", NONE);
DO_TEST("hugepages-pages4", NONE);
DO_TEST("hugepages-pages5", NONE);
DO_TEST("hugepages-pages6", NONE);
DO_TEST("hugepages-pages7", NONE);
DO_TEST("hugepages-shared", NONE);
DO_TEST("hugepages-memaccess", NONE);
DO_TEST("hugepages-memaccess2", NONE);
DO_TEST("nosharepages", NONE);
DO_TEST("restore-v2", NONE);
DO_TEST("migrate", NONE);
DO_TEST("qemu-ns-no-env", NONE);
DO_TEST("disk-aio", NONE);
DO_TEST("disk-cdrom", NONE);
DO_TEST("disk-cdrom-empty", NONE);
DO_TEST("disk-floppy", NONE);
DO_TEST("disk-many", NONE);
DO_TEST("disk-usb-device", NONE);
DO_TEST("disk-virtio", NONE);
DO_TEST("floppy-drive-fat", NONE);
DO_TEST("disk-virtio-drive-queues", QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES);
DO_TEST("disk-drive-boot-disk", NONE);
DO_TEST("disk-drive-boot-cdrom", NONE);
DO_TEST("disk-drive-error-policy-stop", NONE);
DO_TEST("disk-drive-error-policy-enospace", NONE);
DO_TEST("disk-drive-error-policy-wreport-rignore", NONE);
DO_TEST("disk-drive-fmt-qcow", NONE);
DO_TEST("disk-drive-copy-on-read", NONE);
DO_TEST("disk-drive-cache-v2-wt", NONE);
DO_TEST("disk-drive-cache-v2-wb", NONE);
DO_TEST("disk-drive-cache-v2-none", NONE);
DO_TEST("disk-drive-cache-directsync", NONE);
DO_TEST("disk-drive-cache-unsafe", NONE);
DO_TEST("disk-drive-network-nbd", NONE);
DO_TEST("disk-drive-network-nbd-export", NONE);
DO_TEST("disk-drive-network-nbd-ipv6", NONE);
DO_TEST("disk-drive-network-nbd-ipv6-export", NONE);
DO_TEST("disk-drive-network-nbd-unix", NONE);
DO_TEST("disk-drive-network-iscsi", NONE);
DO_TEST("disk-drive-network-iscsi-auth", NONE);
DO_TEST("disk-drive-network-gluster", NONE);
DO_TEST("disk-drive-network-rbd", NONE);
DO_TEST("disk-drive-network-rbd-auth", NONE);
DO_TEST("disk-drive-network-rbd-ipv6", NONE);
DO_TEST("disk-drive-network-rbd-ceph-env", NONE);
DO_TEST("disk-drive-network-source-auth", NONE);
DO_TEST("disk-drive-network-sheepdog", NONE);
DO_TEST("disk-drive-network-vxhs", NONE);
DO_TEST("disk-drive-network-tlsx509", NONE);
DO_TEST("disk-scsi-device",
QEMU_CAPS_SCSI_LSI);
DO_TEST("disk-scsi-vscsi", NONE);
DO_TEST("disk-scsi-virtio-scsi",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("disk-virtio-scsi-num_queues",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("disk-virtio-scsi-reservations",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_PR_MANAGER_HELPER);
DO_TEST("disk-virtio-scsi-cmd_per_lun",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("disk-virtio-scsi-max_sectors",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("disk-virtio-scsi-ioeventfd",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("disk-scsi-megasas",
QEMU_CAPS_SCSI_MEGASAS);
DO_TEST("disk-scsi-mptsas1068",
QEMU_CAPS_SCSI_MPTSAS1068,
QEMU_CAPS_SCSI_DISK_WWN);
DO_TEST("disk-mirror-old", NONE);
DO_TEST("disk-mirror", NONE);
DO_TEST_FULL("disk-active-commit", WHEN_ACTIVE, GIC_NONE, NONE);
DO_TEST("graphics-listen-network", NONE);
DO_TEST("graphics-vnc", NONE);
DO_TEST("graphics-vnc-websocket", NONE);
DO_TEST("graphics-vnc-sasl", NONE);
DO_TEST("graphics-vnc-tls", NONE);
DO_TEST("graphics-vnc-no-listen-attr", NONE);
DO_TEST("graphics-vnc-remove-generated-socket", NONE);
cfg->vncAutoUnixSocket = true;
DO_TEST("graphics-vnc-auto-socket-cfg", NONE);
cfg->vncAutoUnixSocket = false;
DO_TEST("graphics-vnc-socket", NONE);
DO_TEST("graphics-vnc-auto-socket", NONE);
DO_TEST("graphics-sdl", NONE);
DO_TEST("graphics-sdl-fullscreen", NONE);
DO_TEST("graphics-spice", NONE);
DO_TEST("graphics-spice-compression", NONE);
DO_TEST("graphics-spice-qxl-vga", NONE);
DO_TEST("graphics-spice-socket", NONE);
DO_TEST("graphics-spice-auto-socket", NONE);
cfg->spiceAutoUnixSocket = true;
DO_TEST("graphics-spice-auto-socket-cfg", NONE);
cfg->spiceAutoUnixSocket = false;
DO_TEST("input-usbmouse", NONE);
DO_TEST("input-usbtablet", NONE);
DO_TEST("misc-acpi", NONE);
DO_TEST("misc-disable-s3", NONE);
DO_TEST("misc-disable-suspends", NONE);
DO_TEST("misc-enable-s4", NONE);
DO_TEST("misc-no-reboot", NONE);
DO_TEST("misc-uuid", NONE);
DO_TEST("net-vhostuser", NONE);
DO_TEST("net-user", NONE);
DO_TEST("net-user-addr", NONE);
DO_TEST("net-virtio", NONE);
DO_TEST("net-virtio-device", NONE);
DO_TEST("net-virtio-disable-offloads", NONE);
DO_TEST("net-eth", NONE);
DO_TEST("net-eth-ifname", NONE);
DO_TEST("net-eth-hostip", NONE);
DO_TEST("net-virtio-network-portgroup", NONE);
DO_TEST("net-virtio-rxtxqueuesize", NONE);
DO_TEST("net-hostdev", NONE);
DO_TEST("net-hostdev-vfio", NONE);
DO_TEST("net-midonet", NONE);
DO_TEST("net-openvswitch", NONE);
DO_TEST("sound", NONE);
DO_TEST("sound-device", NONE);
DO_TEST("watchdog", NONE);
DO_TEST("net-bandwidth", NONE);
DO_TEST("net-bandwidth2", NONE);
DO_TEST("net-mtu", NONE);
DO_TEST("net-coalesce", NONE);
DO_TEST("serial-tcp-tlsx509-chardev", NONE);
DO_TEST("serial-tcp-tlsx509-chardev-notls", NONE);
DO_TEST("serial-spiceport", NONE);
DO_TEST("serial-spiceport-nospice", NONE);
DO_TEST("console-compat", NONE);
DO_TEST("console-compat2", NONE);
DO_TEST("console-virtio-many", NONE);
DO_TEST("channel-guestfwd", NONE);
DO_TEST("channel-virtio", NONE);
DO_TEST("channel-virtio-state", NONE);
DO_TEST_FULL("channel-unix-source-path", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST("hostdev-usb-address", NONE);
DO_TEST("hostdev-pci-address", NONE);
DO_TEST("hostdev-vfio", NONE);
DO_TEST("hostdev-mdev-precreated", NONE);
DO_TEST("pci-rom", NONE);
DO_TEST("pci-rom-disabled", NONE);
DO_TEST("pci-rom-disabled-invalid", NONE);
DO_TEST("pci-serial-dev-chardev", NONE);
DO_TEST("encrypted-disk", QEMU_CAPS_QCOW2_LUKS);
DO_TEST("encrypted-disk-usage", QEMU_CAPS_QCOW2_LUKS);
DO_TEST("luks-disks", NONE);
DO_TEST("luks-disks-source", NONE);
DO_TEST("memtune", NONE);
DO_TEST("memtune-unlimited", NONE);
DO_TEST("blkiotune", NONE);
DO_TEST("blkiotune-device", NONE);
DO_TEST("cputune", NONE);
DO_TEST("cputune-zero-shares", NONE);
DO_TEST("cputune-iothreadsched", NONE);
DO_TEST("cputune-iothreadsched-zeropriority", NONE);
DO_TEST("cputune-numatune", NONE);
DO_TEST("vcpu-placement-static",
QEMU_CAPS_KVM,
QEMU_CAPS_OBJECT_IOTHREAD);
DO_TEST("smp", NONE);
DO_TEST("iothreads", NONE);
DO_TEST("iothreads-ids", NONE);
DO_TEST("iothreads-ids-partial", NONE);
DO_TEST("cputune-iothreads", NONE);
DO_TEST("iothreads-disk", NONE);
DO_TEST("iothreads-disk-virtio-ccw",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("iothreads-virtio-scsi-pci",
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("iothreads-virtio-scsi-ccw",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_CCW,
QEMU_CAPS_VIRTIO_S390);
DO_TEST("lease", NONE);
DO_TEST("event_idx", NONE);
DO_TEST("vhost_queues", NONE);
DO_TEST("interface-driver", NONE);
DO_TEST("interface-server", NONE);
DO_TEST("virtio-lun", NONE);
DO_TEST("usb-none", NONE);
DO_TEST("usb-controller", NONE);
DO_TEST("usb-piix3-controller",
QEMU_CAPS_PIIX3_USB_UHCI);
DO_TEST("usb-controller-default-q35",
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_PCI_OHCI,
QEMU_CAPS_PIIX3_USB_UHCI,
QEMU_CAPS_NEC_USB_XHCI);
DO_TEST("usb-controller-explicit-q35",
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_PCI_OHCI,
QEMU_CAPS_PIIX3_USB_UHCI,
QEMU_CAPS_NEC_USB_XHCI);
DO_TEST("ppc64-usb-controller",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_PCI_OHCI);
DO_TEST("ppc64-usb-controller-legacy",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_PIIX3_USB_UHCI);
DO_TEST("usb-port-missing", NONE);
DO_TEST("usb-redir", NONE);
DO_TEST("usb-redir-filter", NONE);
DO_TEST("usb-redir-filter-version", NONE);
DO_TEST("blkdeviotune", NONE);
DO_TEST("blkdeviotune-max", NONE);
DO_TEST("blkdeviotune-group-num", NONE);
DO_TEST("blkdeviotune-max-length", NONE);
DO_TEST("controller-usb-order", NONE);
DO_TEST_FULL("seclabel-dynamic-baselabel", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST_FULL("seclabel-dynamic-override", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST_FULL("seclabel-dynamic-labelskip", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST_FULL("seclabel-dynamic-relabel", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST("seclabel-static", NONE);
DO_TEST_FULL("seclabel-static-labelskip", WHEN_ACTIVE, GIC_NONE, NONE);
DO_TEST("seclabel-none", NONE);
DO_TEST("seclabel-dac-none", NONE);
DO_TEST("seclabel-dynamic-none", NONE);
DO_TEST("seclabel-device-multiple", NONE);
DO_TEST_FULL("seclabel-dynamic-none-relabel", WHEN_INACTIVE, GIC_NONE, NONE);
DO_TEST("numad-static-vcpu-no-numatune", NONE);
DO_TEST("disk-scsi-lun-passthrough-sgio",
QEMU_CAPS_SCSI_CD, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_DISK_WWN);
DO_TEST("disk-scsi-disk-vpd",
QEMU_CAPS_SCSI_CD, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_DISK_WWN);
DO_TEST("disk-source-pool", NONE);
DO_TEST("disk-source-pool-mode", NONE);
DO_TEST("disk-drive-discard", NONE);
DO_TEST("disk-drive-detect-zeroes", NONE);
DO_TEST("disk-serial", NONE);
DO_TEST("virtio-rng-random", NONE);
DO_TEST("virtio-rng-egd", NONE);
DO_TEST("pseries-nvram",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-panic-missing",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-panic-no-address",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-phb-simple",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-phb-default-missing",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-phb-numa-node",
QEMU_CAPS_NUMA,
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE);
DO_TEST("pseries-many-devices",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("pseries-many-buses-1",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("pseries-many-buses-2",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("pseries-hostdevs-1",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_VFIO_PCI);
DO_TEST("pseries-hostdevs-2",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_VFIO_PCI);
DO_TEST("pseries-hostdevs-3",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_VFIO_PCI);
DO_TEST("pseries-features",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT);
DO_TEST("pseries-serial-native",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_SPAPR_VTY);
DO_TEST("pseries-serial+console-native",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_SPAPR_VTY);
DO_TEST("pseries-serial-compat",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_SPAPR_VTY);
DO_TEST("pseries-serial-pci",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_PCI_SERIAL);
DO_TEST("pseries-serial-usb",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_QEMU_XHCI,
QEMU_CAPS_DEVICE_USB_SERIAL);
DO_TEST("pseries-console-native",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_DEVICE_SPAPR_VTY);
DO_TEST("pseries-console-virtio",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("mach-virt-serial-native", NONE);
DO_TEST("mach-virt-serial+console-native", NONE);
DO_TEST("mach-virt-serial-compat", NONE);
DO_TEST("mach-virt-serial-pci",
QEMU_CAPS_OBJECT_GPEX,
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCI_SERIAL);
DO_TEST("mach-virt-serial-usb",
QEMU_CAPS_OBJECT_GPEX,
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT,
QEMU_CAPS_DEVICE_QEMU_XHCI,
QEMU_CAPS_DEVICE_USB_SERIAL);
DO_TEST("mach-virt-console-native", NONE);
DO_TEST("mach-virt-console-virtio", NONE);
DO_TEST("balloon-device-auto", NONE);
DO_TEST("balloon-device-period", NONE);
DO_TEST("channel-virtio-auto", NONE);
DO_TEST("console-compat-auto", NONE);
DO_TEST("disk-scsi-device-auto",
QEMU_CAPS_SCSI_LSI);
DO_TEST("console-virtio", NONE);
DO_TEST("serial-target-port-auto", NONE);
DO_TEST("graphics-listen-network2", NONE);
DO_TEST("graphics-spice-timeout", NONE);
DO_TEST("numad-auto-vcpu-no-numatune", NONE);
DO_TEST("numad-auto-memory-vcpu-no-cpuset-and-placement", NONE);
DO_TEST("numad-auto-memory-vcpu-cpuset", NONE);
DO_TEST("usb-ich9-ehci-addr", NONE);
DO_TEST("disk-copy_on_read", NONE);
DO_TEST("tpm-passthrough", NONE);
DO_TEST("tpm-passthrough-crb", NONE);
DO_TEST("metadata", NONE);
DO_TEST("metadata-duplicate", NONE);
DO_TEST("pci-bridge",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_VNC,
QEMU_CAPS_DEVICE_CIRRUS_VGA);
DO_TEST("pci-many",
QEMU_CAPS_DEVICE_CIRRUS_VGA);
DO_TEST("pci-bridge-many-disks",
QEMU_CAPS_DEVICE_PCI_BRIDGE);
DO_TEST("pci-autoadd-addr",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_CIRRUS_VGA);
DO_TEST("pci-autoadd-idx",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_CIRRUS_VGA);
DO_TEST("pci-autofill-addr", NONE);
DO_TEST("q35",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("q35-usb2",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("q35-usb2-multi",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("q35-usb2-reorder",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
qemu: assign virtio devices to PCIe slot when appropriate libvirt previously assigned nearly all devices to a "hotpluggable" legacy PCI slot even on machines with a PCIe root bus (and even though most such machines don't even support hotplug on legacy PCI slots!) Forcing all devices onto legacy PCI slots means that the domain will need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a pci-bridge (to provide hotpluggable legacy PCI slots which, again, usually aren't hotpluggable anyway). To help reduce the need for these legacy controllers, this patch tries to assign virtio-1.0-capable devices to PCIe slots whenever possible, by setting appropriate connectFlags in virDomainCalculateDevicePCIConnectFlags(). Happily, when that function was written (just a few commits ago) it was created with a "virtioFlags" argument, set by both of its callers, which is the proper connectFlags to set for any virtio-*-pci device - depending on the arch/machinetype of the domain, and whether or not the qemu binary supports virtio-1.0, that flag will have either been set to PCI or PCIe. This patch merely enables the functionality by setting the flags for the device to whatever is in virtioFlags if the device is a virtio-*-pci device. NB: the first virtio video device will be placed directly on bus 0 slot 1 rather than on a pcie-root-port due to the override for primary video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not to change that is a topic of discussion, but this patch doesn't change that particular behavior. NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root complex) does *not* support hotplug, this means that suitable controllers must also be in the config (i.e. either pcie-root-port, or pcie-downstream-port). For now, libvirt doesn't add those automatically, so if you put virtio devices in a config for a qemu that has PCIe-capable virtio devices, you'll need to add extra pcie-root-ports yourself. That requirement will be eliminated in a future patch, but for now, it's simple to do this: <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> ... Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
2016-08-13 22:10:41 +00:00
DO_TEST("q35-pcie",
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
qemu: assign virtio devices to PCIe slot when appropriate libvirt previously assigned nearly all devices to a "hotpluggable" legacy PCI slot even on machines with a PCIe root bus (and even though most such machines don't even support hotplug on legacy PCI slots!) Forcing all devices onto legacy PCI slots means that the domain will need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a pci-bridge (to provide hotpluggable legacy PCI slots which, again, usually aren't hotpluggable anyway). To help reduce the need for these legacy controllers, this patch tries to assign virtio-1.0-capable devices to PCIe slots whenever possible, by setting appropriate connectFlags in virDomainCalculateDevicePCIConnectFlags(). Happily, when that function was written (just a few commits ago) it was created with a "virtioFlags" argument, set by both of its callers, which is the proper connectFlags to set for any virtio-*-pci device - depending on the arch/machinetype of the domain, and whether or not the qemu binary supports virtio-1.0, that flag will have either been set to PCI or PCIe. This patch merely enables the functionality by setting the flags for the device to whatever is in virtioFlags if the device is a virtio-*-pci device. NB: the first virtio video device will be placed directly on bus 0 slot 1 rather than on a pcie-root-port due to the override for primary video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not to change that is a topic of discussion, but this patch doesn't change that particular behavior. NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root complex) does *not* support hotplug, this means that suitable controllers must also be in the config (i.e. either pcie-root-port, or pcie-downstream-port). For now, libvirt doesn't add those automatically, so if you put virtio devices in a config for a qemu that has PCIe-capable virtio devices, you'll need to add extra pcie-root-ports yourself. That requirement will be eliminated in a future patch, but for now, it's simple to do this: <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> ... Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
2016-08-13 22:10:41 +00:00
QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
/* same XML as q35-pcie, but don't set
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY */
DO_TEST("q35-virtio-pci",
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
qemu: assign virtio devices to PCIe slot when appropriate libvirt previously assigned nearly all devices to a "hotpluggable" legacy PCI slot even on machines with a PCIe root bus (and even though most such machines don't even support hotplug on legacy PCI slots!) Forcing all devices onto legacy PCI slots means that the domain will need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a pci-bridge (to provide hotpluggable legacy PCI slots which, again, usually aren't hotpluggable anyway). To help reduce the need for these legacy controllers, this patch tries to assign virtio-1.0-capable devices to PCIe slots whenever possible, by setting appropriate connectFlags in virDomainCalculateDevicePCIConnectFlags(). Happily, when that function was written (just a few commits ago) it was created with a "virtioFlags" argument, set by both of its callers, which is the proper connectFlags to set for any virtio-*-pci device - depending on the arch/machinetype of the domain, and whether or not the qemu binary supports virtio-1.0, that flag will have either been set to PCI or PCIe. This patch merely enables the functionality by setting the flags for the device to whatever is in virtioFlags if the device is a virtio-*-pci device. NB: the first virtio video device will be placed directly on bus 0 slot 1 rather than on a pcie-root-port due to the override for primary video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not to change that is a topic of discussion, but this patch doesn't change that particular behavior. NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root complex) does *not* support hotplug, this means that suitable controllers must also be in the config (i.e. either pcie-root-port, or pcie-downstream-port). For now, libvirt doesn't add those automatically, so if you put virtio devices in a config for a qemu that has PCIe-capable virtio devices, you'll need to add extra pcie-root-ports yourself. That requirement will be eliminated in a future patch, but for now, it's simple to do this: <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> ... Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
2016-08-13 22:10:41 +00:00
QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot.
2016-09-19 18:38:47 +00:00
/* same as q35-pcie, but all PCI controllers are added automatically */
DO_TEST("q35-pcie-autoadd",
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
DO_TEST("q35-default-devices-only",
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot.
2016-09-19 18:38:47 +00:00
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
DO_TEST("q35-multifunction",
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot.
2016-09-19 18:38:47 +00:00
QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
DO_TEST("q35-virt-manager-basic",
QEMU_CAPS_KVM,
QEMU_CAPS_ICH9_DISABLE_S3,
QEMU_CAPS_ICH9_DISABLE_S4,
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
QEMU_CAPS_DEVICE_VIRTIO_RNG,
QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_DEVICE_VIRTIO_NET,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_VIRTIO_GPU_VIRGL,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI,
QEMU_CAPS_DEVICE_ICH9_INTEL_HDA,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_SPICE,
QEMU_CAPS_DEVICE_QXL,
QEMU_CAPS_HDA_DUPLEX,
QEMU_CAPS_USB_REDIR);
DO_TEST("pcie-root",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
/* Test automatic and manual setting of pcie-root-port attributes */
DO_TEST("pcie-root-port",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
/* Make sure the default model for PCIe Root Ports is picked correctly
* based on QEMU binary capabilities. We use x86/q35 for the test, but
* any PCIe machine type (such as aarch64/virt) will behave the same */
DO_TEST("pcie-root-port-model-generic",
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT,
QEMU_CAPS_DEVICE_IOH3420);
DO_TEST("pcie-root-port-model-ioh3420",
QEMU_CAPS_DEVICE_IOH3420);
DO_TEST("pcie-switch-upstream-port",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_X3130_UPSTREAM,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("pcie-switch-downstream-port",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_X3130_UPSTREAM,
QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("pci-expander-bus",
QEMU_CAPS_DEVICE_PXB);
DO_TEST("pcie-expander-bus",
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_X3130_UPSTREAM,
QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM,
QEMU_CAPS_DEVICE_PXB_PCIE);
DO_TEST("autoindex",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_X3130_UPSTREAM,
QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_ICH9_USB_EHCI1,
QEMU_CAPS_NEC_USB_XHCI);
/* Make sure the user can always override libvirt's default device
* placement policy by providing an explicit PCI address */
DO_TEST("q35-pci-force-address",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_HDA_DUPLEX);
DO_TEST("hostdev-scsi-vhost-scsi-ccw",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_DEVICE_VHOST_SCSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC, QEMU_CAPS_CCW);
DO_TEST("hostdev-scsi-vhost-scsi-pci",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_DEVICE_VHOST_SCSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
qemu: assign correct type of PCI address for vhost-scsi when using pcie-root Commit 10c73bf1 fixed a bug that I had introduced back in commit 70249927 - if a vhost-scsi device had no manually assigned PCI address, one wouldn't be assigned automatically. There was a slight problem with the logic of the fix though - in the case of domains with pcie-root (e.g. those with a q35 machinetype), qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine if the host-side PCI device is Express or legacy by examining sysfs based on the host-side PCI address stored in hostdev->source.subsys.u.pci.addr, but that part of the union is only valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying to read sysfs for some probably-non-existent device, which fails, and the function virPCIDeviceIsPCIExpress() returns failure (-1). By coincidence, the return value is being examined as a boolean, and since -1 is true, we still end up assigning the vhost-scsi device to an Express slot, but that is just by chance (and could fail in the case that the gibberish in the "hostside PCI address" was the address of a real device that happened to be legacy PCI). Since (according to Paolo Bonzini) vhost-scsi devices appear just like virtio-scsi devices in the guest, they should follow the same rules as virtio devices when deciding whether they should be placed in an Express or a legacy slot. That's accomplished in this patch by returning early with virtioFlags, rather than erroneously using hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe to assure it doesn't get broken in the future.
2017-12-15 16:42:35 +00:00
DO_TEST("hostdev-scsi-vhost-scsi-pcie",
QEMU_CAPS_KVM,
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_DEVICE_VHOST_SCSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC,
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT,
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY);
DO_TEST("hostdev-scsi-lsi",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-virtio-scsi",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-readonly",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-shareable",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-sgio",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-rawio",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-autogen-address",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-large-unit",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-lsi-iscsi",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-lsi-iscsi-auth",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-virtio-iscsi",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-scsi-virtio-iscsi-auth",
QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_SCSI_LSI,
QEMU_CAPS_DEVICE_SCSI_GENERIC);
DO_TEST("hostdev-subsys-mdev-vfio-ccw",
QEMU_CAPS_CCW,
QEMU_CAPS_CCW_CSSID_UNRESTRICTED,
QEMU_CAPS_DEVICE_VFIO_CCW);
DO_TEST("s390-defaultconsole",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-panic",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-panic-missing",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-panic-no-address",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-serial",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-serial-2",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("s390-serial-console",
QEMU_CAPS_CCW, QEMU_CAPS_VIRTIO_S390);
DO_TEST("pcihole64", NONE);
DO_TEST("pcihole64-gib", NONE);
DO_TEST("pcihole64-none", NONE);
DO_TEST("pcihole64-q35",
qemu: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_ICH9_AHCI,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL,
QEMU_CAPS_Q35_PCI_HOLE64_SIZE);
DO_TEST("panic", NONE);
DO_TEST("panic-isa", NONE);
DO_TEST("panic-pseries",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("panic-double", NONE);
DO_TEST("panic-no-address", NONE);
DO_TEST("disk-backing-chains", NONE);
DO_TEST("chardev-label", NONE);
DO_TEST("cpu-numa1", NONE);
DO_TEST("cpu-numa2", NONE);
DO_TEST("cpu-numa-no-memory-element", NONE);
DO_TEST("cpu-numa-disordered", NONE);
DO_TEST("cpu-numa-disjoint", NONE);
DO_TEST("cpu-numa-memshared", NONE);
DO_TEST("numatune-auto-prefer", NONE);
DO_TEST("numatune-memnode", NONE);
DO_TEST("numatune-memnode-no-memory", NONE);
DO_TEST("bios-nvram", NONE);
DO_TEST("bios-nvram-os-interleave", NONE);
DO_TEST("tap-vhost", NONE);
DO_TEST("tap-vhost-incorrect", NONE);
DO_TEST("shmem", NONE);
DO_TEST("shmem-plain-doorbell", NONE);
DO_TEST("smbios", NONE);
DO_TEST("smbios-multiple-type2", NONE);
DO_TEST("aarch64-aavmf-virtio-mmio",
QEMU_CAPS_DEVICE_VIRTIO_MMIO,
QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM);
DO_TEST("aarch64-virtio-pci-default",
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
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: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_VIRTIO_SCSI);
DO_TEST("aarch64-virtio-pci-manual-addresses",
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: initially reserve one open pcie-root-port for hotplug For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
2016-09-28 00:37:30 +00:00
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_VIRTIO_SCSI);
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) Most of QEMU's PCI display device models, such as: libvirt video/model/@type QEMU -device ------------------------- ------------ cirrus cirrus-vga vga VGA qxl qxl-vga virtio virtio-vga come with a linear framebuffer (sometimes called "VGA compatibility framebuffer"). This linear framebuffer lives in one of the PCI device's MMIO BARs, and allows guest code (primarily: firmware drivers, and non-accelerated OS drivers) to display graphics with direct memory access. Due to architectural reasons on aarch64/KVM hosts, this kind of framebuffer doesn't / can't work in qemu-system-(arm|aarch64) -M virt machines. Cache coherency issues guarantee a corrupted / unusable display. The problem has been researched by several people, including kvm-arm maintainers, and it's been decided that the best way (practically the only way) to have boot time graphics for such guests is to consolidate on QEMU's "virtio-gpu-pci" device. >From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt supports <devices> <video> <model type='virtio'/> </video> </devices> but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga" device model. (See the qemuBuildDeviceVideoStr() function and the "qemuDeviceVideo" enum impl.) According to the above, this is not right for the "virt" machine type; the qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga" device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure virtio device without a compatibility framebuffer, is available, and works fine. (The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware for "virt" -- supports "virtio-gpu-pci", as of upstream commit 3ef3209d3028. See <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.) Override the default mapping of "virtio", from "virtio-vga" to "virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true. Cc: Andrea Bolognani <abologna@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
DO_TEST("aarch64-video-virtio-gpu-pci",
QEMU_CAPS_OBJECT_GPEX,
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) Most of QEMU's PCI display device models, such as: libvirt video/model/@type QEMU -device ------------------------- ------------ cirrus cirrus-vga vga VGA qxl qxl-vga virtio virtio-vga come with a linear framebuffer (sometimes called "VGA compatibility framebuffer"). This linear framebuffer lives in one of the PCI device's MMIO BARs, and allows guest code (primarily: firmware drivers, and non-accelerated OS drivers) to display graphics with direct memory access. Due to architectural reasons on aarch64/KVM hosts, this kind of framebuffer doesn't / can't work in qemu-system-(arm|aarch64) -M virt machines. Cache coherency issues guarantee a corrupted / unusable display. The problem has been researched by several people, including kvm-arm maintainers, and it's been decided that the best way (practically the only way) to have boot time graphics for such guests is to consolidate on QEMU's "virtio-gpu-pci" device. >From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt supports <devices> <video> <model type='virtio'/> </video> </devices> but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga" device model. (See the qemuBuildDeviceVideoStr() function and the "qemuDeviceVideo" enum impl.) According to the above, this is not right for the "virt" machine type; the qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga" device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure virtio device without a compatibility framebuffer, is available, and works fine. (The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware for "virt" -- supports "virtio-gpu-pci", as of upstream commit 3ef3209d3028. See <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.) Override the default mapping of "virtio", from "virtio-vga" to "virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true. Cc: Andrea Bolognani <abologna@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
QEMU_CAPS_DEVICE_PCI_BRIDGE, QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) Most of QEMU's PCI display device models, such as: libvirt video/model/@type QEMU -device ------------------------- ------------ cirrus cirrus-vga vga VGA qxl qxl-vga virtio virtio-vga come with a linear framebuffer (sometimes called "VGA compatibility framebuffer"). This linear framebuffer lives in one of the PCI device's MMIO BARs, and allows guest code (primarily: firmware drivers, and non-accelerated OS drivers) to display graphics with direct memory access. Due to architectural reasons on aarch64/KVM hosts, this kind of framebuffer doesn't / can't work in qemu-system-(arm|aarch64) -M virt machines. Cache coherency issues guarantee a corrupted / unusable display. The problem has been researched by several people, including kvm-arm maintainers, and it's been decided that the best way (practically the only way) to have boot time graphics for such guests is to consolidate on QEMU's "virtio-gpu-pci" device. >From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt supports <devices> <video> <model type='virtio'/> </video> </devices> but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga" device model. (See the qemuBuildDeviceVideoStr() function and the "qemuDeviceVideo" enum impl.) According to the above, this is not right for the "virt" machine type; the qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga" device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure virtio device without a compatibility framebuffer, is available, and works fine. (The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware for "virt" -- supports "virtio-gpu-pci", as of upstream commit 3ef3209d3028. See <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.) Override the default mapping of "virtio", from "virtio-vga" to "virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true. Cc: Andrea Bolognani <abologna@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
QEMU_CAPS_DEVICE_VIRTIO_GPU, QEMU_CAPS_BOOTINDEX);
DO_TEST("aarch64-pci-serial",
QEMU_CAPS_DEVICE_PCI_SERIAL,
QEMU_CAPS_CHARDEV_LOGFILE,
QEMU_CAPS_OBJECT_GPEX,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT);
DO_TEST("aarch64-traditional-pci",
QEMU_CAPS_OBJECT_GPEX,
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_PCI_SERIAL);
DO_TEST("aarch64-video-default",
QEMU_CAPS_OBJECT_GPEX,
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_VNC);
DO_TEST_FULL("aarch64-gic-none", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-none-v2", WHEN_BOTH, GIC_V2, NONE);
DO_TEST_FULL("aarch64-gic-none-v3", WHEN_BOTH, GIC_V3, NONE);
DO_TEST_FULL("aarch64-gic-none-both", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST_FULL("aarch64-gic-none-tcg", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST_FULL("aarch64-gic-default", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-default-v2", WHEN_BOTH, GIC_V2, NONE);
DO_TEST_FULL("aarch64-gic-default-v3", WHEN_BOTH, GIC_V3, NONE);
DO_TEST_FULL("aarch64-gic-default-both", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST_FULL("aarch64-gic-v2", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-v2", WHEN_BOTH, GIC_V2, NONE);
DO_TEST_FULL("aarch64-gic-v2", WHEN_BOTH, GIC_V3, NONE);
DO_TEST_FULL("aarch64-gic-v2", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST_FULL("aarch64-gic-v3", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-v3", WHEN_BOTH, GIC_V2, NONE);
DO_TEST_FULL("aarch64-gic-v3", WHEN_BOTH, GIC_V3, NONE);
DO_TEST_FULL("aarch64-gic-v3", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST_FULL("aarch64-gic-host", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-host", WHEN_BOTH, GIC_V2, NONE);
DO_TEST_FULL("aarch64-gic-host", WHEN_BOTH, GIC_V3, NONE);
DO_TEST_FULL("aarch64-gic-host", WHEN_BOTH, GIC_BOTH, NONE);
DO_TEST("memory-hotplug", NONE);
DO_TEST("memory-hotplug-nonuma", NONE);
DO_TEST("memory-hotplug-dimm", NONE);
DO_TEST("memory-hotplug-nvdimm", NONE);
DO_TEST("memory-hotplug-nvdimm-access", NONE);
DO_TEST("memory-hotplug-nvdimm-label", NONE);
DO_TEST("net-udp", NONE);
DO_TEST("video-virtio-gpu-device", NONE);
DO_TEST("video-virtio-gpu-virgl", NONE);
DO_TEST("video-virtio-gpu-spice-gl", NONE);
DO_TEST("video-virtio-gpu-sdl-gl", NONE);
DO_TEST("virtio-input", NONE);
DO_TEST("virtio-input-passthrough", NONE);
DO_TEST("memorybacking-set", NONE);
DO_TEST("memorybacking-unset", NONE);
DO_TEST("virtio-options", QEMU_CAPS_VIRTIO_SCSI);
virObjectUnref(cfg);
DO_TEST("acpi-table", NONE);
DO_TEST("video-device-pciaddr-default",
QEMU_CAPS_KVM,
QEMU_CAPS_VNC,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_DEVICE_QXL);
DO_TEST("video-qxl-heads", NONE);
DO_TEST("video-qxl-noheads", NONE);
DO_TEST("video-virtio-gpu-secondary", NONE);
DO_TEST("video-virtio-gpu-ccw",
QEMU_CAPS_CCW,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS,
QEMU_CAPS_VNC,
QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW);
DO_TEST("video-virtio-gpu-ccw-auto",
QEMU_CAPS_CCW,
QEMU_CAPS_DEVICE_VIRTIO_GPU,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS,
QEMU_CAPS_VNC,
QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW);
DO_TEST("intel-iommu",
QEMU_CAPS_DEVICE_INTEL_IOMMU);
DO_TEST("intel-iommu-machine",
QEMU_CAPS_MACHINE_IOMMU);
DO_TEST("intel-iommu-caching-mode",
QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
QEMU_CAPS_DEVICE_IOH3420);
DO_TEST("intel-iommu-eim", NONE);
DO_TEST("intel-iommu-device-iotlb", NONE);
DO_TEST("cpu-check-none", NONE);
DO_TEST("cpu-check-partial", NONE);
DO_TEST("cpu-check-full", NONE);
DO_TEST("cpu-check-default-none", NONE);
DO_TEST("cpu-check-default-none2", NONE);
DO_TEST("cpu-check-default-partial", NONE);
DO_TEST("cpu-check-default-partial2", NONE);
DO_TEST("vmcoreinfo", NONE);
DO_TEST("smartcard-host", NONE);
DO_TEST("smartcard-host-certificates", NONE);
DO_TEST("smartcard-passthrough-tcp", NONE);
DO_TEST("smartcard-passthrough-spicevmc", NONE);
DO_TEST("smartcard-controller", NONE);
DO_TEST("pseries-cpu-compat-power9",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-cpu-compat",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("pseries-cpu-exact",
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE);
DO_TEST("user-aliases", QEMU_CAPS_QCOW2_LUKS);
DO_TEST("input-virtio-ccw",
QEMU_CAPS_CCW,
QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE,
QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW,
QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW,
QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW);
/* Test disks with format probing enabled for legacy reasons.
* New tests should not go in this section. */
driver.config->allowDiskFormatProbing = true;
DO_TEST("disk-many-format-probing", NONE);
driver.config->allowDiskFormatProbing = false;
# define DO_TEST_STATUS(name) \
do { \
if (testInfoSetStatus(&info, name, GIC_NONE) < 0) { \
VIR_TEST_DEBUG("Failed to generate status test data for '%s'", name); \
return -1; \
} \
\
if (virTestRun("QEMU status XML-2-XML " name, \
testCompareStatusXMLToXMLFiles, &info) < 0) \
ret = -1; \
\
testInfoClear(&info); \
} while (0)
DO_TEST_STATUS("blockjob-mirror");
DO_TEST_STATUS("vcpus-multi");
DO_TEST_STATUS("modern");
DO_TEST_STATUS("migration-out-nbd");
DO_TEST_STATUS("migration-in-params");
DO_TEST_STATUS("migration-out-params");
DO_TEST_STATUS("migration-out-nbd-tls");
DO_TEST_STATUS("disk-secinfo-upgrade");
DO_TEST("vhost-vsock", QEMU_CAPS_DEVICE_VHOST_VSOCK);
DO_TEST("vhost-vsock-auto", QEMU_CAPS_DEVICE_VHOST_VSOCK);
if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
virFileDeleteTree(fakerootdir);
qemuTestDriverFree(&driver);
VIR_FREE(fakerootdir);
2007-07-18 21:34:22 +00:00
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
2007-07-18 21:34:22 +00:00
}
VIR_TEST_MAIN_PRELOAD(mymain,
abs_builddir "/.libs/virpcimock.so",
abs_builddir "/.libs/virrandommock.so")
#else
int
main(void)
{
return EXIT_AM_SKIP;
}
#endif /* WITH_QEMU */