Bugfixes for emulated Xen support

Selected bugfixes for mainline and stable, especially to the per-vCPU
 local APIC vector delivery mode for event channel notifications, which
 was broken in a number of ways.
 
 The xen-block driver has been defaulting to the wrong protocol for x86
 guest, and this fixes that — which is technically an incompatible change
 but I'm fairly sure nobody relies on the broken behaviour (and in
 production I *have* seen guests which rely on the correct behaviour,
 which now matches the blkback driver in the Linux kernel).
 
 A handful of other simple fixes for issues which came to light as new
 features (qv) were being developed.
 -----BEGIN PGP SIGNATURE-----
 
 iQJIBAABCAAyFiEEvgfZ/VSAmrLEsP9fY3Ys2mfi81kFAmVIvv4UHGR3bXcyQGlu
 ZnJhZGVhZC5vcmcACgkQY3Ys2mfi81nFmRAAvK3VNuGDV56TJqFdtEWD+3jzSZU0
 CoL1mxggvwnlFn1SdHvbC5jl+UscknErcNbqlxMTTg9jQiiQqzFuaWujJnL0dEOY
 RJiS2scKln/1gv9NRbLE31FjPwoNz+zJI/iMvdutjT7Ll//v34jY0vd1Y5Wo53ay
 MBschuuxD1sUUTHNj5f9afrgZaetJfgBSNZraiLR5T2HEadJVJuhItdGxW1+KaPI
 zBIcflIeZmJl9b/L1a2bP3KJmRo8QzHB56X3uzwkPhYhYSU2dnCaJTLCkiNfK+Qh
 SgCBMlzsvJbIZqDA9YPOGdKK1ArfTJRmRDwAkqH0YQknQGoIkpN+7eQiiSv6PMS5
 U/93V7r6MfaftIs6YdWSnFozWeBuyKZL9H2nAXqZgL5t6uEMVR8Un/kFnGfslTFY
 9gQ1o4IM6ECLiXhIP/sPNOprrbFb0HU7QPtEDJOxrJzBM+IfLbldRHn4p9CccqQA
 LHvJF98VhX1d0nA0iZBT3qqfKPbmUhRV9Jrm+WamqNrRXhiGdF8EidsUf8RWX+JD
 xZWJiqhTwShxdLE6TC/JgFz4cQCVHG8QiZstZUbdq59gtz9YO5PGByMgI3ds7iNQ
 lGXAPFm+1wU85W4dZOH7qyim6d9ytFm2Fm110BKM8l9B6UKEuKHpsxXMqdo65JXI
 7uBKbVpdPKul0DY=
 =dQ7h
 -----END PGP SIGNATURE-----

Merge tag 'pull-xenfv-stable-20231106' of git://git.infradead.org/users/dwmw2/qemu into staging

Bugfixes for emulated Xen support

Selected bugfixes for mainline and stable, especially to the per-vCPU
local APIC vector delivery mode for event channel notifications, which
was broken in a number of ways.

The xen-block driver has been defaulting to the wrong protocol for x86
guest, and this fixes that — which is technically an incompatible change
but I'm fairly sure nobody relies on the broken behaviour (and in
production I *have* seen guests which rely on the correct behaviour,
which now matches the blkback driver in the Linux kernel).

A handful of other simple fixes for issues which came to light as new
features (qv) were being developed.

# -----BEGIN PGP SIGNATURE-----
#
# iQJIBAABCAAyFiEEvgfZ/VSAmrLEsP9fY3Ys2mfi81kFAmVIvv4UHGR3bXcyQGlu
# ZnJhZGVhZC5vcmcACgkQY3Ys2mfi81nFmRAAvK3VNuGDV56TJqFdtEWD+3jzSZU0
# CoL1mxggvwnlFn1SdHvbC5jl+UscknErcNbqlxMTTg9jQiiQqzFuaWujJnL0dEOY
# RJiS2scKln/1gv9NRbLE31FjPwoNz+zJI/iMvdutjT7Ll//v34jY0vd1Y5Wo53ay
# MBschuuxD1sUUTHNj5f9afrgZaetJfgBSNZraiLR5T2HEadJVJuhItdGxW1+KaPI
# zBIcflIeZmJl9b/L1a2bP3KJmRo8QzHB56X3uzwkPhYhYSU2dnCaJTLCkiNfK+Qh
# SgCBMlzsvJbIZqDA9YPOGdKK1ArfTJRmRDwAkqH0YQknQGoIkpN+7eQiiSv6PMS5
# U/93V7r6MfaftIs6YdWSnFozWeBuyKZL9H2nAXqZgL5t6uEMVR8Un/kFnGfslTFY
# 9gQ1o4IM6ECLiXhIP/sPNOprrbFb0HU7QPtEDJOxrJzBM+IfLbldRHn4p9CccqQA
# LHvJF98VhX1d0nA0iZBT3qqfKPbmUhRV9Jrm+WamqNrRXhiGdF8EidsUf8RWX+JD
# xZWJiqhTwShxdLE6TC/JgFz4cQCVHG8QiZstZUbdq59gtz9YO5PGByMgI3ds7iNQ
# lGXAPFm+1wU85W4dZOH7qyim6d9ytFm2Fm110BKM8l9B6UKEuKHpsxXMqdo65JXI
# 7uBKbVpdPKul0DY=
# =dQ7h
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Nov 2023 18:25:02 HKT
# gpg:                using RSA key BE07D9FD54809AB2C4B0FF5F63762CDA67E2F359
# gpg:                issuer "dwmw2@infradead.org"
# gpg: Good signature from "David Woodhouse <dwmw2@infradead.org>" [unknown]
# gpg:                 aka "David Woodhouse <dwmw2@exim.org>" [unknown]
# gpg:                 aka "David Woodhouse <david@woodhou.se>" [unknown]
# gpg:                 aka "David Woodhouse <dwmw2@kernel.org>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: BE07 D9FD 5480 9AB2 C4B0  FF5F 6376 2CDA 67E2 F359

* tag 'pull-xenfv-stable-20231106' of git://git.infradead.org/users/dwmw2/qemu:
  hw/xen: use correct default protocol for xen-block on x86
  hw/xen: take iothread mutex in xen_evtchn_reset_op()
  hw/xen: fix XenStore watch delivery to guest
  hw/xen: don't clear map_track[] in xen_gnttab_reset()
  hw/xen: select kernel mode for per-vCPU event channel upcall vector
  i386/xen: fix per-vCPU upcall vector for Xen emulation
  i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This commit is contained in:
Stefan Hajnoczi 2023-11-07 09:41:24 +08:00
commit 54e97162db
6 changed files with 31 additions and 13 deletions

View file

@ -115,9 +115,13 @@ static void xen_block_connect(XenDevice *xendev, Error **errp)
return;
}
if (xen_device_frontend_scanf(xendev, "protocol", "%ms",
&str) != 1) {
protocol = BLKIF_PROTOCOL_NATIVE;
if (xen_device_frontend_scanf(xendev, "protocol", "%ms", &str) != 1) {
/* x86 defaults to the 32-bit protocol even for 64-bit guests. */
if (object_dynamic_cast(OBJECT(qdev_get_machine()), "x86-machine")) {
protocol = BLKIF_PROTOCOL_X86_32;
} else {
protocol = BLKIF_PROTOCOL_NATIVE;
}
} else {
if (strcmp(str, XEN_IO_PROTO_ABI_X86_32) == 0) {
protocol = BLKIF_PROTOCOL_X86_32;

View file

@ -490,6 +490,12 @@ int xen_evtchn_set_callback_param(uint64_t param)
break;
}
/* If the guest has set a per-vCPU callback vector, prefer that. */
if (gsi && kvm_xen_has_vcpu_callback_vector()) {
in_kernel = kvm_xen_has_cap(EVTCHN_SEND);
gsi = 0;
}
if (!ret) {
/* If vector delivery was turned *off* then tell the kernel */
if ((s->callback_param >> CALLBACK_VIA_TYPE_SHIFT) ==
@ -1129,6 +1135,7 @@ int xen_evtchn_reset_op(struct evtchn_reset *reset)
return -ESRCH;
}
QEMU_IOTHREAD_LOCK_GUARD();
return xen_evtchn_soft_reset();
}

View file

@ -541,7 +541,5 @@ int xen_gnttab_reset(void)
s->entries.v1[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
s->entries.v1[GNTTAB_RESERVED_XENSTORE].frame = XEN_SPECIAL_PFN(XENSTORE);
memset(s->map_track, 0, s->max_frames * ENTRIES_PER_FRAME_V1);
return 0;
}

View file

@ -1357,10 +1357,12 @@ static void fire_watch_cb(void *opaque, const char *path, const char *token)
} else {
deliver_watch(s, path, token);
/*
* If the message was queued because there was already ring activity,
* no need to wake the guest. But if not, we need to send the evtchn.
* Attempt to queue the message into the actual ring, and send
* the event channel notification if any bytes are copied.
*/
xen_be_evtchn_notify(s->eh, s->be_port);
if (s->rsp_pending && put_rsp(s) > 0) {
xen_be_evtchn_notify(s->eh, s->be_port);
}
}
}