Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

[Gerd Hoffmann]

On Tue, Mar 26, 2024 at 01:30:48PM +, Mark Cave-Ayland wrote:
> Heh I've actually been using isapc over the past couple of weeks to fire up
> some old programs in a Windows 3 VM :)

I'm wondering why these use cases can't simply use the 'pc' machine
type?

The early pci chipsets of the 90-ies have been designed in a
backward-compatible manner, with devices such as the IDE controller
being mapped to the standard ISA ioports.  So even an historic OS which
does not know what PCI is can run on that hardware, by simply talking to
devices using the standard ISA io ports ...

take care,
  Gerd

RE: Questions about CXL device (type 3 memory) hotplug

[Yuquan Wang]

On Mon, May 22, 2023 at 05:11:39PM -0700, Dan Williams wrote:
> Yasunori Gotou (Fujitsu) wrote:
[...]

Hi, all

There was some confusions about CXL device hotplug when I recently
tried to use Qemu to emulate CXL device hotplug and verify the relevant
functions of kernel.

> > Q1) Can PCIe hotplug driver detect and call CXL driver?

[...]

> 
> Yes.
> 
> The cxl_pci driver (drivers/cxl/pci.c) is just a typical PCI driver as
> far as the PCI hotplug driver is concerned. So add/remove events of a
> CXL card get turned into probe()/remove() events on the driver.
> 

1. Can we divide steps of CXL device hotplug into two parts(PCI hotplug & 
Memory Hotplug)?

PCI Hotplug: the same as the native PCIe hotplug, including initializing cxl.io,
 assigning PCIe BARs, allocating interrupts, etc. And the cxl_pci 
driver
 is responsible for this part.

Memory Hotplug: focusing on enabling CXL memory including discovering and 
Configuring HDM,
extracting NUMA info from device, notifying memory management, 
etc.

> > 
> > Q2) Can QEMU/KVM emulate CXL device hotplug?
> > 
> >I heard that QEMU/KVM has PCIe device hotplug emulation, but I'm not sure
> >it can hotplug CXL device.
> 
> It can, but as far as the driver is concerned you can achieve the same
> by:
> 
> echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind
> 
> ...that exercises the same software flows as physical unplug.
>

2. What is the difference between "echo $devname > 
/sys/bus/pci/drivers/cxl_pci/unbind" and
"(qemu) device_del cxl-mem0" ?

According to the test, I found that "(qemu) device_del cxl-mem0" would directly
unplug the device and cause the interrupts on the cxl root port. It seems like 
this
operation would not only trigger cxl_pci driver but also pcieport driver.

The kernel dmesg is like below:

(qemu) device_del cxl-mem0
# dmesg
[  699.057907] pcieport :0c:00.0: pciehp: pending interrupts 0x0001 from 
Slot Status
[  699.058929] pcieport :0c:00.0: pciehp: Slot(0): Button press: will power 
off in 5 sec
[  699.059986] pcieport :0c:00.0: pciehp: pending interrupts 0x0010 from 
Slot Status
[  699.060099] pcieport :0c:00.0: pciehp: pciehp_set_indicators: SLOTCTRL 
90 write cmd 2c0

Then I also tried "echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind"
to check the behaviour of kernel. The kernel dmesg is like below:

# echo :0d:00.0 > /sys/bus/pci/drivers/cxl_pci/unbind
# dmesg
[70387.978931] cxl_pci :0d:00.0: vgaarb: pci_notify
[70388.021476] cxl_mem mem0: disconnect mem0 from port1
[70388.033099] pci :0d:00.0: vgaarb: pci_notify

It seems like this operation would just unbind the cxl_pci driver from the cxl 
device.

Is my understanding about these two method correct?

3) Can I just use "ndctl/test/cxl-topology.sh" to test the cxl hotplug 
functions of kernel?

   IIUC, cxl-topology.sh would utilize cxl_test (tools/testing/cxl) which is 
for regression
   testing the kernel-user ABI.

PS: My qemu command line:
qemu-system-x86_64 \
-M q35,nvdimm=on,cxl=on \
-m 4G \
-smp 4 \
-object memory-backend-ram,size=2G,id=mem0 \
-numa node,nodeid=0,cpus=0-1,memdev=mem0 \
-object memory-backend-ram,size=2G,id=mem1 \
-numa node,nodeid=1,cpus=2-3,memdev=mem1 \
-object memory-backend-ram,size=256M,id=cxl-mem0 \
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
-device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \
-device cxl-type3,bus=root_port0,volatile-memdev=cxl-mem0,id=cxl-mem0 \
-M 
cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k 
\
-hda ../disk/ubuntu_x86_test_new.qcow2 \
-nographic \

Qemu version: 8.2.50, the lastest commit of branch cxl-2024-03-05 in 
"https://gitlab.com/jic23/qemu";
Kernel version: 6.8.0-rc6

Many thanks
Yuquan

[PATCH v6 0/2] Improved Memory Tier Creation for CPUless NUMA Nodes

[Ho-Ren (Jack) Chuang]

When a memory device, such as CXL1.1 type3 memory, is emulated as
normal memory (E820_TYPE_RAM), the memory device is indistinguishable
from normal DRAM in terms of memory tiering with the current implementation.
The current memory tiering assigns all detected normal memory nodes
to the same DRAM tier. This results in normal memory devices with
different attributions being unable to be assigned to the correct memory tier,
leading to the inability to migrate pages between different types of memory.
https://lore.kernel.org/linux-mm/ph0pr08mb7955e9f08ccb64f23963b5c3a8...@ph0pr08mb7955.namprd08.prod.outlook.com/T/

This patchset automatically resolves the issues. It delays the initialization
of memory tiers for CPUless NUMA nodes until they obtain HMAT information
and after all devices are initialized at boot time, eliminating the need
for user intervention. If no HMAT is specified, it falls back to
using `default_dram_type`.

Example usecase:
We have CXL memory on the host, and we create VMs with a new system memory
device backed by host CXL memory. We inject CXL memory performance attributes
through QEMU, and the guest now sees memory nodes with performance attributes
in HMAT. With this change, we enable the guest kernel to construct
the correct memory tiering for the memory nodes.

-v6:
 Thanks to Ying's comments,
 * Move `default_dram_perf_lock` to the function's beginning for clarity
 * Fix double unlocking at v5
-v5:
 Thanks to Ying's comments,
 * Add comments about what is protected by `default_dram_perf_lock`
 * Fix an uninitialized pointer mtype
 * Slightly shorten the time holding `default_dram_perf_lock`
 * Fix a deadlock bug in `mt_perf_to_adistance`
 * 
https://lore.kernel.org/lkml/20240327041646.3258110-1-horenchu...@bytedance.com/T/#u
-v4:
 Thanks to Ying's comments,
 * Remove redundant code
 * Reorganize patches accordingly
 * 
https://lore.kernel.org/lkml/20240322070356.315922-1-horenchu...@bytedance.com/T/#u
-v3:
 Thanks to Ying's comments,
 * Make the newly added code independent of HMAT
 * Upgrade set_node_memory_tier to support more cases
 * Put all non-driver-initialized memory types into default_memory_types
   instead of using hmat_memory_types
 * find_alloc_memory_type -> mt_find_alloc_memory_type
 * 
https://lore.kernel.org/lkml/20240320061041.3246828-1-horenchu...@bytedance.com/T/#u
-v2:
 Thanks to Ying's comments,
 * Rewrite cover letter & patch description
 * Rename functions, don't use _hmat
 * Abstract common functions into find_alloc_memory_type()
 * Use the expected way to use set_node_memory_tier instead of modifying it
 * 
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
 * 
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u

Ho-Ren (Jack) Chuang (2):
  memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and putting memory types
  memory tier: create CPUless memory tiers after obtaining HMAT info

 drivers/dax/kmem.c   |  20 +-
 include/linux/memory-tiers.h |  13 
 mm/memory-tiers.c| 126 ++-
 3 files changed, 125 insertions(+), 34 deletions(-)

-- 
Ho-Ren (Jack) Chuang

[PATCH v6 1/2] memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types

[Ho-Ren (Jack) Chuang]

Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.

Signed-off-by: Ho-Ren (Jack) Chuang 
---
 drivers/dax/kmem.c   | 20 ++--
 include/linux/memory-tiers.h | 13 +
 mm/memory-tiers.c| 32 
 3 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 42ee360cf4e3..01399e5b53b2 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -55,21 +55,10 @@ static LIST_HEAD(kmem_memory_types);
 
 static struct memory_dev_type *kmem_find_alloc_memory_type(int adist)
 {
-   bool found = false;
struct memory_dev_type *mtype;
 
mutex_lock(&kmem_memory_type_lock);
-   list_for_each_entry(mtype, &kmem_memory_types, list) {
-   if (mtype->adistance == adist) {
-   found = true;
-   break;
-   }
-   }
-   if (!found) {
-   mtype = alloc_memory_type(adist);
-   if (!IS_ERR(mtype))
-   list_add(&mtype->list, &kmem_memory_types);
-   }
+   mtype = mt_find_alloc_memory_type(adist, &kmem_memory_types);
mutex_unlock(&kmem_memory_type_lock);
 
return mtype;
@@ -77,13 +66,8 @@ static struct memory_dev_type 
*kmem_find_alloc_memory_type(int adist)
 
 static void kmem_put_memory_types(void)
 {
-   struct memory_dev_type *mtype, *mtn;
-
mutex_lock(&kmem_memory_type_lock);
-   list_for_each_entry_safe(mtype, mtn, &kmem_memory_types, list) {
-   list_del(&mtype->list);
-   put_memory_type(mtype);
-   }
+   mt_put_memory_types(&kmem_memory_types);
mutex_unlock(&kmem_memory_type_lock);
 }
 
diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
index 69e781900082..a44c03c2ba3a 100644
--- a/include/linux/memory-tiers.h
+++ b/include/linux/memory-tiers.h
@@ -48,6 +48,9 @@ int mt_calc_adistance(int node, int *adist);
 int mt_set_default_dram_perf(int nid, struct access_coordinate *perf,
 const char *source);
 int mt_perf_to_adistance(struct access_coordinate *perf, int *adist);
+struct memory_dev_type *mt_find_alloc_memory_type(int adist,
+   struct list_head 
*memory_types);
+void mt_put_memory_types(struct list_head *memory_types);
 #ifdef CONFIG_MIGRATION
 int next_demotion_node(int node);
 void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets);
@@ -136,5 +139,15 @@ static inline int mt_perf_to_adistance(struct 
access_coordinate *perf, int *adis
 {
return -EIO;
 }
+
+struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct list_head 
*memory_types)
+{
+   return NULL;
+}
+
+void mt_put_memory_types(struct list_head *memory_types)
+{
+
+}
 #endif /* CONFIG_NUMA */
 #endif  /* _LINUX_MEMORY_TIERS_H */
diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
index 0537664620e5..974af10cfdd8 100644
--- a/mm/memory-tiers.c
+++ b/mm/memory-tiers.c
@@ -623,6 +623,38 @@ void clear_node_memory_type(int node, struct 
memory_dev_type *memtype)
 }
 EXPORT_SYMBOL_GPL(clear_node_memory_type);
 
+struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct list_head 
*memory_types)
+{
+   bool found = false;
+   struct memory_dev_type *mtype;
+
+   list_for_each_entry(mtype, memory_types, list) {
+   if (mtype->adistance == adist) {
+   found = true;
+   break;
+   }
+   }
+   if (!found) {
+   mtype = alloc_memory_type(adist);
+   if (!IS_ERR(mtype))
+   list_add(&mtype->list, memory_types);
+   }
+
+   return mtype;
+}
+EXPORT_SYMBOL_GPL(mt_find_alloc_memory_type);
+
+void mt_put_memory_types(struct list_head *memory_types)
+{
+   struct memory_dev_type *mtype, *mtn;
+
+   list_for_each_entry_safe(mtype, mtn, memory_types, list) {
+   list_del(&mtype->list);
+   put_memory_type(mtype);
+   }
+}
+EXPORT_SYMBOL_GPL(mt_put_memory_types);
+
 static void dump_hmem_attrs(struct access_coordinate *coord, const char 
*prefix)
 {
pr_info(
-- 
Ho-Ren (Jack) Chuang

[PATCH v6 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info

[Ho-Ren (Jack) Chuang]

The current implementation treats emulated memory devices, such as
CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
(E820_TYPE_RAM). However, these emulated devices have different
characteristics than traditional DRAM, making it important to
distinguish them. Thus, we modify the tiered memory initialization process
to introduce a delay specifically for CPUless NUMA nodes. This delay
ensures that the memory tier initialization for these nodes is deferred
until HMAT information is obtained during the boot process. Finally,
demotion tables are recalculated at the end.

* late_initcall(memory_tier_late_init);
Some device drivers may have initialized memory tiers between
`memory_tier_init()` and `memory_tier_late_init()`, potentially bringing
online memory nodes and configuring memory tiers. They should be excluded
in the late init.

* Handle cases where there is no HMAT when creating memory tiers
There is a scenario where a CPUless node does not provide HMAT information.
If no HMAT is specified, it falls back to using the default DRAM tier.

* Introduce another new lock `default_dram_perf_lock` for adist calculation
In the current implementation, iterating through CPUlist nodes requires
holding the `memory_tier_lock`. However, `mt_calc_adistance()` will end up
trying to acquire the same lock, leading to a potential deadlock.
Therefore, we propose introducing a standalone `default_dram_perf_lock` to
protect `default_dram_perf_*`. This approach not only avoids deadlock
but also prevents holding a large lock simultaneously.

* Upgrade `set_node_memory_tier` to support additional cases, including
  default DRAM, late CPUless, and hot-plugged initializations.
To cover hot-plugged memory nodes, `mt_calc_adistance()` and
`mt_find_alloc_memory_type()` are moved into `set_node_memory_tier()` to
handle cases where memtype is not initialized and where HMAT information is
available.

* Introduce `default_memory_types` for those memory types that are not
  initialized by device drivers.
Because late initialized memory and default DRAM memory need to be managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.

Signed-off-by: Ho-Ren (Jack) Chuang 
Signed-off-by: Hao Xiang 
---
 mm/memory-tiers.c | 94 +++
 1 file changed, 78 insertions(+), 16 deletions(-)

diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
index 974af10cfdd8..e24fc3bebae4 100644
--- a/mm/memory-tiers.c
+++ b/mm/memory-tiers.c
@@ -36,6 +36,11 @@ struct node_memory_type_map {
 
 static DEFINE_MUTEX(memory_tier_lock);
 static LIST_HEAD(memory_tiers);
+/*
+ * The list is used to store all memory types that are not created
+ * by a device driver.
+ */
+static LIST_HEAD(default_memory_types);
 static struct node_memory_type_map node_memory_types[MAX_NUMNODES];
 struct memory_dev_type *default_dram_type;
 
@@ -108,6 +113,8 @@ static struct demotion_nodes *node_demotion __read_mostly;
 
 static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
 
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
 static bool default_dram_perf_error;
 static struct access_coordinate default_dram_perf;
 static int default_dram_perf_ref_nid = NUMA_NO_NODE;
@@ -505,7 +512,8 @@ static inline void __init_node_memory_type(int node, struct 
memory_dev_type *mem
 static struct memory_tier *set_node_memory_tier(int node)
 {
struct memory_tier *memtier;
-   struct memory_dev_type *memtype;
+   struct memory_dev_type *mtype = default_dram_type;
+   int adist = MEMTIER_ADISTANCE_DRAM;
pg_data_t *pgdat = NODE_DATA(node);
 
 
@@ -514,11 +522,20 @@ static struct memory_tier *set_node_memory_tier(int node)
if (!node_state(node, N_MEMORY))
return ERR_PTR(-EINVAL);
 
-   __init_node_memory_type(node, default_dram_type);
+   mt_calc_adistance(node, &adist);
+   if (node_memory_types[node].memtype == NULL) {
+   mtype = mt_find_alloc_memory_type(adist, &default_memory_types);
+   if (IS_ERR(mtype)) {
+   mtype = default_dram_type;
+   pr_info("Failed to allocate a memory type. Fall 
back.\n");
+   }
+   }
+
+   __init_node_memory_type(node, mtype);
 
-   memtype = node_memory_types[node].memtype;
-   node_set(node, memtype->nodes);
-   memtier = find_create_memory_tier(memtype);
+   mtype = node_memory_types[node].memtype;
+   node_set(node, mtype->nodes);
+   memtier = find_create_memory_tier(mtype);
if (!IS_ERR(memtier))
rcu_assign_pointer(pgdat->memtier, memtier);
return memtier;
@@ -655,6 +672,34 @@ void mt_put_memory_types(struct list_head *memory_types)
 }
 EXPORT_SYMBOL_GPL(mt_put_memory_types);
 
+/*
+ * This is invoked via `late_initcall()` to initialize memory tiers for
+ * CPU-less memo

Re: [PATCH for-9.0] tcg/optimize: Fix sign_mask for logical right-shift

[Philippe Mathieu-Daudé]

On 26/3/24 23:22, Richard Henderson wrote:

The 'sign' computation is attempting to locate the sign bit that has
been repeated, so that we can test if that bit is known zero.  That
computation can be zero if there are no known sign repetitions.

Cc: qemu-sta...@nongnu.org
Fixes: 93a967fbb57 ("tcg/optimize: Propagate sign info for shifting")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2248
Signed-off-by: Richard Henderson 
---
  tcg/optimize.c|  2 +-
  tests/tcg/aarch64/test-2248.c | 25 +
  tests/tcg/aarch64/Makefile.target |  1 +
  3 files changed, 27 insertions(+), 1 deletion(-)
  create mode 100644 tests/tcg/aarch64/test-2248.c




diff --git a/tests/tcg/aarch64/test-2248.c b/tests/tcg/aarch64/test-2248.c
new file mode 100644
index 00..6cc20e3c6c
--- /dev/null
+++ b/tests/tcg/aarch64/test-2248.c
@@ -0,0 +1,25 @@


  /* SPDX-License-Identifier: GPL-2.0-or-later */

  /* See https://gitlab.com/qemu-project/qemu/-/issues/2248 */


+#include 
+
+__attribute__((noinline))
+long test(long x, long y, long sh)
+{
+long r;
+asm("cmp   %1, %2\n\t"
+"cset  x12, lt\n\t"
+"and   w11, w12, #0xff\n\t"
+"cmp   w11, #0\n\t"
+"csetm x14, ne\n\t"
+"lsr   x13, x14, %3\n\t"
+"sxtb  %0, w13"
+: "=r"(r)
+: "r"(x), "r"(y), "r"(sh)
+: "x11", "x12", "x13", "x14");
+return r;
+}
+
+int main()
+{
+long r = test(0, 1, 2);
+assert(r == -1);
+return 0;
+}


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH for-9.1 v5 1/3] hw: Add compat machines for 9.1

[Zhao Liu]

On Mon, Mar 25, 2024 at 03:14:20PM +0100, Paolo Bonzini wrote:
> Date: Mon, 25 Mar 2024 15:14:20 +0100
> From: Paolo Bonzini 
> Subject: [PATCH for-9.1 v5 1/3] hw: Add compat machines for 9.1
> X-Mailer: git-send-email 2.44.0
> 
> Add 9.1 machine types for arm/i440fx/m68k/q35/s390x/spapr.
> 
> Cc: Cornelia Huck 
> Cc: Thomas Huth 
> Cc: Harsh Prateek Bora 
> Cc: Gavin Shan 
> Signed-off-by: Paolo Bonzini 
> ---
>  include/hw/boards.h|  3 +++
>  include/hw/i386/pc.h   |  3 +++
>  hw/arm/virt.c  | 11 +--
>  hw/core/machine.c  |  3 +++
>  hw/i386/pc.c   |  3 +++
>  hw/i386/pc_piix.c  | 17 ++---
>  hw/i386/pc_q35.c   | 14 --
>  hw/m68k/virt.c | 11 +--
>  hw/ppc/spapr.c | 17 ++---
>  hw/s390x/s390-virtio-ccw.c | 14 +-
>  10 files changed, 83 insertions(+), 13 deletions(-)
>

Reviewed-by: Zhao Liu 

Re: [PATCH-for-9.0? v2 4/4] meson: Enable -Wstatic-in-inline

[Philippe Mathieu-Daudé]

On 26/3/24 18:28, Thomas Huth wrote:

On 26/03/2024 18.10, Philippe Mathieu-Daudé wrote:

Compilers are clever enough to inline code when necessary.

The only case we accept an inline function is static in
header (we use C, not C++).

Add the -Wstatic-in-inline CPPFLAG to prevent public and


I think this is rather a compiler than a pre-processor flag, so 
s/CPPFLAG/CFLAGS/ ?


Oops indeed you are right, thanks!



Anyway:
Reviewed-by: Thomas Huth 



inline function to be added in the code base.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20240313184954.42513-5-phi...@linaro.org>
---
  meson.build | 1 +
  1 file changed, 1 insertion(+)

Re: [PATCH for-9.1 v5 2/3] target/i386: add guest-phys-bits cpu property

[Zhao Liu]

Hi Paolo,

On Mon, Mar 25, 2024 at 03:14:21PM +0100, Paolo Bonzini wrote:
> Date: Mon, 25 Mar 2024 15:14:21 +0100
> From: Paolo Bonzini 
> Subject: [PATCH for-9.1 v5 2/3] target/i386: add guest-phys-bits cpu
>  property
> X-Mailer: git-send-email 2.44.0
> 
> From: Gerd Hoffmann 
> 
> Allows to set guest-phys-bits (cpuid leaf 8008, eax[23:16])
> via -cpu $model,guest-phys-bits=$nr.
> 
> Signed-off-by: Gerd Hoffmann 
> Message-ID: <20240318155336.156197-3-kra...@redhat.com>
> Signed-off-by: Paolo Bonzini 
> ---
> v4->v5:
> - move here all non-KVM parts
> - add compat property and support for special value "-1" (accelerator
>   defines value)
> 
>  target/i386/cpu.h |  1 +
>  hw/i386/pc.c  |  4 +++-
>  target/i386/cpu.c | 22 ++
>  3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 6b057380791..83e47358451 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -2026,6 +2026,7 @@ struct ArchCPU {
>  
>  /* Number of physical address bits supported */
>  uint32_t phys_bits;
> +uint32_t guest_phys_bits;

Maybe here it deserves a comment, just as most any other fields...what
about copying commit message of patch 3 like:

/*
 * Number of guest physical address bits supported. Usually this is
 * identical to host physical address bits. With NPT or EPT being used
 * this might be restricted to 48 (max 4-level paging address space
 * size) even if the host cpu supports more physical address bits.
 */

Otherwise,

Reviewed-by: Zhao Liu 

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Jason Wang]

On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
>
> On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  wrote:
> >
> > Hi Cindy:
> >
> > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > >
> > > we need a crash in Non-standard image, here is the jira for this 
> > > https://issues.redhat.com/browse/RHEL-28522
> > > The root cause of the issue is that an IRQFD was used without 
> > > initialization..
> > >
> > > During the booting process of the Vyatta image, the behavior of the 
> > > called function in qemu is as follows:
> > >
> > > 1. vhost_net_stop() was called, this will call the function
> > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> >
> > Before vhost_net_stop(), do we know which vector is used by which queue?
> >
> before this stop, vdev->config_verctor is get from
> virtio_pci_common_read/virtio_pci_common_write
> it was set to vector 0

I basically meant if vector 0 is shared with some virtqueues here.

> > >
> > > 2. virtio_reset() was called -->set configure vector to VIRTIO_NO_VECTORt
> > >
> > > 3.vhost_net_start() was called (at this time the configure vector is
> > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() with
> > > assgin= true, so the irqfd for vector 0 was not "init" during this process
> >
> > How does the configure vector differ from the virtqueue vector here?
> >
> All the vectors are VIRTIO_NO_VECTOR (including vq). any
> msix_fire_vector_notifier()
> been called will cause the crash at this time.

Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
the assignment is true?

> So I think this should
> be a bug in this guest image

The point is Qemu should not crash even if the guest driver is buggy.

It would be nice if we can have a qtest for this on top.

Thanks

> > >
> > > 4. The system continues to boot and msix_fire_vector_notifier() was
> > > called unmask the vector 0 and then met the crash
> > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > >
> > > The reason for not reproducing in RHEL/fedora guest image is because
> > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop and then 
> > > virtio_reset, and also won't call msix_fire_vector_notifier for vector 0 
> > > during system boot.
> > >
> > > The reason for not reproducing before configure interrupt support is 
> > > because
> > > vector 0 is for configure interrupt,  before the support for configure 
> > > interrupts, the notifier process will not handle vector 0.
> > >
> > > For the device Vyatta using, it doesn't support configure interrupts at 
> > > all, So we plan to disable the configure interrupts in unsupported device
> >
> > Btw, let's tweak the changelog, it's a little bit hard to understand.
> >
> sure will do
> thanks
> Cindy
> > Thanks
> >
> > >
> > > Signed-off-by: Cindy Lu 
> > >
> > > Cindy Lu (2):
> > >   virtio-net: disable the configure interrupt for not support device
> > >   virtio-pci: check if the configure interrupt enable
> > >
> > >  hw/net/virtio-net.c|  5 -
> > >  hw/virtio/virtio-pci.c | 41 +-
> > >  hw/virtio/virtio.c |  1 +
> > >  include/hw/virtio/virtio.h |  1 +
> > >  4 files changed, 29 insertions(+), 19 deletions(-)
> > >
> > > --
> > > 2.43.0
> > >
> >
>

Re: [PULL 35/38] spapr: nested: Introduce H_GUEST_[GET|SET]_STATE hcalls.

[Thomas Huth]

On 27/03/2024 06.41, Harsh Prateek Bora wrote:



On 3/26/24 21:32, Peter Maydell wrote:

On Tue, 12 Mar 2024 at 17:11, Nicholas Piggin  wrote:


From: Harsh Prateek Bora 

Introduce the nested PAPR hcalls:
 - H_GUEST_GET_STATE which is used to get state of a nested guest or
   a guest VCPU. The value field for each element in the request is
   destination to be updated to reflect current state on success.
 - H_GUEST_SET_STATE which is used to modify the state of a guest or
   a guest VCPU. On success, guest (or its VCPU) state shall be
   updated as per the value field for the requested element(s).

Reviewed-by: Nicholas Piggin 
Signed-off-by: Michael Neuling 
Signed-off-by: Harsh Prateek Bora 
Signed-off-by: Nicholas Piggin 


Hi; Coverity points out a problem with this code (CID 1540008, 1540009):




+static target_ulong h_guest_getset_state(PowerPCCPU *cpu,
+ SpaprMachineState *spapr,
+ target_ulong *args,
+ bool set)
+{
+    target_ulong flags = args[0];
+    target_ulong lpid = args[1];
+    target_ulong vcpuid = args[2];
+    target_ulong buf = args[3];
+    target_ulong buflen = args[4];
+    struct guest_state_request gsr;
+    SpaprMachineStateNestedGuest *guest;
+
+    guest = spapr_get_nested_guest(spapr, lpid);
+    if (!guest) {
+    return H_P2;
+    }
+    gsr.buf = buf;
+    assert(buflen <= GSB_MAX_BUF_SIZE);
+    gsr.len = buflen;
+    gsr.flags = 0;
+    if (flags & H_GUEST_GETSET_STATE_FLAG_GUEST_WIDE) {


flags is a target_ulong, which means it might only be 32 bits.
But H_GUEST_GETSET_STATE_FLAG_GUEST_WIDE has a bit set in the
upper 32 bits only. So Coverity complains about this condition
being always-zero and the body of the if being dead code.

What was the intention here?


Hi Peter,
Ideally this is intended to be running on a ppc64 where target_ulong
should be uint64_t. I guess same holds true for existing nested-hv code
as well.

Hi Nick,
Do you think keeping both nested APIs (i.e. entire spapr_nested.c)
within #ifdef TARGET_PPC64 would be a better choice here?


spapr_numa.c is only included with CONFIG_PSERIES in hw/ppc/meson.build, so 
that should already take care that this code is only compiled with a 64-bit 
target ... Can we somehow teach Coverity to take that into consideration?


 Thomas

Re: [PATCH for-9.1 v5 3/3] kvm: add support for guest physical bits

[Zhao Liu]

Hi Paolo,

On Mon, Mar 25, 2024 at 03:14:22PM +0100, Paolo Bonzini wrote:
> Date: Mon, 25 Mar 2024 15:14:22 +0100
> From: Paolo Bonzini 
> Subject: [PATCH for-9.1 v5 3/3] kvm: add support for guest physical bits
> X-Mailer: git-send-email 2.44.0

[snip]

>  static bool kvm_cpu_realizefn(CPUState *cs, Error **errp)
>  {
>  X86CPU *cpu = X86_CPU(cs);
>  CPUX86State *env = &cpu->env;
> +bool ret;
>  
>  /*
>   * The realize order is important, since x86_cpu_realize() checks if
> @@ -50,7 +72,17 @@ static bool kvm_cpu_realizefn(CPUState *cs, Error **errp)
> MSR_IA32_UCODE_REV);
>  }
>  }
> -return host_cpu_realizefn(cs, errp);
> +ret = host_cpu_realizefn(cs, errp);
> +if (!ret) {
> +return ret;
> +}
> +
> +if ((env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) &&
> +cpu->guest_phys_bits == -1) {
> +kvm_set_guest_phys_bits(cs);
> +}
> +
> +return true;
>  }
>

Just nit, it seems the comment about "realize order" in
kvm_cpu_realizefn() should also be updated to include this new
kvm_set_guest_phys_bits().

Or, I feel the guest_phys_bits could also be set in host_cpu_realizefn()
since it also indicates the host support.

Anyway, this won't affect this current series. LGTM,

Reviewed-by: Zhao Liu 

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Cindy Lu]

On Wed, Mar 27, 2024 at 3:54 PM Jason Wang  wrote:
>
> On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
> >
> > On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  wrote:
> > >
> > > Hi Cindy:
> > >
> > > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > > >
> > > > we need a crash in Non-standard image, here is the jira for this 
> > > > https://issues.redhat.com/browse/RHEL-28522
> > > > The root cause of the issue is that an IRQFD was used without 
> > > > initialization..
> > > >
> > > > During the booting process of the Vyatta image, the behavior of the 
> > > > called function in qemu is as follows:
> > > >
> > > > 1. vhost_net_stop() was called, this will call the function
> > > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> > >
> > > Before vhost_net_stop(), do we know which vector is used by which queue?
> > >
> > before this stop, vdev->config_verctor is get from
> > virtio_pci_common_read/virtio_pci_common_write
> > it was set to vector 0
>
> I basically meant if vector 0 is shared with some virtqueues here.
>
Really sorry for this, vq's vector is 1,2, and will not share with the
configure vector
> > > >
> > > > 2. virtio_reset() was called -->set configure vector to 
> > > > VIRTIO_NO_VECTORt
> > > >
> > > > 3.vhost_net_start() was called (at this time the configure vector is
> > > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() with
> > > > assgin= true, so the irqfd for vector 0 was not "init" during this 
> > > > process
> > >
> > > How does the configure vector differ from the virtqueue vector here?
> > >
> > All the vectors are VIRTIO_NO_VECTOR (including vq). any
> > msix_fire_vector_notifier()
> > been called will cause the crash at this time.
>
> Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
> the assignment is true?
>
It will allocate, but  the vector is VIRTIO_NO_VECTOR (0x)

then it will called kvm_virtio_pci_vector_use_one()

in this function, there is a check for

if (vector >= msix_nr_vectors_allocated(dev))

{ return 0; }

So it will return.

> > So I think this should
> > be a bug in this guest image
>
> The point is Qemu should not crash even if the guest driver is buggy.
>
> It would be nice if we can have a qtest for this on top.
>
> Thanks
>
sure, got it, I have done the Qtest, and it passed
here is the result

Ok: 794
Expected Fail:  0
Fail:   0
Unexpected Pass:0
Skipped:32
Timeout:0

> > > >
> > > > 4. The system continues to boot and msix_fire_vector_notifier() was
> > > > called unmask the vector 0 and then met the crash
> > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > > >
> > > > The reason for not reproducing in RHEL/fedora guest image is because
> > > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop and 
> > > > then virtio_reset, and also won't call msix_fire_vector_notifier for 
> > > > vector 0 during system boot.
> > > >
> > > > The reason for not reproducing before configure interrupt support is 
> > > > because
> > > > vector 0 is for configure interrupt,  before the support for configure 
> > > > interrupts, the notifier process will not handle vector 0.
> > > >
> > > > For the device Vyatta using, it doesn't support configure interrupts at 
> > > > all, So we plan to disable the configure interrupts in unsupported 
> > > > device
> > >
> > > Btw, let's tweak the changelog, it's a little bit hard to understand.
> > >
> > sure will do
> > thanks
> > Cindy
> > > Thanks
> > >
> > > >
> > > > Signed-off-by: Cindy Lu 
> > > >
> > > > Cindy Lu (2):
> > > >   virtio-net: disable the configure interrupt for not support device
> > > >   virtio-pci: check if the configure interrupt enable
> > > >
> > > >  hw/net/virtio-net.c|  5 -
> > > >  hw/virtio/virtio-pci.c | 41 +-
> > > >  hw/virtio/virtio.c |  1 +
> > > >  include/hw/virtio/virtio.h |  1 +
> > > >  4 files changed, 29 insertions(+), 19 deletions(-)
> > > >
> > > > --
> > > > 2.43.0
> > > >
> > >
> >
>

[PATCH] configure: Disable -Werror by default if sanitizers are enabled

[Akihiko Odaki]

With GCC 13.2.1 I got the following warning when sanitizers are enabled:

../hw/net/rtl8139.c: In function 'rtl8139_io_writeb':
../hw/net/rtl8139.c:2273:17: error: writing 8 bytes into a region of size 0 
[-Werror=stringop-overflow=]
 2273 | memcpy(data_to_checksum, saved_ip_header + 12, 8);

The bug is reported upstream and you can find details at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494

The GCC documentation states it is not recommended to combine -Werror
and sanitizers so disable -Werror by default if sanitizers are enabled.

Signed-off-by: Akihiko Odaki 
---
 configure | 12 
 1 file changed, 12 insertions(+)

diff --git a/configure b/configure
index 3cd736b139f3..3407f9971db1 100755
--- a/configure
+++ b/configure
@@ -262,6 +262,7 @@ unset target_list_exclude
 # The following Meson options are handled manually (still they
 # are included in the automatically generated help message)
 # because they automatically enable/disable other options
+sanitizers=no
 tcg="auto"
 cfi="false"
 
@@ -713,6 +714,10 @@ for opt do
   meson_option_add -Doptimization=0
   default_cflags='-O0 -g'
   ;;
+  --disable-sanitizers) sanitizers=no
+  ;;
+  --enable-sanitizers) sanitizers=yes
+  ;;
   --disable-tcg) tcg="disabled"
   ;;
   --enable-tcg) tcg="enabled"
@@ -1706,9 +1711,15 @@ if test "$skip_meson" = no; then
   echo "cpp_link_args = [$(meson_quote $CXXFLAGS $LDFLAGS $EXTRA_CXXFLAGS 
$EXTRA_LDFLAGS)]" >> $cross
 
   # Only enable by default for git builds and on select OSes
+  # Also don't enable if sanitizers are enabled. The GCC documentation says:
+  # > Note that sanitizers tend to increase the rate of false positive 
warnings,
+  # > most notably those around -Wmaybe-uninitialized. We recommend against
+  # > combining -Werror and [the use of] sanitizers.
+  # https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html
   echo "# environment defaults, can still be overridden on " >> $cross
   echo "# the command line" >> $cross
   if test -e "$source_path/.git" && \
+  test "$sanitizers" == no && \
   { test "$host_os" = linux || test "$host_os" = "windows"; }; then
   echo 'werror = true' >> $cross
   fi
@@ -1789,6 +1800,7 @@ if test "$skip_meson" = no; then
   test -n "${LIB_FUZZING_ENGINE+xxx}" && meson_option_add 
"-Dfuzzing_engine=$LIB_FUZZING_ENGINE"
   test "$plugins" = yes && meson_option_add "-Dplugins=true"
   test "$tcg" != enabled && meson_option_add "-Dtcg=$tcg"
+  test "$sanitizers" = yes && meson_option_add -Dsanitizers=true
   run_meson() {
 NINJA=$ninja $meson setup "$@" "$PWD" "$source_path"
   }

---
base-commit: ba49d760eb04630e7b15f423ebecf6c871b8f77b
change-id: 20240327-werror-5d2e974c3d7d

Best regards,
-- 
Akihiko Odaki 

[PATCH v2] hw/net/net_tx_pkt: Fix virtio header without checksum offloading

[Akihiko Odaki]

It is incorrect to have the VIRTIO_NET_HDR_F_NEEDS_CSUM set when
checksum offloading is disabled so clear the bit.

TCP/UDP checksum is usually offloaded when the peer requires virtio
headers because they can instruct the peer to compute checksum. However,
igb disables TX checksum offloading when a VF is enabled whether the
peer requires virtio headers because a transmitted packet can be routed
to it and it expects the packet has a proper checksum. Therefore, it
is necessary to have a correct virtio header even when checksum
offloading is disabled.

A real TCP/UDP checksum will be computed and saved in the buffer when
checksum offloading is disabled. The virtio specification requires to
set the packet checksum stored in the buffer to the TCP/UDP pseudo
header when the VIRTIO_NET_HDR_F_NEEDS_CSUM bit is set so the bit must
be cleared in that case.

Fixes: ffbd2dbd8e64 ("e1000e: Perform software segmentation for loopback")
Buglink: https://issues.redhat.com/browse/RHEL-23067
Signed-off-by: Akihiko Odaki 
---
Changes in v2:
- Dropped VIRTIO_NET_HDR_F_DATA_VALID. (Jason Wang)
- Link to v1: https://lore.kernel.org/r/20240324-tx-v1-1-a3b413574...@daynix.com
---
 hw/net/net_tx_pkt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index 2e5f58b3c9cc..2134a18c4c90 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -833,6 +833,7 @@ bool net_tx_pkt_send_custom(struct NetTxPkt *pkt, bool 
offload,
 
 if (offload || gso_type == VIRTIO_NET_HDR_GSO_NONE) {
 if (!offload && pkt->virt_hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
+pkt->virt_hdr.flags &= ~VIRTIO_NET_HDR_F_NEEDS_CSUM;
 net_tx_pkt_do_sw_csum(pkt, &pkt->vec[NET_TX_PKT_L2HDR_FRAG],
   pkt->payload_frags + 
NET_TX_PKT_PL_START_FRAG - 1,
   pkt->payload_len);

---
base-commit: ba49d760eb04630e7b15f423ebecf6c871b8f77b
change-id: 20240324-tx-c57d3c22ad73

Best regards,
-- 
Akihiko Odaki 

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Christian Schoenebeck]

On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:
> On 3/26/24 14:05, Greg Kurz wrote:
> > On Tue, 26 Mar 2024 10:26:04 -0300
> > Daniel Henrique Barboza  wrote:
> > 
> >> The local 9p driver in virtio-9p-test.c its temporary dir right at the
> >> start of qos-test (via virtio_9p_create_local_test_dir()) and only
> >> deletes it after qos-test is finished (via
> >> virtio_9p_remove_local_test_dir()).
> >>
> >> This means that any qos-test machine that ends up running virtio-9p-test 
> >> local
> >> tests more than once will end up re-using the same temp dir. This is
> >> what's happening in [1] after we introduced the riscv machine nodes: if
> >> we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
> >> this is what happens:
> >>
> >> - a temp dir is created, e.g. qtest-9p-local-WZLDL2;
> >>
> >> - virtio-9p-device tests will run virtio-9p-test successfully;
> >>
> >> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the
> >>first slow test at fs_create_dir() because the "01" file was already
> >>created by fs_create_dir() test when running with the virtio-9p-device.
> >>
> >> We can fix it by making every test clean up their changes in the
> >> filesystem after they're done. But we don't need every test either:
> >> what fs_create_file() does is already exercised in fs_unlinkat_dir(),
> >> i.e. a dir is created, verified to be created, and then removed. Fixing
> >> fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
> >> both. The same theme follows every test in virtio-9p-test.c, where the
> >> 'unlikat' variant does the same thing the 'create' does but with some
> >> cleaning in the end.
> >>
> >> Consolide some tests as follows:
> >>
> >> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
> >>fs_create_unlinkat_dir();
> >>
> >> - fs_create_file() is removed. fs_unlinkat_file() is renamed to
> >>fs_create_unlinkat_file(). The "04" dir it uses is now being removed;
> >>
> >> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
> >>fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
> >>creates is now being removed.
> >>
> > 
> > The  change looks good functionally but it breaks the legitimate assumption
> > that files "06/*" come from test #6 and so on... I think you should consider
> > renumbering to avoid confusion when debugging logs.
> > 
> > Since this will bring more hunks, please split this in enough reviewable
> > patches.
> 
> Fair enough. Let me cook a v2. Thanks,

Wouldn't it be much simpler to just change the name of the temporary
directory, such that it contains the device name as well? Then these tests
runs would run on independent directories and won't interfere with each other
and that wouldn't need much changes I guess.

/Christian

Re: [PATCH for-9.0 0/3] qtest/virtio-9p-test.c: fix slow tests

[Christian Schoenebeck]

On Tuesday, March 26, 2024 5:07:16 PM CET Daniel Henrique Barboza wrote:
> 
> On 3/26/24 12:55, Greg Kurz wrote:
> > Bom dia Daniel !
> 
> Bonne après-midi !
> 
> > 
> > On Tue, 26 Mar 2024 10:26:03 -0300
> > Daniel Henrique Barboza  wrote:
> > 
> >> Hi,
> >>
> >> Thomas reported in [1] a problem that happened with the RISC-V machine
> >> where some tests from virtio-9p-test.c were failing with '-m slow', i.e.
> >> enabling slow tests.
> >>
> >> In the end it wasn't a RISC-V specific problem. It just so happens that
> >> the recently added riscv machine nodes runs the tests from
> >> virtio-9p-test two times for each qos-test run: one with the
> >> virtio-9p-device device and another with the virtio-9p-pci. The temp dir
> >> for these tests is being created at the start of qos-test and removed
> >> only at the end of qos-test, and the tests are leaving dirs and files
> >> behind. virtio-9-device tests run first, creates stuff in the temp dir,
> >> then when virtio-9p-pci tests runs again it'll fail because the previous
> >> run left created dirs and files in the same temp dir. Here's a run that
> >> exemplifies the problem:
> >>
> >> $ MALLOC_PERTURB_=21 V=2 QTEST_QEMU_BINARY=./qemu-system-riscv64 
> >> ./tests/qtest/qos-test -m slow
> >> (...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest 
> >> unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev 
> >> socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control 
> >> -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev 
> >> local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr
> >>  -device virtio-9p-device,fsdev=fsdev0,mount_tag=qtest -accel qtest
> >> ( goes ok ...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest 
> >> unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev 
> >> socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control 
> >> -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev 
> >> local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr
> >>  -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> >> ok 168 
> >> /riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
> >> Received response 7 (RLERROR) instead of 73 (RMKDIR)
> >> Rlerror has errno 17 (File exists)
> >> **
> >> ERROR:../tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: 
> >> assertion failed (hdr.id == id): (7 == 73)
> >>
> >> As we can see we're running both 'virtio-9p-device' tests and 
> >> 'virtio-9p-pci'
> >> tests using the same '/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2'
> >> temp dir.
> >>
> > 
> > 
> > Good catch ! I'll try to find some time to review.
> > 
> >> The quick fix I came up with was to make each test clean themselves up
> >> after each run. The tests were also consolidated, i.e. fewer tests with the
> >> same coverage, because the 'unlikat' tests were doing the same thing the
> >> 'create' tests were doing but removing stuff after. Might as well keep just
> >> the 'unlikat' tests.
> >>
> > 
> > As long as coverage is preserved, I'm fine with consolidation of the
> > checks. In any case, last call goes to Christian.
> > 
> >> I also went ahead and reverted 558f5c42efd ("tests/9pfs: Mark "local"
> >> tests as "slow"") after realizing that the problem I was fixing is also
> >> the same problem that this patch was trying to working around with the
> >> skip [2]. I validated this change in this Gitlab pipeline:
> >>
> > 
> > Are you sure with that ? Issues look very similar indeed but not
> > exactly the same.
> 
> We can skip this revert if we're not sure about it. Gitlab passed with it but
> perhaps this isn't evidence enough. I'll let you guys decide.

I am a bit surprised because errnos were different (file exists vs. not
supported), but indeed, it did pass in your Gitlab pipeline. So I am fine with
bringing those tests back in on Gitlab.

/Christian

Re: [PATCH v4 1/2] kvm: add support for guest physical bits

[Paolo Bonzini]

On Wed, Mar 20, 2024 at 3:45 AM Xiaoyao Li  wrote:
> If users pass configuration like "-cpu
> qemu64,phys-bits=52,host-phys-bits-limit=45", the cpu->guest_phys_bits
> will be set to 45. I think this is not what we want, though the usage
> seems insane.
>
> We can guard it as
>
>   if (cpu->host_phys_bits && cpu->host_phys_bits_limit &&
>   cpu->guest_phys_bits > cpu->host_phys_bits_limt)
> {
> }

> Simpler, we can guard with cpu->phys_bits like below, because
> cpu->host_phys_bits_limit is used to guard cpu->phys_bits in
> host_cpu_realizefn()
>
>   if (cpu->guest_phys_bits > cpu->phys_bits) {
> cpu->guest_phys_bits = cpu->phys_bits;
> }
>
>
> with this resolved,
>
> Reviewed-by: Xiaoyao Li 

[oops sorry - I noticed now that this email was never sent, so I am
sending it for archival]

There are more issues:

1) for compatibility with older machine types, the GuestPhysAddrSize
should remain 0. One possibility is to have "-1" as "accelerator
default" and "0" as "show it as zero in CPUID".

2) a "guest-phys-bits is not user-configurable in 32 bit" error is
probably a good idea just like it does for cpu->phys_bits

3) I think the order of the patches makes more sense if the property
is added first and KVM is adjusted second.

I'll post a v5 myself (mostly because it has to include the creation
of 9.1 machine types).

Paolo

> > +}
> > +}
> > +
> >   static bool kvm_cpu_realizefn(CPUState *cs, Error **errp)
> >   {
> >   X86CPU *cpu = X86_CPU(cs);
> >   CPUX86State *env = &cpu->env;
> > +bool ret;
> >
> >   /*
> >* The realize order is important, since x86_cpu_realize() checks if
> > @@ -50,7 +73,13 @@ static bool kvm_cpu_realizefn(CPUState *cs, Error **errp)
> >  MSR_IA32_UCODE_REV);
> >   }
> >   }
> > -return host_cpu_realizefn(cs, errp);
> > +ret = host_cpu_realizefn(cs, errp);
> > +if (!ret) {
> > +return ret;
> > +}
> > +
> > +kvm_set_guest_phys_bits(cs);
> > +return true;
> >   }
> >
> >   static bool lmce_supported(void)
>Ther

Re: [PATCH 12/26] KVM: track whether guest state is encrypted

[Paolo Bonzini]

On Tue, Mar 26, 2024 at 4:48 PM Xiaoyao Li  wrote:
> So, this requires confidential guests to call
> kvm_mark_guest_state_protected() in its machine_init_done notifier callback?
>
> But for TDX, the guest_state is protected at the beginning, not some
> time later when machine_init_done.

Good point, I will change this to an "if".

Paolo

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Jason Wang]

On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu  wrote:
>
> On Wed, Mar 27, 2024 at 3:54 PM Jason Wang  wrote:
> >
> > On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
> > >
> > > On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  wrote:
> > > >
> > > > Hi Cindy:
> > > >
> > > > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > > > >
> > > > > we need a crash in Non-standard image, here is the jira for this 
> > > > > https://issues.redhat.com/browse/RHEL-28522
> > > > > The root cause of the issue is that an IRQFD was used without 
> > > > > initialization..
> > > > >
> > > > > During the booting process of the Vyatta image, the behavior of the 
> > > > > called function in qemu is as follows:
> > > > >
> > > > > 1. vhost_net_stop() was called, this will call the function
> > > > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> > > >
> > > > Before vhost_net_stop(), do we know which vector is used by which queue?
> > > >
> > > before this stop, vdev->config_verctor is get from
> > > virtio_pci_common_read/virtio_pci_common_write
> > > it was set to vector 0
> >
> > I basically meant if vector 0 is shared with some virtqueues here.
> >
> Really sorry for this, vq's vector is 1,2, and will not share with the
> configure vector
> > > > >
> > > > > 2. virtio_reset() was called -->set configure vector to 
> > > > > VIRTIO_NO_VECTORt
> > > > >
> > > > > 3.vhost_net_start() was called (at this time the configure vector is
> > > > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() with
> > > > > assgin= true, so the irqfd for vector 0 was not "init" during this 
> > > > > process
> > > >
> > > > How does the configure vector differ from the virtqueue vector here?
> > > >
> > > All the vectors are VIRTIO_NO_VECTOR (including vq). any
> > > msix_fire_vector_notifier()
> > > been called will cause the crash at this time.
> >
> > Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
> > the assignment is true?
> >
> It will allocate, but  the vector is VIRTIO_NO_VECTOR (0x)
>
> then it will called kvm_virtio_pci_vector_use_one()
>
> in this function, there is a check for
>
> if (vector >= msix_nr_vectors_allocated(dev))
>
> { return 0; }
>
> So it will return.

How about let's just fix this?

Btw, it's better to explain in detail like the above in the next version.

Thanks

>
> > > So I think this should
> > > be a bug in this guest image
> >
> > The point is Qemu should not crash even if the guest driver is buggy.
> >
> > It would be nice if we can have a qtest for this on top.
> >
> > Thanks
> >
> sure, got it, I have done the Qtest, and it passed
> here is the result
>
> Ok: 794
> Expected Fail:  0
> Fail:   0
> Unexpected Pass:0
> Skipped:32
> Timeout:0
>
> > > > >
> > > > > 4. The system continues to boot and msix_fire_vector_notifier() was
> > > > > called unmask the vector 0 and then met the crash
> > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > > > >
> > > > > The reason for not reproducing in RHEL/fedora guest image is because
> > > > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop and 
> > > > > then virtio_reset, and also won't call msix_fire_vector_notifier for 
> > > > > vector 0 during system boot.
> > > > >
> > > > > The reason for not reproducing before configure interrupt support is 
> > > > > because
> > > > > vector 0 is for configure interrupt,  before the support for 
> > > > > configure interrupts, the notifier process will not handle vector 0.
> > > > >
> > > > > For the device Vyatta using, it doesn't support configure interrupts 
> > > > > at all, So we plan to disable the configure interrupts in unsupported 
> > > > > device
> > > >
> > > > Btw, let's tweak the changelog, it's a little bit hard to understand.
> > > >
> > > sure will do
> > > thanks
> > > Cindy
> > > > Thanks
> > > >
> > > > >
> > > > > Signed-off-by: Cindy Lu 
> > > > >
> > > > > Cindy Lu (2):
> > > > >   virtio-net: disable the configure interrupt for not support device
> > > > >   virtio-pci: check if the configure interrupt enable
> > > > >
> > > > >  hw/net/virtio-net.c|  5 -
> > > > >  hw/virtio/virtio-pci.c | 41 
> > > > > +-
> > > > >  hw/virtio/virtio.c |  1 +
> > > > >  include/hw/virtio/virtio.h |  1 +
> > > > >  4 files changed, 29 insertions(+), 19 deletions(-)
> > > > >
> > > > > --
> > > > > 2.43.0
> > > > >
> > > >
> > >
> >
>

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Jason Wang]

On Wed, Mar 27, 2024 at 5:12 PM Jason Wang  wrote:
>
> On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu  wrote:
> >
> > On Wed, Mar 27, 2024 at 3:54 PM Jason Wang  wrote:
> > >
> > > On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
> > > >
> > > > On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  wrote:
> > > > >
> > > > > Hi Cindy:
> > > > >
> > > > > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > > > > >
> > > > > > we need a crash in Non-standard image, here is the jira for this 
> > > > > > https://issues.redhat.com/browse/RHEL-28522
> > > > > > The root cause of the issue is that an IRQFD was used without 
> > > > > > initialization..
> > > > > >
> > > > > > During the booting process of the Vyatta image, the behavior of the 
> > > > > > called function in qemu is as follows:
> > > > > >
> > > > > > 1. vhost_net_stop() was called, this will call the function
> > > > > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > > > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> > > > >
> > > > > Before vhost_net_stop(), do we know which vector is used by which 
> > > > > queue?
> > > > >
> > > > before this stop, vdev->config_verctor is get from
> > > > virtio_pci_common_read/virtio_pci_common_write
> > > > it was set to vector 0
> > >
> > > I basically meant if vector 0 is shared with some virtqueues here.
> > >
> > Really sorry for this, vq's vector is 1,2, and will not share with the
> > configure vector
> > > > > >
> > > > > > 2. virtio_reset() was called -->set configure vector to 
> > > > > > VIRTIO_NO_VECTORt
> > > > > >
> > > > > > 3.vhost_net_start() was called (at this time the configure vector is
> > > > > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() 
> > > > > > with
> > > > > > assgin= true, so the irqfd for vector 0 was not "init" during this 
> > > > > > process
> > > > >
> > > > > How does the configure vector differ from the virtqueue vector here?
> > > > >
> > > > All the vectors are VIRTIO_NO_VECTOR (including vq). any
> > > > msix_fire_vector_notifier()
> > > > been called will cause the crash at this time.
> > >
> > > Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
> > > the assignment is true?
> > >
> > It will allocate, but  the vector is VIRTIO_NO_VECTOR (0x)
> >
> > then it will called kvm_virtio_pci_vector_use_one()
> >
> > in this function, there is a check for
> >
> > if (vector >= msix_nr_vectors_allocated(dev))
> >
> > { return 0; }
> >
> > So it will return.
>
> How about let's just fix this?

Btw, another question, how does vDPA work here?

Thanks

>
> Btw, it's better to explain in detail like the above in the next version.
>
> Thanks
>
> >
> > > > So I think this should
> > > > be a bug in this guest image
> > >
> > > The point is Qemu should not crash even if the guest driver is buggy.
> > >
> > > It would be nice if we can have a qtest for this on top.
> > >
> > > Thanks
> > >
> > sure, got it, I have done the Qtest, and it passed
> > here is the result
> >
> > Ok: 794
> > Expected Fail:  0
> > Fail:   0
> > Unexpected Pass:0
> > Skipped:32
> > Timeout:0
> >
> > > > > >
> > > > > > 4. The system continues to boot and msix_fire_vector_notifier() was
> > > > > > called unmask the vector 0 and then met the crash
> > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > > > > >
> > > > > > The reason for not reproducing in RHEL/fedora guest image is because
> > > > > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop and 
> > > > > > then virtio_reset, and also won't call msix_fire_vector_notifier 
> > > > > > for vector 0 during system boot.
> > > > > >
> > > > > > The reason for not reproducing before configure interrupt support 
> > > > > > is because
> > > > > > vector 0 is for configure interrupt,  before the support for 
> > > > > > configure interrupts, the notifier process will not handle vector 0.
> > > > > >
> > > > > > For the device Vyatta using, it doesn't support configure 
> > > > > > interrupts at all, So we plan to disable the configure interrupts 
> > > > > > in unsupported device
> > > > >
> > > > > Btw, let's tweak the changelog, it's a little bit hard to understand.
> > > > >
> > > > sure will do
> > > > thanks
> > > > Cindy
> > > > > Thanks
> > > > >
> > > > > >
> > > > > > Signed-off-by: Cindy Lu 
> > > > > >
> > > > > > Cindy Lu (2):
> > > > > >   virtio-net: disable the configure interrupt for not support device
> > > > > >   virtio-pci: check if the configure interrupt enable
> > > > > >
> > > > > >  hw/net/virtio-net.c|  5 -
> > > > > >  hw/virtio/virtio-pci.c | 41 
> > > > > > +-
> > > > > >  hw/virtio/virtio.c |  1 +
> > > > > >  include/hw/virtio/virtio.h |  1 +
> > > > > >  4 files changed, 29 insertions(+), 19 deletions(-)
> > > >

Re: [PATCH-for-9.1 01/18] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

[Philippe Mathieu-Daudé]

On 6/3/24 17:41, Thomas Huth wrote:

On 05/03/2024 14.42, Philippe Mathieu-Daudé wrote:

The pc-i440fx-2.0 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
  docs/about/deprecated.rst   |  2 +-
  docs/about/removed-features.rst |  2 +-
  include/hw/i386/pc.h    |  3 ---
  hw/i386/pc.c    | 15 -
  hw/i386/pc_piix.c   | 37 -
  5 files changed, 2 insertions(+), 57 deletions(-)




diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f5ff970acf..bb7ef31af2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -311,21 +311,6 @@ GlobalProperty pc_compat_2_1[] = {
  };
  const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
-GlobalProperty pc_compat_2_0[] = {
-    PC_CPU_MODEL_IDS("2.0.0")
-    { "virtio-scsi-pci", "any_layout", "off" },
-    { "PIIX4_PM", "memory-hotplug-support", "off" },
-    { "apic", "version", "0x11" },
-    { "nec-usb-xhci", "superspeed-ports-first", "off" },
-    { "nec-usb-xhci", "force-pcie-endcap", "on" },
-    { "pci-serial", "prog_if", "0" },
-    { "pci-serial-2x", "prog_if", "0" },
-    { "pci-serial-4x", "prog_if", "0" },
-    { "virtio-net-pci", "guest_announce", "off" },
-    { "ICH9-LPC", "memory-hotplug-support", "off" },


I think you could clean up memory-hotplug-support for the ICH9-LPC 
device now, too (in a separate patch).


Great suggestion, thanks!



For this patch here:
Reviewed-by: Thomas Huth 

Re: [PATCH-for-9.0? v2 4/4] meson: Enable -Wstatic-in-inline

[Paolo Bonzini]

On 3/26/24 18:10, Philippe Mathieu-Daudé wrote:

Compilers are clever enough to inline code when necessary.

The only case we accept an inline function is static in
header (we use C, not C++).

Add the -Wstatic-in-inline CPPFLAG to prevent public and
inline function to be added in the code base.


No problem with the first three patches, but -Wstatic-in-inline is not
warning for non-static inline functions.  The warning is enabled by
default by GCC (which has no way to disable it even) and by clang
outside headers:

f.h:
static int y;

inline int f()
{
return y;
}

f.c:
#include "f.h"

int main()
{
}

$ clang f.c
./f.h:5:12: warning: static variable 'y' is used in an inline function with 
external linkage [-Wstatic-in-inline]

$ gcc f.c
f.h:5:12: warning: ‘y’ is static but used in inline function ‘f’ which is not 
static

The actual effect of this patch is to enable the warning on clang *even
outside headers* (clang only enables the warning in headers by default
because, if a static variable belongs to the main source file, it has a
single definition anyway unlike if it's defined in an included file).

For now I'm queuing patches 1-3 only.

Paolo


Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20240313184954.42513-5-phi...@linaro.org>
Reviewed-by: Thomas Huth 
---
  meson.build | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meson.build b/meson.build
index c9c3217ba4..f400f7d36c 100644
--- a/meson.build
+++ b/meson.build
@@ -591,6 +591,7 @@ warn_flags = [
'-Wold-style-definition',
'-Wredundant-decls',
'-Wshadow=local',
+  '-Wstatic-in-inline',
'-Wstrict-prototypes',
'-Wtype-limits',
'-Wundef',

Re: [PATCH for-9.1 v2 02/11] libvhost-user: fail vu_message_write() if sendmsg() is failing

[Stefano Garzarella]

On Tue, Mar 26, 2024 at 03:36:52PM +0100, David Hildenbrand wrote:

On 26.03.24 15:34, Eric Blake wrote:

On Tue, Mar 26, 2024 at 02:39:27PM +0100, Stefano Garzarella wrote:

In vu_message_write() we use sendmsg() to send the message header,
then a write() to send the payload.

If sendmsg() fails we should avoid sending the payload, since we
were unable to send the header.

Discovered before fixing the issue with the previous patch, where
sendmsg() failed on macOS due to wrong parameters, but the frontend
still sent the payload which the backend incorrectly interpreted
as a wrong header.

Signed-off-by: Stefano Garzarella 
---
 subprojects/libvhost-user/libvhost-user.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/subprojects/libvhost-user/libvhost-user.c 
b/subprojects/libvhost-user/libvhost-user.c
index 22bea0c775..a11afd1960 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -639,6 +639,11 @@ vu_message_write(VuDev *dev, int conn_fd, VhostUserMsg 
*vmsg)
 rc = sendmsg(conn_fd, &msg, 0);
 } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+if (rc <= 0) {


Is rejecting a 0 return value correct?  Technically, a 0 return means
a successful write of 0 bytes - but then again, it is unwise to
attempt to send an fd or other auxilliary ddata without at least one
regular byte, so we should not be attempting a write of 0 bytes.  So I
guess this one is okay, although I might have used < instead of <=.


I blindly copied what they already do at the end of the same function.
However, your observation is correct. That said they have a sendmsg()
to send the header. After this we have a write() loop to send the
payload.

Now if sendmsg() returns 0, but we have not sent all the header, what
should we do? Try sendmsg() again? For how many times?



I was wondering if we could see some partial sendmsg()/write 
succeeding. Meaning, we transferred some bytes but not all, and we'd 
actually need to loop ...


Yep, true, but I would fix it in another patch/series if you agree.

Thanks,
Stefano

Re: [PATCH for-9.1 v2 03/11] libvhost-user: mask F_INFLIGHT_SHMFD if memfd is not supported

[Stefano Garzarella]

On Tue, Mar 26, 2024 at 09:36:54AM -0500, Eric Blake wrote:

On Tue, Mar 26, 2024 at 02:39:28PM +0100, Stefano Garzarella wrote:

libvhost-user will panic when receiving VHOST_USER_GET_INFLIGHT_FD
message if MFD_ALLOW_SEALING is not defined, since it's not able
to create a memfd.

VHOST_USER_GET_INFLIGHT_FD is used only if
VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD is negotiated. So, let's mask
that feature if the backend is not able to properly handle these
messages.

Signed-off-by: Stefano Garzarella 
---
 subprojects/libvhost-user/libvhost-user.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/subprojects/libvhost-user/libvhost-user.c 
b/subprojects/libvhost-user/libvhost-user.c
index a11afd1960..1c361ffd51 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -1674,6 +1674,16 @@ vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg 
*vmsg)
 features |= dev->iface->get_protocol_features(dev);
 }

+/*
+ * If MFD_ALLOW_SEALING is not defined, we are not able to handle
+ * VHOST_USER_GET_INFLIGHT_FD messages, since we can't create a memfd.
+ * Those messages are used only if VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
+ * is negotiated. A device implementation can enable it, so let's mask
+ * it to avoid a runtime panic.
+ */
+#ifndef MFD_ALLOW_SEALING
+features &= ~(1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD);
+#endif


Masking the feature out of advertisement is obviously correct. But
should we also fix the code for handling
VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD to return an error to any client
that requests it in error when the feature was not advertised, instead
of panicking?


Totally agree!

Do I send a separate patch from this series or include it in this
series?
I would do the former because this one is already long enough.

Thanks,
Stefano

Re: [PATCH for-9.1 v2 02/11] libvhost-user: fail vu_message_write() if sendmsg() is failing

[David Hildenbrand]

I was wondering if we could see some partial sendmsg()/write
succeeding. Meaning, we transferred some bytes but not all, and we'd
actually need to loop ...


Yep, true, but I would fix it in another patch/series if you agree.


Absolutely.

--
Cheers,

David / dhildenb

[PATCH for-9.0 v2 4/7] qtest/virtio-9p-test.c: consolidate create file tests

[Daniel Henrique Barboza]

Similar to what was done with fs_create_dir() in the previous patch, and
for the same reasons, let's consolidate fs_create_file() and
fs_unlinkat_file() in a single test that has the same coverage:

- fs_create_file() is removed;

- rename fs_unlinkat_file() to fs_create_unlinkat_file();

- change fs_create_unlinkat_file() to also remove the created dir.

The remaining tests got their dir changed to reflect that we're now with
one less test.

Reported-by: Thomas Huth 
Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 42 ++--
 1 file changed, 16 insertions(+), 26 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 2cea1b4189..75d4d1cf4b 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -534,31 +534,14 @@ static void fs_create_unlinkat_dir(void *obj, void *data,
 g_assert(stat(new_dir_path, &st) != 0);
 }
 
-static void fs_create_file(void *obj, void *data, QGuestAllocator *t_alloc)
+static void fs_create_unlinkat_file(void *obj, void *data,
+QGuestAllocator *t_alloc)
 {
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
 const char *new_dir = "02";
-g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "1st_file");
-g_autofree char *new_file_path = virtio_9p_test_path(new_file);
-
-tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
-tlcreate({ .client = v9p, .atPath = new_dir, .name = "1st_file" });
-
-/* check if created file exists now ... */
-g_assert(stat(new_file_path, &st) == 0);
-/* ... and is a regular file */
-g_assert((st.st_mode & S_IFMT) == S_IFREG);
-}
-
-static void fs_unlinkat_file(void *obj, void *data, QGuestAllocator *t_alloc)
-{
-QVirtio9P *v9p = obj;
-v9fs_set_allocator(t_alloc);
-struct stat st;
-const char *new_dir = "03";
+g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
 g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "doa_file");
 g_autofree char *new_file_path = virtio_9p_test_path(new_file);
 
@@ -574,6 +557,13 @@ static void fs_unlinkat_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 tunlinkat({ .client = v9p, .atPath = new_dir, .name = "doa_file" });
 /* file should be gone now */
 g_assert(stat(new_file_path, &st) != 0);
+
+/* cleanup: remove the created dir */
+tunlinkat({
+.client = v9p, .atPath = "/", .name = new_dir,
+.flags = P9_DOTL_AT_REMOVEDIR
+});
+g_assert(stat(new_dir_path, &st) != 0);
 }
 
 static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc)
@@ -581,7 +571,7 @@ static void fs_symlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "04";
+const char *new_dir = "03";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *symlink_file = NULL;
@@ -614,7 +604,7 @@ static void fs_unlinkat_symlink(void *obj, void *data,
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "05";
+const char *new_dir = "04";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *symlink_file = NULL;
@@ -648,7 +638,7 @@ static void fs_hardlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st_real, st_link;
-const char *new_dir = "06";
+const char *new_dir = "05";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *hardlink_file = NULL;
@@ -685,7 +675,7 @@ static void fs_unlinkat_hardlink(void *obj, void *data,
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st_real, st_link;
-const char *new_dir = "07";
+const char *new_dir = "06";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *hardlink_file = NULL;
@@ -771,8 +761,8 @@ static void register_virtio_9p_test(void)
 qos_add_test("local/config", "virtio-9p", pci_config,  &opts);
 qos_add_test("local/create_unlinkat_dir", "virtio-9p",
  fs_create_unlinkat_dir, &opts);
-qos_add_test("local/create_file", "virtio-9p", fs_create_file, &opts);
-qos_add_test("local/unlinkat_file", "virtio-9p", fs_unlinkat_file, &opts);
+qos_add_test("local/create_unlinkat_file", "virtio-9p",
+ fs_create_unlinkat_file, &opts);
 qos_add_test("local/symlink_file", "virtio-9p", fs_symlink_file, &opts);
 qos_add_test("local/unlinkat_symlink", "virtio-9p", fs_unlinkat_symlink,
  &opts);
-- 
2.44.0

[PATCH for-9.0 v2 1/7] qtest/virtio-9p-test.c: add '_path' in path vars

[Daniel Henrique Barboza]

Add a '_path' call in all variables that are receiving a full path via
virtio_9p_test_path().

Aside from being more accurate with what the variable represents, this
will allow us to use 'new_dir' and 'real_path' and so on to parametrize
test values in the next patch.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 64 
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 65e69491e5..23edca05c5 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -512,7 +512,7 @@ static void fs_create_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 v9fs_set_allocator(t_alloc);
 struct stat st;
 g_autofree char *root_path = virtio_9p_test_path("");
-g_autofree char *new_dir = virtio_9p_test_path("01");
+g_autofree char *new_dir_path = virtio_9p_test_path("01");
 
 g_assert(root_path != NULL);
 
@@ -520,7 +520,7 @@ static void fs_create_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 tmkdir({ .client = v9p, .atPath = "/", .name = "01" });
 
 /* check if created directory really exists now ... */
-g_assert(stat(new_dir, &st) == 0);
+g_assert(stat(new_dir_path, &st) == 0);
 /* ... and is actually a directory */
 g_assert((st.st_mode & S_IFMT) == S_IFDIR);
 }
@@ -531,7 +531,7 @@ static void fs_unlinkat_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 v9fs_set_allocator(t_alloc);
 struct stat st;
 g_autofree char *root_path = virtio_9p_test_path("");
-g_autofree char *new_dir = virtio_9p_test_path("02");
+g_autofree char *new_dir_path = virtio_9p_test_path("02");
 
 g_assert(root_path != NULL);
 
@@ -539,7 +539,7 @@ static void fs_unlinkat_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 tmkdir({ .client = v9p, .atPath = "/", .name = "02" });
 
 /* check if created directory really exists now ... */
-g_assert(stat(new_dir, &st) == 0);
+g_assert(stat(new_dir_path, &st) == 0);
 /* ... and is actually a directory */
 g_assert((st.st_mode & S_IFMT) == S_IFDIR);
 
@@ -548,7 +548,7 @@ static void fs_unlinkat_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 .flags = P9_DOTL_AT_REMOVEDIR
 });
 /* directory should be gone now */
-g_assert(stat(new_dir, &st) != 0);
+g_assert(stat(new_dir_path, &st) != 0);
 }
 
 static void fs_create_file(void *obj, void *data, QGuestAllocator *t_alloc)
@@ -556,14 +556,14 @@ static void fs_create_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *new_file = virtio_9p_test_path("03/1st_file");
+g_autofree char *new_file_path = virtio_9p_test_path("03/1st_file");
 
 tattach({ .client = v9p });
 tmkdir({ .client = v9p, .atPath = "/", .name = "03" });
 tlcreate({ .client = v9p, .atPath = "03", .name = "1st_file" });
 
 /* check if created file exists now ... */
-g_assert(stat(new_file, &st) == 0);
+g_assert(stat(new_file_path, &st) == 0);
 /* ... and is a regular file */
 g_assert((st.st_mode & S_IFMT) == S_IFREG);
 }
@@ -573,20 +573,20 @@ static void fs_unlinkat_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *new_file = virtio_9p_test_path("04/doa_file");
+g_autofree char *new_file_path = virtio_9p_test_path("04/doa_file");
 
 tattach({ .client = v9p });
 tmkdir({ .client = v9p, .atPath = "/", .name = "04" });
 tlcreate({ .client = v9p, .atPath = "04", .name = "doa_file" });
 
 /* check if created file exists now ... */
-g_assert(stat(new_file, &st) == 0);
+g_assert(stat(new_file_path, &st) == 0);
 /* ... and is a regular file */
 g_assert((st.st_mode & S_IFMT) == S_IFREG);
 
 tunlinkat({ .client = v9p, .atPath = "04", .name = "doa_file" });
 /* file should be gone now */
-g_assert(stat(new_file, &st) != 0);
+g_assert(stat(new_file_path, &st) != 0);
 }
 
 static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc)
@@ -594,13 +594,13 @@ static void fs_symlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *real_file = virtio_9p_test_path("05/real_file");
-g_autofree char *symlink_file = virtio_9p_test_path("05/symlink_file");
+g_autofree char *real_file_path = virtio_9p_test_path("05/real_file");
+g_autofree char *symlink_file_path = 
virtio_9p_test_path("05/symlink_file");
 
 tattach({ .client = v9p });
 tmkdir({ .client = v9p, .atPath = "/", .name = "05" });
 tlcreate({ .client = v9p, .atPath = "05", .name = "real_file" });
-g_assert(stat(real_file, &st) == 0);
+g_assert(stat(real_file_path, &st) == 0);
 g_assert((st.st_mode & S_IF

[PATCH for-9.0 v2 6/7] qtest/virtio-9p-test.c: consolidate hardlink tests

[Daniel Henrique Barboza]

We've consolidated all local 9p tests but the hardlink ones. To make
fs_unlinkat_hardlink() to act exactly like fs_hardlink_file() we added
the g_assert(st_link...) checks in fs_unlinkat_hardlink() as well.

After that:

- remove fs_hardlink_file(). Rename fs_unlinkat_hardlink() to
  fs_create_unlinkat_hardlink();

- remove the created dir and 'real_file' at the end of
  fs_create_unlinkat_hardlink().

After this patch all local 9p tests are now cleaning themselves up after
execution and we shouldn't experience errors like the one reported in
[1].

[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html

Reported-by: Thomas Huth 
Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 52 +++-
 1 file changed, 16 insertions(+), 36 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 222d11037d..f85f4ef407 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -614,12 +614,14 @@ static void fs_create_unlinkat_symlink(void *obj, void 
*data,
 g_assert(stat(new_dir_path, &st) != 0);
 }
 
-static void fs_hardlink_file(void *obj, void *data, QGuestAllocator *t_alloc)
+static void fs_create_unlinkat_hardlink(void *obj, void *data,
+QGuestAllocator *t_alloc)
 {
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
-struct stat st_real, st_link;
+struct stat st_real, st_link, st;
 const char *new_dir = "04";
+g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *hardlink_file = NULL;
@@ -648,43 +650,22 @@ static void fs_hardlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 g_assert((st_link.st_mode & S_IFMT) == S_IFREG);
 g_assert(st_link.st_dev == st_real.st_dev);
 g_assert(st_link.st_ino == st_real.st_ino);
-}
-
-static void fs_unlinkat_hardlink(void *obj, void *data,
- QGuestAllocator *t_alloc)
-{
-QVirtio9P *v9p = obj;
-v9fs_set_allocator(t_alloc);
-struct stat st_real, st_link;
-const char *new_dir = "05";
-g_autofree char *real_file = NULL;
-g_autofree char *real_file_path = NULL;
-g_autofree char *hardlink_file = NULL;
-g_autofree char *hardlink_file_path = NULL;
-
-real_file = g_strdup_printf("%s/%s", new_dir, "real_file");
-real_file_path = virtio_9p_test_path(real_file);
-
-hardlink_file = g_strdup_printf("%s/%s", new_dir, "hardlink_file");
-hardlink_file_path = virtio_9p_test_path(hardlink_file);
-
-tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
-tlcreate({ .client = v9p, .atPath = new_dir, .name = "real_file" });
-g_assert(stat(real_file_path, &st_real) == 0);
-g_assert((st_real.st_mode & S_IFMT) == S_IFREG);
-
-tlink({
-.client = v9p, .atPath = new_dir, .name = "hardlink_file",
-.toPath = real_file
-});
-g_assert(stat(hardlink_file_path, &st_link) == 0);
 
 tunlinkat({ .client = v9p, .atPath = new_dir, .name = "hardlink_file" });
 /* symlink should be gone now */
 g_assert(stat(hardlink_file_path, &st_link) != 0);
 /* and old file should still exist */
 g_assert(stat(real_file_path, &st_real) == 0);
+
+/* cleanup: remove created file and dir */
+tunlinkat({ .client = v9p, .atPath = new_dir, .name = "real_file" });
+g_assert(stat(real_file_path, &st_real) != 0);
+
+tunlinkat({
+.client = v9p, .atPath = "/", .name = new_dir,
+.flags = P9_DOTL_AT_REMOVEDIR
+});
+g_assert(stat(new_dir_path, &st) != 0);
 }
 
 static void *assign_9p_local_driver(GString *cmd_line, void *arg)
@@ -746,9 +727,8 @@ static void register_virtio_9p_test(void)
  fs_create_unlinkat_file, &opts);
 qos_add_test("local/create_unlinkat_symlink", "virtio-9p",
  fs_create_unlinkat_symlink, &opts);
-qos_add_test("local/hardlink_file", "virtio-9p", fs_hardlink_file, &opts);
-qos_add_test("local/unlinkat_hardlink", "virtio-9p", fs_unlinkat_hardlink,
- &opts);
+qos_add_test("local/create_unlinkat_hardlink", "virtio-9p",
+ fs_create_unlinkat_hardlink, &opts);
 }
 
 libqos_init(register_virtio_9p_test);
-- 
2.44.0

[PATCH for-9.0 v2 3/7] qtest/virtio-9p-test.c: consolidate create dir tests

[Daniel Henrique Barboza]

The local 9p driver in virtio-9p-test.c its temporary dir right at the
start of qos-test (via virtio_9p_create_local_test_dir()) and only
deletes it after qos-test is finished (via
virtio_9p_remove_local_test_dir()).

This means that any qos-test machine that ends up running virtio-9p-test
local tests more than once will end up re-using the same temp dir. This
is what's happening in [1] after we introduced the riscv machine nodes:
if we enable slow tests with the '-m slow' flag using
qemu-system-riscv64, this is what happens:

- a temp dir is created;

- virtio-9p-device tests will run virtio-9p-test successfully;

- virtio-9p-pci tests will run virtio-9p-test, and fail right at the
  first slow test at fs_create_dir() because the "01" file was already
  created by fs_create_dir() test when running with the virtio-9p-device.

We can fix it by making every test clean up their changes in the
filesystem after they're done. But we don't need every test either: what
fs_create_file() does is already exercised in fs_unlinkat_dir(), i.e. a
dir is created, verified to be created, and then removed.  Fixing
fs_create_file() would turn it into fs_unlinkat_dir(), so we don't need
both.

The same idea applies to every test in virtio-9p-test.c, where the
'unlinkat' variant does the same thing the 'create' does but with some
cleaning in the end. But we'll start with fs_create_dir() and
fs_unlinkat_dir() only:

- fs_create_dir() is removed. s_unlinkat_dir() is renamed to
  fs_create_unlinkat_dir();

- update the dir names for every other test since we have 1 less test.

[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html

Reported-by: Thomas Huth 
Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 39 +---
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index be031abc17..2cea1b4189 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -506,7 +506,8 @@ static void fs_readdir_split_512(void *obj, void *data,
 
 /* tests using the 9pfs 'local' fs driver */
 
-static void fs_create_dir(void *obj, void *data, QGuestAllocator *t_alloc)
+static void fs_create_unlinkat_dir(void *obj, void *data,
+   QGuestAllocator *t_alloc)
 {
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
@@ -524,26 +525,6 @@ static void fs_create_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 g_assert(stat(new_dir_path, &st) == 0);
 /* ... and is actually a directory */
 g_assert((st.st_mode & S_IFMT) == S_IFDIR);
-}
-
-static void fs_unlinkat_dir(void *obj, void *data, QGuestAllocator *t_alloc)
-{
-QVirtio9P *v9p = obj;
-v9fs_set_allocator(t_alloc);
-struct stat st;
-const char *new_dir = "02";
-g_autofree char *root_path = virtio_9p_test_path("");
-g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
-
-g_assert(root_path != NULL);
-
-tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
-
-/* check if created directory really exists now ... */
-g_assert(stat(new_dir_path, &st) == 0);
-/* ... and is actually a directory */
-g_assert((st.st_mode & S_IFMT) == S_IFDIR);
 
 tunlinkat({
 .client = v9p, .atPath = "/", .name = new_dir,
@@ -558,7 +539,7 @@ static void fs_create_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "03";
+const char *new_dir = "02";
 g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "1st_file");
 g_autofree char *new_file_path = virtio_9p_test_path(new_file);
 
@@ -577,7 +558,7 @@ static void fs_unlinkat_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "04";
+const char *new_dir = "03";
 g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "doa_file");
 g_autofree char *new_file_path = virtio_9p_test_path(new_file);
 
@@ -600,7 +581,7 @@ static void fs_symlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "05";
+const char *new_dir = "04";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *symlink_file = NULL;
@@ -633,7 +614,7 @@ static void fs_unlinkat_symlink(void *obj, void *data,
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-const char *new_dir = "06";
+const char *new_dir = "05";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *symlink_file = NULL;
@@ -667,7 +648,7 @@ static void fs_hardlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Cindy Lu]

On Wed, Mar 27, 2024 at 5:12 PM Jason Wang  wrote:
>
> On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu  wrote:
> >
> > On Wed, Mar 27, 2024 at 3:54 PM Jason Wang  wrote:
> > >
> > > On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
> > > >
> > > > On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  wrote:
> > > > >
> > > > > Hi Cindy:
> > > > >
> > > > > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > > > > >
> > > > > > we need a crash in Non-standard image, here is the jira for this 
> > > > > > https://issues.redhat.com/browse/RHEL-28522
> > > > > > The root cause of the issue is that an IRQFD was used without 
> > > > > > initialization..
> > > > > >
> > > > > > During the booting process of the Vyatta image, the behavior of the 
> > > > > > called function in qemu is as follows:
> > > > > >
> > > > > > 1. vhost_net_stop() was called, this will call the function
> > > > > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > > > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> > > > >
> > > > > Before vhost_net_stop(), do we know which vector is used by which 
> > > > > queue?
> > > > >
> > > > before this stop, vdev->config_verctor is get from
> > > > virtio_pci_common_read/virtio_pci_common_write
> > > > it was set to vector 0
> > >
> > > I basically meant if vector 0 is shared with some virtqueues here.
> > >
> > Really sorry for this, vq's vector is 1,2, and will not share with the
> > configure vector
> > > > > >
> > > > > > 2. virtio_reset() was called -->set configure vector to 
> > > > > > VIRTIO_NO_VECTORt
> > > > > >
> > > > > > 3.vhost_net_start() was called (at this time the configure vector is
> > > > > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() 
> > > > > > with
> > > > > > assgin= true, so the irqfd for vector 0 was not "init" during this 
> > > > > > process
> > > > >
> > > > > How does the configure vector differ from the virtqueue vector here?
> > > > >
> > > > All the vectors are VIRTIO_NO_VECTOR (including vq). any
> > > > msix_fire_vector_notifier()
> > > > been called will cause the crash at this time.
> > >
> > > Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
> > > the assignment is true?
> > >
> > It will allocate, but  the vector is VIRTIO_NO_VECTOR (0x)
> >
> > then it will called kvm_virtio_pci_vector_use_one()
> >
> > in this function, there is a check for
> >
> > if (vector >= msix_nr_vectors_allocated(dev))
> >
> > { return 0; }
> >
> > So it will return.
>
> How about let's just fix this?
>
> Btw, it's better to explain in detail like the above in the next version.
>
> Thanks
>
The problem is I think the behavior here is correct, The vector here is
 VIRTIO_NO_VECTOR and we should return,
the fix could work maybe is we try get to know if this was changed
from another value
and use that one? this seems strange.
Thanks
cindy
> >
> > > > So I think this should
> > > > be a bug in this guest image
> > >
> > > The point is Qemu should not crash even if the guest driver is buggy.
> > >
> > > It would be nice if we can have a qtest for this on top.
> > >
> > > Thanks
> > >
> > sure, got it, I have done the Qtest, and it passed
> > here is the result
> >
> > Ok: 794
> > Expected Fail:  0
> > Fail:   0
> > Unexpected Pass:0
> > Skipped:32
> > Timeout:0
> >
> > > > > >
> > > > > > 4. The system continues to boot and msix_fire_vector_notifier() was
> > > > > > called unmask the vector 0 and then met the crash
> > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > > > > >
> > > > > > The reason for not reproducing in RHEL/fedora guest image is because
> > > > > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop and 
> > > > > > then virtio_reset, and also won't call msix_fire_vector_notifier 
> > > > > > for vector 0 during system boot.
> > > > > >
> > > > > > The reason for not reproducing before configure interrupt support 
> > > > > > is because
> > > > > > vector 0 is for configure interrupt,  before the support for 
> > > > > > configure interrupts, the notifier process will not handle vector 0.
> > > > > >
> > > > > > For the device Vyatta using, it doesn't support configure 
> > > > > > interrupts at all, So we plan to disable the configure interrupts 
> > > > > > in unsupported device
> > > > >
> > > > > Btw, let's tweak the changelog, it's a little bit hard to understand.
> > > > >
> > > > sure will do
> > > > thanks
> > > > Cindy
> > > > > Thanks
> > > > >
> > > > > >
> > > > > > Signed-off-by: Cindy Lu 
> > > > > >
> > > > > > Cindy Lu (2):
> > > > > >   virtio-net: disable the configure interrupt for not support device
> > > > > >   virtio-pci: check if the configure interrupt enable
> > > > > >
> > > > > >  hw/net/virtio-net.c|  5 -
> > > > > >  hw/virtio/virtio-pci.c | 41 
> > > > > > +

[PATCH for-9.0 v2 7/7] qtest/virtio-9p-test.c: remove g_test_slow() gate

[Daniel Henrique Barboza]

Commit 558f5c42ef gated the local tests with g_test_slow() to skip them
in 'make check'. The reported issue back then was this following CI
problem:

https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html

This problem ended up being fixed when the recently added risc-v machine
nodes faced the same issue [1]. We're now able to run these tests with
'make check' in the CI.

This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824.

[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html

Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index f85f4ef407..8d8a7578b7 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -710,15 +710,6 @@ static void register_virtio_9p_test(void)
 
 
 /* 9pfs test cases using the 'local' filesystem driver */
-
-/*
- * XXX: Until we are sure that these tests can run everywhere,
- * keep them as "slow" so that they aren't run with "make check".
- */
-if (!g_test_slow()) {
-return;
-}
-
 opts.before = assign_9p_local_driver;
 qos_add_test("local/config", "virtio-9p", pci_config,  &opts);
 qos_add_test("local/create_unlinkat_dir", "virtio-9p",
-- 
2.44.0

[PATCH for-9.0 v2 2/7] qtest/virtio-9p-test.c: parametrize 'dir' name in local tests

[Daniel Henrique Barboza]

All local 9p tests creates a different dir inside tempdir, where '01' is
the dir for the first test, '02' the dir fot the second test and so on.

We want to make tests autoclean themselves while also consolidating
them in fewer tests, but this will incur a lot of dir changes that will
be unpleasant to deal with at it is today - the dir name is hard coded
in every 9p API call.

Add a 'new_dir' var in each test that will hold the created dir name. If
the test also creates new files/symlinks, parametrize them as well since
they also use the dir name.

After these changes, changing the val of "new_dir" will change all dir
references the test uses.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 108 +++
 1 file changed, 72 insertions(+), 36 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 23edca05c5..be031abc17 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -511,13 +511,14 @@ static void fs_create_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
+const char *new_dir = "01";
 g_autofree char *root_path = virtio_9p_test_path("");
-g_autofree char *new_dir_path = virtio_9p_test_path("01");
+g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
 
 g_assert(root_path != NULL);
 
 tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = "01" });
+tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
 
 /* check if created directory really exists now ... */
 g_assert(stat(new_dir_path, &st) == 0);
@@ -530,13 +531,14 @@ static void fs_unlinkat_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
+const char *new_dir = "02";
 g_autofree char *root_path = virtio_9p_test_path("");
-g_autofree char *new_dir_path = virtio_9p_test_path("02");
+g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
 
 g_assert(root_path != NULL);
 
 tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = "02" });
+tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
 
 /* check if created directory really exists now ... */
 g_assert(stat(new_dir_path, &st) == 0);
@@ -544,7 +546,7 @@ static void fs_unlinkat_dir(void *obj, void *data, 
QGuestAllocator *t_alloc)
 g_assert((st.st_mode & S_IFMT) == S_IFDIR);
 
 tunlinkat({
-.client = v9p, .atPath = "/", .name = "02",
+.client = v9p, .atPath = "/", .name = new_dir,
 .flags = P9_DOTL_AT_REMOVEDIR
 });
 /* directory should be gone now */
@@ -556,11 +558,13 @@ static void fs_create_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *new_file_path = virtio_9p_test_path("03/1st_file");
+const char *new_dir = "03";
+g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "1st_file");
+g_autofree char *new_file_path = virtio_9p_test_path(new_file);
 
 tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = "03" });
-tlcreate({ .client = v9p, .atPath = "03", .name = "1st_file" });
+tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
+tlcreate({ .client = v9p, .atPath = new_dir, .name = "1st_file" });
 
 /* check if created file exists now ... */
 g_assert(stat(new_file_path, &st) == 0);
@@ -573,18 +577,20 @@ static void fs_unlinkat_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *new_file_path = virtio_9p_test_path("04/doa_file");
+const char *new_dir = "04";
+g_autofree char *new_file = g_strdup_printf("%s/%s", new_dir, "doa_file");
+g_autofree char *new_file_path = virtio_9p_test_path(new_file);
 
 tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = "04" });
-tlcreate({ .client = v9p, .atPath = "04", .name = "doa_file" });
+tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
+tlcreate({ .client = v9p, .atPath = new_dir, .name = "doa_file" });
 
 /* check if created file exists now ... */
 g_assert(stat(new_file_path, &st) == 0);
 /* ... and is a regular file */
 g_assert((st.st_mode & S_IFMT) == S_IFREG);
 
-tunlinkat({ .client = v9p, .atPath = "04", .name = "doa_file" });
+tunlinkat({ .client = v9p, .atPath = new_dir, .name = "doa_file" });
 /* file should be gone now */
 g_assert(stat(new_file_path, &st) != 0);
 }
@@ -594,17 +600,26 @@ static void fs_symlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
-g_autofree char *real_file_path = virtio_9p_

[PATCH for-9.0 v2 0/7] qtest/virtio-9p-test.c: fix slow tests

[Daniel Henrique Barboza]

Hi,

In this new version I added a handful of patches to make it easier to
review, as suggested by Greg in v1.

Thomas, the changes made aren't negligible so I didn't add your
Tested-by. You're more than welcome to give this version a try :)

The first 2 patches are needed to ease the burden of individual test
changes. It was really annoying to deal with changing the dir name every
time a test was being removed. Parametrizing the dir name (and anything
that has the dir in it) makes it trivial to change the dir name when
needed.

I kept the slow revert patch (7) because this series is passing the Gitlab
CI with it:

https://gitlab.com/danielhb/qemu/-/pipelines/1228813691

I'll leave to the 9p maintainers to decide whether we should go ahead with
it or not. 

Changes from v1:
- patches 1 and 2 from v1: dropped
- patches 1 and 2 (new):
  - parametrize 'new_dir' name
- patches 3, 4, 5, 6 (new):
  - individual test consolidation
- v1 link: https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg06146.html

Daniel Henrique Barboza (7):
  qtest/virtio-9p-test.c: add '_path' in path vars
  qtest/virtio-9p-test.c: parametrize 'dir' name in local tests
  qtest/virtio-9p-test.c: consolidate create dir tests
  qtest/virtio-9p-test.c: consolidate create file tests
  qtest/virtio-9p-test.c: consolidate create symlink tests
  qtest/virtio-9p-test.c: consolidate hardlink tests
  qtest/virtio-9p-test.c: remove g_test_slow() gate

 tests/qtest/virtio-9p-test.c | 228 +++
 1 file changed, 96 insertions(+), 132 deletions(-)

-- 
2.44.0

[PATCH for-9.0 v2 5/7] qtest/virtio-9p-test.c: consolidate create symlink tests

[Daniel Henrique Barboza]

fs_unlinkat_symlink() does the same thing as fs_symlink_file() while
also removing the created symlink. We also want every test to not leave
stuff behind after each run to avoid subsequential runs to fail.

We can achieve all that by:

- remove fs_unlinkat_symlink(). fs_unlinkat_symlink() is now named
  fs_create_unlinkat_symlink();

- remove 'real_file' and the created dir at the end of
  fs_create_unlinkat_symlink().

The hardlink tests dir names were updated because now we have one less
test.

Reported-by: Thomas Huth 
Signed-off-by: Daniel Henrique Barboza 
---
 tests/qtest/virtio-9p-test.c | 54 
 1 file changed, 17 insertions(+), 37 deletions(-)

diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 75d4d1cf4b..222d11037d 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -566,12 +566,14 @@ static void fs_create_unlinkat_file(void *obj, void *data,
 g_assert(stat(new_dir_path, &st) != 0);
 }
 
-static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc)
+static void fs_create_unlinkat_symlink(void *obj, void *data,
+   QGuestAllocator *t_alloc)
 {
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st;
 const char *new_dir = "03";
+g_autofree char *new_dir_path = virtio_9p_test_path(new_dir);
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *symlink_file = NULL;
@@ -596,41 +598,20 @@ static void fs_symlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 
 /* check if created link exists now */
 g_assert(stat(symlink_file_path, &st) == 0);
-}
-
-static void fs_unlinkat_symlink(void *obj, void *data,
-QGuestAllocator *t_alloc)
-{
-QVirtio9P *v9p = obj;
-v9fs_set_allocator(t_alloc);
-struct stat st;
-const char *new_dir = "04";
-g_autofree char *real_file = NULL;
-g_autofree char *real_file_path = NULL;
-g_autofree char *symlink_file = NULL;
-g_autofree char *symlink_file_path = NULL;
-
-real_file = g_strdup_printf("%s/%s", new_dir, "real_file");
-real_file_path = virtio_9p_test_path(real_file);
-
-symlink_file = g_strdup_printf("%s/%s", new_dir, "symlink_file");
-symlink_file_path = virtio_9p_test_path(symlink_file);
-
-tattach({ .client = v9p });
-tmkdir({ .client = v9p, .atPath = "/", .name = new_dir });
-tlcreate({ .client = v9p, .atPath = new_dir, .name = "real_file" });
-g_assert(stat(real_file_path, &st) == 0);
-g_assert((st.st_mode & S_IFMT) == S_IFREG);
-
-tsymlink({
-.client = v9p, .atPath = new_dir, .name = "symlink_file",
-.symtgt = "real_file"
-});
-g_assert(stat(symlink_file_path, &st) == 0);
 
 tunlinkat({ .client = v9p, .atPath = new_dir, .name = "symlink_file" });
 /* symlink should be gone now */
 g_assert(stat(symlink_file_path, &st) != 0);
+
+/* cleanup: remove created file and dir */
+tunlinkat({ .client = v9p, .atPath = new_dir, .name = "real_file" });
+g_assert(stat(real_file_path, &st) != 0);
+
+tunlinkat({
+.client = v9p, .atPath = "/", .name = new_dir,
+.flags = P9_DOTL_AT_REMOVEDIR
+});
+g_assert(stat(new_dir_path, &st) != 0);
 }
 
 static void fs_hardlink_file(void *obj, void *data, QGuestAllocator *t_alloc)
@@ -638,7 +619,7 @@ static void fs_hardlink_file(void *obj, void *data, 
QGuestAllocator *t_alloc)
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st_real, st_link;
-const char *new_dir = "05";
+const char *new_dir = "04";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *hardlink_file = NULL;
@@ -675,7 +656,7 @@ static void fs_unlinkat_hardlink(void *obj, void *data,
 QVirtio9P *v9p = obj;
 v9fs_set_allocator(t_alloc);
 struct stat st_real, st_link;
-const char *new_dir = "06";
+const char *new_dir = "05";
 g_autofree char *real_file = NULL;
 g_autofree char *real_file_path = NULL;
 g_autofree char *hardlink_file = NULL;
@@ -763,9 +744,8 @@ static void register_virtio_9p_test(void)
  fs_create_unlinkat_dir, &opts);
 qos_add_test("local/create_unlinkat_file", "virtio-9p",
  fs_create_unlinkat_file, &opts);
-qos_add_test("local/symlink_file", "virtio-9p", fs_symlink_file, &opts);
-qos_add_test("local/unlinkat_symlink", "virtio-9p", fs_unlinkat_symlink,
- &opts);
+qos_add_test("local/create_unlinkat_symlink", "virtio-9p",
+ fs_create_unlinkat_symlink, &opts);
 qos_add_test("local/hardlink_file", "virtio-9p", fs_hardlink_file, &opts);
 qos_add_test("local/unlinkat_hardlink", "virtio-9p", fs_unlinkat_hardlink,
  &opts);
-- 
2.44.0

Re: [PATCH-for-9.1 17/18] target/i386: Remove X86CPU::kvm_no_smi_migration field

[Philippe Mathieu-Daudé]

On 6/3/24 19:30, Thomas Huth wrote:

On 05/03/2024 14.42, Philippe Mathieu-Daudé wrote:

X86CPU::kvm_no_smi_migration was only used by the
pc-i440fx-2.3 machine, which got removed. Remove it
and simplify kvm_put_vcpu_events().

Signed-off-by: Philippe Mathieu-Daudé 
---
  target/i386/cpu.h | 3 ---
  target/i386/cpu.c | 2 --
  target/i386/kvm/kvm.c | 6 --
  3 files changed, 11 deletions(-)




diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 42970ab046..571cbbf1fc 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4344,12 +4344,6 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int 
level)

  events.smi.pending = 0;
  events.smi.latched_init = 0;
  }
-    /* Stop SMI delivery on old machine types to avoid a reboot
- * on an inward migration of an old VM.
- */
-    if (!cpu->kvm_no_smi_migration) {
-    events.flags |= KVM_VCPUEVENT_VALID_SMM;
-    }


Shouldn't it be the other way round, i.e. that the flag is now always set?


Oops you are right, good catch!



pc_compat_2_3[] had:

     { TYPE_X86_CPU, "kvm-no-smi-migration", "on" },

... so I think kvm_no_smi_migration was set to true for the old machines?

  Thomas

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Daniel Henrique Barboza]

On 3/27/24 05:47, Christian Schoenebeck wrote:

On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:

On 3/26/24 14:05, Greg Kurz wrote:

On Tue, 26 Mar 2024 10:26:04 -0300
Daniel Henrique Barboza  wrote:


The local 9p driver in virtio-9p-test.c its temporary dir right at the
start of qos-test (via virtio_9p_create_local_test_dir()) and only
deletes it after qos-test is finished (via
virtio_9p_remove_local_test_dir()).

This means that any qos-test machine that ends up running virtio-9p-test local
tests more than once will end up re-using the same temp dir. This is
what's happening in [1] after we introduced the riscv machine nodes: if
we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
this is what happens:

- a temp dir is created, e.g. qtest-9p-local-WZLDL2;

- virtio-9p-device tests will run virtio-9p-test successfully;

- virtio-9p-pci tests will run virtio-9p-test, and fail right at the
first slow test at fs_create_dir() because the "01" file was already
created by fs_create_dir() test when running with the virtio-9p-device.

We can fix it by making every test clean up their changes in the
filesystem after they're done. But we don't need every test either:
what fs_create_file() does is already exercised in fs_unlinkat_dir(),
i.e. a dir is created, verified to be created, and then removed. Fixing
fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
both. The same theme follows every test in virtio-9p-test.c, where the
'unlikat' variant does the same thing the 'create' does but with some
cleaning in the end.

Consolide some tests as follows:

- fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
fs_create_unlinkat_dir();

- fs_create_file() is removed. fs_unlinkat_file() is renamed to
fs_create_unlinkat_file(). The "04" dir it uses is now being removed;

- fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
creates is now being removed.



The  change looks good functionally but it breaks the legitimate assumption
that files "06/*" come from test #6 and so on... I think you should consider
renumbering to avoid confusion when debugging logs.

Since this will bring more hunks, please split this in enough reviewable
patches.


Fair enough. Let me cook a v2. Thanks,


Wouldn't it be much simpler to just change the name of the temporary
directory, such that it contains the device name as well? Then these tests
runs would run on independent directories and won't interfere with each other
and that wouldn't need much changes I guess.


That's true. If we were just trying to fix the issue then I would go with this
approach since it's simpler. But given that we're also cutting half the tests 
while
retaining the coverage I think this approach is worth the extra code.


Thanks,


Daniel





/Christian

Re: [RFC 0/2] disable the configuration interrupt for the unsupported device

[Cindy Lu]

On Wed, Mar 27, 2024 at 5:13 PM Jason Wang  wrote:
>
> On Wed, Mar 27, 2024 at 5:12 PM Jason Wang  wrote:
> >
> > On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu  wrote:
> > >
> > > On Wed, Mar 27, 2024 at 3:54 PM Jason Wang  wrote:
> > > >
> > > > On Wed, Mar 27, 2024 at 2:03 PM Cindy Lu  wrote:
> > > > >
> > > > > On Wed, Mar 27, 2024 at 11:05 AM Jason Wang  
> > > > > wrote:
> > > > > >
> > > > > > Hi Cindy:
> > > > > >
> > > > > > On Wed, Mar 27, 2024 at 9:29 AM Cindy Lu  wrote:
> > > > > > >
> > > > > > > we need a crash in Non-standard image, here is the jira for this 
> > > > > > > https://issues.redhat.com/browse/RHEL-28522
> > > > > > > The root cause of the issue is that an IRQFD was used without 
> > > > > > > initialization..
> > > > > > >
> > > > > > > During the booting process of the Vyatta image, the behavior of 
> > > > > > > the called function in qemu is as follows:
> > > > > > >
> > > > > > > 1. vhost_net_stop() was called, this will call the function
> > > > > > > virtio_pci_set_guest_notifiers() with assgin= false, and
> > > > > > > virtio_pci_set_guest_notifiers(） will release the irqfd for 
> > > > > > > vector 0
> > > > > >
> > > > > > Before vhost_net_stop(), do we know which vector is used by which 
> > > > > > queue?
> > > > > >
> > > > > before this stop, vdev->config_verctor is get from
> > > > > virtio_pci_common_read/virtio_pci_common_write
> > > > > it was set to vector 0
> > > >
> > > > I basically meant if vector 0 is shared with some virtqueues here.
> > > >
> > > Really sorry for this, vq's vector is 1,2, and will not share with the
> > > configure vector
> > > > > > >
> > > > > > > 2. virtio_reset() was called -->set configure vector to 
> > > > > > > VIRTIO_NO_VECTORt
> > > > > > >
> > > > > > > 3.vhost_net_start() was called (at this time the configure vector 
> > > > > > > is
> > > > > > > still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() 
> > > > > > > with
> > > > > > > assgin= true, so the irqfd for vector 0 was not "init" during 
> > > > > > > this process
> > > > > >
> > > > > > How does the configure vector differ from the virtqueue vector here?
> > > > > >
> > > > > All the vectors are VIRTIO_NO_VECTOR (including vq). any
> > > > > msix_fire_vector_notifier()
> > > > > been called will cause the crash at this time.
> > > >
> > > > Won't virtio_pci_set_guest_notifiers() will try to allocate irqfd when
> > > > the assignment is true?
> > > >
> > > It will allocate, but  the vector is VIRTIO_NO_VECTOR (0x)
> > >
> > > then it will called kvm_virtio_pci_vector_use_one()
> > >
> > > in this function, there is a check for
> > >
> > > if (vector >= msix_nr_vectors_allocated(dev))
> > >
> > > { return 0; }
> > >
> > > So it will return.
> >
> > How about let's just fix this?
>
> Btw, another question, how does vDPA work here?
>
> Thanks
>
the rhel/fedroa guest image will not call  vrtio_stop and virtio_reset
during the boot
So vector will not change to  VIRTIO_NO_VECTOR. So the vdpa's
configure interrupt
Should work ok and there is no crash
Thanks
cindy

> >
> > Btw, it's better to explain in detail like the above in the next version.
> >
> > Thanks
> >
> > >
> > > > > So I think this should
> > > > > be a bug in this guest image
> > > >
> > > > The point is Qemu should not crash even if the guest driver is buggy.
> > > >
> > > > It would be nice if we can have a qtest for this on top.
> > > >
> > > > Thanks
> > > >
> > > sure, got it, I have done the Qtest, and it passed
> > > here is the result
> > >
> > > Ok: 794
> > > Expected Fail:  0
> > > Fail:   0
> > > Unexpected Pass:0
> > > Skipped:32
> > > Timeout:0
> > >
> > > > > > >
> > > > > > > 4. The system continues to boot and msix_fire_vector_notifier() 
> > > > > > > was
> > > > > > > called unmask the vector 0 and then met the crash
> > > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 1
> > > > > > > [msix_fire_vector_notifier] 112 called vector 0 is_masked 0
> > > > > > >
> > > > > > > The reason for not reproducing in RHEL/fedora guest image is 
> > > > > > > because
> > > > > > > REHL/Fedora doesn't have the behavior of calling vhost_net_stop 
> > > > > > > and then virtio_reset, and also won't call 
> > > > > > > msix_fire_vector_notifier for vector 0 during system boot.
> > > > > > >
> > > > > > > The reason for not reproducing before configure interrupt support 
> > > > > > > is because
> > > > > > > vector 0 is for configure interrupt,  before the support for 
> > > > > > > configure interrupts, the notifier process will not handle vector 
> > > > > > > 0.
> > > > > > >
> > > > > > > For the device Vyatta using, it doesn't support configure 
> > > > > > > interrupts at all, So we plan to disable the configure interrupts 
> > > > > > > in unsupported device
> > > > > >
> > > > > > Btw, let's tweak the changelog, it's a little bit hard to 
> > > > > > understand.
> > > > > >
> > > > > sure will do
> 

Re: [PATCH for-9.1 v2 04/11] vhost-user-server: don't abort if we can't set fd non-blocking

[Stefano Garzarella]

On Tue, Mar 26, 2024 at 09:40:12AM -0500, Eric Blake wrote:

On Tue, Mar 26, 2024 at 02:39:29PM +0100, Stefano Garzarella wrote:

In vhost-user-server we set all fd received from the other peer
in non-blocking mode. For some of them (e.g. memfd, shm_open, etc.)
if we fail, it's not really a problem, because we don't use these
fd with blocking operations, but only to map memory.

In these cases a failure is not bad, so let's just report a warning
instead of panicking if we fail to set some fd in non-blocking mode.

This for example occurs in macOS where setting shm_open() fd
non-blocking is failing (errno: 25).


What is errno 25 on MacOS?


It should be ENOTTY.
I'll add in the commit description.





Signed-off-by: Stefano Garzarella 
---
 util/vhost-user-server.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c
index 3bfb1ad3ec..064999f0b7 100644
--- a/util/vhost-user-server.c
+++ b/util/vhost-user-server.c
@@ -66,7 +66,11 @@ static void vmsg_unblock_fds(VhostUserMsg *vmsg)
 {
 int i;
 for (i = 0; i < vmsg->fd_num; i++) {
-qemu_socket_set_nonblock(vmsg->fds[i]);
+int ret = qemu_socket_try_set_nonblock(vmsg->fds[i]);
+if (ret) {


Should this be 'if (ret < 0)'?


I was confused by the assert() in qemu_socket_set_nonblock():
void qemu_socket_set_nonblock(int fd)
{
int f;
f = qemu_socket_try_set_nonblock(fd);
assert(f == 0);
}

BTW, I see most of the code checks ret < 0, so I'll fix it.




+warn_report("Failed to set fd %d nonblock for request %d: %s",
+vmsg->fds[i], vmsg->request, strerror(-ret));
+}


This now ignores all errors even on pre-existing fds where we NEED
non-blocking, rather than just the specific (expected) error we are
seeing on MacOS.  Should this code be a bit more precise about
checking that -ret == EXXX for the expected errno value we are
ignoring for the specific fds where non-blocking is not essential?


Good point, maybe I'll just avoid calling vmsg_unblock_fds() when the
message is VHOST_USER_ADD_MEM_REG or VHOST_USER_SET_MEM_TABLE.

These should be the cases where carried fds are used for mmap() and so
there is no need to mark them non-blocking.

WDYT?

Stefano

[PATCH-for-9.1 v2 00/21] hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines

[Philippe Mathieu-Daudé]

Missing review: 4-6, 10-12, 16, 19-20

Since v1:
- Addressed Zhao and Thomas review comments
- Removal around ICH9 acpi_memory_hotplug (Thomas)

Kill legacy code, because we need to evolve.

I ended there via dynamic machine -> ICH9 -> legacy ACPI...

This should also help Igor cleanups:
http://lore.kernel.org/qemu-devel/20240326171632.3cc75...@imammedo.users.ipa.redhat.com/

Philippe Mathieu-Daudé (21):
  hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine
  hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag
  hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag
  hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size
  hw/acpi/ich9: Remove 'memory-hotplug-support' property
  hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'
  hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine
  target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'
  hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded
  hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()
  hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()
  hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm
  hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()
  hw/mem/memory-device: Remove legacy_align from
memory_device_pre_plug()
  hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine
  hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob
  hw/i386/pc: Remove PCMachineClass::rsdp_in_ram
  hw/i386/acpi: Remove AcpiBuildState::rsdp field
  hw/i386/pc: Remove 2.3 and deprecate 2.4 to 2.7 pc-i440fx machines
  target/i386: Remove X86CPU::kvm_no_smi_migration field
  hw/i386/pc: Replace PCMachineClass::acpi_data_size by
PC_ACPI_DATA_SIZE

 docs/about/deprecated.rst |   2 +-
 docs/about/removed-features.rst   |   2 +-
 hw/usb/hcd-xhci.h |   4 +-
 include/hw/firmware/smbios.h  |   3 +-
 include/hw/i386/pc.h  |  22 --
 include/hw/mem/memory-device.h|   2 +-
 include/hw/mem/pc-dimm.h  |   3 +-
 target/i386/cpu.h |   3 -
 target/i386/kvm/kvm-cpu.h |  41 --
 hw/acpi/ich9.c|  46 ++-
 hw/arm/virt.c |   5 +-
 hw/i386/acpi-build.c  |  95 ++-
 hw/i386/fw_cfg.c  |   3 +-
 hw/i386/pc.c  | 107 --
 hw/i386/pc_piix.c | 101 
 hw/loongarch/virt.c   |   4 +-
 hw/mem/memory-device.c|  12 +--
 hw/mem/pc-dimm.c  |   6 +-
 hw/ppc/spapr.c|   2 +-
 hw/riscv/virt.c   |   2 +-
 hw/smbios/smbios.c|  13 +---
 hw/usb/hcd-xhci-nec.c |   4 -
 hw/usb/hcd-xhci-pci.c |   4 +-
 hw/usb/hcd-xhci.c |  42 ++
 hw/virtio/virtio-md-pci.c |   2 +-
 target/i386/cpu.c |   2 -
 target/i386/kvm/kvm-cpu.c |   3 +-
 target/i386/kvm/kvm.c |   7 +-
 tests/avocado/mem-addr-space-check.py |   3 +-
 29 files changed, 64 insertions(+), 481 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

-- 
2.41.0

[PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag

[Philippe Mathieu-Daudé]

XHCI_FLAG_FORCE_PCIE_ENDCAP was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it
and simplify usb_xhci_pci_realize().

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/usb/hcd-xhci.h | 1 -
 hw/usb/hcd-xhci-nec.c | 2 --
 hw/usb/hcd-xhci-pci.c | 3 +--
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 98f598382a..1efa4858fb 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -37,7 +37,6 @@ typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
 XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_FORCE_PCIE_ENDCAP,
 XHCI_FLAG_ENABLE_STREAMS,
 };
 
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 328e5bfe7c..5d5b069cf9 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -43,8 +43,6 @@ static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
 XHCI_FLAG_SS_FIRST, true),
-DEFINE_PROP_BIT("force-pcie-endcap", XHCINecState, flags,
-XHCI_FLAG_FORCE_PCIE_ENDCAP, false),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 4423983308..cbad96f393 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -148,8 +148,7 @@ static void usb_xhci_pci_realize(struct PCIDevice *dev, 
Error **errp)
  PCI_BASE_ADDRESS_MEM_TYPE_64,
  &s->xhci.mem);
 
-if (pci_bus_is_express(pci_get_bus(dev)) ||
-xhci_get_flag(&s->xhci, XHCI_FLAG_FORCE_PCIE_ENDCAP)) {
+if (pci_bus_is_express(pci_get_bus(dev))) {
 ret = pcie_endpoint_cap_init(dev, 0xa0);
 assert(ret > 0);
 }
-- 
2.41.0

[PATCH-for-9.1 v2 03/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag

[Philippe Mathieu-Daudé]

XHCI_FLAG_SS_FIRST was only used by the pc-i440fx-2.0 machine,
which got removed. Remove it and simplify various functions in
hcd-xhci.c.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/usb/hcd-xhci.h |  3 +--
 hw/usb/hcd-xhci-nec.c |  2 --
 hw/usb/hcd-xhci-pci.c |  1 -
 hw/usb/hcd-xhci.c | 42 --
 4 files changed, 9 insertions(+), 39 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 1efa4858fb..fe16d7ad05 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -36,8 +36,7 @@ typedef struct XHCIStreamContext XHCIStreamContext;
 typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
-XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_ENABLE_STREAMS,
+XHCI_FLAG_ENABLE_STREAMS = 1,
 };
 
 typedef enum TRBType {
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 5d5b069cf9..0c063b3697 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -41,8 +41,6 @@ struct XHCINecState {
 static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msi", XHCIPciState, msi, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
-DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
-XHCI_FLAG_SS_FIRST, true),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index cbad96f393..264d7ebb77 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -242,7 +242,6 @@ static void qemu_xhci_instance_init(Object *obj)
 s->msix = ON_OFF_AUTO_AUTO;
 xhci->numintrs = XHCI_MAXINTRS;
 xhci->numslots = XHCI_MAXSLOTS;
-xhci_set_flag(xhci, XHCI_FLAG_SS_FIRST);
 }
 
 static const TypeInfo qemu_xhci_info = {
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index ad40232eb6..b6411f0bda 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -541,18 +541,10 @@ static XHCIPort *xhci_lookup_port(XHCIState *xhci, struct 
USBPort *uport)
 case USB_SPEED_LOW:
 case USB_SPEED_FULL:
 case USB_SPEED_HIGH:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index + xhci->numports_3;
-} else {
-index = uport->index;
-}
+index = uport->index + xhci->numports_3;
 break;
 case USB_SPEED_SUPER:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index;
-} else {
-index = uport->index + xhci->numports_2;
-}
+index = uport->index;
 break;
 default:
 return NULL;
@@ -2779,11 +2771,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x28: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_2<<8) | (xhci->numports_3+1);
-} else {
-ret = (xhci->numports_2<<8) | 1;
-}
+ret = (xhci->numports_2 << 8) | (xhci->numports_3 + 1);
 break;
 case 0x2c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -2795,11 +2783,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x38: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_3<<8) | 1;
-} else {
-ret = (xhci->numports_3<<8) | (xhci->numports_2+1);
-}
+ret = (xhci->numports_3 << 8) | 1;
 break;
 case 0x3c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -3349,13 +,8 @@ static void usb_xhci_init(XHCIState *xhci)
 for (i = 0; i < usbports; i++) {
 speedmask = 0;
 if (i < xhci->numports_2) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = &xhci->ports[i + xhci->numports_3];
-port->portnr = i + 1 + xhci->numports_3;
-} else {
-port = &xhci->ports[i];
-port->portnr = i + 1;
-}
+port = &xhci->ports[i + xhci->numports_3];
+port->portnr = i + 1 + xhci->numports_3;
 port->uport = &xhci->uports[i];
 port->speedmask =
 USB_SPEED_MASK_LOW  |
@@ -3366,13 +3345,8 @@ static void usb_xhci_init(XHCIState *xhci)
 speedmask |= port->speedmask;
 }
 if (i < xhci->numports_3) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = &xhci->ports[i];
-port->portnr = i + 1;
-} else {
-port = &xhci->ports[i + xhci->numports_2];
-port->portnr = i + 1 + xhci->numports_2;
-}
+port = &xhc

[PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.0 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-2-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 15 -
 hw/i386/pc_piix.c   | 37 -
 5 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..b567415d62 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
+``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2)
 '
 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f9cf874f7b..51119e623f 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-1.7`` (removed in 4.0 up to 8.2)
+``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 27a68071d7..67856f54c3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -285,9 +285,6 @@ extern const size_t pc_compat_2_2_len;
 extern GlobalProperty pc_compat_2_1[];
 extern const size_t pc_compat_2_1_len;
 
-extern GlobalProperty pc_compat_2_0[];
-extern const size_t pc_compat_2_0_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e80f02bef4..e7b6abf237 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -311,21 +311,6 @@ GlobalProperty pc_compat_2_1[] = {
 };
 const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
 
-GlobalProperty pc_compat_2_0[] = {
-PC_CPU_MODEL_IDS("2.0.0")
-{ "virtio-scsi-pci", "any_layout", "off" },
-{ "PIIX4_PM", "memory-hotplug-support", "off" },
-{ "apic", "version", "0x11" },
-{ "nec-usb-xhci", "superspeed-ports-first", "off" },
-{ "nec-usb-xhci", "force-pcie-endcap", "on" },
-{ "pci-serial", "prog_if", "0" },
-{ "pci-serial-2x", "prog_if", "0" },
-{ "pci-serial-4x", "prog_if", "0" },
-{ "virtio-net-pci", "guest_announce", "off" },
-{ "ICH9-LPC", "memory-hotplug-support", "off" },
-};
-const size_t pc_compat_2_0_len = G_N_ELEMENTS(pc_compat_2_0);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..585231ef7b 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -441,11 +441,6 @@ static void pc_compat_2_1_fn(MachineState *machine)
 x86_cpu_change_kvm_default("svm", NULL);
 }
 
-static void pc_compat_2_0_fn(MachineState *machine)
-{
-pc_compat_2_1_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -872,38 +867,6 @@ static void pc_i440fx_2_1_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
   pc_i440fx_2_1_machine_options);
 
-static void pc_i440fx_2_0_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_1_machine_options(m);
-m->hw_version = "2.0.0";
-compat_props_add(m->compat_props, pc_compat_2_0, pc_compat_2_0_len);
-pcmc->smbios_legacy_mode = true;
-pcmc->has_reserved_memory = false;
-/* This value depends on the actual DSDT and SSDT compiled into
- * the source QEMU; unfortunately it depends on the binary and
- * not on the machine type, so we cannot make pc-i440fx-1.7 work on
- * both QEMU 1.7 and QEMU 2.0.
- *
- * Large variations cause migration to fail for more than one
- * consecutive value of the "-smp" maxcpus option.
- *
- * For small variations of the kind caused by different iasl versions,
- * the 4k rounding usually leaves slack.  However, there could be still
- * one or two values that break.  For QEMU 1.7 and QEMU 2.0 the
- * slack is only ~10 bytes before one "-smp maxcpus" value breaks!
- *
- * 6652 is valid for QEMU 2.0, the right value for pc-i440fx-1.7 on
- * QEMU

[PATCH-for-9.1 v2 06/21] hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'

[Philippe Mathieu-Daudé]

acpi_memory_hotplug::is_enabled is set to %true once via
ich9_lpc_initfn() -> ich9_pm_add_properties(). No need to
check it, so remove now dead code.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/acpi/ich9.c | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 9b605af21a..02d8546bd3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -153,17 +153,10 @@ static int ich9_pm_post_load(void *opaque, int version_id)
  .offset = vmstate_offset_pointer(_state, _field, uint8_t),  \
  }
 
-static bool vmstate_test_use_memhp(void *opaque)
-{
-ICH9LPCPMRegs *s = opaque;
-return s->acpi_memory_hotplug.is_enabled;
-}
-
 static const VMStateDescription vmstate_memhp_state = {
 .name = "ich9_pm/memhp",
 .version_id = 1,
 .minimum_version_id = 1,
-.needed = vmstate_test_use_memhp,
 .fields = (const VMStateField[]) {
 VMSTATE_MEMORY_HOTPLUG(acpi_memory_hotplug, ICH9LPCPMRegs),
 VMSTATE_END_OF_LIST()
@@ -335,11 +328,9 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm, 
qemu_irq sci_irq)
 legacy_acpi_cpu_hotplug_init(pci_address_space_io(lpc_pci),
 OBJECT(lpc_pci), &pm->gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
 
-if (pm->acpi_memory_hotplug.is_enabled) {
-acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), 
OBJECT(lpc_pci),
- &pm->acpi_memory_hotplug,
- ACPI_MEMORY_HOTPLUG_BASE);
-}
+acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
+ &pm->acpi_memory_hotplug,
+ ACPI_MEMORY_HOTPLUG_BASE);
 }
 
 static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, const char *name,
@@ -460,12 +451,7 @@ void ich9_pm_device_pre_plug_cb(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
-!lpc->pm.acpi_memory_hotplug.is_enabled) {
-error_setg(errp,
-   "memory hotplug is not enabled: %s.memory-hotplug-support "
-   "is not set", object_get_typename(OBJECT(lpc)));
-} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 uint64_t negotiated = lpc->smi_negotiated_features;
 
 if (negotiated & BIT_ULL(ICH9_LPC_SMI_F_BROADCAST_BIT) &&
@@ -509,8 +495,7 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_request_cb(hotplug_dev,
   &lpc->pm.acpi_memory_hotplug, dev,
   errp);
@@ -545,8 +530,7 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_cb(&lpc->pm.acpi_memory_hotplug, dev, errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!lpc->pm.cpu_hotplug_legacy) {
-- 
2.41.0

[PATCH-for-9.1 v2 05/21] hw/acpi/ich9: Remove 'memory-hotplug-support' property

[Philippe Mathieu-Daudé]

No external code sets the 'memory-hotplug-support'
property, remove it.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/acpi/ich9.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 573d032e8e..9b605af21a 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -351,21 +351,6 @@ static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, 
const char *name,
 visit_type_uint32(v, name, &value, errp);
 }
 
-static bool ich9_pm_get_memory_hotplug_support(Object *obj, Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-return s->pm.acpi_memory_hotplug.is_enabled;
-}
-
-static void ich9_pm_set_memory_hotplug_support(Object *obj, bool value,
-   Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-s->pm.acpi_memory_hotplug.is_enabled = value;
-}
-
 static bool ich9_pm_get_cpu_hotplug_legacy(Object *obj, Error **errp)
 {
 ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
@@ -445,9 +430,6 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs *pm)
 NULL, NULL, pm);
 object_property_add_uint32_ptr(obj, ACPI_PM_PROP_GPE0_BLK_LEN,
&gpe0_len, OBJ_PROP_FLAG_READ);
-object_property_add_bool(obj, "memory-hotplug-support",
- ich9_pm_get_memory_hotplug_support,
- ich9_pm_set_memory_hotplug_support);
 object_property_add_bool(obj, "cpu-hotplug-legacy",
  ich9_pm_get_cpu_hotplug_legacy,
  ich9_pm_set_cpu_hotplug_legacy);
-- 
2.41.0

[PATCH-for-9.1 v2 12/21] hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm

[Philippe Mathieu-Daudé]

PCMachineClass::enforce_aligned_dimm was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true. Remove it, simplifying pc_get_device_memory_range().
Update the comment in Avocado test_phybits_low_pse36().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h  |  3 ---
 hw/i386/pc.c  | 14 +++---
 tests/avocado/mem-addr-space-check.py |  3 +--
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index c2d9af36b2..231aae92ed 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,8 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @enforce_aligned_dimm: check that DIMM's address/size is aligned by
- *backend's alignment value if provided
  * @acpi_data_size: Size of the chunk of memory at the top of RAM
  *  for the BIOS ACPI tables and other BIOS
  *  datastructures.
@@ -114,7 +112,6 @@ struct PCMachineClass {
 /* RAM / address space compat: */
 bool gigabyte_align;
 bool has_reserved_memory;
-bool enforce_aligned_dimm;
 bool broken_reserved_end;
 bool enforce_amd_1tb_hole;
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f9650a2821..adbc43ab90 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -716,7 +716,6 @@ static void pc_get_device_memory_range(PCMachineState *pcms,
hwaddr *base,
ram_addr_t *device_mem_size)
 {
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 MachineState *machine = MACHINE(pcms);
 ram_addr_t size;
 hwaddr addr;
@@ -724,10 +723,8 @@ static void pc_get_device_memory_range(PCMachineState 
*pcms,
 size = machine->maxram_size - machine->ram_size;
 addr = ROUND_UP(pc_above_4g_end(pcms), 1 * GiB);
 
-if (pcmc->enforce_aligned_dimm) {
-/* size device region assuming 1G page max alignment per slot */
-size += (1 * GiB) * machine->ram_slots;
-}
+/* size device region assuming 1G page max alignment per slot */
+size += (1 * GiB) * machine->ram_slots;
 
 *base = addr;
 *device_mem_size = size;
@@ -1285,12 +1282,9 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq 
*i8259_irqs)
 static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
Error **errp)
 {
-const PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 const X86MachineState *x86ms = X86_MACHINE(hotplug_dev);
-const PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 const MachineState *ms = MACHINE(hotplug_dev);
 const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
-const uint64_t legacy_align = TARGET_PAGE_SIZE;
 Error *local_err = NULL;
 
 /*
@@ -1315,8 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev),
- pcmc->enforce_aligned_dimm ? NULL : &legacy_align, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
@@ -1778,7 +1771,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
  * to be used at the moment, 32K should be enough for a while.  */
diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
index af019969c0..ad75170d52 100644
--- a/tests/avocado/mem-addr-space-check.py
+++ b/tests/avocado/mem-addr-space-check.py
@@ -31,8 +31,7 @@ def test_phybits_low_pse36(self):
 at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
 we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
 hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
-for dimm alignment for all newer machines (see enforce_aligned_dimm
-property for pc machines and pc_get_device_memory_range()). That leaves
+for dimm alignment for all machines. That leaves
 total hotpluggable actual memory size of 59 GiB. If the VM is started
 with 0.5 GiB of memory, maxmem should be set to a maximum value of
 59.5 GiB to ensure that the processor can address all memory directly.
-- 
2.41.0

[PATCH-for-9.1 v2 13/21] hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()

[Philippe Mathieu-Daudé]

'legacy_align' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-11-phi...@linaro.org>
---
 include/hw/mem/pc-dimm.h | 3 +--
 hw/arm/virt.c| 2 +-
 hw/i386/pc.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/mem/pc-dimm.c | 6 ++
 hw/ppc/spapr.c   | 2 +-
 6 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 322bebe555..fe0f3ea963 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -66,8 +66,7 @@ struct PCDIMMDeviceClass {
 void (*unrealize)(PCDIMMDevice *dimm);
 };
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp);
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp);
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine);
 void pc_dimm_unplug(PCDIMMDevice *dimm, MachineState *machine);
 #endif
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a55ef916cb..7af05a6a2d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2736,7 +2736,7 @@ static void virt_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index adbc43ab90..baa1b228a9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1309,7 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 00d3005e54..af71bd2a99 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -1025,7 +1025,7 @@ static bool memhp_type_supported(DeviceState *dev)
 static void virt_mem_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
  Error **errp)
 {
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_machine_device_pre_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 37f1f4ccfd..836384a90f 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -44,8 +44,7 @@ static MemoryRegion *pc_dimm_get_memory_region(PCDIMMDevice 
*dimm, Error **errp)
 return host_memory_backend_get_memory(dimm->hostmem);
 }
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp)
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp)
 {
 Error *local_err = NULL;
 int slot;
@@ -70,8 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine,
 &error_abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, legacy_align,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index c417f9dd52..770b49456a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3667,7 +3667,7 @@ static void spapr_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), errp);
 }
 
 struct SpaprDimmState {
-- 
2.41.0

[PATCH-for-9.1 v2 04/21] hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size

[Philippe Mathieu-Daudé]

PCMachineClass::legacy_acpi_table_size was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it and simplify
acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 62 +---
 2 files changed, 12 insertions(+), 51 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 67856f54c3..4ad724601a 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -103,7 +103,6 @@ struct PCMachineClass {
 /* ACPI compat: */
 bool has_acpi_build;
 bool rsdp_in_ram;
-int legacy_acpi_table_size;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 53f804ac16..a6f8203460 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2499,13 +2499,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
-unsigned facs, dsdt, rsdt, fadt;
+unsigned facs, dsdt, rsdt;
 AcpiPmInfo pm;
 AcpiMiscInfo misc;
 AcpiMcfgInfo mcfg;
 Range pci_hole = {}, pci_hole64 = {};
 uint8_t *u;
-size_t aml_len = 0;
 GArray *tables_blob = tables->table_data;
 AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
 Object *vmgenid_dev;
@@ -2551,19 +2550,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 build_dsdt(tables_blob, tables->linker, &pm, &misc,
&pci_hole, &pci_hole64, machine);
 
-/* Count the size of the DSDT and SSDT, we will need it for legacy
- * sizing of ACPI tables.
- */
-aml_len += tables_blob->len - dsdt;
-
 /* ACPI tables pointed to by RSDT */
-fadt = tables_blob->len;
 acpi_add_table(table_offsets, tables_blob);
 pm.fadt.facs_tbl_offset = &facs;
 pm.fadt.dsdt_tbl_offset = &dsdt;
 pm.fadt.xdsdt_tbl_offset = &dsdt;
 build_fadt(tables_blob, tables->linker, &pm.fadt, oem_id, oem_table_id);
-aml_len += tables_blob->len - fadt;
 
 acpi_add_table(table_offsets, tables_blob);
 acpi_build_madt(tables_blob, tables->linker, x86ms,
@@ -2694,49 +2686,19 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * too simple to be enough.  4k turned out to be too small an
  * alignment very soon, and in fact it is almost impossible to
  * keep the table size stable for all (max_cpus, max_memory_slots)
- * combinations.  So the table size is always 64k for pc-i440fx-2.1
- * and we give an error if the table grows beyond that limit.
- *
- * We still have the problem of migrating from "-M pc-i440fx-2.0".  For
- * that, we exploit the fact that QEMU 2.1 generates _smaller_ tables
- * than 2.0 and we can always pad the smaller tables with zeros.  We can
- * then use the exact size of the 2.0 tables.
- *
- * All this is for PIIX4, since QEMU 2.0 didn't support Q35 migration.
+ * combinations.
  */
-if (pcmc->legacy_acpi_table_size) {
-/* Subtracting aml_len gives the size of fixed tables.  Then add the
- * size of the PIIX4 DSDT/SSDT in QEMU 2.0.
- */
-int legacy_aml_len =
-pcmc->legacy_acpi_table_size +
-ACPI_BUILD_LEGACY_CPU_AML_SIZE * x86ms->apic_id_limit;
-int legacy_table_size =
-ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
- ACPI_BUILD_ALIGN_SIZE);
-if ((tables_blob->len > legacy_table_size) &&
-!pcmc->resizable_acpi_blob) {
-/* Should happen only with PCI bridges and -M pc-i440fx-2.0.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, legacy_table_size);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-g_array_set_size(tables_blob, legacy_table_size);
-} else {
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots. 
 */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
+/* Make sure we have a buffer in case we need to resize the tables. */
+if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
+!pcmc->resizable_acpi_blob) {
+/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
+ 

[PATCH-for-9.1 v2 07/21] hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.1 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-7-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c|  7 ---
 hw/i386/pc_piix.c   | 23 ---
 5 files changed, 2 insertions(+), 35 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index b567415d62..deadcc044f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2)
+``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2)
 '
 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 51119e623f..01c55103d3 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4ad724601a..b528f17904 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -281,9 +281,6 @@ extern const size_t pc_compat_2_3_len;
 extern GlobalProperty pc_compat_2_2[];
 extern const size_t pc_compat_2_2_len;
 
-extern GlobalProperty pc_compat_2_1[];
-extern const size_t pc_compat_2_1_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e7b6abf237..21a19f9f9f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -304,13 +304,6 @@ GlobalProperty pc_compat_2_2[] = {
 };
 const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
 
-GlobalProperty pc_compat_2_1[] = {
-PC_CPU_MODEL_IDS("2.1.0")
-{ "coreduo" "-" TYPE_X86_CPU, "vmx", "on" },
-{ "core2duo" "-" TYPE_X86_CPU, "vmx", "on" },
-};
-const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 585231ef7b..02f3bce4f3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -66,7 +66,6 @@
 #include "hw/hyperv/vmbus-bridge.h"
 #include "hw/mem/nvdimm.h"
 #include "hw/i386/acpi-build.h"
-#include "kvm/kvm-cpu.h"
 #include "target/i386/cpu.h"
 
 #define XEN_IOAPIC_NUM_PIRQS 128ULL
@@ -435,12 +434,6 @@ static void pc_compat_2_2_fn(MachineState *machine)
 pc_compat_2_3_fn(machine);
 }
 
-static void pc_compat_2_1_fn(MachineState *machine)
-{
-pc_compat_2_2_fn(machine);
-x86_cpu_change_kvm_default("svm", NULL);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -851,22 +844,6 @@ static void pc_i440fx_2_2_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_2, "pc-i440fx-2.2", pc_compat_2_2_fn,
   pc_i440fx_2_2_machine_options);
 
-static void pc_i440fx_2_1_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_2_machine_options(m);
-m->hw_version = "2.1.0";
-m->default_display = NULL;
-compat_props_add(m->compat_props, hw_compat_2_1, hw_compat_2_1_len);
-compat_props_add(m->compat_props, pc_compat_2_1, pc_compat_2_1_len);
-pcmc->smbios_uuid_encoded = false;
-pcmc->enforce_aligned_dimm = false;
-}
-
-DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
-  pc_i440fx_2_1_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0

[PATCH-for-9.1 v2 09/21] hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded

[Philippe Mathieu-Daudé]

PCMachineClass::smbios_uuid_encoded was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true, remove it.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/fw_cfg.c | 3 +--
 hw/i386/pc.c | 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b528f17904..c2d9af36b2 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -109,7 +109,6 @@ struct PCMachineClass {
 /* SMBIOS compat: */
 bool smbios_defaults;
 bool smbios_legacy_mode;
-bool smbios_uuid_encoded;
 SmbiosEntryPointType default_smbios_ep_type;
 
 /* RAM / address space compat: */
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index d802d2787f..f7c2501161 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,8 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name,
-pcmc->smbios_uuid_encoded);
+smbios_set_defaults("QEMU", mc->desc, mc->name, true);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 21a19f9f9f..f9650a2821 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1776,7 +1776,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->has_acpi_build = true;
 pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
-pcmc->smbios_uuid_encoded = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_aligned_dimm = true;
-- 
2.41.0

[PATCH-for-9.1 v2 10/21] hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()

[Philippe Mathieu-Daudé]

'uuid_encoded' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/firmware/smbios.h | 3 +--
 hw/arm/virt.c| 3 +--
 hw/i386/fw_cfg.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/riscv/virt.c  | 2 +-
 hw/smbios/smbios.c   | 6 ++
 6 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 8d3fb2fb3b..f066ab7262 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -331,8 +331,7 @@ void smbios_add_usr_blob_size(size_t size);
 void smbios_entry_add(QemuOpts *opts, Error **errp);
 void smbios_set_cpuid(uint32_t version, uint32_t features);
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded);
+ const char *version);
 void smbios_set_default_processor_family(uint16_t processor_family);
 uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
 void smbios_get_tables(MachineState *ms,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a9a913aead..a55ef916cb 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1650,8 +1650,7 @@ static void virt_build_smbios(VirtMachineState *vms)
 }
 
 smbios_set_defaults("QEMU", product,
-vmc->smbios_old_sys_ver ? "1.0" : mc->name,
-true);
+vmc->smbios_old_sys_ver ? "1.0" : mc->name);
 
 /* build the array of physical mem area from base_memmap */
 mem_array.address = vms->memmap[VIRT_MEM].base;
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index f7c2501161..ecc4047a4b 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,7 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name, true);
+smbios_set_defaults("QEMU", mc->desc, mc->name);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 441d764843..00d3005e54 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -355,7 +355,7 @@ static void virt_build_smbios(LoongArchMachineState *lams)
 return;
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 smbios_get_tables(ms, SMBIOS_ENTRY_POINT_TYPE_64,
   NULL, 0,
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d171e74f7b..1ed9b0552e 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1277,7 +1277,7 @@ static void virt_build_smbios(RISCVVirtState *s)
 product = "KVM Virtual Machine";
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 if (riscv_is_32bit(&s->soc[0])) {
 smbios_set_default_processor_family(0x200);
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index eed5787b15..8261eb716f 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,7 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static bool smbios_uuid_encoded = true;
+static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -1017,11 +1017,9 @@ void smbios_set_default_processor_family(uint16_t 
processor_family)
 }
 
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded)
+ const char *version)
 {
 smbios_have_defaults = true;
-smbios_uuid_encoded = uuid_encoded;
 
 SMBIOS_SET_DEFAULT(smbios_type1.manufacturer, manufacturer);
 SMBIOS_SET_DEFAULT(smbios_type1.product, product);
-- 
2.41.0

[PATCH-for-9.1 v2 14/21] hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug()

[Philippe Mathieu-Daudé]

'legacy_align' is always NULL, remove it, simplifying
memory_device_pre_plug().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-12-phi...@linaro.org>
---
 include/hw/mem/memory-device.h |  2 +-
 hw/i386/pc.c   |  3 +--
 hw/mem/memory-device.c | 12 
 hw/mem/pc-dimm.c   |  2 +-
 hw/virtio/virtio-md-pci.c  |  2 +-
 5 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/hw/mem/memory-device.h b/include/hw/mem/memory-device.h
index e0571c8a31..c0a58087cc 100644
--- a/include/hw/mem/memory-device.h
+++ b/include/hw/mem/memory-device.h
@@ -169,7 +169,7 @@ uint64_t get_plugged_memory_size(void);
 unsigned int memory_devices_get_reserved_memslots(void);
 bool memory_devices_memslot_auto_decision_active(void);
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp);
+Error **errp);
 void memory_device_plug(MemoryDeviceState *md, MachineState *ms);
 void memory_device_unplug(MemoryDeviceState *md, MachineState *ms);
 uint64_t memory_device_get_region_size(const MemoryDeviceState *md,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index baa1b228a9..44283d3165 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1377,8 +1377,7 @@ static void pc_hv_balloon_pre_plug(HotplugHandler 
*hotplug_dev,
 {
 /* The vmbus handler has no hotplug handler; we should never end up here. 
*/
 g_assert(!dev->hotplugged);
-memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), NULL,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_hv_balloon_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
index e098585cda..a5f279adcc 100644
--- a/hw/mem/memory-device.c
+++ b/hw/mem/memory-device.c
@@ -345,7 +345,7 @@ uint64_t get_plugged_memory_size(void)
 }
 
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp)
+Error **errp)
 {
 const MemoryDeviceClass *mdc = MEMORY_DEVICE_GET_CLASS(md);
 Error *local_err = NULL;
@@ -388,14 +388,10 @@ void memory_device_pre_plug(MemoryDeviceState *md, 
MachineState *ms,
 return;
 }
 
-if (legacy_align) {
-align = *legacy_align;
-} else {
-if (mdc->get_min_alignment) {
-align = mdc->get_min_alignment(md);
-}
-align = MAX(align, memory_region_get_alignment(mr));
+if (mdc->get_min_alignment) {
+align = mdc->get_min_alignment(md);
 }
+align = MAX(align, memory_region_get_alignment(mr));
 addr = mdc->get_addr(md);
 addr = memory_device_get_free_addr(ms, !addr ? NULL : &addr, align,
memory_region_size(mr), &local_err);
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 836384a90f..27919ca45d 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -69,7 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine, Error **errp)
 &error_abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c
index 62bfb7920b..9ec5067662 100644
--- a/hw/virtio/virtio-md-pci.c
+++ b/hw/virtio/virtio-md-pci.c
@@ -37,7 +37,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState 
*ms, Error **errp)
  * First, see if we can plug this memory device at all. If that
  * succeeds, branch of to the actual hotplug handler.
  */
-memory_device_pre_plug(md, ms, NULL, &local_err);
+memory_device_pre_plug(md, ms, &local_err);
 if (!local_err && bus_handler) {
 hotplug_handler_pre_plug(bus_handler, dev, &local_err);
 }
-- 
2.41.0

[PATCH-for-9.1 v2 08/21] target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'

[Philippe Mathieu-Daudé]

x86_cpu_change_kvm_default() was only used out of kvm-cpu.c by
the pc-i440fx-2.1 machine, which got removed. Make it static,
and remove its declaration. "kvm-cpu.h" is now empty, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-8-phi...@linaro.org>
---
 target/i386/kvm/kvm-cpu.h | 41 ---
 target/i386/kvm/kvm-cpu.c |  3 +--
 2 files changed, 1 insertion(+), 43 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

diff --git a/target/i386/kvm/kvm-cpu.h b/target/i386/kvm/kvm-cpu.h
deleted file mode 100644
index e858ca21e5..00
--- a/target/i386/kvm/kvm-cpu.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * i386 KVM CPU type and functions
- *
- *  Copyright (c) 2003 Fabrice Bellard
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see .
- */
-
-#ifndef KVM_CPU_H
-#define KVM_CPU_H
-
-#ifdef CONFIG_KVM
-/*
- * Change the value of a KVM-specific default
- *
- * If value is NULL, no default will be set and the original
- * value from the CPU model table will be kept.
- *
- * It is valid to call this function only for properties that
- * are already present in the kvm_default_props table.
- */
-void x86_cpu_change_kvm_default(const char *prop, const char *value);
-
-#else /* !CONFIG_KVM */
-
-#define x86_cpu_change_kvm_default(a, b)
-
-#endif /* CONFIG_KVM */
-
-#endif /* KVM_CPU_H */
diff --git a/target/i386/kvm/kvm-cpu.c b/target/i386/kvm/kvm-cpu.c
index 9c791b7b05..cb8c73d20c 100644
--- a/target/i386/kvm/kvm-cpu.c
+++ b/target/i386/kvm/kvm-cpu.c
@@ -10,7 +10,6 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "host-cpu.h"
-#include "kvm-cpu.h"
 #include "qapi/error.h"
 #include "sysemu/sysemu.h"
 #include "hw/boards.h"
@@ -144,7 +143,7 @@ static PropValue kvm_default_props[] = {
 /*
  * Only for builtin_x86_defs models initialized with x86_register_cpudef_types.
  */
-void x86_cpu_change_kvm_default(const char *prop, const char *value)
+static void x86_cpu_change_kvm_default(const char *prop, const char *value)
 {
 PropValue *pv;
 for (pv = kvm_default_props; pv->prop; pv++) {
-- 
2.41.0

[PATCH-for-9.1 v2 11/21] hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()

[Philippe Mathieu-Daudé]

'smbios_encode_uuid' is always true, remove it,
simplifying smbios_encode_uuid().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/smbios/smbios.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 8261eb716f..3b7703489d 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,6 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -600,11 +599,9 @@ static void smbios_build_type_0_table(void)
 static void smbios_encode_uuid(struct smbios_uuid *uuid, QemuUUID *in)
 {
 memcpy(uuid, in, 16);
-if (smbios_uuid_encoded) {
-uuid->time_low = bswap32(uuid->time_low);
-uuid->time_mid = bswap16(uuid->time_mid);
-uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
-}
+uuid->time_low = bswap32(uuid->time_low);
+uuid->time_mid = bswap16(uuid->time_mid);
+uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
 }
 
 static void smbios_build_type_1_table(void)
-- 
2.41.0

[PATCH-for-9.1 v2 16/21] hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob

[Philippe Mathieu-Daudé]

PCMachineClass::resizable_acpi_blob was only used by the
pc-i440fx-2.2 machine, which got removed. It is now always
true. Remove it, simplifying acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  3 ---
 hw/i386/acpi-build.c | 10 --
 hw/i386/pc.c |  1 -
 3 files changed, 14 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index df97df6ca7..10a8ffa0de 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -124,9 +124,6 @@ struct PCMachineClass {
 /* create kvmclock device even when KVM PV features are not exposed */
 bool kvmclock_create_always;
 
-/* resizable acpi blob compat */
-bool resizable_acpi_blob;
-
 /*
  * whether the machine type implements broken 32-bit address space bound
  * check for memory.
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a6f8203460..ab2d4d8dcb 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2688,16 +2688,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * keep the table size stable for all (max_cpus, max_memory_slots)
  * combinations.
  */
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
 acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
 
 acpi_align_size(tables->linker->cmd_blob, ACPI_BUILD_ALIGN_SIZE);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c37d813af0..ae2d220269 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1753,7 +1753,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
-pcmc->resizable_acpi_blob = true;
 x86mc->apic_xrupt_override = true;
 assert(!mc->get_hotplug_handler);
 mc->get_hotplug_handler = pc_get_hotplug_handler;
-- 
2.41.0

[PATCH-for-9.1 v2 20/21] target/i386: Remove X86CPU::kvm_no_smi_migration field

[Philippe Mathieu-Daudé]

X86CPU::kvm_no_smi_migration was only used by the
pc-i440fx-2.3 machine, which got removed. Remove it
and simplify kvm_put_vcpu_events().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/cpu.h | 3 ---
 target/i386/cpu.c | 2 --
 target/i386/kvm/kvm.c | 7 +--
 3 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 6b05738079..5b016d6667 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2018,9 +2018,6 @@ struct ArchCPU {
 /* if set, limit maximum value for phys_bits when host_phys_bits is true */
 uint8_t host_phys_bits_limit;
 
-/* Stop SMI delivery for migration compatibility with old machines */
-bool kvm_no_smi_migration;
-
 /* Forcefully disable KVM PV features not exposed in guest CPUIDs */
 bool kvm_pv_enforce_cpuid;
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 33760a2ee1..f9991e7398 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7905,8 +7905,6 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("x-vendor-cpuid-only", X86CPU, vendor_cpuid_only, true),
 DEFINE_PROP_BOOL("lmce", X86CPU, enable_lmce, false),
 DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),
-DEFINE_PROP_BOOL("kvm-no-smi-migration", X86CPU, kvm_no_smi_migration,
- false),
 DEFINE_PROP_BOOL("kvm-pv-enforce-cpuid", X86CPU, kvm_pv_enforce_cpuid,
  false),
 DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index e68cbe9293..88f4a7da33 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4337,6 +4337,7 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.sipi_vector = env->sipi_vector;
 
 if (has_msr_smbase) {
+events.flags |= KVM_VCPUEVENT_VALID_SMM;
 events.smi.smm = !!(env->hflags & HF_SMM_MASK);
 events.smi.smm_inside_nmi = !!(env->hflags2 & HF2_SMM_INSIDE_NMI_MASK);
 if (kvm_irqchip_in_kernel()) {
@@ -4351,12 +4352,6 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.smi.pending = 0;
 events.smi.latched_init = 0;
 }
-/* Stop SMI delivery on old machine types to avoid a reboot
- * on an inward migration of an old VM.
- */
-if (!cpu->kvm_no_smi_migration) {
-events.flags |= KVM_VCPUEVENT_VALID_SMM;
-}
 }
 
 if (level >= KVM_PUT_RESET_STATE) {
-- 
2.41.0

[PATCH-for-9.1 v2 18/21] hw/i386/acpi: Remove AcpiBuildState::rsdp field

[Philippe Mathieu-Daudé]

AcpiBuildState::rsdp is always NULL, remove it,
simplifying acpi_build_update().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-16-phi...@linaro.org>
---
 hw/i386/acpi-build.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ed0adb0e82..6f9925d176 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2459,7 +2459,6 @@ struct AcpiBuildState {
 MemoryRegion *table_mr;
 /* Is table patched? */
 uint8_t patched;
-void *rsdp;
 MemoryRegion *rsdp_mr;
 MemoryRegion *linker_mr;
 } AcpiBuildState;
@@ -2715,11 +2714,7 @@ static void acpi_build_update(void *build_opaque)
 
 acpi_ram_update(build_state->table_mr, tables.table_data);
 
-if (build_state->rsdp) {
-memcpy(build_state->rsdp, tables.rsdp->data, 
acpi_data_len(tables.rsdp));
-} else {
-acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
-}
+acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
 
 acpi_ram_update(build_state->linker_mr, tables.linker->cmd_blob);
 acpi_build_tables_cleanup(&tables, true);
@@ -2805,7 +2800,6 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-build_state->rsdp = NULL;
 build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
  build_state, tables.rsdp,
  ACPI_BUILD_RSDP_FILE);
-- 
2.41.0

[PATCH-for-9.1 v2 15/21] hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.2 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-13-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  6 +++---
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 23 ---
 hw/i386/pc_piix.c   | 21 -
 5 files changed, 4 insertions(+), 51 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index deadcc044f..f6eac988c0 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,10 +219,10 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.3`` (since 8.2)
+'
 
-These old machine types are quite neglected nowadays and thus might have
+This old machine type is quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 01c55103d3..4664974a8b 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 231aae92ed..df97df6ca7 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -274,9 +274,6 @@ extern const size_t pc_compat_2_4_len;
 extern GlobalProperty pc_compat_2_3[];
 extern const size_t pc_compat_2_3_len;
 
-extern GlobalProperty pc_compat_2_2[];
-extern const size_t pc_compat_2_2_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 44283d3165..c37d813af0 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -281,29 +281,6 @@ GlobalProperty pc_compat_2_3[] = {
 };
 const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
 
-GlobalProperty pc_compat_2_2[] = {
-PC_CPU_MODEL_IDS("2.2.0")
-{ "kvm64" "-" TYPE_X86_CPU, "vme", "off" },
-{ "kvm32" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Conroe" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Penryn" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Nehalem" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Westmere" "-" TYPE_X86_CPU, "vme", "off" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G1" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G2" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G3" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G4" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G5" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "rdrand", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "rdrand", "off" },
-};
-const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 02f3bce4f3..9615e25d56 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -429,11 +429,6 @@ static void pc_compat_2_3_fn(MachineState *machine)
 }
 }
 
-static void pc_compat_2_2_fn(MachineState *machine)
-{
-pc_compat_2_3_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -828,22 +823,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
   pc_i440fx_2_3_machine_options);
 
-static void pc_i440fx_2_2_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_3_machine_options(m);
-m->hw_version = "2.2.0";
-m->default_machine_opts = "firmware=bios-256k.bin,suppress-vmdesc=on";
-compat_props_add(m->compat_props, hw_compat_2_2, hw_compat_2_2_len);
-compat_props_add(m->compat_props, pc_compat_2_2, pc_compat_2_2_len);
-pcmc->rsdp_in_ram = false;
-pcmc->resizable_acpi_blob = false;
-}
-
-DEFINE_I440FX_MACHINE(v

[PATCH-for-9.1 v2 21/21] hw/i386/pc: Replace PCMachineClass::acpi_data_size by PC_ACPI_DATA_SIZE

[Philippe Mathieu-Daudé]

PCMachineClass::acpi_data_size was only used by the pc-i440fx-2.0
machine, which got removed. Since it is constant, replace the class
field by a definition.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-19-phi...@linaro.org>
---
 include/hw/i386/pc.h |  4 
 hw/i386/pc.c | 19 ---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 96ccb4583f..0ad971782c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,9 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @acpi_data_size: Size of the chunk of memory at the top of RAM
- *  for the BIOS ACPI tables and other BIOS
- *  datastructures.
  * @gigabyte_align: Make sure that guest addresses aligned at
  *  1Gbyte boundaries get mapped to host
  *  addresses aligned at 1Gbyte boundaries. This
@@ -100,7 +97,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-unsigned acpi_data_size;
 int pci_root_uid;
 
 /* SMBIOS compat: */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 27e04c52f6..f01a30d3d9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,6 +256,16 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
+/*
+ * @PC_ACPI_DATA_SIZE:
+ * Size of the chunk of memory at the top of RAM for the BIOS ACPI tables
+ * and other BIOS datastructures.
+ *
+ * BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K
+ * reported to be used at the moment, 32K should be enough for a while.
+ */
+#define PC_ACPI_DATA_SIZE (0x2 + 0x8000)
+
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
@@ -634,8 +644,7 @@ void xen_load_linux(PCMachineState *pcms)
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus);
 rom_set_fw(fw_cfg);
 
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 for (i = 0; i < nb_option_roms; i++) {
 assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
!strcmp(option_rom[i].name, "linuxboot_dma.bin") ||
@@ -969,8 +978,7 @@ void pc_memory_init(PCMachineState *pcms,
 }
 
 if (linux_boot) {
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 }
 
 for (i = 0; i < nb_option_roms; i++) {
@@ -1722,9 +1730,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_amd_1tb_hole = true;
-/* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
- * to be used at the moment, 32K should be enough for a while.  */
-pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
 x86mc->apic_xrupt_override = true;
-- 
2.41.0

[PATCH-for-9.1 v2 19/21] hw/i386/pc: Remove 2.3 and deprecate 2.4 to 2.7 pc-i440fx machines

[Philippe Mathieu-Daudé]

The pc-i440fx-2.3 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it. Similarly to the cited commit,
deprecate the 2.4 to 2.7 machines.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/about/deprecated.rst   |  6 +++---
 docs/about/removed-features.rst |  2 +-
 hw/i386/pc.c| 25 -
 hw/i386/pc_piix.c   | 20 
 4 files changed, 4 insertions(+), 49 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index f6eac988c0..22335ef6b0 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,10 +219,10 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.4`` up to ``pc-i440fx-2.7`` (since 9.1)
+'
 
-This old machine type is quite neglected nowadays and thus might have
+These old machine types are quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 4664974a8b..0caa6a63e4 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.3`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5fd83010ba..27e04c52f6 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,31 +256,6 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
-GlobalProperty pc_compat_2_3[] = {
-PC_CPU_MODEL_IDS("2.3.0")
-{ TYPE_X86_CPU, "arat", "off" },
-{ "qemu64" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "kvm64" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "pentium3" "-" TYPE_X86_CPU, "min-level", "2" },
-{ "n270" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "n270" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Westmere" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "IvyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ TYPE_X86_CPU, "kvm-no-smi-migration", "on" },
-};
-const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9615e25d56..c00d2a66a6 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -421,14 +421,6 @@ static void pc_set_south_bridge(Object *obj, int value, 
Error **errp)
  * hw_compat_*, pc_compat_*, or * pc_*_machine_options().
  */
 
-static void pc_compat_2_3_fn(MachineState *machine)
-{
-X86MachineState *x86ms = X86_MACHINE(machine);
-if (kvm_enabled()) {
-x86ms->smm = ON_OFF_AUTO_OFF;
-}
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -811,18 +803,6 @@ static void pc_i440fx_2_4_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
   pc_i440fx_2_4_machine_options)
 
-static void pc_i440fx_2_3_machine_options(MachineClass *m)
-{
-pc_i440fx_2_4_machine_options(m);
-m->hw_version = "2.3.0";
-m->deprecation_reason = "old and unattended - use a newer version instead";
-compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
-compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
-}
-
-DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
-  pc_i440fx_2_3_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0

[PATCH-for-9.1 v2 17/21] hw/i386/pc: Remove PCMachineClass::rsdp_in_ram

[Philippe Mathieu-Daudé]

PCMachineClass::rsdp_in_ram was only used by the
pc-i440fx-2.2 machine, which got removed. It is
now always true. Remove it, simplifying acpi_setup().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-15-phi...@linaro.org>
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 35 ---
 hw/i386/pc.c |  1 -
 3 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 10a8ffa0de..96ccb4583f 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -100,7 +100,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-bool rsdp_in_ram;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ab2d4d8dcb..ed0adb0e82 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2495,7 +2495,6 @@ static
 void acpi_build(AcpiBuildTables *tables, MachineState *machine)
 {
 PCMachineState *pcms = PC_MACHINE(machine);
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
@@ -2667,16 +2666,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 .rsdt_tbl_offset = &rsdt,
 };
 build_rsdp(tables->rsdp, tables->linker, &rsdp_data);
-if (!pcmc->rsdp_in_ram) {
-/* We used to allocate some extra space for RSDP revision 2 but
- * only used the RSDP revision 0 space. The extra bytes were
- * zeroed out and not used.
- * Here we continue wasting those extra 16 bytes to make sure we
- * don't break migration for machine types 2.2 and older due to
- * RSDP blob size mismatch.
- */
-build_append_int_noprefix(tables->rsdp, 0, 16);
-}
 }
 
 /* We'll expose it all to Guest so we want to reduce
@@ -2755,7 +2744,6 @@ static const VMStateDescription vmstate_acpi_build = {
 void acpi_setup(void)
 {
 PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(pcms);
 AcpiBuildTables tables;
 AcpiBuildState *build_state;
@@ -2817,25 +2805,10 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-if (!pcmc->rsdp_in_ram) {
-/*
- * Keep for compatibility with old machine types.
- * Though RSDP is small, its contents isn't immutable, so
- * we'll update it along with the rest of tables on guest access.
- */
-uint32_t rsdp_size = acpi_data_len(tables.rsdp);
-
-build_state->rsdp = g_memdup(tables.rsdp->data, rsdp_size);
-fw_cfg_add_file_callback(x86ms->fw_cfg, ACPI_BUILD_RSDP_FILE,
- acpi_build_update, NULL, build_state,
- build_state->rsdp, rsdp_size, true);
-build_state->rsdp_mr = NULL;
-} else {
-build_state->rsdp = NULL;
-build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
- build_state, tables.rsdp,
- ACPI_BUILD_RSDP_FILE);
-}
+build_state->rsdp = NULL;
+build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
+ build_state, tables.rsdp,
+ ACPI_BUILD_RSDP_FILE);
 
 qemu_register_reset(acpi_build_reset, build_state);
 acpi_build_reset(build_state);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ae2d220269..5fd83010ba 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1743,7 +1743,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 
 pcmc->pci_enabled = true;
 pcmc->has_acpi_build = true;
-pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-- 
2.41.0

Re: [PATCH 10/10] pnv/phb4: Mask off LSI Source-ID based on number of interrupts

[Saif Abrar]

Hello Cedric,


  }
  +static void pnv_phb4_fund_A_reset(PnvPHB4 *phb)

What is fund_A ?


I used 'fund_A' as an abbreviation to "Fundamental Register Set A".

Please let know if you suggest another abbreviation to name this method.



+{
+    phb->regs[PHB_LSI_SOURCE_ID >> 3] = PPC_BITMASK(4, 12);


Is this mask the default value for HW ?
Yes, the spec defines the bits[04:12] of LSI Source ID having reset 
value: 0x1FF



Regards,

Saif


On 25-03-2024 07:04 pm, Cédric Le Goater wrote:

On 3/21/24 11:04, Saif Abrar wrote:

Add a method to reset the value of LSI Source-ID.
Mask off LSI source-id based on number of interrupts in the big/small 
PHB.


Looks ok.



Signed-off-by: Saif Abrar 
---
  hw/pci-host/pnv_phb4.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index f48750ee54..8fbaf6512e 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -489,6 +489,7 @@ static void pnv_phb4_update_xsrc(PnvPHB4 *phb)
    lsi_base = GETFIELD(PHB_LSI_SRC_ID, 
phb->regs[PHB_LSI_SOURCE_ID >> 3]);

  lsi_base <<= 3;
+    lsi_base &= (xsrc->nr_irqs - 1);
    /* TODO: handle reset values of PHB_LSI_SRC_ID */
  if (!lsi_base) {
@@ -1966,6 +1967,12 @@ static void pnv_phb4_ro_mask_init(PnvPHB4 *phb)
  /* TODO: Add more RO-masks as regs are implemented in the model */
  }
  +static void pnv_phb4_fund_A_reset(PnvPHB4 *phb)


What is fund_A ?


+{
+    phb->regs[PHB_LSI_SOURCE_ID >> 3] = PPC_BITMASK(4, 12);


Is this mask the default value for HW ?


Thanks,

C.



+    pnv_phb4_update_xsrc(phb);
+}
+
  static void pnv_phb4_err_reg_reset(PnvPHB4 *phb)
  {
  STICKY_RST(PHB_ERR_STATUS,   0, PPC_BITMASK(0, 33));
@@ -2023,6 +2030,7 @@ static void pnv_phb4_reset(void *dev)
  pnv_phb4_cfg_core_reset(phb);
  pnv_phb4_pbl_core_reset(phb);
  +    pnv_phb4_fund_A_reset(phb);
  pnv_phb4_err_reg_reset(phb);
  pnv_phb4_pcie_stack_reg_reset(phb);
  pnv_phb4_regb_err_reg_reset(phb);
@@ -2102,8 +2110,6 @@ static void pnv_phb4_realize(DeviceState *dev, 
Error **errp)

  return;
  }
  -    pnv_phb4_update_xsrc(phb);
-
  phb->qirqs = qemu_allocate_irqs(xive_source_set_irq, xsrc, 
xsrc->nr_irqs);

    pnv_phb4_xscom_realize(phb);

[PATCH] riscv: thead: Add th.mxstatus CSR emulation

[Christoph Müllner]

The th.mxstatus CSR can be used to identify available custom extension
on T-Head CPUs. The CSR is documented here:
  https://github.com/T-head-Semi/thead-extension-spec/pull/45

An important property of this patch is, that the th.mxstatus MAEE field
is not set (indicating that XTheadMaee is not available).
XTheadMaee is a memory attribute extension (similar to Svpbmt) which is
implemented in many T-Head CPUs (C906, C910, etc.) and utilizes bits
in PTEs that are marked as reserved. QEMU maintainers prefer to not
implement XTheadMaee, so we need give kernels a mechanism to identify
if XTheadMaee is available in a system or not. And this patch introduces
this mechanism in QEMU in a way that's compatible with real HW
(i.e., probing the th.mxstatus.MAEE bit).

Further context can be found on the list:
https://lists.gnu.org/archive/html/qemu-devel/2024-02/msg00775.html

Signed-off-by: Christoph Müllner 
---
 target/riscv/cpu.c   |  1 +
 target/riscv/cpu.h   |  3 ++
 target/riscv/meson.build |  1 +
 target/riscv/th_csr.c| 76 
 4 files changed, 81 insertions(+)
 create mode 100644 target/riscv/th_csr.c

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 36e3e5fdaf..b82ba95ae6 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -545,6 +545,7 @@ static void rv64_thead_c906_cpu_init(Object *obj)
 cpu->cfg.mvendorid = THEAD_VENDOR_ID;
 #ifndef CONFIG_USER_ONLY
 set_satp_mode_max_supported(cpu, VM_1_10_SV39);
+th_register_custom_csrs(cpu);
 #endif
 
 /* inherited from parent obj via riscv_cpu_init() */
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 3b1a02b944..c9f8f06751 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -824,4 +824,7 @@ void riscv_cpu_register_gdb_regs_for_features(CPUState *cs);
 uint8_t satp_mode_max_from_map(uint32_t map);
 const char *satp_mode_str(uint8_t satp_mode, bool is_32_bit);
 
+/* Implemented in th_csr.c */
+void th_register_custom_csrs(RISCVCPU *cpu);
+
 #endif /* RISCV_CPU_H */
diff --git a/target/riscv/meson.build b/target/riscv/meson.build
index a5e0734e7f..a4bd61e52a 100644
--- a/target/riscv/meson.build
+++ b/target/riscv/meson.build
@@ -33,6 +33,7 @@ riscv_system_ss.add(files(
   'monitor.c',
   'machine.c',
   'pmu.c',
+  'th_csr.c',
   'time_helper.c',
   'riscv-qmp-cmds.c',
 ))
diff --git a/target/riscv/th_csr.c b/target/riscv/th_csr.c
new file mode 100644
index 00..7fbcf88b5b
--- /dev/null
+++ b/target/riscv/th_csr.c
@@ -0,0 +1,76 @@
+/*
+ * T-Head-specific CSRs.
+ *
+ * Copyright (c) 2024 VRULL GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "cpu_vendorid.h"
+
+#define CSR_TH_MXSTATUS 0x7c0
+
+/* TH_MXSTATUS bits */
+#define TH_MXSTATUS_UCMEBIT(16)
+#define TH_MXSTATUS_MAEEBIT(21)
+#define TH_MXSTATUS_THEADISAEE  BIT(22)
+
+typedef struct {
+int csrno;
+int (*insertion_test)(RISCVCPU *cpu);
+riscv_csr_operations csr_ops;
+} riscv_csr;
+
+static RISCVException m_mode(CPURISCVState *env, int csrno)
+{
+if (env->debugger)
+return RISCV_EXCP_NONE;
+if (env->priv != PRV_M)
+return RISCV_EXCP_ILLEGAL_INST;
+return RISCV_EXCP_NONE;
+}
+
+static int test_thead_mvendorid(RISCVCPU *cpu)
+{
+if (cpu->cfg.mvendorid != THEAD_VENDOR_ID)
+return -1;
+return 0;
+}
+
+static RISCVException read_th_mxstatus(CPURISCVState *env, int csrno,
+   target_ulong *val)
+{
+/* We don't set MAEE here, because QEMU does not implement MAEE. */
+*val = TH_MXSTATUS_UCME | TH_MXSTATUS_THEADISAEE;
+return RISCV_EXCP_NONE;
+}
+
+static riscv_csr th_csr_list[] = {
+{
+.csrno = CSR_TH_MXSTATUS,
+.insertion_test = test_thead_mvendorid,
+.csr_ops = { "th.mxstatus", m_mode, read_th_mxstatus }
+}
+};
+
+void th_register_custom_csrs(RISCVCPU *cpu)
+{
+for (size_t i = 0; i < ARRAY_SIZE(th_csr_list); i++) {
+int csrno = th_csr_list[i].csrno;
+riscv_csr_operations *csr_ops = &th_csr_list[i].csr_ops;
+if (!th_csr_list[i].insertion_test(cpu))
+riscv_set_csr_ops(csrno, csr_ops);
+}
+}
-- 
2.44.0

Re: [PULL 00/15] riscv-to-apply queue

[Michael Tokarev]

26.03.2024 12:56, Alistair Francis пишет:

On Tue, Mar 26, 2024 at 7:53 PM Michael Tokarev  wrote:


On 24.03.2024 21:12, Daniel Henrique Barboza wrote:

On 3/24/24 12:07, Michael Tokarev wrote:



Unfortunately this doesn't quite work, the following changes
fail to apply to 8.2:

929e521a47 target/riscv: always clear vstart for ldst_whole insns
b46631f122 target/riscv: remove 'over' brconds from vector trans
d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls
bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns
385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration



The amount of work can be non-trivial for this backport, so I'd say we should
leave it aside for now. If someone has a good argument for this work then we
can re-evaluate.


So, out of 15 patches in this series (minus the first one already
mentioned) - should I pick 9 remaining patches for stable (the ones
which applies) or none at all? :)


Sorry for the confusion.

The 9 patches that applied and

385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration

should all be picked for stable.


Got it, picked all plus 385e575cd5 which needed just trivial context fixup.
Thank you for the clarification!


PS: What is the best way in future to help ease some of the stable
burden? Should I try and cherry pick them beforehand and then mention
that as a follow up to the PR?


The only problem for me so far is the patch selection, - this is why I'm
asking to Cc changes which should go to stable, to qemu-stable@.  So far
I was a bit pro-active and asked about some changes which I *feel* are
suitable, like in this case.  It is much better if someone who actually
has knowledge about the area being changed, decides if it's stable material
or not.  At the same time, I don't mind at all if more changes than needed
are Cc'ed like this, - at least as long as it's obvious they're not really
needed (like fixing a bug introduced in commit which isn't in any release
yet).

I usually don't have any issues with applying patches which don't apply
directly to stable - this is not a burden.  In some cases when this happens,
I can edit the commit (like I just did for 385e575cd5), or pick some previous
changes too if they're okay, or in even more rare cases, ask for clarification
or even for help with back-porting, - but this last category is really rare.

Some changes gets rejected for stable in the end due to too much back-porting
effort or requiring too much prior context.

So the only real issue for me is to know which changes are to pick, - that's 
all.
And this is the only thing I'm asking, - in this thread and elsewhere.

Thank you!

/mjt

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Christian Schoenebeck]

On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote:
> On 3/27/24 05:47, Christian Schoenebeck wrote:
> > On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:
> >> On 3/26/24 14:05, Greg Kurz wrote:
> >>> On Tue, 26 Mar 2024 10:26:04 -0300
> >>> Daniel Henrique Barboza  wrote:
> >>>
>  The local 9p driver in virtio-9p-test.c its temporary dir right at the
>  start of qos-test (via virtio_9p_create_local_test_dir()) and only
>  deletes it after qos-test is finished (via
>  virtio_9p_remove_local_test_dir()).
> 
>  This means that any qos-test machine that ends up running virtio-9p-test 
>  local
>  tests more than once will end up re-using the same temp dir. This is
>  what's happening in [1] after we introduced the riscv machine nodes: if
>  we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
>  this is what happens:
> 
>  - a temp dir is created, e.g. qtest-9p-local-WZLDL2;
> 
>  - virtio-9p-device tests will run virtio-9p-test successfully;
> 
>  - virtio-9p-pci tests will run virtio-9p-test, and fail right at the
>  first slow test at fs_create_dir() because the "01" file was already
>  created by fs_create_dir() test when running with the 
>  virtio-9p-device.
> 
>  We can fix it by making every test clean up their changes in the
>  filesystem after they're done. But we don't need every test either:
>  what fs_create_file() does is already exercised in fs_unlinkat_dir(),
>  i.e. a dir is created, verified to be created, and then removed. Fixing
>  fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
>  both. The same theme follows every test in virtio-9p-test.c, where the
>  'unlikat' variant does the same thing the 'create' does but with some
>  cleaning in the end.
> 
>  Consolide some tests as follows:
> 
>  - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
>  fs_create_unlinkat_dir();
> 
>  - fs_create_file() is removed. fs_unlinkat_file() is renamed to
>  fs_create_unlinkat_file(). The "04" dir it uses is now being removed;
> 
>  - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
>  fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
>  creates is now being removed.
> 
> >>>
> >>> The  change looks good functionally but it breaks the legitimate 
> >>> assumption
> >>> that files "06/*" come from test #6 and so on... I think you should 
> >>> consider
> >>> renumbering to avoid confusion when debugging logs.
> >>>
> >>> Since this will bring more hunks, please split this in enough reviewable
> >>> patches.
> >>
> >> Fair enough. Let me cook a v2. Thanks,
> > 
> > Wouldn't it be much simpler to just change the name of the temporary
> > directory, such that it contains the device name as well? Then these tests
> > runs would run on independent directories and won't interfere with each 
> > other
> > and that wouldn't need much changes I guess.
> 
> That's true. If we were just trying to fix the issue then I would go with this
> approach since it's simpler. But given that we're also cutting half the tests 
> while
> retaining the coverage I think this approach is worth the extra code.

Well, I am actually not so keen into all those changes. These tests were
intentionally split, and yes with costs of a bit redundant (test case) code.
But they were cleanly build up on each other, from fundamental requirements
like whether it is possible to create a directory and file ... and then the
subsequent tests would become more and more demanding.

That way it was easier to review if somebody reports a test to fail, because
you could immediately see whether the preceding fundamental tests succeeded.

/Christian

Re: [PATCH for-9.1 v2 09/11] hostmem: add a new memory backend based on POSIX shm_open()

[Stefano Garzarella]

On Tue, Mar 26, 2024 at 03:45:52PM +0100, David Hildenbrand wrote:

+mode = 0;
+oflag = O_RDWR | O_CREAT | O_EXCL;
+backend_name = host_memory_backend_get_name(backend);
+
+/*
+ * Some operating systems allow creating anonymous POSIX shared memory
+ * objects (e.g. FreeBSD provides the SHM_ANON constant), but this is not
+ * defined by POSIX, so let's create a unique name.
+ *
+ * From Linux's shm_open(3) man-page:
+ *   For  portable  use,  a shared  memory  object should be identified
+ *   by a name of the form /somename;"
+ */
+g_string_printf(shm_name, "/qemu-" FMT_pid "-shm-%s", getpid(),
+backend_name);


Hm, shouldn't we just let the user specify a name, and if no name was 
specified, generate one ourselves?


I thought about it and initially did it that way, but then some problems 
came up so I tried to keep it as simple as possible for the user and for 
our use case (having an fd associated with memory and sharing it with 
other processes).


The problems I had were:

- what mode_t to use if the object does not exist and needs to be 
  created?


- exclude O_EXCL if the user passes the name since they may have already 
  created it?


- call shm_unlink() only at object deallocation?

So I thought that for now we only support the "anonymous" mode, and if 
in the future we have a use case where the user wants to specify the 
name, we can add it later.


That said, if you think it's already useful from the beginning, I can 
add the name as an optional parameter.




I'm also not quite sure if "host_memory_backend_get_name()" should be 
used for the purpose here.


What problem do you see? As an alternative I thought of a static 
counter.


Thanks,
Stefano

[PATCH v2 0/3] edk2: get version + date from git submodule

[Gerd Hoffmann]

v2 changes:
 - store version information in git

Gerd Hoffmann (3):
  edk2: get version + date from git submodule
  edk2: commit version info
  edk2/seabios: use common extra version

 roms/Makefile | 25 ++---
 roms/edk2-version |  2 ++
 2 files changed, 20 insertions(+), 7 deletions(-)
 create mode 100644 roms/edk2-version

-- 
2.44.0

[PATCH v2 1/3] edk2: get version + date from git submodule

[Gerd Hoffmann]

Turned out hard-coding version and date in the Makefile wasn't a bright
idea.  Updating it on edk2 updates is easily forgotten.  Fetch the info
from git instead.  Store in edk2-version, so this can be committed to
the repo and is present in tarballs too.

Signed-off-by: Gerd Hoffmann 
---
 roms/Makefile | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/roms/Makefile b/roms/Makefile
index edc234a0e886..783a5cab4f4c 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -52,6 +52,8 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
 #
 EDK2_EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
 
+-include edk2-version
+
 default help:
@echo "nothing is build by default"
@echo "available build targets:"
@@ -147,10 +149,19 @@ skiboot:
$(MAKE) -C skiboot CROSS=$(powerpc64_cross_prefix)
cp skiboot/skiboot.lid ../pc-bios/skiboot.lid
 
-efi:
+edk2-version: edk2
+   if test -e edk2/.git; then \
+   echo "EDK2_STABLE = $$(cd edk2; git describe --tags --match 
'edk2-stable*')" > $@; \
+   echo "EDK2_DATE = $$(cd edk2; git log -1 --pretty='format:%cd' 
--date='format:%m/%d/%Y')" >> $@; \
+   else \
+   touch $@; \
+   fi
+
+efi: edk2-version
$(PYTHON) edk2-build.py --config edk2-build.config \
-   --version-override "edk2-stable202302-for-qemu" \
-   --release-date "03/01/2023"
+   --version-override "$(EDK2_STABLE)-for-qemu" \
+   --release-date "$(EDK2_DATE)" \
+   --silent --no-logs
rm -f ../pc-bios/edk2-*.fd.bz2
bzip2 --verbose ../pc-bios/edk2-*.fd
 
-- 
2.44.0

[PATCH 0/3] target/i386/cpu: Misc cleanup for warning message

[Zhao Liu]

From: Zhao Liu 

Hi Paolo and list,

In i386, there're 2 cases useing static variables to implement warning
only once.

So consolidate the use of warn_report_once() in i386 part. (Based on
the commit 5012e522aca1 "Update version for v9.0.0-rc1 release")

Thanks and Best Regards,
Zhao
---
Zhao Liu (3):
  target/i386/host-cpu: Consolidate the use of warn_report_once()
  target/i386/cpu: Consolidate the use of warn_report_once()
  target/i386/cpu: Merge the warning and error messages for AMD HT check

 target/i386/cpu.c  | 13 +
 target/i386/host-cpu.c | 11 ---
 2 files changed, 9 insertions(+), 15 deletions(-)

-- 
2.34.1

[PATCH 3/3] target/i386/cpu: Merge the warning and error messages for AMD HT check

[Zhao Liu]

From: Zhao Liu 

Currently, the difference between warn_report_once() and
error_report_once() is the former has the "warning:" prefix, while the
latter does not have a similar level prefix.

At the meantime, considering that there is no error handling logic here,
and the purpose of error_report_once() is only to prompt the user with
an abnormal message, there is no need to use an error-level message here,
and instead we can just use a warning.

Therefore, downgrade the message in error_report_once() to warning, and
merge it into the previous warn_report_once().

Signed-off-by: Zhao Liu 
---
 target/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 0487469d75f3..ec2787197d42 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7454,9 +7454,9 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
 cs->nr_threads > 1) {
 warn_report_once("This family of AMD CPU doesn't support "
- "hyperthreading(%d).", cs->nr_threads);
-error_report_once("Please configure -smp options properly"
-  " or try enabling topoext feature.");
+ "hyperthreading(%d). Please configure -smp "
+ "options properly or try enabling topoext "
+ "feature.", cs->nr_threads);
 }
 
 #ifndef CONFIG_USER_ONLY
-- 
2.34.1

[PATCH 2/3] target/i386/cpu: Consolidate the use of warn_report_once()

[Zhao Liu]

From: Zhao Liu 

The difference between error_printf() and error_report() is the latter
may contain more information, such as the name of the program
("qemu-system-x86_64").

Thus its variant error_report_once() and warn_report()'s variant
warn_report_once() can be used here to print the information only once
without a static local variable "ht_warned".

Signed-off-by: Zhao Liu 
---
 target/i386/cpu.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 33760a2ee163..0487469d75f3 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7230,7 +7230,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 X86CPUClass *xcc = X86_CPU_GET_CLASS(dev);
 CPUX86State *env = &cpu->env;
 Error *local_err = NULL;
-static bool ht_warned;
 unsigned requested_lbr_fmt;
 
 #if defined(CONFIG_TCG) && !defined(CONFIG_USER_ONLY)
@@ -7453,13 +7452,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
  */
 if (IS_AMD_CPU(env) &&
 !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
-cs->nr_threads > 1 && !ht_warned) {
-warn_report("This family of AMD CPU doesn't support "
-"hyperthreading(%d)",
-cs->nr_threads);
-error_printf("Please configure -smp options properly"
- " or try enabling topoext feature.\n");
-ht_warned = true;
+cs->nr_threads > 1) {
+warn_report_once("This family of AMD CPU doesn't support "
+ "hyperthreading(%d).", cs->nr_threads);
+error_report_once("Please configure -smp options properly"
+  " or try enabling topoext feature.");
 }
 
 #ifndef CONFIG_USER_ONLY
-- 
2.34.1

Re: [PATCH v1 01/11] Introduce a common abstract struct HostIOMMUDevice

[Cédric Le Goater]

Hello Zhenzhong,

On 3/19/24 12:58, Duan, Zhenzhong wrote:

Hi Cédric,


-Original Message-
From: Cédric Le Goater 
Sent: Tuesday, March 19, 2024 4:17 PM
To: Duan, Zhenzhong ; qemu-
de...@nongnu.org
Cc: alex.william...@redhat.com; eric.au...@redhat.com;
pet...@redhat.com; jasow...@redhat.com; m...@redhat.com;
j...@nvidia.com; nicol...@nvidia.com; joao.m.mart...@oracle.com; Tian,
Kevin ; Liu, Yi L ; Sun, Yi Y
; Peng, Chao P 
Subject: Re: [PATCH v1 01/11] Introduce a common abstract struct
HostIOMMUDevice

Hello Zhenzhong,

On 2/28/24 04:58, Zhenzhong Duan wrote:

HostIOMMUDevice will be inherited by two sub classes,
legacy and iommufd currently.

Introduce a helper function host_iommu_base_device_init to initialize it.

Suggested-by: Eric Auger 
Signed-off-by: Zhenzhong Duan 
---
   include/sysemu/host_iommu_device.h | 22 ++
   1 file changed, 22 insertions(+)
   create mode 100644 include/sysemu/host_iommu_device.h

diff --git a/include/sysemu/host_iommu_device.h

b/include/sysemu/host_iommu_device.h

new file mode 100644
index 00..fe80ab25fb
--- /dev/null
+++ b/include/sysemu/host_iommu_device.h
@@ -0,0 +1,22 @@
+#ifndef HOST_IOMMU_DEVICE_H
+#define HOST_IOMMU_DEVICE_H
+
+typedef enum HostIOMMUDevice_Type {
+HID_LEGACY,
+HID_IOMMUFD,
+HID_MAX,
+} HostIOMMUDevice_Type;
+
+typedef struct HostIOMMUDevice {
+HostIOMMUDevice_Type type;


A type field is not a good sign and that's where QOM is useful.


Yes, agree.
I didn't choose QOM because in iommufd-cdev series, VFIOContainer chooses not 
using QOM model.
See the discussion: https://lore.kernel.org/all/YmuFv2s5TPuw7K%2Fu@yekko/
I thought HostIOMMUDevice need to follow same rule.

But after further digging into this, I think it may be ok to use QOM model as 
long as we don't expose
HostIOMMUDevice in qapi/qom.json and not use USER_CREATABLE interface. Your 
thoughts?


yes. Can we change a bit this series to use QOM ? something like :

typedef struct HostIOMMUDevice {
Object parent;
} HostIOMMUDevice;

#define TYPE_HOST_IOMMU "host.iommu"

OBJECT_DECLARE_TYPE(HostIOMMUDevice, HostIOMMUClass, HOST_IOMMU)

struct HostIOMMUClass {

ObjectClass parent_class;

int (*get_type)(HostIOMMUDevice *hiod, uint64_t *type, Error **errp);

int (*get_cap)(HostIOMMUDevice *hiod, uint64_t *cap, Error **errp);
};

Inherited objects would be TYPE_HOST_IOMMU_IOMMUFD and TYPE_HOST_IOMMU_LEGACY.
Each class implementing the handlers or not (legacy mode).

The class handlers are introduced for the intel-iommu helper vtd_check_hdev()
in order to avoid using iommufd routines directly. HostIOMMUDevice is supposed
to abstract the Host IOMMU device, so we need to abstract also all the
interfaces to this object.

The .host_iommu_device_create() handler could be merged in .attach_device()
possibly. Anyhow, please use now object_new() and object_unref() instead.
host_iommu_base_device_init() is useless IMHO.





Is vtd_check_hdev() the only use of this field ?


Currently yes. virtio-iommu may have similar usage.


If so, can we simplify with a QOM interface in any way ?


QOM interface is a set of callbacks, guess you mean QOM class,
saying HostIOMMUDevice class, IOMMULegacyDevice class and IOMMUFDDevice class?


See above proposal. it should work fine.

Also, I think it is better to use a IOMMUFDBackend* parameter for
iommufd_device_get_info() to be consistent with the other routines.

Then It would interesting to see how this applies to Eric's series.

Thanks,

C.

[PATCH 1/3] target/i386/host-cpu: Consolidate the use of warn_report_once()

[Zhao Liu]

From: Zhao Liu 

Use warn_report_once() to get rid of the static local variable "warned".

Signed-off-by: Zhao Liu 
---
 target/i386/host-cpu.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/target/i386/host-cpu.c b/target/i386/host-cpu.c
index 92ecb7254b83..280e427c017c 100644
--- a/target/i386/host-cpu.c
+++ b/target/i386/host-cpu.c
@@ -55,18 +55,15 @@ static uint32_t host_cpu_adjust_phys_bits(X86CPU *cpu)
 {
 uint32_t host_phys_bits = host_cpu_phys_bits();
 uint32_t phys_bits = cpu->phys_bits;
-static bool warned;
 
 /*
  * Print a warning if the user set it to a value that's not the
  * host value.
  */
-if (phys_bits != host_phys_bits && phys_bits != 0 &&
-!warned) {
-warn_report("Host physical bits (%u)"
-" does not match phys-bits property (%u)",
-host_phys_bits, phys_bits);
-warned = true;
+if (phys_bits != host_phys_bits && phys_bits != 0) {
+warn_report_once("Host physical bits (%u)"
+ " does not match phys-bits property (%u)",
+ host_phys_bits, phys_bits);
 }
 
 if (cpu->host_phys_bits) {
-- 
2.34.1

[PATCH v2 3/3] edk2/seabios: use common extra version

[Gerd Hoffmann]

Bring a bit more consistency into the naming.

Signed-off-by: Gerd Hoffmann 
---
 roms/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/roms/Makefile b/roms/Makefile
index 783a5cab4f4c..dfed2b216a1e 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -41,8 +41,8 @@ x86_64_cross_prefix := $(call find-cross-prefix,x86_64)
 riscv32_cross_prefix := $(call find-cross-prefix,riscv32)
 riscv64_cross_prefix := $(call find-cross-prefix,riscv64)
 
-# tag our seabios builds
-SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
+# tag our firmware builds
+FIRMWARE_EXTRAVERSION = -prebuilt.qemu.org
 
 #
 # EfiRom utility is shipped with edk2 / tianocore, in BaseTools/
@@ -93,12 +93,12 @@ build-seabios-config-%: config.%
mkdir -p seabios/builds/$*
cp $< seabios/builds/$*/.config
$(MAKE) -C seabios \
-   EXTRAVERSION=$(SEABIOS_EXTRAVERSION) \
+   EXTRAVERSION=$(FIRMWARE_EXTRAVERSION) \
CROSS_PREFIX=$(x86_64_cross_prefix) \
KCONFIG_CONFIG=$(CURDIR)/seabios/builds/$*/.config \
OUT=$(CURDIR)/seabios/builds/$*/ oldnoconfig
$(MAKE) -C seabios \
-   EXTRAVERSION=$(SEABIOS_EXTRAVERSION) \
+   EXTRAVERSION=$(FIRMWARE_EXTRAVERSION) \
CROSS_PREFIX=$(x86_64_cross_prefix) \
KCONFIG_CONFIG=$(CURDIR)/seabios/builds/$*/.config \
OUT=$(CURDIR)/seabios/builds/$*/ all
@@ -159,7 +159,7 @@ edk2-version: edk2
 
 efi: edk2-version
$(PYTHON) edk2-build.py --config edk2-build.config \
-   --version-override "$(EDK2_STABLE)-for-qemu" \
+   --version-override "$(EDK2_STABLE)$(FIRMWARE_EXTRAVERSION)" \
--release-date "$(EDK2_DATE)" \
--silent --no-logs
rm -f ../pc-bios/edk2-*.fd.bz2
-- 
2.44.0

[PATCH v2 2/3] edk2: commit version info

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 roms/edk2-version | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 roms/edk2-version

diff --git a/roms/edk2-version b/roms/edk2-version
new file mode 100644
index ..1594ed8c4de9
--- /dev/null
+++ b/roms/edk2-version
@@ -0,0 +1,2 @@
+EDK2_STABLE = edk2-stable202402
+EDK2_DATE = 02/14/2024
-- 
2.44.0

Re: vhost-user-blk reconnect issue

[Stefano Garzarella]

Hi Yajun,

On Mon, Mar 25, 2024 at 10:54:13AM +, Yajun Wu wrote:

Hi experts,

With latest QEMU (8.2.90), we find two vhost-user-blk backend reconnect 
failure scenarios:


Do you know if has it ever worked and so it's a regression, or have we 
always had this problem?


Thanks,
Stefano


1. Disconnect vhost-user-blk backend before guest driver probe vblk device, 
then reconnect backend after guest driver probe device. QEMU won't send out any 
vhost messages to restore backend.
This is because vhost->vdev is NULL before guest driver probe vblk device, so 
vhost_user_blk_disconnect won't be called, s->connected is still true. Next 
vhost_user_blk_connect will simply return without doing anything.

2. modprobe -r virtio-blk inside VM, then disconnect backend, then reconnect 
backend, then modprobe virtio-blk. QEMU won't send messages in vhost_dev_init.
This is because rmmod will let qemu call vhost_user_blk_stop, vhost->vdev also 
become NULL(in vhost_dev_stop), vhost_user_blk_disconnect won't be called. Again 
s->connected is still true, even chr connect is closed.

I think even vhost->vdev is NULL, vhost_user_blk_disconnect should be called 
when chr connect close?
Hope we can have a fix soon.


Thanks,
Yajun

Re: [PATCH] tests/qtest: Standardize qtest function caller strings.

[Het Gala]

On 27/03/24 2:37 am, Fabiano Rosas wrote:

Het Gala  writes:

Some comments, mostly just thinking out loud...


For  --> migrate
//
//O:/...

For  --> validate
///O:/O:/
/O:/O:/...

Do we need an optional 'capability' element? I'm not sure how practical
is to leave that as 'others', because that puts it at the end of the
string. We'd want the element that's more important/with more variants
to be towards the start of the string so we can run all tests of the
same kind with the -r option.

While also looking at different functions for figuring out the transport
and invocation, my observation was that, there might be many capabilities
added to the same test, while it might not be important also.
Ex: /migrate/multifd/tcp/plain
1. multifd is defined as a migration mode.
2. It is also a capability, and comes in 2 parts [multifd, multifd-channels]
   though one is a capability and another is parameter
Similarly in other examples of compression, there are many capabilities
and parameters added, but it might be not important to mention that ?

Secondly, there are multiple migration capabilities IIRC (> 15). And a test
requiring multiple capabilities, the overall string would be too long, and
not that important also to mention all capabilities.

Just thinking out of mind - Can we have selective list of capabilities ? 
1. multifd 2. compress (again, there might be confusion with multifd 
compression methods like zstd, zlib and just 'compress') 3. zero-page 
(This will have sub capabilities ?)



test-type:: migrate | validate

We could alternatively drop migration|migrate|validate. They are kind of
superfluous.

I agree with the above comment. 'migrate' and 'validate' have a different
set of variables required, some necessary, while other optional. IMO this
will help is in streamlining the design further.

migration-mode
   a. migrate --> :: precopy | postcopy | multifd
   b. validate -->:: (what to validate)
methods  :: preempt | recovery | reboot | suspend | simple

I want some inputs here.
1. is there a better variable name rather than 'methods'
2. 'simple' does not fit perfect here IMO.

transport:: tcp | fd | unix | file
invocation   :: uri | channels | both
CompressionType  :: zlib | zstd | none

s/none/nocomp/ ? We're already familiar with that.

Ack. Will change that.

encryptionType   :: tls | plain

s/plain/notls/ ?

What if there is another encryption technique in future ?

Or maybe we simply omit the noop options. It would make the string way
shorter in most cases.

This might be a better approach. Can have some keys/variables as optional
while some necessary. For ex: for 'migrate' - transport and invocation
might be necessary while it might not be necessary for 'validate' qtests

validate-test-result :: success | failure
others   :: other comments/capability that needs to be
 addressed. Can be multiple

(more than one applicable, separated by using '-' in between)
O: optional

Signed-off-by: Het Gala
Suggested-by: Fabiano Rosas
---
  tests/qtest/migration-test.c | 143 ++-
  1 file changed, 72 insertions(+), 71 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index bd9f4b9dbb..bf4d000b76 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c

Regards,
Het Gala

Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

[Daniel P . Berrangé]

On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
> On Tue, 26 Mar 2024 14:29:58 +0100
> Philippe Mathieu-Daudé  wrote:
> 
> > Hi Igor,
> > 
> > On 26/3/24 14:08, Thomas Huth wrote:
> > > 
> > > s/iaspc/isapc/ in the subject
> > > 
> > > On 26/03/2024 13.51, Igor Mammedov wrote:  
> > >> ISAPC machine was introduced 25 years ago and it's a lot of time since
> > >> such machine was around with real ISA only PC hardware practically 
> > >> defunct.
> > >> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on 
> > >> RHEL9 host
> > >> in only TCG mode, while in KVM mode it hung in the middle of boot)  
> > 
> > I'm quite opposed to this patch. QEMU models various very-old /
> > defunct hardware. I'm pretty sure Bernhard and myself are OK to
> > keep maintaining it, besides we are working in separating it from
> > the i440fx+piix machine. Also, this machine is particularly
> > interesting for my single-binary experiments.
> 
> it would not be fair to ask you or Bernard to deal with every
> case where ISAPC related code gets in a way, nor it's fair to
> ask other contributors to ensure that their patches don't break
> semi-working ISAPC or refactor code that relates to it. 
> 
> [
> for example I'd like to refactor smbios parts in the image
> ACPI table builder, but the I'd have to do it for legacy
> part as well without means to verify that. Sure it can be
> done but at cost of extra time spent to rewrite something
> that would never be used and to find test env to verify
> touched code.
> ]

Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
is from 1999, while PCI has been around since 1992.

IOW, we shouldn't even be exposing SMBIOS with the isapc
machine type. If we address that, then isapc has no impact
on your ability to refactor SMBIOS code.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH-for-9.1 v2 14/21] hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug()

[David Hildenbrand]

  void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp)
+Error **errp)
  {
  const MemoryDeviceClass *mdc = MEMORY_DEVICE_GET_CLASS(md);
  Error *local_err = NULL;
@@ -388,14 +388,10 @@ void memory_device_pre_plug(MemoryDeviceState *md, 
MachineState *ms,
  return;
  }
  
-if (legacy_align) {

-align = *legacy_align;
-} else {
-if (mdc->get_min_alignment) {
-align = mdc->get_min_alignment(md);
-}
-align = MAX(align, memory_region_get_alignment(mr));
+if (mdc->get_min_alignment) {
+align = mdc->get_min_alignment(md);
  }
+align = MAX(align, memory_region_get_alignment(mr));
  addr = mdc->get_addr(md);
  addr = memory_device_get_free_addr(ms, !addr ? NULL : &addr, align,
 memory_region_size(mr), &local_err);


Very nice!

Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb

Re: [PATCH v2 2/2] target/riscv: Support xtheadmaee for thead-c906

[Conor Dooley]

Christoph linked here on his submission to Linux of a fix for this, so I
am reviving this to leave a couple comments :)

On Thu, Feb 15, 2024 at 02:24:02PM +1000, Alistair Francis wrote:
> On Mon, Feb 5, 2024 at 6:37 PM Christoph Müllner
>  wrote:
> > On Mon, Feb 5, 2024 at 3:42 AM Alistair Francis  
> > wrote:
> > > On Sun, Feb 4, 2024 at 3:44 PM LIU Zhiwei  
> > > wrote:

> > > >  ppn = (pte & (target_ulong)PTE_PPN_MASK) >> PTE_PPN_SHIFT;
> > >
> > > Unfortunately we won't be able to take this upstream. This is core
> > > QEMU RISC-V code that is now being changed against the spec. I think
> > > adding the CSR is fine, but we can't take this core change.
> > >
> > > A fix that works for everyone should be supporting the th_mxstatus
> > > CSR, but don't support setting the TH_MXSTATUS_MAEE bit. That way
> > > guests can detect that the bit isn't set and not use the reserved bits
> > > in the PTE. From my understanding the extra PTE bits are related to
> > > cache control in the hardware, which we don't need here
> >
> > Sounds good! Let me recap the overall plan:
> > * QEMU does not emulate MAEE, but signals that MAEE is not available
> > by setting TH_MXSTATUS_MAEE to 0.
> 
> Yep!
> 
> > * Consequence: The c906 emulation does not enable any page-base memory
> > attribute mechanism.
> 
> Exactly
> 
> > * OpenSBI tests the TH_MXSTATUS_MAEE bit (M-mode only) and provides
> > that information to user-space (e.g. DTB).
> 
> To the kernel, but yep!
> 
> > * The current Linux errata code will be enhanced to not assume MAEE
> > for each core with T-Head vendor ID, but also query the MAEE bit and
> > ensure it is set.
> 
> I feel like it should already do that :)

It doesn't quite do this right now. It only makes the assumption for
CPUs where marchid and mvendorid are zero. The c908, and I think Guo Ren
confirmed it will be the case going forward, sets these to non-zero
values. We should have always required a dt property be set, rather than
using m*id, but we can't go back on that for these devices. Going
forward, if there are more CPUs that want to use this e.g. C908 in MAEE
mode (it can do svpbmt too) I'm gonna require it is explicitly set in
DT.

> > * Booting on a QEMU c906 will not enable MAEE, but will still boot.
> 
> That's the hope
> 
> >
> > We never had a complete MAEE implementation upstream, because that's not 
> > needed.
> > But until recently we could mess with reserved bits how we want.
> > Now that QEMU is more restrictive about reserved bits in the PTEs, we
> > need to address this in the kernel.
> >
> > The downside is, that the kernel now sees a c906 CPU without MAEE and
> > such a CPU does not exist.
> 
> Yeah, that is the downside. But in reality a CPU could exist that
> doesn't allow seeing MAEE, so I don't think it's that insane.

Aye, and the case of a new CPU disabling it but not setting m*id will be
a pain.

> > But that's fine, because this does not require extra code to handle this 
> > case.
> > Also, the additional check for the MAEE bit in the kernel errata
> > probing code is likely needed anyway for future T-Head CPUs.
> 
> Exactly

I don't really want to have extension detection side channels like this
in Linux if it can be at all avoided, I'd rather get this information from
DT or ACPI. The marchid == mvendorid == 0x0 case has a pretty high chance
of needing some special handling in the future though, so something
targeting those cases when there's some demonstrable problem seems fair
to me.

Cheers,
Conor.


signature.asc
Description: PGP signature

Compiling QEMU with different optimization levels & -Werror=maybe-uninitialized

[Marc-André Lureau]

Hi,

Depending -Doptimization=, I get different results (GCC 13.2.1)
- g: produces -Werror=maybe-uninitialized errors
- 0: clean build
- 1: produces -Werror=maybe-uninitialized errors
- 2: clean build
- 3: produces few -Werror=maybe-uninitialized errors
- s: produces -Werror=maybe-uninitialized errors

They are about 20, probably false-positives, although it's
understandable the compiler is confused as I am too sometime!

Is it a known issue? Are we willing to help the compiler in all those
optimization levels? I can send a patch series for review in this
case.

thanks

--
Marc-André Lureau

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Daniel Henrique Barboza]

On 3/27/24 07:14, Christian Schoenebeck wrote:

On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote:

On 3/27/24 05:47, Christian Schoenebeck wrote:

On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:

On 3/26/24 14:05, Greg Kurz wrote:

On Tue, 26 Mar 2024 10:26:04 -0300
Daniel Henrique Barboza  wrote:


The local 9p driver in virtio-9p-test.c its temporary dir right at the
start of qos-test (via virtio_9p_create_local_test_dir()) and only
deletes it after qos-test is finished (via
virtio_9p_remove_local_test_dir()).

This means that any qos-test machine that ends up running virtio-9p-test local
tests more than once will end up re-using the same temp dir. This is
what's happening in [1] after we introduced the riscv machine nodes: if
we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
this is what happens:

- a temp dir is created, e.g. qtest-9p-local-WZLDL2;

- virtio-9p-device tests will run virtio-9p-test successfully;

- virtio-9p-pci tests will run virtio-9p-test, and fail right at the
 first slow test at fs_create_dir() because the "01" file was already
 created by fs_create_dir() test when running with the virtio-9p-device.

We can fix it by making every test clean up their changes in the
filesystem after they're done. But we don't need every test either:
what fs_create_file() does is already exercised in fs_unlinkat_dir(),
i.e. a dir is created, verified to be created, and then removed. Fixing
fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
both. The same theme follows every test in virtio-9p-test.c, where the
'unlikat' variant does the same thing the 'create' does but with some
cleaning in the end.

Consolide some tests as follows:

- fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
 fs_create_unlinkat_dir();

- fs_create_file() is removed. fs_unlinkat_file() is renamed to
 fs_create_unlinkat_file(). The "04" dir it uses is now being removed;

- fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
 fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
 creates is now being removed.



The  change looks good functionally but it breaks the legitimate assumption
that files "06/*" come from test #6 and so on... I think you should consider
renumbering to avoid confusion when debugging logs.

Since this will bring more hunks, please split this in enough reviewable
patches.


Fair enough. Let me cook a v2. Thanks,


Wouldn't it be much simpler to just change the name of the temporary
directory, such that it contains the device name as well? Then these tests
runs would run on independent directories and won't interfere with each other
and that wouldn't need much changes I guess.


That's true. If we were just trying to fix the issue then I would go with this
approach since it's simpler. But given that we're also cutting half the tests 
while
retaining the coverage I think this approach is worth the extra code.


Well, I am actually not so keen into all those changes. These tests were
intentionally split, and yes with costs of a bit redundant (test case) code.
But they were cleanly build up on each other, from fundamental requirements
like whether it is possible to create a directory and file ... and then the
subsequent tests would become more and more demanding.

That way it was easier to review if somebody reports a test to fail, because
you could immediately see whether the preceding fundamental tests succeeded.


The current test design is flawed. It's based on a premise that doesn't happen, 
i.e.
a new temp dir will be created every time the test suit is executed. In reality 
the
temp dir is created only once in the constructor of the test, at the start of 
qos-test
(tests/qtest/qos-test.c, run_one_test()) and removed only once at the destructor
at the end of the run.

It's not possible to add a 'device name' in the created temp dir because we're 
too early
in the process, the tests didn't start at that point. So, with the current temp 
dir design,
the tests needs to clean themselves up after each run.

Here's the alternatives I'm willing to go for:

- what I just sent in v2;

- add cleanups in all existing tests. We can keep all of them, but the 'create' 
tests
will be carbon copies of the 'unlinkat' tests but with different names. Can be 
done;

- if we really want the tests untouched we can rework how the 'temp dir' is 
created/deleted.
The test dir will be created and removed after each test via the 'before' 
callback. To be
honest this seems like the best approach we can take, aside from what I did in 
v2, and
it's on par with how tests like vhost-user-test.c works.


Thanks,


Daniel



/Christian

[RFC] util/error-report: Add "error: " prefix for error-level report

[Zhao Liu]

From: Zhao Liu 

When vreport() was introduced, there was no prefix for error-level
(REPORT_TYPE_ERROR) report. The original reason is "To maintain
compatibility we don't add anything here" as Alistair said in his
RFC v3 series [1].

This was done in the context of inheriting the original error_report()
interface without the prefix style. And it was also useful to have a
means of error handling, such as exit(), when error occurs, so that the
error message - the most serious level - can be noticed by the user.

Nowadays, however, error_report() and its variants have a tendency to be
"abused": it is used a lot just for the sake of logging something more
noticeable than the "warn" or "info" level, in the absence of
appropriate error handling logic.

But, in the use case above, due to the lack of a prefix, it is in fact
less informative to the user than warn_report()/info_report() (with
"warn:" or "info: " prfix), which does not match its highest level.

Therefore, add "error: " prefix for error-level report.

[1]: https://lore.kernel.org/qemu-devel/87r2xuay5h@dusky.pond.sub.org/#t

Signed-off-by: Zhao Liu 
---
 util/error-report.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/util/error-report.c b/util/error-report.c
index 6e44a5573217..e981c0b032f0 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -213,6 +213,7 @@ static void vreport(report_type type, const char *fmt, 
va_list ap)
 
 switch (type) {
 case REPORT_TYPE_ERROR:
+error_printf("error: ");
 break;
 case REPORT_TYPE_WARNING:
 error_printf("warning: ");
-- 
2.34.1

Re: [PATCH-for-9.1 v2 13/21] hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()

[David Hildenbrand]

On 27.03.24 10:51, Philippe Mathieu-Daudé wrote:

'legacy_align' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-11-phi...@linaro.org>
---


I was really confused for a second until I saw that this series is 
dependent on another one.


Please make sure to CC people you CC on patches to also CC on the cover 
letter.


Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb

[PATCH] MAINTAINERS: Fix error-report.c entry

[Zhao Liu]

From: Zhao Liu 

The commit 15002f60f792 ("util: rename qemu-error.c to match its header
name") renamed util/qemu-error.c to util/error-report.c but missed to
change the corresponding entry.

To avoid get_maintainer.pl failing, update the error-report.c entry.

Signed-off-by: Zhao Liu 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a07af6b9d48e..197a06b42ff0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3013,7 +3013,7 @@ F: include/qapi/error.h
 F: include/qemu/error-report.h
 F: qapi/error.json
 F: util/error.c
-F: util/qemu-error.c
+F: util/error-report.c
 F: scripts/coccinelle/err-bad-newline.cocci
 F: scripts/coccinelle/error-use-after-free.cocci
 F: scripts/coccinelle/error_propagate_null.cocci
-- 
2.34.1

Re: Compiling QEMU with different optimization levels & -Werror=maybe-uninitialized

[Daniel P . Berrangé]

On Wed, Mar 27, 2024 at 03:28:08PM +0400, Marc-André Lureau wrote:
> Hi,
> 
> Depending -Doptimization=, I get different results (GCC 13.2.1)
> - g: produces -Werror=maybe-uninitialized errors
> - 0: clean build
> - 1: produces -Werror=maybe-uninitialized errors
> - 2: clean build
> - 3: produces few -Werror=maybe-uninitialized errors
> - s: produces -Werror=maybe-uninitialized errors
> 
> They are about 20, probably false-positives, although it's
> understandable the compiler is confused as I am too sometime!

If any of those maybe-uninitialized warnings are genuine bugs, our
use of use of -ftrivial-auto-var-init provides a safety net that
protects us

> 
> Is it a known issue? Are we willing to help the compiler in all those
> optimization levels? I can send a patch series for review in this
> case.

...none the less, IMHO, it is good practice to initialize all local stack
allocated variables at time of declaration no matter what. So if you have
patches to clear those false positives, I'd suggest  we just do it.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH-for-9.0 v2 05/19] hw/display: Restrict xen_register_framebuffer() call to Xen

[Anthony PERARD]

On Tue, Nov 14, 2023 at 03:38:01PM +0100, Philippe Mathieu-Daudé wrote:
> Only call xen_register_framebuffer() when Xen is enabled.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

I don't think this patch is very useful but it's fine, so:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH for-9.1 v2 09/11] hostmem: add a new memory backend based on POSIX shm_open()

[David Hildenbrand]

On 27.03.24 11:23, Stefano Garzarella wrote:

On Tue, Mar 26, 2024 at 03:45:52PM +0100, David Hildenbrand wrote:

+mode = 0;
+oflag = O_RDWR | O_CREAT | O_EXCL;
+backend_name = host_memory_backend_get_name(backend);
+
+/*
+ * Some operating systems allow creating anonymous POSIX shared memory
+ * objects (e.g. FreeBSD provides the SHM_ANON constant), but this is not
+ * defined by POSIX, so let's create a unique name.
+ *
+ * From Linux's shm_open(3) man-page:
+ *   For  portable  use,  a shared  memory  object should be identified
+ *   by a name of the form /somename;"
+ */
+g_string_printf(shm_name, "/qemu-" FMT_pid "-shm-%s", getpid(),
+backend_name);


Hm, shouldn't we just let the user specify a name, and if no name was
specified, generate one ourselves?


I thought about it and initially did it that way, but then some problems
came up so I tried to keep it as simple as possible for the user and for
our use case (having an fd associated with memory and sharing it with
other processes).

The problems I had were:

- what mode_t to use if the object does not exist and needs to be
created? >
- exclude O_EXCL if the user passes the name since they may have already
created it?


I'd handle both like we handle files. But I understand now that you 
really just want to "simulate" memfd.




- call shm_unlink() only at object deallocation?


Right, we don't really do that for ordinary files, they keep existing. 
We only have the "discard-data" property to free up memory.


For memfd, it just happens "automatically". They cannot be looked up by 
name, and once the last user closes the fd, it gets destroyed.




So I thought that for now we only support the "anonymous" mode, and if
in the future we have a use case where the user wants to specify the
name, we can add it later.


Okay, so for now you really only want an anonymous fd that behaves like 
a memfd, got it.


Likely we should somehow fail if the "POSIX shared memory object" 
already exists. Hmm.




That said, if you think it's already useful from the beginning, I can
add the name as an optional parameter.



I'm also not quite sure if "host_memory_backend_get_name()" should be
used for the purpose here.


What problem do you see? As an alternative I thought of a static
counter.


If it's really just an "internal UUID", as we'll remove the file using 
shm_unlink(), then the name in fact shouldn't matter and this would be 
fine. Correct?



So I assume if we ever want to have non-anonymous fds here, we'd pass in 
a new property "name", and change the logic how we open/unlink. Makes sense.


--
Cheers,

David / dhildenb

Re: [PATCH-for-9.0 v2 08/19] hw/xen: Remove unused Xen stubs

[Anthony PERARD]

On Tue, Nov 14, 2023 at 03:38:04PM +0100, Philippe Mathieu-Daudé wrote:
> All these stubs are protected by a 'if (xen_enabled())' check.

Are you sure? There's still nothing that prevent a compiler from wanting
those, I don't think.

Sure, often compilers will remove dead code in `if(0){...}`, but there's
no guaranty, is there?

Cheers,

-- 
Anthony PERARD

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Christian Schoenebeck]

On Wednesday, March 27, 2024 12:28:17 PM CET Daniel Henrique Barboza wrote:
> On 3/27/24 07:14, Christian Schoenebeck wrote:
> > On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote:
> >> On 3/27/24 05:47, Christian Schoenebeck wrote:
> >>> On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:
>  On 3/26/24 14:05, Greg Kurz wrote:
> > On Tue, 26 Mar 2024 10:26:04 -0300
> > Daniel Henrique Barboza  wrote:
> >
> >> The local 9p driver in virtio-9p-test.c its temporary dir right at the
> >> start of qos-test (via virtio_9p_create_local_test_dir()) and only
> >> deletes it after qos-test is finished (via
> >> virtio_9p_remove_local_test_dir()).
> >>
> >> This means that any qos-test machine that ends up running 
> >> virtio-9p-test local
> >> tests more than once will end up re-using the same temp dir. This is
> >> what's happening in [1] after we introduced the riscv machine nodes: if
> >> we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
> >> this is what happens:
> >>
> >> - a temp dir is created, e.g. qtest-9p-local-WZLDL2;
> >>
> >> - virtio-9p-device tests will run virtio-9p-test successfully;
> >>
> >> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the
> >>  first slow test at fs_create_dir() because the "01" file was 
> >> already
> >>  created by fs_create_dir() test when running with the 
> >> virtio-9p-device.
> >>
> >> We can fix it by making every test clean up their changes in the
> >> filesystem after they're done. But we don't need every test either:
> >> what fs_create_file() does is already exercised in fs_unlinkat_dir(),
> >> i.e. a dir is created, verified to be created, and then removed. Fixing
> >> fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
> >> both. The same theme follows every test in virtio-9p-test.c, where the
> >> 'unlikat' variant does the same thing the 'create' does but with some
> >> cleaning in the end.
> >>
> >> Consolide some tests as follows:
> >>
> >> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
> >>  fs_create_unlinkat_dir();
> >>
> >> - fs_create_file() is removed. fs_unlinkat_file() is renamed to
> >>  fs_create_unlinkat_file(). The "04" dir it uses is now being 
> >> removed;
> >>
> >> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
> >>  fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
> >>  creates is now being removed.
> >>
> >
> > The  change looks good functionally but it breaks the legitimate 
> > assumption
> > that files "06/*" come from test #6 and so on... I think you should 
> > consider
> > renumbering to avoid confusion when debugging logs.
> >
> > Since this will bring more hunks, please split this in enough reviewable
> > patches.
> 
>  Fair enough. Let me cook a v2. Thanks,
> >>>
> >>> Wouldn't it be much simpler to just change the name of the temporary
> >>> directory, such that it contains the device name as well? Then these tests
> >>> runs would run on independent directories and won't interfere with each 
> >>> other
> >>> and that wouldn't need much changes I guess.
> >>
> >> That's true. If we were just trying to fix the issue then I would go with 
> >> this
> >> approach since it's simpler. But given that we're also cutting half the 
> >> tests while
> >> retaining the coverage I think this approach is worth the extra code.
> > 
> > Well, I am actually not so keen into all those changes. These tests were
> > intentionally split, and yes with costs of a bit redundant (test case) code.
> > But they were cleanly build up on each other, from fundamental requirements
> > like whether it is possible to create a directory and file ... and then the
> > subsequent tests would become more and more demanding.
> > 
> > That way it was easier to review if somebody reports a test to fail, because
> > you could immediately see whether the preceding fundamental tests succeeded.
> 
> The current test design is flawed. It's based on a premise that doesn't 
> happen, i.e.
> a new temp dir will be created every time the test suit is executed. In 
> reality the
> temp dir is created only once in the constructor of the test, at the start of 
> qos-test
> (tests/qtest/qos-test.c, run_one_test()) and removed only once at the 
> destructor
> at the end of the run.
> 
> It's not possible to add a 'device name' in the created temp dir because 
> we're too early
> in the process, the tests didn't start at that point. So, with the current 
> temp dir design,
> the tests needs to clean themselves up after each run.
> 
> Here's the alternatives I'm willing to go for:
> 
> - what I just sent in v2;
> 
> - add cleanups in all existing tests. We can keep all of th

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Greg Kurz]

On Wed, 27 Mar 2024 13:26:45 +0100
Christian Schoenebeck  wrote:

> On Wednesday, March 27, 2024 12:28:17 PM CET Daniel Henrique Barboza wrote:
> > On 3/27/24 07:14, Christian Schoenebeck wrote:
> > > On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza 
> > > wrote:
> > >> On 3/27/24 05:47, Christian Schoenebeck wrote:
> > >>> On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:
> >  On 3/26/24 14:05, Greg Kurz wrote:
> > > On Tue, 26 Mar 2024 10:26:04 -0300
> > > Daniel Henrique Barboza  wrote:
> > >
> > >> The local 9p driver in virtio-9p-test.c its temporary dir right at 
> > >> the
> > >> start of qos-test (via virtio_9p_create_local_test_dir()) and only
> > >> deletes it after qos-test is finished (via
> > >> virtio_9p_remove_local_test_dir()).
> > >>
> > >> This means that any qos-test machine that ends up running 
> > >> virtio-9p-test local
> > >> tests more than once will end up re-using the same temp dir. This is
> > >> what's happening in [1] after we introduced the riscv machine nodes: 
> > >> if
> > >> we enable slow tests with the '-m slow' flag using 
> > >> qemu-system-riscv64,
> > >> this is what happens:
> > >>
> > >> - a temp dir is created, e.g. qtest-9p-local-WZLDL2;
> > >>
> > >> - virtio-9p-device tests will run virtio-9p-test successfully;
> > >>
> > >> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the
> > >>  first slow test at fs_create_dir() because the "01" file was 
> > >> already
> > >>  created by fs_create_dir() test when running with the 
> > >> virtio-9p-device.
> > >>
> > >> We can fix it by making every test clean up their changes in the
> > >> filesystem after they're done. But we don't need every test either:
> > >> what fs_create_file() does is already exercised in fs_unlinkat_dir(),
> > >> i.e. a dir is created, verified to be created, and then removed. 
> > >> Fixing
> > >> fs_create_file() would turn it into fs_unlikat_dir(), so we don't 
> > >> need
> > >> both. The same theme follows every test in virtio-9p-test.c, where 
> > >> the
> > >> 'unlikat' variant does the same thing the 'create' does but with some
> > >> cleaning in the end.
> > >>
> > >> Consolide some tests as follows:
> > >>
> > >> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
> > >>  fs_create_unlinkat_dir();
> > >>
> > >> - fs_create_file() is removed. fs_unlinkat_file() is renamed to
> > >>  fs_create_unlinkat_file(). The "04" dir it uses is now being 
> > >> removed;
> > >>
> > >> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
> > >>  fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir 
> > >> it
> > >>  creates is now being removed.
> > >>
> > >
> > > The  change looks good functionally but it breaks the legitimate 
> > > assumption
> > > that files "06/*" come from test #6 and so on... I think you should 
> > > consider
> > > renumbering to avoid confusion when debugging logs.
> > >
> > > Since this will bring more hunks, please split this in enough 
> > > reviewable
> > > patches.
> > 
> >  Fair enough. Let me cook a v2. Thanks,
> > >>>
> > >>> Wouldn't it be much simpler to just change the name of the temporary
> > >>> directory, such that it contains the device name as well? Then these 
> > >>> tests
> > >>> runs would run on independent directories and won't interfere with each 
> > >>> other
> > >>> and that wouldn't need much changes I guess.
> > >>
> > >> That's true. If we were just trying to fix the issue then I would go 
> > >> with this
> > >> approach since it's simpler. But given that we're also cutting half the 
> > >> tests while
> > >> retaining the coverage I think this approach is worth the extra code.
> > > 
> > > Well, I am actually not so keen into all those changes. These tests were
> > > intentionally split, and yes with costs of a bit redundant (test case) 
> > > code.
> > > But they were cleanly build up on each other, from fundamental 
> > > requirements
> > > like whether it is possible to create a directory and file ... and then 
> > > the
> > > subsequent tests would become more and more demanding.
> > > 
> > > That way it was easier to review if somebody reports a test to fail, 
> > > because
> > > you could immediately see whether the preceding fundamental tests 
> > > succeeded.
> > 
> > The current test design is flawed. It's based on a premise that doesn't 
> > happen, i.e.
> > a new temp dir will be created every time the test suit is executed. In 
> > reality the
> > temp dir is created only once in the constructor of the test, at the start 
> > of qos-test
> > (tests/qtest/qos-test.c, run_one_test()) and removed only once at the 
> > destructor
> > at the end of the r

Re: [RFC] util/error-report: Add "error: " prefix for error-level report

[Thomas Huth]

On 27/03/2024 12.46, Zhao Liu wrote:

From: Zhao Liu 

When vreport() was introduced, there was no prefix for error-level
(REPORT_TYPE_ERROR) report. The original reason is "To maintain
compatibility we don't add anything here" as Alistair said in his
RFC v3 series [1].

This was done in the context of inheriting the original error_report()
interface without the prefix style. And it was also useful to have a
means of error handling, such as exit(), when error occurs, so that the
error message - the most serious level - can be noticed by the user.

Nowadays, however, error_report() and its variants have a tendency to be
"abused": it is used a lot just for the sake of logging something more
noticeable than the "warn" or "info" level, in the absence of
appropriate error handling logic.

But, in the use case above, due to the lack of a prefix, it is in fact
less informative to the user than warn_report()/info_report() (with
"warn:" or "info: " prfix), which does not match its highest level.

Therefore, add "error: " prefix for error-level report.

[1]: https://lore.kernel.org/qemu-devel/87r2xuay5h@dusky.pond.sub.org/#t

Signed-off-by: Zhao Liu 
---
  util/error-report.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/util/error-report.c b/util/error-report.c
index 6e44a5573217..e981c0b032f0 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -213,6 +213,7 @@ static void vreport(report_type type, const char *fmt, 
va_list ap)
  
  switch (type) {

  case REPORT_TYPE_ERROR:
+error_printf("error: ");
  break;
  case REPORT_TYPE_WARNING:
  error_printf("warning: ");


Sounds like a good idea to me, but I think you should then also remove
the hard-coded "error:" strings in the various error_reports():

$ grep -ri 'error_report.*"error:'
migration/block-dirty-bitmap.c:error_report("Error: block device name is not 
set");
migration/block-dirty-bitmap.c:error_report("Error: Unknown bitmap 
alias '%s' on node "
migration/block-dirty-bitmap.c:error_report("Error: unknown dirty 
bitmap "
migration/block-dirty-bitmap.c:error_report("Error: block device name is not 
set");
target/i386/kvm/kvm.c:error_report("error: failed to set MSR 0x%" PRIx32 " 
to 0x%" PRIx64,
target/i386/kvm/kvm.c:error_report("error: failed to get MSR 0x%" 
PRIx32,
util/vhost-user-server.c:error_report("Error: too big message request: %d, 
"
accel/hvf/hvf-all.c:error_report("Error: HV_ERROR");
accel/hvf/hvf-all.c:error_report("Error: HV_BUSY");
accel/hvf/hvf-all.c:error_report("Error: HV_BAD_ARGUMENT");
accel/hvf/hvf-all.c:error_report("Error: HV_NO_RESOURCES");
accel/hvf/hvf-all.c:error_report("Error: HV_NO_DEVICE");
accel/hvf/hvf-all.c:error_report("Error: HV_UNSUPPORTED");
accel/hvf/hvf-all.c:error_report("Error: HV_DENIED");
monitor/hmp-cmds.c:error_reportf_err(err, "Error: ");
hw/arm/xlnx-zcu102.c:error_report("ERROR: RAM size 0x%" PRIx64 " above max 
supported of "
hw/block/dataplane/xen-block.c:error_report("error: unknown operation 
(%d)", request->req.operation);
hw/block/dataplane/xen-block.c:error_report("error: write req for ro 
device");
hw/block/dataplane/xen-block.c:error_report("error: nr_segments too 
big");
hw/block/dataplane/xen-block.c:error_report("error: first > last 
sector");
hw/block/dataplane/xen-block.c:error_report("error: page crossing");
hw/block/dataplane/xen-block.c:error_report("error: access beyond end of 
file");
hw/rdma/rdma_backend.c:rdma_error_report("Error: Not a MAD request, 
skipping");
hw/s390x/s390-skeys.c:error_report("Error: Setting storage keys for pages 
with unallocated "
hw/s390x/s390-skeys.c:error_report("Error: Getting storage keys for pages 
with unallocated "
hw/usb/bus.c:error_report("Error: no usb bus to attach usbdevice %s, "
gdbstub/gdbstub.c:error_report("Error: Bad gdb register numbering for 
'%s', "

 Thomas

[PATCH-for-9.1] target/nios2: Remove machines and system emulation

[Philippe Mathieu-Daudé]

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").

Cc: Marek Vasut 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS   |   4 -
 docs/about/deprecated.rst |   5 -
 docs/about/emulation.rst  |   3 -
 docs/about/removed-features.rst   |   5 +
 docs/system/replay.rst|   2 +-
 configs/devices/nios2-softmmu/default.mak |   6 -
 configs/targets/nios2-softmmu.mak |   2 -
 qapi/machine.json |   2 +-
 hw/nios2/boot.h   |  10 -
 include/hw/intc/nios2_vic.h   |  66 
 include/sysemu/arch_init.h|   1 -
 target/nios2/cpu-param.h  |   6 +-
 target/nios2/cpu.h|  42 ---
 target/nios2/helper.h |   9 -
 target/nios2/mmu.h|  52 ---
 hw/intc/nios2_vic.c   | 313 --
 hw/nios2/10m50_devboard.c | 181 ---
 hw/nios2/boot.c   | 234 --
 hw/nios2/generic_nommu.c  | 101 --
 target/nios2/cpu.c| 160 +-
 target/nios2/helper.c | 371 --
 target/nios2/mmu.c| 216 -
 target/nios2/monitor.c|  35 --
 target/nios2/nios2-semi.c | 230 --
 target/nios2/op_helper.c  |  45 ---
 target/nios2/translate.c  | 254 +--
 tests/qtest/machine-none-test.c   |   1 -
 .gitlab-ci.d/buildtest.yml|   4 +-
 .gitlab-ci.d/crossbuilds.yml  |   2 +-
 hw/Kconfig|   1 -
 hw/intc/Kconfig   |   3 -
 hw/intc/meson.build   |   1 -
 hw/meson.build|   1 -
 hw/nios2/Kconfig  |  13 -
 hw/nios2/meson.build  |   6 -
 qemu-options.hx   |   8 +-
 scripts/coverity-scan/COMPONENTS.md   |   2 +-
 target/nios2/meson.build  |   9 -
 tests/avocado/boot_linux_console.py   |   8 -
 tests/avocado/replay_kernel.py|  11 -
 tests/tcg/nios2/Makefile.softmmu-target   |  32 --
 tests/tcg/nios2/test-shadow-1.S   |  40 ---
 42 files changed, 24 insertions(+), 2473 deletions(-)
 delete mode 100644 configs/devices/nios2-softmmu/default.mak
 delete mode 100644 configs/targets/nios2-softmmu.mak
 delete mode 100644 hw/nios2/boot.h
 delete mode 100644 include/hw/intc/nios2_vic.h
 delete mode 100644 target/nios2/mmu.h
 delete mode 100644 hw/intc/nios2_vic.c
 delete mode 100644 hw/nios2/10m50_devboard.c
 delete mode 100644 hw/nios2/boot.c
 delete mode 100644 hw/nios2/generic_nommu.c
 delete mode 100644 target/nios2/helper.c
 delete mode 100644 target/nios2/mmu.c
 delete mode 100644 target/nios2/monitor.c
 delete mode 100644 target/nios2/nios2-semi.c
 delete mode 100644 hw/nios2/Kconfig
 delete mode 100644 hw/nios2/meson.build
 delete mode 100644 tests/tcg/nios2/Makefile.softmmu-target
 delete mode 100644 tests/tcg/nios2/test-shadow-1.S

diff --git a/MAINTAINERS b/MAINTAINERS
index a07af6b9d4..3b48fcf8d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -296,11 +296,7 @@ R: Chris Wulff 
 R: Marek Vasut 
 S: Orphan
 F: target/nios2/
-F: hw/nios2/
-F: hw/intc/nios2_vic.c
 F: disas/nios2.c
-F: include/hw/intc/nios2_vic.h
-F: configs/devices/nios2-softmmu/default.mak
 F: tests/docker/dockerfiles/debian-nios2-cross.d/build-toolchain.sh
 F: tests/tcg/nios2/
 
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..0b709dfc72 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -226,11 +226,6 @@ These old machine types are quite neglected nowadays and 
thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
-Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
-'''
-
-The Nios II architecture is orphan.
-
 ``shix`` (since 9.0)
 
 
diff --git a/docs/about/emulation.rst b/docs/about/emulation.rst
index a2eefe3f3f..a7c185bbfb 100644
--- a/docs/about/emulation.rst
+++ b/docs/about/emulation.rst
@@ -180,9 +180,6 @@ for that architecture.
   * - MIPS
 - System
 - Unified Hosting Interface (MD01069)
-  * - Nios II
-- System
-- 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=libgloss/nios2/nios2-semi.txt;hb=HEAD
   * - RISC-V
 - System and User-mode
 - 
https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f9cf874f7b..43a9bfa29f 100644
--- a/docs/abou

Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests

[Daniel Henrique Barboza]

On 3/27/24 09:26, Christian Schoenebeck wrote:

On Wednesday, March 27, 2024 12:28:17 PM CET Daniel Henrique Barboza wrote:

On 3/27/24 07:14, Christian Schoenebeck wrote:

On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote:

On 3/27/24 05:47, Christian Schoenebeck wrote:

On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote:

On 3/26/24 14:05, Greg Kurz wrote:

On Tue, 26 Mar 2024 10:26:04 -0300
Daniel Henrique Barboza  wrote:


The local 9p driver in virtio-9p-test.c its temporary dir right at the
start of qos-test (via virtio_9p_create_local_test_dir()) and only
deletes it after qos-test is finished (via
virtio_9p_remove_local_test_dir()).

This means that any qos-test machine that ends up running virtio-9p-test local
tests more than once will end up re-using the same temp dir. This is
what's happening in [1] after we introduced the riscv machine nodes: if
we enable slow tests with the '-m slow' flag using qemu-system-riscv64,
this is what happens:

- a temp dir is created, e.g. qtest-9p-local-WZLDL2;

- virtio-9p-device tests will run virtio-9p-test successfully;

- virtio-9p-pci tests will run virtio-9p-test, and fail right at the
  first slow test at fs_create_dir() because the "01" file was already
  created by fs_create_dir() test when running with the virtio-9p-device.

We can fix it by making every test clean up their changes in the
filesystem after they're done. But we don't need every test either:
what fs_create_file() does is already exercised in fs_unlinkat_dir(),
i.e. a dir is created, verified to be created, and then removed. Fixing
fs_create_file() would turn it into fs_unlikat_dir(), so we don't need
both. The same theme follows every test in virtio-9p-test.c, where the
'unlikat' variant does the same thing the 'create' does but with some
cleaning in the end.

Consolide some tests as follows:

- fs_create_dir() is removed. fs_unlinkat_dir() is renamed to
  fs_create_unlinkat_dir();

- fs_create_file() is removed. fs_unlinkat_file() is renamed to
  fs_create_unlinkat_file(). The "04" dir it uses is now being removed;

- fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to
  fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it
  creates is now being removed.



The  change looks good functionally but it breaks the legitimate assumption
that files "06/*" come from test #6 and so on... I think you should consider
renumbering to avoid confusion when debugging logs.

Since this will bring more hunks, please split this in enough reviewable
patches.


Fair enough. Let me cook a v2. Thanks,


Wouldn't it be much simpler to just change the name of the temporary
directory, such that it contains the device name as well? Then these tests
runs would run on independent directories and won't interfere with each other
and that wouldn't need much changes I guess.


That's true. If we were just trying to fix the issue then I would go with this
approach since it's simpler. But given that we're also cutting half the tests 
while
retaining the coverage I think this approach is worth the extra code.


Well, I am actually not so keen into all those changes. These tests were
intentionally split, and yes with costs of a bit redundant (test case) code.
But they were cleanly build up on each other, from fundamental requirements
like whether it is possible to create a directory and file ... and then the
subsequent tests would become more and more demanding.

That way it was easier to review if somebody reports a test to fail, because
you could immediately see whether the preceding fundamental tests succeeded.


The current test design is flawed. It's based on a premise that doesn't happen, 
i.e.
a new temp dir will be created every time the test suit is executed. In reality 
the
temp dir is created only once in the constructor of the test, at the start of 
qos-test
(tests/qtest/qos-test.c, run_one_test()) and removed only once at the destructor
at the end of the run.

It's not possible to add a 'device name' in the created temp dir because we're 
too early
in the process, the tests didn't start at that point. So, with the current temp 
dir design,
the tests needs to clean themselves up after each run.

Here's the alternatives I'm willing to go for:

- what I just sent in v2;

- add cleanups in all existing tests. We can keep all of them, but the 'create' 
tests
will be carbon copies of the 'unlinkat' tests but with different names. Can be 
done;

- if we really want the tests untouched we can rework how the 'temp dir' is 
created/deleted.
The test dir will be created and removed after each test via the 'before' 
callback. To be
honest this seems like the best approach we can take, aside from what I did in 
v2, and
it's on par with how tests like vhost-user-test.c works.


Yeah, the latter sounds like the best solution to me, too.


Fair enough. I have it ready here - I'll just wait to see how Gitlab likes it 
before
post

Re: [PATCH-for-9.0? v2 4/4] meson: Enable -Wstatic-in-inline

[Philippe Mathieu-Daudé]

On 27/3/24 10:26, Paolo Bonzini wrote:

On 3/26/24 18:10, Philippe Mathieu-Daudé wrote:

Compilers are clever enough to inline code when necessary.

The only case we accept an inline function is static in
header (we use C, not C++).

Add the -Wstatic-in-inline CPPFLAG to prevent public and
inline function to be added in the code base.


No problem with the first three patches, but -Wstatic-in-inline is not
warning for non-static inline functions.  The warning is enabled by
default by GCC (which has no way to disable it even) and by clang
outside headers:

f.h:
static int y;

inline int f()
{
     return y;
}

f.c:
#include "f.h"

int main()
{
}

$ clang f.c
./f.h:5:12: warning: static variable 'y' is used in an inline function 
with external linkage [-Wstatic-in-inline]


$ gcc f.c
f.h:5:12: warning: ‘y’ is static but used in inline function ‘f’ which 
is not static


The actual effect of this patch is to enable the warning on clang *even
outside headers* (clang only enables the warning in headers by default
because, if a static variable belongs to the main source file, it has a
single definition anyway unlike if it's defined in an included file).


IIUC your comment, you are worried about system headers declaring
non-static inline functions?



For now I'm queuing patches 1-3 only.

Paolo


Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20240313184954.42513-5-phi...@linaro.org>
Reviewed-by: Thomas Huth 
---
  meson.build | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meson.build b/meson.build
index c9c3217ba4..f400f7d36c 100644
--- a/meson.build
+++ b/meson.build
@@ -591,6 +591,7 @@ warn_flags = [
    '-Wold-style-definition',
    '-Wredundant-decls',
    '-Wshadow=local',
+  '-Wstatic-in-inline',
    '-Wstrict-prototypes',
    '-Wtype-limits',
    '-Wundef',

Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

[Philippe Mathieu-Daudé]

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").

Cc: Marek Vasut 
Signed-off-by: Philippe Mathieu-Daudé 
---
  MAINTAINERS   |   4 -
  docs/about/deprecated.rst |   5 -
  docs/about/emulation.rst  |   3 -
  docs/about/removed-features.rst   |   5 +
  docs/system/replay.rst|   2 +-
  configs/devices/nios2-softmmu/default.mak |   6 -
  configs/targets/nios2-softmmu.mak |   2 -
  qapi/machine.json |   2 +-
  hw/nios2/boot.h   |  10 -
  include/hw/intc/nios2_vic.h   |  66 
  include/sysemu/arch_init.h|   1 -
  target/nios2/cpu-param.h  |   6 +-
  target/nios2/cpu.h|  42 ---
  target/nios2/helper.h |   9 -
  target/nios2/mmu.h|  52 ---
  hw/intc/nios2_vic.c   | 313 --
  hw/nios2/10m50_devboard.c | 181 ---
  hw/nios2/boot.c   | 234 --
  hw/nios2/generic_nommu.c  | 101 --
  target/nios2/cpu.c| 160 +-
  target/nios2/helper.c | 371 --
  target/nios2/mmu.c| 216 -
  target/nios2/monitor.c|  35 --
  target/nios2/nios2-semi.c | 230 --
  target/nios2/op_helper.c  |  45 ---
  target/nios2/translate.c  | 254 +--
  tests/qtest/machine-none-test.c   |   1 -
  .gitlab-ci.d/buildtest.yml|   4 +-
  .gitlab-ci.d/crossbuilds.yml  |   2 +-
  hw/Kconfig|   1 -
  hw/intc/Kconfig   |   3 -
  hw/intc/meson.build   |   1 -
  hw/meson.build|   1 -
  hw/nios2/Kconfig  |  13 -
  hw/nios2/meson.build  |   6 -
  qemu-options.hx   |   8 +-
  scripts/coverity-scan/COMPONENTS.md   |   2 +-
  target/nios2/meson.build  |   9 -
  tests/avocado/boot_linux_console.py   |   8 -
  tests/avocado/replay_kernel.py|  11 -
  tests/tcg/nios2/Makefile.softmmu-target   |  32 --
  tests/tcg/nios2/test-shadow-1.S   |  40 ---
  42 files changed, 24 insertions(+), 2473 deletions(-)
  delete mode 100644 configs/devices/nios2-softmmu/default.mak
  delete mode 100644 configs/targets/nios2-softmmu.mak
  delete mode 100644 hw/nios2/boot.h
  delete mode 100644 include/hw/intc/nios2_vic.h
  delete mode 100644 target/nios2/mmu.h
  delete mode 100644 hw/intc/nios2_vic.c
  delete mode 100644 hw/nios2/10m50_devboard.c
  delete mode 100644 hw/nios2/boot.c
  delete mode 100644 hw/nios2/generic_nommu.c
  delete mode 100644 target/nios2/helper.c
  delete mode 100644 target/nios2/mmu.c
  delete mode 100644 target/nios2/monitor.c
  delete mode 100644 target/nios2/nios2-semi.c
  delete mode 100644 hw/nios2/Kconfig
  delete mode 100644 hw/nios2/meson.build
  delete mode 100644 tests/tcg/nios2/Makefile.softmmu-target
  delete mode 100644 tests/tcg/nios2/test-shadow-1.S




diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-bool
-select NIOS2
-select SERIAL
-select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.

Re: [RFC] util/error-report: Add "error: " prefix for error-level report

[Zhao Liu]

On Wed, Mar 27, 2024 at 01:36:07PM +0100, Thomas Huth wrote:

[snip]

> Sounds like a good idea to me, but I think you should then also remove
> the hard-coded "error:" strings in the various error_reports():

Thanks Thomas! I missed this case, will remove these hard-code prefix
first.

> $ grep -ri 'error_report.*"error:'
> migration/block-dirty-bitmap.c:error_report("Error: block device name 
> is not set");
> migration/block-dirty-bitmap.c:error_report("Error: Unknown 
> bitmap alias '%s' on node "
> migration/block-dirty-bitmap.c:error_report("Error: unknown 
> dirty bitmap "
> migration/block-dirty-bitmap.c:error_report("Error: block device name 
> is not set");
> target/i386/kvm/kvm.c:error_report("error: failed to set MSR 0x%" 
> PRIx32 " to 0x%" PRIx64,
> target/i386/kvm/kvm.c:error_report("error: failed to get MSR 0x%" 
> PRIx32,
> util/vhost-user-server.c:error_report("Error: too big message 
> request: %d, "
> accel/hvf/hvf-all.c:error_report("Error: HV_ERROR");
> accel/hvf/hvf-all.c:error_report("Error: HV_BUSY");
> accel/hvf/hvf-all.c:error_report("Error: HV_BAD_ARGUMENT");
> accel/hvf/hvf-all.c:error_report("Error: HV_NO_RESOURCES");
> accel/hvf/hvf-all.c:error_report("Error: HV_NO_DEVICE");
> accel/hvf/hvf-all.c:error_report("Error: HV_UNSUPPORTED");
> accel/hvf/hvf-all.c:error_report("Error: HV_DENIED");
> monitor/hmp-cmds.c:error_reportf_err(err, "Error: ");
> hw/arm/xlnx-zcu102.c:error_report("ERROR: RAM size 0x%" PRIx64 " 
> above max supported of "
> hw/block/dataplane/xen-block.c:error_report("error: unknown operation 
> (%d)", request->req.operation);
> hw/block/dataplane/xen-block.c:error_report("error: write req for ro 
> device");
> hw/block/dataplane/xen-block.c:error_report("error: nr_segments 
> too big");
> hw/block/dataplane/xen-block.c:error_report("error: first > last 
> sector");
> hw/block/dataplane/xen-block.c:error_report("error: page 
> crossing");
> hw/block/dataplane/xen-block.c:error_report("error: access beyond end 
> of file");
> hw/rdma/rdma_backend.c:rdma_error_report("Error: Not a MAD 
> request, skipping");
> hw/s390x/s390-skeys.c:error_report("Error: Setting storage keys for 
> pages with unallocated "
> hw/s390x/s390-skeys.c:error_report("Error: Getting storage keys for 
> pages with unallocated "
> hw/usb/bus.c:error_report("Error: no usb bus to attach usbdevice %s, "
> gdbstub/gdbstub.c:error_report("Error: Bad gdb register numbering 
> for '%s', "
> 
>  Thomas
> 
> 

Re: [PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

[Zhao Liu]

On Wed, Mar 27, 2024 at 10:51:03AM +0100, Philippe Mathieu-Daudé wrote:
> Date: Wed, 27 Mar 2024 10:51:03 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated
>  pc-i440fx-2.0 machine
> X-Mailer: git-send-email 2.41.0
> 
> The pc-i440fx-2.0 machine was deprecated for the 8.2
> release (see commit c7437f0ddb "docs/about: Mark the
> old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
> time to remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Reviewed-by: Thomas Huth 
> Message-Id: <20240305134221.30924-2-phi...@linaro.org>
> ---
>  docs/about/deprecated.rst   |  2 +-
>  docs/about/removed-features.rst |  2 +-
>  include/hw/i386/pc.h|  3 ---
>  hw/i386/pc.c| 15 -
>  hw/i386/pc_piix.c   | 37 -
>  5 files changed, 2 insertions(+), 57 deletions(-)

Reviewed-by: Zhao Liu 

Re: [PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag

[Zhao Liu]

On Wed, Mar 27, 2024 at 10:51:04AM +0100, Philippe Mathieu-Daudé wrote:
> Date: Wed, 27 Mar 2024 10:51:04 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove
>  XHCI_FLAG_FORCE_PCIE_ENDCAP flag
> X-Mailer: git-send-email 2.41.0
> 
> XHCI_FLAG_FORCE_PCIE_ENDCAP was only used by the
> pc-i440fx-2.0 machine, which got removed. Remove it
> and simplify usb_xhci_pci_realize().
> 
> Reviewed-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/usb/hcd-xhci.h | 1 -
>  hw/usb/hcd-xhci-nec.c | 2 --
>  hw/usb/hcd-xhci-pci.c | 3 +--
>  3 files changed, 1 insertion(+), 5 deletions(-)

Reviewed-by: Zhao Liu 

[PATCH v3] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI

[Alexei Filippov]

kvm_riscv_handle_sbi() may return not supported return code to not trigger
qemu abort with vendor-specific sbi.

Added SBI related return code's defines.

Signed-off-by: Alexei Filippov 
Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
Reviewed-by: Daniel Henrique Barboza 
Reviewed-by: Alistair Francis 
---

Changes since v2:
-Clear kvm_riscv_handle_sbi()
-Add SBI_ERR_NO_SHMEM return code's define
 target/riscv/kvm/kvm-cpu.c | 13 +
 target/riscv/sbi_ecall_interface.h | 12 
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 6a6c6cae80..844942d9ba 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -1392,7 +1392,6 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cs)
 
 static int kvm_riscv_handle_sbi(CPUState *cs, struct kvm_run *run)
 {
-int ret = 0;
 unsigned char ch;
 switch (run->riscv_sbi.extension_id) {
 case SBI_EXT_0_1_CONSOLE_PUTCHAR:
@@ -1400,22 +1399,20 @@ static int kvm_riscv_handle_sbi(CPUState *cs, struct 
kvm_run *run)
 qemu_chr_fe_write(serial_hd(0)->be, &ch, sizeof(ch));
 break;
 case SBI_EXT_0_1_CONSOLE_GETCHAR:
-ret = qemu_chr_fe_read_all(serial_hd(0)->be, &ch, sizeof(ch));
-if (ret == sizeof(ch)) {
+if (qemu_chr_fe_read_all(serial_hd(0)->be, &ch, sizeof(ch)) == 
sizeof(ch)) {
 run->riscv_sbi.ret[0] = ch;
 } else {
-run->riscv_sbi.ret[0] = -1;
+run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
 }
-ret = 0;
 break;
 default:
 qemu_log_mask(LOG_UNIMP,
-  "%s: un-handled SBI EXIT, specific reasons is %lu\n",
+  "%s: Unhandled SBI exit with extension-id %lu\n",
   __func__, run->riscv_sbi.extension_id);
-ret = -1;
+run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
 break;
 }
-return ret;
+return 0;
 }
 
 int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
diff --git a/target/riscv/sbi_ecall_interface.h 
b/target/riscv/sbi_ecall_interface.h
index 43899d08f6..a2e21d9b8c 100644
--- a/target/riscv/sbi_ecall_interface.h
+++ b/target/riscv/sbi_ecall_interface.h
@@ -69,4 +69,16 @@
 #define SBI_EXT_VENDOR_END  0x09FF
 /* clang-format on */
 
+/* SBI return error codes */
+#define SBI_SUCCESS  0
+#define SBI_ERR_FAILURE -1
+#define SBI_ERR_NOT_SUPPORTED   -2
+#define SBI_ERR_INVALID_PARAM   -3
+#define SBI_ERR_DENIED  -4
+#define SBI_ERR_INVALID_ADDRESS -5
+#define SBI_ERR_ALREADY_AVAILABLE   -6
+#define SBI_ERR_ALREADY_STARTED -7
+#define SBI_ERR_ALREADY_STOPPED -8
+#define SBI_ERR_NO_SHMEM-9
+
 #endif
-- 
2.34.1