From 0592b1e444e8ef7f00fb04a637dba72b732b70e4 Mon Sep 17 00:00:00 2001 From: Stefan Hajnoczi Date: Mon, 9 Dec 2019 21:09:57 +0000 Subject: [PATCH 1/9] virtio: don't enable notifications during polling Virtqueue notifications are not necessary during polling, so we disable them. This allows the guest driver to avoid MMIO vmexits. Unfortunately the virtio-blk and virtio-scsi handler functions re-enable notifications, defeating this optimization. Fix virtio-blk and virtio-scsi emulation so they leave notifications disabled. The key thing to remember for correctness is that polling always checks one last time after ending its loop, therefore it's safe to lose the race when re-enabling notifications at the end of polling. There is a measurable performance improvement of 5-10% with the null-co block driver. Real-life storage configurations will see a smaller improvement because the MMIO vmexit overhead contributes less to latency. Signed-off-by: Stefan Hajnoczi Message-Id: <20191209210957.65087-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/block/virtio-blk.c | 9 +++++++-- hw/scsi/virtio-scsi.c | 9 +++++++-- hw/virtio/virtio.c | 12 ++++++------ include/hw/virtio/virtio.h | 1 + 4 files changed, 21 insertions(+), 10 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 2db9804cfe..fbe2ed6779 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -766,13 +766,16 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq) { VirtIOBlockReq *req; MultiReqBuffer mrb = {}; + bool suppress_notifications = virtio_queue_get_notification(vq); bool progress = false; aio_context_acquire(blk_get_aio_context(s->blk)); blk_io_plug(s->blk); do { - virtio_queue_set_notification(vq, 0); + if (suppress_notifications) { + virtio_queue_set_notification(vq, 0); + } while ((req = virtio_blk_get_request(s, vq))) { progress = true; @@ -783,7 +786,9 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq) } } - virtio_queue_set_notification(vq, 1); + if (suppress_notifications) { + virtio_queue_set_notification(vq, 1); + } } while (!virtio_queue_empty(vq)); if (mrb.num_reqs) { diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 8b9e5e2b49..eddb13e7c6 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -594,12 +594,15 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq) { VirtIOSCSIReq *req, *next; int ret = 0; + bool suppress_notifications = virtio_queue_get_notification(vq); bool progress = false; QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs); do { - virtio_queue_set_notification(vq, 0); + if (suppress_notifications) { + virtio_queue_set_notification(vq, 0); + } while ((req = virtio_scsi_pop_req(s, vq))) { progress = true; @@ -619,7 +622,9 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq) } } - virtio_queue_set_notification(vq, 1); + if (suppress_notifications) { + virtio_queue_set_notification(vq, 1); + } } while (ret != -EINVAL && !virtio_queue_empty(vq)); QTAILQ_FOREACH_SAFE(req, &reqs, next, next) { diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c index 90971f4afa..daa8250332 100644 --- a/hw/virtio/virtio.c +++ b/hw/virtio/virtio.c @@ -390,6 +390,11 @@ void virtio_queue_set_notification(VirtQueue *vq, int enable) rcu_read_unlock(); } +bool virtio_queue_get_notification(VirtQueue *vq) +{ + return vq->notification; +} + int virtio_queue_ready(VirtQueue *vq) { return vq->vring.avail != 0; @@ -2572,17 +2577,12 @@ static bool virtio_queue_host_notifier_aio_poll(void *opaque) { EventNotifier *n = opaque; VirtQueue *vq = container_of(n, VirtQueue, host_notifier); - bool progress; if (!vq->vring.desc || virtio_queue_empty(vq)) { return false; } - progress = virtio_queue_notify_aio_vq(vq); - - /* In case the handler function re-enabled notifications */ - virtio_queue_set_notification(vq, 0); - return progress; + return virtio_queue_notify_aio_vq(vq); } static void virtio_queue_host_notifier_aio_poll_end(EventNotifier *n) diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h index ca2fbaeb35..7394715407 100644 --- a/include/hw/virtio/virtio.h +++ b/include/hw/virtio/virtio.h @@ -229,6 +229,7 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int version_id); void virtio_notify_config(VirtIODevice *vdev); +bool virtio_queue_get_notification(VirtQueue *vq); void virtio_queue_set_notification(VirtQueue *vq, int enable); int virtio_queue_ready(VirtQueue *vq); -- Gitee From 30203c01fa1bb2a7b92575683f85695a2d420b38 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Wed, 18 Dec 2019 11:30:12 +0000 Subject: [PATCH 2/9] usbredir: Prevent recursion in usbredir_write I've got a case where usbredir_write manages to call back into itself via spice; this patch causes the recursion to fail (0 bytes) the write; this seems to avoid the deadlock I was previously seeing. I can't say I fully understand the interaction of usbredir and spice; but there are a few similar guards in spice and usbredir to catch other cases especially onces also related to spice_server_char_device_wakeup This case seems to be triggered by repeated migration+repeated reconnection of the viewer; but my debugging suggests the migration finished before this hits. The backtrace of the hang looks like: reds_handle_ticket reds_handle_other_links reds_channel_do_link red_channel_connect spicevmc_connect usbredir_create_parser usbredirparser_do_write usbredir_write qemu_chr_fe_write qemu_chr_write qemu_chr_write_buffer spice_chr_write spice_server_char_device_wakeup red_char_device_wakeup red_char_device_write_to_device vmc_write usbredirparser_do_write usbredir_write qemu_chr_fe_write qemu_chr_write qemu_chr_write_buffer qemu_mutex_lock_impl and we fail as we lang through qemu_chr_write_buffer's lock twice. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1752320 Signed-off-by: Dr. David Alan Gilbert Message-Id: <20191218113012.13331-1-dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann --- hw/usb/redirect.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c index 9764a57987..3cf82589ed 100644 --- a/hw/usb/redirect.c +++ b/hw/usb/redirect.c @@ -109,6 +109,7 @@ struct USBRedirDevice { /* Properties */ CharBackend cs; bool enable_streams; + bool in_write; uint8_t debug; int32_t bootindex; char *filter_str; @@ -286,6 +287,13 @@ static int usbredir_write(void *priv, uint8_t *data, int count) return 0; } + /* Recursion check */ + if (dev->in_write) { + DPRINTF("usbredir_write recursion\n"); + return 0; + } + dev->in_write = true; + r = qemu_chr_fe_write(&dev->cs, data, count); if (r < count) { if (!dev->watch) { @@ -296,6 +304,7 @@ static int usbredir_write(void *priv, uint8_t *data, int count) r = 0; } } + dev->in_write = false; return r; } -- Gitee From 33d6a2bc0e432a85962b71bcb2c3b5eec39bf436 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Tue, 7 Jan 2020 09:36:06 +0100 Subject: [PATCH 3/9] xhci: recheck slot status MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Factor out slot status check into a helper function. Add an additional check after completing transfers. This is needed in case a guest queues multiple transfers in a row and a device unplug happens while qemu processes them. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1786413 Signed-off-by: Gerd Hoffmann Reviewed-by: Philippe Mathieu-Daudé Message-id: 20200107083606.12393-1-kraxel@redhat.com --- hw/usb/hcd-xhci.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index 24565de1d1..4b42f53b9c 100644 --- a/hw/usb/hcd-xhci.c +++ b/hw/usb/hcd-xhci.c @@ -1860,6 +1860,13 @@ static void xhci_kick_ep(XHCIState *xhci, unsigned int slotid, xhci_kick_epctx(epctx, streamid); } +static bool xhci_slot_ok(XHCIState *xhci, int slotid) +{ + return (xhci->slots[slotid - 1].uport && + xhci->slots[slotid - 1].uport->dev && + xhci->slots[slotid - 1].uport->dev->attached); +} + static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) { XHCIState *xhci = epctx->xhci; @@ -1877,9 +1884,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) /* If the device has been detached, but the guest has not noticed this yet the 2 above checks will succeed, but we must NOT continue */ - if (!xhci->slots[epctx->slotid - 1].uport || - !xhci->slots[epctx->slotid - 1].uport->dev || - !xhci->slots[epctx->slotid - 1].uport->dev->attached) { + if (!xhci_slot_ok(xhci, epctx->slotid)) { return; } @@ -1986,6 +1991,10 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) } else { xhci_fire_transfer(xhci, xfer, epctx); } + if (!xhci_slot_ok(xhci, epctx->slotid)) { + /* surprise removal -> stop processing */ + break; + } if (xfer->complete) { /* update ring dequeue ptr */ xhci_set_ep_state(xhci, epctx, stctx, epctx->state); -- Gitee From 437a9d2c7e48495ffc467808eece045579956c79 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Thu, 16 Jan 2020 20:24:13 +0000 Subject: [PATCH 4/9] vhost: Add names to section rounded warning Add the memory region names to section rounding/alignment warnings. Signed-off-by: Dr. David Alan Gilbert Message-Id: <20200116202414.157959-2-dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/virtio/vhost.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index 9c16f0d107..ae61c33c15 100644 --- a/hw/virtio/vhost.c +++ b/hw/virtio/vhost.c @@ -591,9 +591,10 @@ static void vhost_region_add_section(struct vhost_dev *dev, * match up in the same RAMBlock if they do. */ if (mrs_gpa < prev_gpa_start) { - error_report("%s:Section rounded to %"PRIx64 - " prior to previous %"PRIx64, - __func__, mrs_gpa, prev_gpa_start); + error_report("%s:Section '%s' rounded to %"PRIx64 + " prior to previous '%s' %"PRIx64, + __func__, section->mr->name, mrs_gpa, + prev_sec->mr->name, prev_gpa_start); /* A way to cleanly fail here would be better */ return; } -- Gitee From 6e084ff24ad73eb4f7541573c6097013f5b94959 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Thu, 7 Feb 2019 18:22:40 +0000 Subject: [PATCH 5/9] vhost-user: Print unexpected slave message types MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When we receive an unexpected message type on the slave fd, print the type. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Daniel P. Berrangé Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Dr. David Alan Gilbert --- hw/virtio/vhost-user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 4ca5b2551e..f012774210 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -1054,7 +1054,7 @@ static void slave_read(void *opaque) fd[0]); break; default: - error_report("Received unexpected msg type."); + error_report("Received unexpected msg type: %d.", hdr.request); ret = -EINVAL; } -- Gitee From f076af734a5964c3e48b2d223130f855b86f40e5 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Fri, 1 Mar 2019 11:18:30 +0000 Subject: [PATCH 6/9] contrib/libvhost-user: Protect slave fd with mutex MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In future patches we'll be performing commands on the slave-fd driven by commands on queues, since those queues will be driven by individual threads we need to make sure they don't attempt to use the slave-fd for multiple commands in parallel. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Daniel P. Berrangé Signed-off-by: Dr. David Alan Gilbert --- contrib/libvhost-user/libvhost-user.c | 24 ++++++++++++++++++++---- contrib/libvhost-user/libvhost-user.h | 3 +++ 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/libvhost-user.c index cb5f5770e4..fb75837032 100644 --- a/contrib/libvhost-user/libvhost-user.c +++ b/contrib/libvhost-user/libvhost-user.c @@ -387,26 +387,37 @@ vu_send_reply(VuDev *dev, int conn_fd, VhostUserMsg *vmsg) return vu_message_write(dev, conn_fd, vmsg); } +/* + * Processes a reply on the slave channel. + * Entered with slave_mutex held and releases it before exit. + * Returns true on success. + */ static bool vu_process_message_reply(VuDev *dev, const VhostUserMsg *vmsg) { VhostUserMsg msg_reply; + bool result = false; if ((vmsg->flags & VHOST_USER_NEED_REPLY_MASK) == 0) { - return true; + result = true; + goto out; } if (!vu_message_read(dev, dev->slave_fd, &msg_reply)) { - return false; + goto out; } if (msg_reply.request != vmsg->request) { DPRINT("Received unexpected msg type. Expected %d received %d", vmsg->request, msg_reply.request); - return false; + goto out; } - return msg_reply.payload.u64 == 0; + result = msg_reply.payload.u64 == 0; + +out: + pthread_mutex_unlock(&dev->slave_mutex); + return result; } /* Kick the log_call_fd if required. */ @@ -1102,10 +1113,13 @@ bool vu_set_queue_host_notifier(VuDev *dev, VuVirtq *vq, int fd, return false; } + pthread_mutex_lock(&dev->slave_mutex); if (!vu_message_write(dev, dev->slave_fd, &vmsg)) { + pthread_mutex_unlock(&dev->slave_mutex); return false; } + /* Also unlocks the slave_mutex */ return vu_process_message_reply(dev, &vmsg); } @@ -1625,6 +1639,7 @@ vu_deinit(VuDev *dev) close(dev->slave_fd); dev->slave_fd = -1; } + pthread_mutex_destroy(&dev->slave_mutex); if (dev->sock != -1) { close(dev->sock); @@ -1660,6 +1675,7 @@ vu_init(VuDev *dev, dev->remove_watch = remove_watch; dev->iface = iface; dev->log_call_fd = -1; + pthread_mutex_init(&dev->slave_mutex, NULL); dev->slave_fd = -1; dev->max_queues = max_queues; diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/libvhost-user.h index 46b600799b..1844b6f8d4 100644 --- a/contrib/libvhost-user/libvhost-user.h +++ b/contrib/libvhost-user/libvhost-user.h @@ -19,6 +19,7 @@ #include #include #include +#include #include "standard-headers/linux/virtio_ring.h" /* Based on qemu/hw/virtio/vhost-user.c */ @@ -355,6 +356,8 @@ struct VuDev { VuVirtq *vq; VuDevInflightInfo inflight_info; int log_call_fd; + /* Must be held while using slave_fd */ + pthread_mutex_t slave_mutex; int slave_fd; uint64_t log_size; uint8_t *log_table; -- Gitee From 8fa62daca5978e77ed690797a882c3d0aad8d0d4 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Mon, 12 Aug 2019 17:35:19 +0100 Subject: [PATCH 7/9] libvhost-user: Fix some memtable remap cases If a new setmemtable command comes in once the vhost threads are running, it will remap the guests address space and the threads will now be looking in the wrong place. Fortunately we're running this command under lock, so we can update the queue mappings so that threads will look in the new-right place. Note: This doesn't fix things that the threads might be doing without a lock (e.g. a readv/writev!) That's for another time. Signed-off-by: Dr. David Alan Gilbert --- contrib/libvhost-user/libvhost-user.c | 33 ++++++++++++++++++++------- contrib/libvhost-user/libvhost-user.h | 3 +++ 2 files changed, 28 insertions(+), 8 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/libvhost-user.c index fb75837032..164e6d1df8 100644 --- a/contrib/libvhost-user/libvhost-user.c +++ b/contrib/libvhost-user/libvhost-user.c @@ -559,6 +559,21 @@ vu_reset_device_exec(VuDev *dev, VhostUserMsg *vmsg) return false; } +static bool +map_ring(VuDev *dev, VuVirtq *vq) +{ + vq->vring.desc = qva_to_va(dev, vq->vra.desc_user_addr); + vq->vring.used = qva_to_va(dev, vq->vra.used_user_addr); + vq->vring.avail = qva_to_va(dev, vq->vra.avail_user_addr); + + DPRINT("Setting virtq addresses:\n"); + DPRINT(" vring_desc at %p\n", vq->vring.desc); + DPRINT(" vring_used at %p\n", vq->vring.used); + DPRINT(" vring_avail at %p\n", vq->vring.avail); + + return !(vq->vring.desc && vq->vring.used && vq->vring.avail); +} + static bool vu_set_mem_table_exec_postcopy(VuDev *dev, VhostUserMsg *vmsg) { @@ -762,6 +777,14 @@ vu_set_mem_table_exec(VuDev *dev, VhostUserMsg *vmsg) close(vmsg->fds[i]); } + for (i = 0; i < dev->max_queues; i++) { + if (dev->vq[i].vring.desc) { + if (map_ring(dev, &dev->vq[i])) { + vu_panic(dev, "remaping queue %d during setmemtable", i); + } + } + } + return false; } @@ -848,18 +871,12 @@ vu_set_vring_addr_exec(VuDev *dev, VhostUserMsg *vmsg) DPRINT(" avail_user_addr: 0x%016" PRIx64 "\n", vra->avail_user_addr); DPRINT(" log_guest_addr: 0x%016" PRIx64 "\n", vra->log_guest_addr); + vq->vra = *vra; vq->vring.flags = vra->flags; - vq->vring.desc = qva_to_va(dev, vra->desc_user_addr); - vq->vring.used = qva_to_va(dev, vra->used_user_addr); - vq->vring.avail = qva_to_va(dev, vra->avail_user_addr); vq->vring.log_guest_addr = vra->log_guest_addr; - DPRINT("Setting virtq addresses:\n"); - DPRINT(" vring_desc at %p\n", vq->vring.desc); - DPRINT(" vring_used at %p\n", vq->vring.used); - DPRINT(" vring_avail at %p\n", vq->vring.avail); - if (!(vq->vring.desc && vq->vring.used && vq->vring.avail)) { + if (map_ring(dev, vq)) { vu_panic(dev, "Invalid vring_addr message"); return false; } diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/libvhost-user.h index 1844b6f8d4..5cb7708559 100644 --- a/contrib/libvhost-user/libvhost-user.h +++ b/contrib/libvhost-user/libvhost-user.h @@ -327,6 +327,9 @@ typedef struct VuVirtq { int err_fd; unsigned int enable; bool started; + + /* Guest addresses of our ring */ + struct vhost_vring_addr vra; } VuVirtq; enum VuWatchCondtion { -- Gitee From 5b137b37ef7c4941200798cca99200e80ef17a01 Mon Sep 17 00:00:00 2001 From: Greg Kurz Date: Wed, 4 Dec 2019 20:43:43 +0100 Subject: [PATCH 8/9] xics: Don't deassert outputs The correct way to do this is to deassert the input pins on the CPU side. This is the case since a previous change. Signed-off-by: Greg Kurz Message-Id: <157548862298.3650476.1228720391270249433.stgit@bahia.lan> Signed-off-by: David Gibson --- hw/intc/xics.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/hw/intc/xics.c b/hw/intc/xics.c index faa976e2f8..d2d377fc85 100644 --- a/hw/intc/xics.c +++ b/hw/intc/xics.c @@ -303,9 +303,6 @@ static void icp_reset_handler(void *dev) icp->pending_priority = 0xff; icp->mfrr = 0xff; - /* Make all outputs are deasserted */ - qemu_set_irq(icp->output, 0); - if (kvm_irqchip_in_kernel()) { Error *local_err = NULL; -- Gitee From 6a5e994c1dec959143f6d3f83169a7adcb173fc4 Mon Sep 17 00:00:00 2001 From: Eduardo Habkost Date: Thu, 5 Dec 2019 19:33:39 -0300 Subject: [PATCH 9/9] i386: Resolve CPU models to v1 by default When using `query-cpu-definitions` using `-machine none`, QEMU is resolving all CPU models to their latest versions. The actual CPU model version being used by another machine type (e.g. `pc-q35-4.0`) might be different. In theory, this was OK because the correct CPU model version is returned when using the correct `-machine` argument. Except that in practice, this breaks libvirt expectations: libvirt always use `-machine none` when checking if a CPU model is runnable, because runnability is not expected to be affected when the machine type is changed. For example, when running on a Haswell host without TSX, Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts, `query-cpu-definitions` says Haswell is runnable if using `-machine none`, but Haswell is actually not runnable using any of the `pc-*` machine types (because they resolve Haswell to Haswell-v1). In other words, we're breaking the "runnability guarantee" we promised to not break for a few releases (see qemu-deprecated.texi). To address this issue, change the default CPU model version to v1 on all machine types, so we make `query-cpu-definitions` output when using `-machine none` match the results when using `pc-*`. This will change in the future (the plan is to always return the latest CPU model version if using `-machine none`), but only after giving libvirt the opportunity to adapt. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1779078 Signed-off-by: Eduardo Habkost Message-Id: <20191205223339.764534-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost --- qemu-deprecated.texi | 8 ++++++++ target/i386/cpu.c | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index fff07bb2a3..719ac23d72 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -331,3 +331,11 @@ existing CPU models. Management software that needs runnability guarantees must resolve the CPU model aliases using te ``alias-of'' field returned by the ``query-cpu-definitions'' QMP command. + +While those guarantees are kept, the return value of +``query-cpu-definitions'' will have existing CPU model aliases +point to a version that doesn't break runnability guarantees +(specifically, version 1 of those CPU models). In future QEMU +versions, aliases will point to newer CPU model versions +depending on the machine type, so management software must +resolve CPU model aliases before starting a virtual machine. diff --git a/target/i386/cpu.c b/target/i386/cpu.c index e0f3a2dd99..22e0e89718 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -3933,7 +3933,13 @@ static PropValue tcg_default_props[] = { }; -X86CPUVersion default_cpu_version = CPU_VERSION_LATEST; +/* + * We resolve CPU model aliases using -v1 when using "-machine + * none", but this is just for compatibility while libvirt isn't + * adapted to resolve CPU model versions before creating VMs. + * See "Runnability guarantee of CPU models" at * qemu-deprecated.texi. + */ +X86CPUVersion default_cpu_version = 1; void x86_cpu_set_default_version(X86CPUVersion version) { -- Gitee