[PATCH for-8.3 v2 06/46] hw/xen: use qemu_create_nic_bus_devices() to instantiate Xen NICs

From: David Woodhouse When instantiating XenBus itself, for each NIC which is configured with either the model unspecified, or set to to "xen" or "xen-net-device", create a corresponding xen-net-device for it. Now we can revert the previous more hackish version which relied

[PATCH for-8.3 v2 05/46] hw/i386/pc: use qemu_get_nic_info() and pci_init_nic_devices()

From: David Woodhouse Eliminate direct access to nd_table[] and nb_nics by processing the the Xen and ISA NICs first and then calling pci_init_nic_devices() for the rest. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/pc.c| 26

[PATCH for-8.3 v2 43/46] net: remove qemu_check_nic_model()

From: David Woodhouse Signed-off-by: David Woodhouse --- include/net/net.h | 1 - net/net.c | 13 - 2 files changed, 14 deletions(-) diff --git a/include/net/net.h b/include/net/net.h index ce830a47d0..1512650190 100644 --- a/include/net/net.h +++ b/include/net/net.h

[PATCH for-8.3 v2 21/46] hw/arm/allwinner: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/allwinner-a10.c | 6 +- hw/arm/allwinner-h3.c | 6 +- hw/arm/allwinner-r40.c | 27 ++- 3 files changed, 4 insertions(+), 35 deletions(-) diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner

[PATCH for-8.3 v2 00/46] Rework matching of network devices to -nic options

ics static in net/net.c because nothing else has any business poking at them directly. v2: Some build fixes after better coverage testing, revert the Xen fix in this series because I'm putting the less invasive hack into 8.2 (hopefully). David Woodhouse (46): net: add qemu_{config

[PATCH for-8.3 v2 22/46] hw/arm/aspeed: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/aspeed.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index cc59176563..bed5e4f40b 100644 --- a/hw/arm/aspeed.c +++ b/hw/arm/aspeed.c @@ -356,7 +356,6 @@ static

[PATCH for-8.3 v2 32/46] hw/m68k/mcf5208: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/m68k/mcf5208.c | 20 ++-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c index d22d8536db..c1a5bde571 100644 --- a/hw/m68k/mcf5208.c +++ b/hw/m68k/mcf5208.c

[PATCH for-8.3 v2 45/46] net: remove qemu_show_nic_models(), qemu_find_nic_model()

From: David Woodhouse These old functions can be removed now too. Let net_param_nic() print the full set of network devices directly, and also make it note that a list more specific to this platform/config will be available by using '-nic model=help' instead. Signed-off-by: David Woodhouse

[PATCH for-8.3 v2 09/46] hw/arm/virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 92085d2d8f..61706bfcfc 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -1481,9 +1481,7 @@ static void create_pcie

[PATCH for-8.3 v2 18/46] hw/sh4/r2d: use pci_init_nic_devices()

From: David Woodhouse Previously, the first PCI NIC would be assigned to slot 2 even if the user override the model and made it something other than an rtl8139 which is the default. Everything else would be dynamically assigned. Now, the first rtl8139 gets slot 2 and everything else is dynamic

[PATCH for-8.3 v2 44/46] hw/pci: remove pci_nic_init_nofail()

From: David Woodhouse This function is no longer used. Signed-off-by: David Woodhouse --- hw/pci/pci.c | 72 include/hw/pci/pci.h | 3 -- 2 files changed, 75 deletions(-) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 5703266c0b

[PATCH for-8.3 v2 02/46] net: report list of available models according to platform

From: David Woodhouse By noting the models for which a configuration was requested, we can give the user an accurate list of which NIC models were actually available on the platform/configuration that was otherwise chosen. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- net

[PATCH for-8.3 v2 30/46] hw/arm: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/mps2-tz.c | 8 ++-- hw/arm/msf2-soc.c| 6 +- hw/arm/musicpal.c| 3 +-- hw/arm/xilinx_zynq.c | 11 --- hw/arm/xlnx-versal.c | 7 +-- hw/arm/xlnx-zynqmp.c | 8 +--- 6 files changed, 10

[PATCH for-8.3 v2 25/46] hw/net/smc91c111: use qemu_configure_nic_device()

From: David Woodhouse Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preserve the existing behaviour for now. Signed-off-by: David Woodhouse --- hw/arm/gumstix.c | 6 ++ hw

[PATCH for-8.3 v2 23/46] hw/arm/exynos4: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/exynos4_boards.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/arm/exynos4_boards.c b/hw/arm/exynos4_boards.c index b0e13eb4f0..003992189b 100644 --- a/hw/arm/exynos4_boards.c +++ b/hw/arm

[PATCH for-8.3 v2 35/46] hw/mips/mipssim: use qemu_create_nic_device()

From: David Woodhouse The MIPS SIM platform instantiates its NIC only if a corresponding configuration exists for it. Use qemu_create_nic_device() function for that. Signed-off-by: David Woodhouse --- hw/mips/mipssim.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff

[PATCH for-8.3 v2 33/46] hw/m68k/q800: use qemu_find_nic_info()

From: David Woodhouse If a corresponding NIC configuration was found, it will have a MAC address already assigned, so use that. Else, generate and assign a default one. Using qemu_find_nic_info() is simpler than the alternative of using qemu_configure_nic_device() and then having to fetch

[PATCH for-8.3 v2 26/46] hw/net/lan9118: use qemu_configure_nic_device()

From: David Woodhouse Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preseve the existing behaviour for now. Signed-off-by: David Woodhouse --- hw/arm/kzm.c | 4 ++-- hw/arm

[PATCH for-8.3 v2 27/46] hw/arm/highbank: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/highbank.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c index f12aacea6b..798e5391dc 100644 --- a/hw/arm/highbank.c +++ b/hw/arm/highbank.c @@ -296,19

[PATCH for-8.3 v2 10/46] hw/hppa: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/hppa/machine.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c index 67d4d1b5e0..d7cee6e49e 100644 --- a/hw/hppa/machine.c +++ b/hw/hppa/machine.c @@ -309,7 +309,6

[PATCH for-8.3 v2 17/46] hw/ppc: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/ppc/e500.c | 4 +--- hw/ppc/mac_newworld.c | 4 +--- hw/ppc/mac_oldworld.c | 4 +--- hw/ppc/ppc440_bamboo.c | 14 +- 4 files changed, 8 insertions(+), 18 deletions(-) diff --git a/hw/ppc/e500.c b/hw/ppc/e500

[PATCH for-8.3 v2 29/46] hw/arm/stellaris: use qemu_find_nic_info()

From: David Woodhouse Rather than just using qemu_configure_nic_device(), populate the MAC address in the system-registers device by peeking at the NICInfo before it's assigned to the device. Generate the MAC address early, if there is no matching -nic option. Otherwise the MAC address wouldn't

[PATCH for-8.3 v2 39/46] hw/riscv: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/riscv/microchip_pfsoc.c | 14 ++ hw/riscv/sifive_u.c| 7 +-- 2 files changed, 3 insertions(+), 18 deletions(-) diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index b775aa8946..7725dfbde5

[PATCH for-8.3 v2 12/46] hw/mips/fuloong2e: use pci_init_nic_devices()

From: David Woodhouse The previous behaviour was: *if* the first NIC specified on the command line was an RTL8139 (or unspecified model) then it gets assigned to PCI slot 7, which is where the Fuloong board had an RTL8139. All other devices (including the first, if it was specified a anything

[PATCH for-8.3 v2 16/46] hw/ppc/spapr: use qemu_get_nic_info() and pci_init_nic_devices()

From: David Woodhouse Avoid directly referencing nd_table[] by first instantiating any spapr-vlan devices using a qemu_get_nic_info() loop, then calling pci_init_nic_devices() to do the rest. No functional change intended. Signed-off-by: David Woodhouse --- hw/ppc/spapr.c | 18

[PATCH for-8.3 v2 38/46] hw/openrisc/openrisc_sim: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/openrisc/openrisc_sim.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c index 35da123aef..bffd6f721f 100644 --- a/hw/openrisc

[PATCH for-8.3 v2 15/46] hw/ppc/prep: use pci_init_nic_devices()

From: David Woodhouse Previously, the first PCI NIC would be placed in PCI slot 3 and the rest would be dynamically assigned. Even if the user overrode the default NIC type and made it something other than PCNet. Now, the first PCNet NIC (that is, anything not explicitly specified

[PATCH for-8.3 v2 01/46] net: add qemu_{configure,create}_nic_device(), qemu_find_nic_info()

From: David Woodhouse Most code which directly accesses nd_table[] and nb_nics uses them for one of two things. Either "I have created a NIC device and I'd like a configuration for it", or "I will create a NIC device *if* there is a configuration for it". With some variants

[PATCH for-8.3 v2 03/46] net: add qemu_create_nic_bus_devices()

From: David Woodhouse This will instantiate any NICs which live on a given bus type. Each bus is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for Xen it's xen → xen-net-device; no point in overengineering it unless we actually want more). Signed-off-by: David Woodhouse

[PATCH for-8.3 v2 36/46] hw/mips/jazz: use qemu_find_nic_info()

From: David Woodhouse Extract the MAC address from the NICInfo, or generate one explicitly if there was no corresponding NIC configuration, to put it in the PROM. Signed-off-by: David Woodhouse --- hw/mips/jazz.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff

[PATCH for-8.3 v2 19/46] hw/sparc64/sun4u: use pci_init_nic_devices()

From: David Woodhouse The first sunhme NIC gets placed a function 1 on slot 1 of PCI bus A, and the rest are dynamically assigned on PCI bus B. Previously, any PCI NIC would get the special treatment purely by virtue of being first in the list. Signed-off-by: David Woodhouse --- hw/sparc64

[PATCH for-8.3 v2 24/46] hw/arm/fsl: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/fsl-imx25.c | 2 +- hw/arm/fsl-imx6.c | 2 +- hw/arm/fsl-imx6ul.c | 2 +- hw/arm/fsl-imx7.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/arm/fsl-imx25.c b/hw/arm/fsl-imx25.c index 24c4374590

[PATCH for-8.3 v2 07/46] hw/alpha/dp264: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/alpha/dp264.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c index 03495e1e60..52a1fa310b 100644 --- a/hw/alpha/dp264.c +++ b/hw/alpha/dp264.c @@ -124,9 +124,7 @@ static void

[PATCH for-8.3 v2 34/46] hw/microblaze: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/microblaze/petalogix_ml605_mmu.c | 3 +-- hw/microblaze/petalogix_s3adsp1800_mmu.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c

[PATCH for-8.3 v2 11/46] hw/loongarch: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/loongarch/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 4b7dc67a2d..c48804ac38 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -504,9 +504,7

[PATCH for-8.3 v2 14/46] hw/mips/loongson3_virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/mips/loongson3_virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c index 33eae01eca..caedde2df0 100644 --- a/hw/mips/loongson3_virt.c +++ b/hw/mips

[PATCH for-8.3 v2 20/46] hw/xtensa/virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/xtensa/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c index a6cf646e99..5310a88861 100644 --- a/hw/xtensa/virt.c +++ b/hw/xtensa/virt.c @@ -102,9 +102,7 @@ static void

[PATCH for-8.3 v2 13/46] hw/mips/malta: use pci_init_nic_devices()

From: David Woodhouse The Malta board setup code would previously place the first NIC into PCI slot 11 if was a PCNet card, and the rest (including the first if it was anything other than a PCNet card) would be dynamically assigned. Now it will place any PCNet NIC into slot 11

[PATCH for-8.3 v2 37/46] hw/net/lasi_i82596: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/net/lasi_i82596.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c index e37f7fabe9..c4c197aaa8 100644 --- a/hw/net/lasi_i82596.c +++ b/hw/net/lasi_i82596.c @@ -125,11

[PATCH v4 13/17] hw/i386/pc: support '-nic' for xen-net-device

From: David Woodhouse The default NIC creation seems a bit hackish to me. I don't understand why each platform has to call pci_nic_init_nofail() from a point in the code where it actually has a pointer to the PCI bus, and then we have the special cases for things like ne2k_isa

[PATCH v4 14/17] net: do not delete nics in net_cleanup()

From: David Woodhouse In net_cleanup() we only need to delete the netdevs, as those may have state which outlives Qemu when it exits, and thus may actually need to be cleaned up on exit. The nics, on the other hand, are owned by the device which created them. Most devices don't bother to clean

[PATCH v4 15/17] xen-platform: unplug AHCI disks

From: David Woodhouse To support Xen guests using the Q35 chipset, the unplug protocol needs to also remove AHCI disks. Make pci_xen_ide_unplug() more generic, iterating over the children of the PCI device and destroying the "ide-hd" devices. That works the same for both AHCI and ID

[PATCH v4 16/17] doc/sphinx/hxtool.py: add optional label argument to SRST directive

From: David Woodhouse We can't just embed labels directly into files like qemu-options.hx which are included from multiple top-level RST files, because Sphinx sees the labels as duplicate: https://github.com/sphinx-doc/sphinx/issues/9707 So add an 'emitrefs' option to the Sphinx hxtool-doc

[PATCH v4 11/17] hw/xen: only remove peers of PCI NICs on unplug

From: David Woodhouse When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful also to unplug the peer of the *Xen* PV NIC. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/xen/xen_platform.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions

[PATCH v4 17/17] docs: update Xen-on-KVM documentation

From: David Woodhouse Add notes about console and network support, and how to launch PV guests. Clean up the disk configuration examples now that that's simpler, and remove the comment about IDE unplug on q35/AHCI now that it's fixed. Update the -initrd option documentation to explain how

[PATCH v4 12/17] hw/xen: update Xen PV NIC to XenDevice model

From: David Woodhouse This allows us to use Xen PV networking with emulated Xen guests, and to add them on the command line or hotplug. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/net/meson.build| 2 +- hw/net/trace-events | 11 + hw/net/xen_nic.c

[PATCH v4 09/17] hw/xen: update Xen console to XenDevice model

From: David Woodhouse This allows (non-primary) console devices to be created on the command line and hotplugged. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/char/trace-events| 8 + hw/char/xen_console.c | 532 +++- hw/xen

[PATCH v4 08/17] hw/xen: do not repeatedly try to create a failing backend device

From: David Woodhouse If xen_backend_device_create() fails to instantiate a device, the XenBus code will just keep trying over and over again each time the bus is re-enumerated, as long as the backend appears online and in XenbusStateInitialising. The only thing which prevents the XenBus code

[PATCH v4 07/17] hw/xen: add get_frontend_path() method to XenDeviceClass

From: David Woodhouse The primary Xen console is special. The guest's side is set up for it by the toolstack automatically and not by the standard PV init sequence. Accordingly, its *frontend* doesn't appear in …/device/console/0 either; instead it appears under …/console in the guest's

[PATCH v4 10/17] hw/xen: add support for Xen primary console in emulated mode

From: David Woodhouse The primary console is special because the toolstack maps a page into the guest for its ring, and also allocates the guest-side event channel. The guest's grant table is even primed to export that page using a known grant ref#. Add support for all that in emulated mode, so

[PATCH v4 05/17] hw/xen: populate store frontend nodes with XenStore PFN/port

From: David Woodhouse This is kind of redundant since without being able to get these through some other method (HVMOP_get_param) the guest wouldn't be able to access XenStore in order to find them. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/kvm/xen_xenstore.c | 11

[PATCH v4 00/17] Get Xen PV shim running in QEMU, add net and console

reference the '-initrd' command line option with newer Sphinx. • Improve the duplicate detection for Xen block devices to match all partitions and even the same disk number on different majors. David Woodhouse (17): i386/xen: Ignore VCPU_SSHOTTMR_future flag in set_singleshot_timer() hw

[PATCH v4 06/17] hw/xen: automatically assign device index to block devices

From: David Woodhouse There's no need to force the user to assign a vdev. We can automatically assign one, starting at xvda and searching until we find the first disk name that's unused. This means we can now allow '-drive if=xen,file=xxx' to work without an explicit separate -driver argument

[PATCH v4 02/17] hw/xen: Clean up event channel 'type_val' handling to use union

From: David Woodhouse A previous implementation of this stuff used a 64-bit field for all of the port information (vcpu/type/type_val) and did atomic exchanges on them. When I implemented that in Qemu I regretted my life choices and just kept it simple with locking instead. So there's no need

[PATCH v4 03/17] include: update Xen public headers to Xen 4.17.2 release

From: David Woodhouse ... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature, which will come in a subsequent commit. Signed-off-by: David Woodhouse Acked-by: Paul Durrant --- hw/i386/kvm/xen_xenstore.c| 2 +- include/hw/xen/interface/arch-arm.h | 37

[PATCH v4 01/17] i386/xen: Ignore VCPU_SSHOTTMR_future flag in set_singleshot_timer()

From: David Woodhouse Upstream Xen now ignores this flag¹, since the only guest kernel ever to use it was buggy. ¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909 Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- target/i386/kvm/xen-emu.c | 20

[PATCH v4 04/17] i386/xen: advertise XEN_HVM_CPUID_UPCALL_VECTOR in CPUID

From: David Woodhouse This will allow Linux guests (since v6.0) to use the per-vCPU upcall vector delivered as MSI through the local APIC. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- target/i386/kvm/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target/i386

[PULL 0/7] xenfv-stable queue

being developed. David Woodhouse (7): i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel i386/xen: fix per-vCPU upcall vector for Xen emulation hw/xen: select kernel mode for per-vCPU event channel upcall

[PULL 6/7] hw/xen: take iothread mutex in xen_evtchn_reset_op()

From: David Woodhouse The xen_evtchn_soft_reset() function requires the iothread mutex, but is also called for the EVTCHNOP_reset hypercall. Ensure the mutex is taken in that case. Cc: qemu-sta...@nongnu.org Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset") Signed-off-by: David

[PULL 2/7] i386/xen: fix per-vCPU upcall vector for Xen emulation

From: David Woodhouse The per-vCPU upcall vector support had three problems. Firstly it was using the wrong hypercall argument and would always return -EFAULT when the guest tried to set it up. Secondly it was using the wrong ioctl() to pass the vector to the kernel and thus the *kernel* would

[PULL 1/7] i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel

From: David Woodhouse This confuses lscpu into thinking it's running in PVH mode. Cc: qemu-sta...@nongnu.org Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version") Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- target/i386/kvm/xen-emu.c | 1 - 1 file

[PULL 3/7] hw/xen: select kernel mode for per-vCPU event channel upcall vector

From: David Woodhouse A guest which has configured the per-vCPU upcall vector may set the HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero. For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector") will just do

[PULL 4/7] hw/xen: don't clear map_track[] in xen_gnttab_reset()

From: David Woodhouse The refcounts actually correspond to 'active_ref' structures stored in a GHashTable per "user" on the backend side (mostly, per XenDevice). If we zero map_track[] on reset, then when the backend drivers get torn down and release their mapping we hit the assert(s-

[PULL 5/7] hw/xen: fix XenStore watch delivery to guest

From: David Woodhouse When fire_watch_cb() found the response buffer empty, it would call deliver_watch() to generate the XS_WATCH_EVENT message in the response buffer and send an event channel notification to the guest… without actually *copying* the response buffer into the ring. So

[PULL 7/7] hw/xen: use correct default protocol for xen-block on x86

From: David Woodhouse Even on x86_64 the default protocol is the x86-32 one if the guest doesn't specifically ask for x86-64. Cc: qemu-sta...@nongnu.org Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and disconnect functions...") Signed-off-by: David Woodhouse

Re: Lockdep show 6.6-rc regression in Xen HVM CPU hotplug

On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote: > On 24.10.23 12:41, Juergen Gross wrote: > > On 24.10.23 09:43, David Woodhouse wrote: > > > On Tue, 2023-10-24 at 08:53 +0200, Juergen Gross wrote: > > > > > > > > I'm puzzled. This path doesn

Re: Lockdep show 6.6-rc regression in Xen HVM CPU hotplug

On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote: > On 24.10.23 15:45, David Woodhouse wrote: > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote: > > > > > > > I can probably change xen_send_IPI_one() to not need > > > > irq_get_chip_

[PATCH] acpi_idle: use raw_safe_halt() from acpi_idle_play_dead()

From: David Woodhouse Xen HVM guests were observed taking triple-faults when attempting to online a previously offlined vCPU. Investigation showed that the fault was coming from a failing call to lockdep_assert_irqs_disabled(), in load_current_idt() which was too early in the CPU bringup

Re: [PATCH v3 13/28] hw/xen: automatically assign device index to block devices

On Fri, 2023-10-27 at 11:32 +0100, Durrant, Paul wrote: > On 27/10/2023 11:25, David Woodhouse wrote: > > On Fri, 2023-10-27 at 10:01 +0100, Durrant, Paul wrote: > > > > > > This code is allocating a name automatically so I think the onus is on > > > it not cre

Re: [PATCH v3 13/28] hw/xen: automatically assign device index to block devices

On Fri, 2023-10-27 at 10:01 +0100, Durrant, Paul wrote: > > This code is allocating a name automatically so I think the onus is on > it not create a needless clash which is likely to have unpredictable > results depending on what the guest is. Just avoid any aliasing in the > first place and

Re: [PATCH v3 13/28] hw/xen: automatically assign device index to block devices

On Fri, 2023-10-27 at 08:30 +0100, Durrant, Paul wrote: > > > +    if (blockdev->props.vdev.type == XEN_BLOCK_VDEV_TYPE_INVALID) { > > +    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev))); > > +    char fe_path[XENSTORE_ABS_PATH_MAX + 1]; > > +    char *value; > > +  

Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation

On Thu, 2023-10-26 at 10:25 +0100, David Woodhouse wrote: > > > So it would have been entirely possible to use -initrd 'bzImage > > console=hvc0 root=/dev/xvda1' if Xen worked like that. > > Xen does allow that too. I didn't realise our multiboot loader did though. >

Re: [QEMU][PATCHv2 1/8] xen: when unplugging emulated devices skip virtio devices

On Wed, 2023-10-25 at 18:23 -0700, Stefano Stabellini wrote: > On Thu, 26 Oct 2023, David Woodhouse wrote: > > On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote: > > > From: Juergen Gross > > > > > > Virtio devices should never be unplugged at boot ti

Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation

On Thu, 2023-10-26 at 10:26 +0200, Kevin Wolf wrote: > > > > > > +.. parsed-literal:: > > > > > + > > > > > +  |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split > > > > > \\ > > > > > +   -chardev stdio,id=char0 -device xen-console,chardev=char0 \\ > > > > > +   -display

Re: [QEMU][PATCHv2 1/8] xen: when unplugging emulated devices skip virtio devices

On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote: > From: Juergen Gross > > Virtio devices should never be unplugged at boot time, as they are > similar to pci passthrough devices. > > Signed-off-by: Juergen Gross > Signed-off-by: Vikram Garhwal Hm, do your virtio NICs still actually

Re: Lockdep show 6.6-rc regression in Xen HVM CPU hotplug

On Wed, 2023-10-25 at 17:10 +0100, David Woodhouse wrote: > On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote: > > On 24.10.23 15:45, David Woodhouse wrote: > > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote: > > > > > > > > > I can p

Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation

On Wed, 2023-10-25 at 19:56 +0100, Andrew Cooper wrote: > On 25/10/2023 7:26 pm, David Woodhouse wrote: >   > > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote: > >   > > > On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote: > >   > > >

Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation

On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote: > On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote: > > From: David Woodhouse > > > > Add notes about console and network support, and how to launch PV guests. > > Clean up the disk configuration examp

Re: Lockdep show 6.6-rc regression in Xen HVM CPU hotplug

On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote: > On 24.10.23 15:45, David Woodhouse wrote: > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote: > > > > > > > I can probably change xen_send_IPI_one() to not need > > > > irq_get_chip_

Re: [PATCH 38/45] hw/riscv: use qemu_configure_nic_device()

On Wed, 2023-10-25 at 12:42 -0300, Daniel Henrique Barboza wrote: > > I believe you forgot to remove the 'nd' variable. Building with this patch > (applying > patches 1 to 4 first) fails with: > > > ../hw/riscv/microchip_pfsoc.c: In function ‘microchip_pfsoc_soc_realize’: >

[PATCH v3 03/28] hw/xen: select kernel mode for per-vCPU event channel upcall vector

From: David Woodhouse A guest which has configured the per-vCPU upcall vector may set the HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero. For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector") will just do

[PATCH v3 05/28] hw/xen: fix XenStore watch delivery to guest

From: David Woodhouse When fire_watch_cb() found the response buffer empty, it would call deliver_watch() to generate the XS_WATCH_EVENT message in the response buffer and send an event channel notification to the guest… without actually *copying* the response buffer into the ring. So

[PATCH v3 11/28] i386/xen: advertise XEN_HVM_CPUID_UPCALL_VECTOR in CPUID

From: David Woodhouse This will allow Linux guests (since v6.0) to use the per-vCPU upcall vector delivered as MSI through the local APIC. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- target/i386/kvm/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target/i386

[PATCH v3 13/28] hw/xen: automatically assign device index to block devices

From: David Woodhouse There's no need to force the user to assign a vdev. We can automatically assign one, starting at xvda and searching until we find the first disk name that's unused. This means we can now allow '-drive if=xen,file=xxx' to work without an explicit separate -driver argument

[PATCH v3 24/28] net: add qemu_create_nic_bus_devices()

From: David Woodhouse This will instantiate any NICs which live on a given bus type. Each bus is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for Xen it's xen → xen-net-device; no point in overengineering it unless we actually want more). Signed-off-by: David Woodhouse

[PATCH v3 27/28] hw/xen: use qemu_create_nic_bus_devices() to instantiate Xen NICs

From: David Woodhouse When instantiating XenBus itself, for each NIC which is configured with either the model unspecified, or set to to "xen" or "xen-net-device", create a corresponding xen-net-device for it. Now we can launch emulated Xen guests with '-nic user', and

[PATCH v3 25/28] hw/pci: add pci_init_nic_devices(), pci_init_nic_in_slot()

From: David Woodhouse The loop over nd_table[] to add PCI NICs is repeated in quite a few places. Add a helper function to do it. Some platforms also try to instantiate a specific model in a specific slot, to match the real hardware. Add pci_init_nic_in_slot() for that purpose. Signed-off

[PATCH v3 15/28] hw/xen: do not repeatedly try to create a failing backend device

From: David Woodhouse If xen_backend_device_create() fails to instantiate a device, the XenBus code will just keep trying over and over again each time the bus is re-enumerated, as long as the backend appears online and in XenbusStateInitialising. The only thing which prevents the XenBus code

[PATCH v3 19/28] hw/xen: update Xen PV NIC to XenDevice model

From: David Woodhouse This allows us to use Xen PV networking with emulated Xen guests, and to add them on the command line or hotplug. Signed-off-by: David Woodhouse --- hw/net/meson.build| 2 +- hw/net/trace-events | 11 + hw/net/xen_nic.c | 484

[PATCH v3 08/28] i386/xen: Ignore VCPU_SSHOTTMR_future flag in set_singleshot_timer()

From: David Woodhouse Upstream Xen now ignores this flag¹, since the only guest kernel ever to use it was buggy. ¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909 Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- target/i386/kvm/xen-emu.c | 20

[PATCH v3 22/28] net: add qemu_{configure,create}_nic_device(), qemu_find_nic_info()

From: David Woodhouse Most code which directly accesses nd_table[] and nb_nics uses them for one of two things. Either "I have created a NIC device and I'd like a configuration for it", or "I will create a NIC device *if* there is a configuration for it". With some variants

[PATCH v3 20/28] net: do not delete nics in net_cleanup()

From: David Woodhouse In net_cleanup() we only need to delete the netdevs, as those may have state which outlives Qemu when it exits, and thus may actually need to be cleaned up on exit. The nics, on the other hand, are owned by the device which created them. Most devices don't bother to clean

[PATCH v3 16/28] hw/xen: update Xen console to XenDevice model

From: David Woodhouse This allows (non-primary) console devices to be created on the command line and hotplugged. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/char/trace-events| 8 + hw/char/xen_console.c | 532 +++- hw/xen

[PATCH v3 09/28] hw/xen: Clean up event channel 'type_val' handling to use union

From: David Woodhouse A previous implementation of this stuff used a 64-bit field for all of the port information (vcpu/type/type_val) and did atomic exchanges on them. When I implemented that in Qemu I regretted my life choices and just kept it simple with locking instead. So there's no need

[PATCH v3 02/28] i386/xen: fix per-vCPU upcall vector for Xen emulation

From: David Woodhouse The per-vCPU upcall vector support had three problems. Firstly it was using the wrong hypercall argument and would always return -EFAULT when the guest tried to set it up. Secondly it was using the wrong ioctl() to pass the vector to the kernel and thus the *kernel* would

[PATCH v3 18/28] hw/xen: only remove peers of PCI NICs on unplug

From: David Woodhouse When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful also to unplug the peer of the *Xen* PV NIC. Signed-off-by: David Woodhouse --- hw/i386/xen/xen_platform.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/hw/i386/xen

[PATCH v3 04/28] hw/xen: don't clear map_track[] in xen_gnttab_reset()

From: David Woodhouse The refcounts actually correspond to 'active_ref' structures stored in a GHashTable per "user" on the backend side (mostly, per XenDevice). If we zero map_track[] on reset, then when the backend drivers get torn down and release their mapping we hit the assert(s-

[PATCH v3 10/28] include: update Xen public headers to Xen 4.17.2 release

From: David Woodhouse ... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature, which will come in a subsequent commit. Signed-off-by: David Woodhouse Acked-by: Paul Durrant --- hw/i386/kvm/xen_xenstore.c| 2 +- include/hw/xen/interface/arch-arm.h | 37

[PATCH v3 12/28] hw/xen: populate store frontend nodes with XenStore PFN/port

From: David Woodhouse This is kind of redundant since without being able to get these through some other method (HVMOP_get_param) the guest wouldn't be able to access XenStore in order to find them. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/kvm/xen_xenstore.c | 11

[PATCH v3 00/28] Get Xen PV shim running in QEMU, add net & console

led in just the basic part that's needed for Xen support, and the remaining bombing run on all the platforms can wait; I won't spam the list with the rest of that again just yet. David Woodhouse (28): i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel i386/xen: fix per-vCPU upcall vecto

<    1   2   3   4   5   6   7   8   9   >