Re: [RESEND PATCH 1/3] hw/intc: openpic: Correct the reset value of IPIDR for FSL chipset

[Bin Meng]

On Tue, Sep 21, 2021 at 4:13 PM Philippe Mathieu-Daudé  wrote:
>
> On 9/21/21 05:25, David Gibson wrote:
> > On Sat, Sep 18, 2021 at 11:26:51AM +0800, Bin Meng wrote:
> >> The reset value of IPIDR should be zero for Freescale chipset, per
> >> the following 2 manuals I checked:
> >>
> >> - P2020RM (https://www.nxp.com/webapp/Download?colCode=P2020RM)
> >> - P4080RM (https://www.nxp.com/webapp/Download?colCode=P4080RM)
> >>
> >> Currently it is set to 1, which leaves the IPI enabled on core 0
> >> after power-on reset. Such may cause unexpected interrupt to be
> >> delivered to core 0 if the IPI is triggered from core 0 to other
> >> cores later.
> >>
> >> Fixes: ffd5e9fe0276 ("openpic: Reset IRQ source private members")
> >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/584
> >> Signed-off-by: Bin Meng 
> >
> > Since these patches are very simple and look sensible, I've applied
> > them to ppc-for-6.2.
> >
> > However, you should note that Greg and I are both moving into other
> > areas and don't have much capacity for ppc maintainership any more.
> > Therefore I'll shortly be sending some MAINTAINERS updates moving
> > openpic (amongst other things) to "Orphan" status.
>
> I'm not trying to force Bin to become (yet) another maintainer,
> but from his previous contributions, he demonstrated a very good
> knowledge of embedded PowerPC ISA & chipsets, his patches have good
> quality and description, and he is consistent over time in his
> contributions. So if he is interested, I'd vouch for him as a
> maintainer for embedded ppc. Now up to him, his time and/or employer :)
>

Thanks Philippe for the offer.

David, is this the whole PowerPC domain will become un-maintained
soon, or is this just openpic and a few other things like a subset of
PowerPC?

I got extensive working experience on Freescale/AMCC PowerPC chipset
in the past, but I never touched anything on the Mac stuff with IBM
chip. And I am not sure if I have enough time to do the work :(

Regards,
Bin

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Greg Kurz]

On Tue, 21 Sep 2021 16:43:47 -0300
Daniel Henrique Barboza  wrote:

> This patch has a handful of modifications for the recent added
> FORM2 support:
> 
> - there is no particular reason for both 'lookup_index_table' and
> 'distance_table' to be allocated in the heap, since their sizes are
> known right at the start of the function. Use static allocation in
> them to spare a couple of g_new0() calls;
> 
> - to not allocate more than the necessary size in 'distance_table'. At
> this moment the array is oversized due to allocating uint32_t for all
> elements, when most of them fits in an uint8_t;
> 
> - create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
> distance value.
> 

Not needed. A notion of minimal distance, which is obviously
synonymous to local, already exists in the "sysemu/numa.h"
header :

#define NUMA_DISTANCE_MIN 10

> Signed-off-by: Daniel Henrique Barboza 
> ---
>  hw/ppc/spapr_numa.c | 35 +++
>  1 file changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
> index 58d5dc7084..039a0439c6 100644
> --- a/hw/ppc/spapr_numa.c
> +++ b/hw/ppc/spapr_numa.c
> @@ -19,6 +19,9 @@
>  /* Moved from hw/ppc/spapr_pci_nvlink2.c */
>  #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))
>  
> +/* Macro to avoid hardcoding the local distance value */
> +#define NUMA_LOCAL_DISTANCE 10
> +
>  /*
>   * Retrieves max_dist_ref_points of the current NUMA affinity.
>   */
> @@ -500,17 +503,21 @@ static void 
> spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
>  MachineState *ms = MACHINE(spapr);
>  NodeInfo *numa_info = ms->numa_state->nodes;
>  int nb_numa_nodes = ms->numa_state->num_nodes;
> +/* Lookup index table has an extra uint32_t with its length */
> +uint32_t lookup_index_table[nb_numa_nodes + 1];
>  int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
> -g_autofree uint32_t *lookup_index_table = NULL;
> -g_autofree uint32_t *distance_table = NULL;
> -int src, dst, i, distance_table_size;
> -uint8_t *node_distances;
> +/*
> + * Distance table is an uint8_t array with a leading uint32_t
> + * containing its length.
> + */
> +uint8_t distance_table[distance_table_entries + 4];
> +uint32_t *distance_table_length;
> +int src, dst, i;
>  
>  /*
>   * ibm,numa-lookup-index-table: array with length and a
>   * list of NUMA ids present in the guest.
>   */
> -lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
>  lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);
>  
>  for (i = 0; i < nb_numa_nodes; i++) {
> @@ -518,8 +525,7 @@ static void 
> spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
>  }
>  
>  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
> - lookup_index_table,
> - (nb_numa_nodes + 1) * sizeof(uint32_t)));
> + lookup_index_table, sizeof(lookup_index_table)));
>  
>  /*
>   * ibm,numa-distance-table: contains all node distances. First
> @@ -531,11 +537,10 @@ static void 
> spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
>   * array because NUMA ids can be sparse (node 0 is the first,
>   * node 8 is the second ...).
>   */
> -distance_table = g_new0(uint32_t, distance_table_entries + 1);
> -distance_table[0] = cpu_to_be32(distance_table_entries);
> +distance_table_length = (uint32_t *)distance_table;
> +distance_table_length[0] = cpu_to_be32(distance_table_entries);
>  
> -node_distances = (uint8_t *)_table[1];
> -i = 0;
> +i = 4;
>  

A comment reminding why we're doing that wouldn't hurt, e.g.

/* Skip the array size (uint32_t) */

With these fixed, especially using NUMA_DISTANCE_MIN, you
can add:

Reviewed-by: Greg Kurz 

>  for (src = 0; src < nb_numa_nodes; src++) {
>  for (dst = 0; dst < nb_numa_nodes; dst++) {
> @@ -546,18 +551,16 @@ static void 
> spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
>   * adding the numa_info to retrieve distance info from.
>   */
>  if (src == dst) {
> -node_distances[i++] = 10;
> +distance_table[i++] = NUMA_LOCAL_DISTANCE;
>  continue;
>  }
>  
> -node_distances[i++] = numa_info[src].distance[dst];
> +distance_table[i++] = numa_info[src].distance[dst];
>  }
>  }
>  
> -distance_table_size = distance_table_entries * sizeof(uint8_t) +
> -  sizeof(uint32_t);
>  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-distance-table",
> - distance_table, distance_table_size));
> + distance_table, sizeof(distance_table)));
>  }
>  
>  /*

Re: [PATCH v3 21/35] acpi: madt: arm/x86: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: marcel.apfelb...@gmail.com
> CC: shannon.zha...@gmail.com
> CC: peter.mayd...@linaro.org
> CC: qemu-...@nongnu.org
> CC: drjo...@redhat.com
> CC: eau...@redhat.com
> ---
>  include/hw/acpi/acpi-defs.h |  9 -
>  hw/arm/virt-acpi-build.c| 19 +++
>  hw/i386/acpi-common.c   | 19 +++
>  3 files changed, 22 insertions(+), 25 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index c4f0a202e8..c7fa5caa06 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -176,15 +176,6 @@ typedef struct AcpiFacsDescriptorRev1 
> AcpiFacsDescriptorRev1;
>  #define ACPI_DUAL_PIC0
>  #define ACPI_MULTIPLE_APIC   1
>  
> -/* Master MADT */
> -
> -struct AcpiMultipleApicTable {
> -ACPI_TABLE_HEADER_DEF /* ACPI common table header */
> -uint32_t local_apic_address; /* Physical address of local APIC */
> -uint32_t flags;
> -} QEMU_PACKED;
> -typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
> -
>  /* Values for Type in APIC sub-headers */
>  
>  #define ACPI_APIC_PROCESSOR  0
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 6ba02cf281..e3bdcd44e8 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -567,19 +567,26 @@ build_gtdt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>   vms->oem_table_id);
>  }
>  
> -/* MADT */
> +/*
> + * ACPI spec, Revision 5.0
> + * 5.2.12 Multiple APIC Description Table (MADT)
> + */
>  static void
>  build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>  {
>  VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(vms);
> -int madt_start = table_data->len;
>  const MemMapEntry *memmap = vms->memmap;
>  const int *irqmap = vms->irqmap;
>  AcpiMadtGenericDistributor *gicd;
>  AcpiMadtGenericMsiFrame *gic_msi;
>  int i;
> +AcpiTable table = { .sig = "APIC", .rev = 3, .oem_id = vms->oem_id,
> +.oem_table_id = vms->oem_table_id };
>  
> -acpi_data_push(table_data, sizeof(AcpiMultipleApicTable));
> +acpi_table_begin(, table_data);
> +/* Local Interrupt Controller Address */
> +build_append_int_noprefix(table_data, 0, 4);
> +build_append_int_noprefix(table_data, 0, 4); /* Flags */
>  
>  gicd = acpi_data_push(table_data, sizeof *gicd);
>  gicd->type = ACPI_APIC_GENERIC_DISTRIBUTOR;
> @@ -650,11 +657,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  gic_msi->spi_count = cpu_to_le16(NUM_GICV2M_SPIS);
>  gic_msi->spi_base = cpu_to_le16(irqmap[VIRT_GIC_V2M] + ARM_SPI_BASE);
>  }
> -
> -build_header(linker, table_data,
> - (void *)(table_data->data + madt_start), "APIC",
> - table_data->len - madt_start, 3, vms->oem_id,
> - vms->oem_table_id);
> +acpi_table_end(linker, );
>  }
>  
>  /* FADT */
> diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> index 1f5947fcf9..a0cde1d874 100644
> --- a/hw/i386/acpi-common.c
> +++ b/hw/i386/acpi-common.c
> @@ -71,24 +71,29 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
>  }
>  }
>  
> +/*
> + * ACPI spec, Revision 1.0b
> + * 5.2.8 Multiple APIC Description Table
> + */
>  void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
>   X86MachineState *x86ms, AcpiDeviceIf *adev,
>   const char *oem_id, const char *oem_table_id)
>  {
>  MachineClass *mc = MACHINE_GET_CLASS(x86ms);
>  const CPUArchIdList *apic_ids = 
> mc->possible_cpu_arch_ids(MACHINE(x86ms));
> -int madt_start = table_data->len;
>  AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(adev);
>  bool x2apic_mode = false;
>  
> -AcpiMultipleApicTable *madt;
>  AcpiMadtIoApic *io_apic;
>  AcpiMadtIntsrcovr *intsrcovr;
>  int i;
> +AcpiTable table = { .sig = "APIC", .rev = 1, .oem_id = oem_id,
> +.oem_table_id = oem_table_id };
>  
> -madt = acpi_data_push(table_data, sizeof *madt);
> -madt->local_apic_address = cpu_to_le32(APIC_DEFAULT_ADDRESS);
> -madt->flags = cpu_to_le32(1);
> +acpi_table_begin(, table_data);
> +/* Local APIC Address */
> +build_append_int_noprefix(table_data, APIC_DEFAULT_ADDRESS, 4);
> +build_append_int_noprefix(table_data, 1 /* PCAT_COMPAT */, 4); /* Flags 
> */
>  
>  for (i = 0; i < apic_ids->len; i++) {
>  adevc->madt_cpu(adev, i, apic_ids, table_data);
> @@ -156,8 +161,6 @@ void acpi_build_madt(GArray *table_data, BIOSLinker 
> 

Re: [PATCH v4 02/20] nubus-device: expose separate super slot memory region

[Mark Cave-Ayland]

On 20/09/2021 20:54, Laurent Vivier wrote:


Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

According to "Designing Cards and Drivers for the Macintosh Family" each 
physical
nubus slot can access 2 separate address ranges: a super slot memory region 
which
is 256MB and a standard slot memory region which is 16MB.

Currently a Nubus device uses the physical slot number to determine whether it 
is
using a standard slot memory region or a super slot memory region rather than
exposing both memory regions for use as required.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Philippe Mathieu-Daudé 
---
  hw/nubus/nubus-device.c  | 36 ++--
  include/hw/nubus/nubus.h |  1 +
  2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/hw/nubus/nubus-device.c b/hw/nubus/nubus-device.c
index be01269563..36203848e5 100644
--- a/hw/nubus/nubus-device.c
+++ b/hw/nubus/nubus-device.c
@@ -168,26 +168,26 @@ static void nubus_device_realize(DeviceState *dev, Error 
**errp)
  }
  
  nd->slot = nubus->current_slot++;

-name = g_strdup_printf("nubus-slot-%d", nd->slot);
-
-if (nd->slot < NUBUS_FIRST_SLOT) {
-/* Super */
-slot_offset = (nd->slot - 6) * NUBUS_SUPER_SLOT_SIZE;
-
-memory_region_init(>slot_mem, OBJECT(dev), name,
-   NUBUS_SUPER_SLOT_SIZE);
-memory_region_add_subregion(>super_slot_io, slot_offset,
->slot_mem);
-} else {
-/* Normal */
-slot_offset = nd->slot * NUBUS_SLOT_SIZE;
-
-memory_region_init(>slot_mem, OBJECT(dev), name, NUBUS_SLOT_SIZE);
-memory_region_add_subregion(>slot_io, slot_offset,
->slot_mem);
-}
  
+/* Super */

+slot_offset = (nd->slot - 6) * NUBUS_SUPER_SLOT_SIZE;
+


Is it possible to remove this patch?

The "(nd->slot - 6)" looks weird and it is removed in patch 20.


This is another place where I decided to keep the existing logic as-is and then make 
the change to remove the -6 offset later on in patch 12 ("nubus: move nubus to its 
own 32-bit address space").


Certainly the existing offset is wrong, but given that there are currently no devices 
that use the super slot then I will bring the change to remove the offset forward to 
this patch in v5.



If not:

Reviewed-by: Laurent Vivier 

Thanks,
Laurent



ATB,

Mark.

Re: [PATCH v4 09/20] macfb: don't register declaration ROM

[BALATON Zoltan]

On Wed, 22 Sep 2021, Mark Cave-Ayland wrote:

On 20/09/2021 21:01, Laurent Vivier wrote:

Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

The macfb device is an on-board framebuffer and so is initialised by the
system declaration ROM included within the MacOS toolbox ROM.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index d8183b9bbd..76808b69cc 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -383,10 +383,6 @@ static void macfb_sysbus_realize(DeviceState *dev, 
Error **errp)

  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
  }
  -const uint8_t macfb_rom[] = {
-255, 0, 0, 0,
-};
-
  static void macfb_nubus_realize(DeviceState *dev, Error **errp)
  {
  NubusDevice *nd = NUBUS_DEVICE(dev);
@@ -399,8 +395,6 @@ static void macfb_nubus_realize(DeviceState *dev, 
Error **errp)

  macfb_common_realize(dev, ms, errp);
  memory_region_add_subregion(>slot_mem, DAFB_BASE, 
>mem_ctrl);
  memory_region_add_subregion(>slot_mem, VIDEO_BASE, 
>mem_vram);

-
-nubus_register_rom(nd, macfb_rom, sizeof(macfb_rom), 1, 9, 0xf);
  }
static void macfb_sysbus_reset(DeviceState *d)



Will macfb continue to work with "-kernel" and without providing any MacOS 
ROM?


Yes indeed, since on the Quadra 800 the declaration ROM for the framebuffer 
is embedded within the MacOS toolbox ROM.


Even if you want to boot Linux but have no toolbox ROM? (As the ROM is not 
free and thus not included with QEMU one can assume that's a common use 
case to boot Linux with -kernel but without -bios; I think that's what 
Laurent was asking about).


Regards,
BALATON Zoltan

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Philippe Mathieu-Daudé]

On 9/21/21 21:43, Daniel Henrique Barboza wrote:

This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/spapr_numa.c | 35 +++
  1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
index 58d5dc7084..039a0439c6 100644
--- a/hw/ppc/spapr_numa.c
+++ b/hw/ppc/spapr_numa.c
@@ -19,6 +19,9 @@
  /* Moved from hw/ppc/spapr_pci_nvlink2.c */
  #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))
  
+/* Macro to avoid hardcoding the local distance value */

+#define NUMA_LOCAL_DISTANCE 10
+
  /*
   * Retrieves max_dist_ref_points of the current NUMA affinity.
   */
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  MachineState *ms = MACHINE(spapr);
  NodeInfo *numa_info = ms->numa_state->nodes;
  int nb_numa_nodes = ms->numa_state->num_nodes;
+/* Lookup index table has an extra uint32_t with its length */
+uint32_t lookup_index_table[nb_numa_nodes + 1];
  int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-g_autofree uint32_t *lookup_index_table = NULL;
-g_autofree uint32_t *distance_table = NULL;
-int src, dst, i, distance_table_size;
-uint8_t *node_distances;


This should have be of ptrdiff_t type.


+/*
+ * Distance table is an uint8_t array with a leading uint32_t
+ * containing its length.
+ */
+uint8_t distance_table[distance_table_entries + 4];


The previous code seems better by using the heap, now we have
to worry about stack overflow...


+uint32_t *distance_table_length;


Please drop, ...


+int src, dst, i;
  
  /*

   * ibm,numa-lookup-index-table: array with length and a
   * list of NUMA ids present in the guest.
   */
-lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
  lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);
  
  for (i = 0; i < nb_numa_nodes; i++) {

@@ -518,8 +525,7 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  }
  
  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",

- lookup_index_table,
- (nb_numa_nodes + 1) * sizeof(uint32_t)));
+ lookup_index_table, sizeof(lookup_index_table)));
  
  /*

   * ibm,numa-distance-table: contains all node distances. First
@@ -531,11 +537,10 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
   * array because NUMA ids can be sparse (node 0 is the first,
   * node 8 is the second ...).
   */
-distance_table = g_new0(uint32_t, distance_table_entries + 1);
-distance_table[0] = cpu_to_be32(distance_table_entries);
+distance_table_length = (uint32_t *)distance_table;
+distance_table_length[0] = cpu_to_be32(distance_table_entries);


... and use instead:

   stl_be_p(distance_table, distance_table_entries);


-node_distances = (uint8_t *)_table[1];
-i = 0;
+i = 4;
  
  for (src = 0; src < nb_numa_nodes; src++) {

  for (dst = 0; dst < nb_numa_nodes; dst++) {
@@ -546,18 +551,16 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
   * adding the numa_info to retrieve distance info from.
   */
  if (src == dst) {
-node_distances[i++] = 10;
+distance_table[i++] = NUMA_LOCAL_DISTANCE;
  continue;
  }
  
-node_distances[i++] = numa_info[src].distance[dst];

+distance_table[i++] = numa_info[src].distance[dst];
  }
  }
  
-distance_table_size = distance_table_entries * sizeof(uint8_t) +

-  sizeof(uint32_t);
  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-distance-table",
- distance_table, distance_table_size));
+ distance_table, sizeof(distance_table)));
  }
  
  /*

[PATCH 3/3] docs: rSTify the "SubmitAPatch" wiki

[Kashyap Chamarthy]

- The original wiki is here[1]. I copied the wiki source[2] into a .wiki
  file, and used `pandoc` to convert it to rST:

$> pandoc -f Mediawiki -t rst submitting-a-patch.wiki -o
   submitting-a-patch.rst

- The only minor touch-ups I did was to fix URLs.  But 99%, it is a 1-1
  conversion.

  (An example of a "touch-up": under the section "Patch emails must
  include a Signed-off-by: line", I updated the "see SubmittingPatches
  1.12"  to "1.12) Sign your work")

- I have also converted a couple other small wiki pages (included in
  this patch series):

  - SpellCheck: https://wiki.qemu.org/Contribute/SpellCheck
  - TrivialPatches: https://wiki.qemu.org/Contribute/TrivialPatches

- Over time, many people contributed to this wiki page; you can find all
  the authors in the wiki history[3].

[1] https://wiki.qemu.org/Contribute/SubmitAPatch
[2] http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch=edit
[3] http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch=history

Signed-off-by: Kashyap Chamarthy 
---
NB: As of writing this, qemu.org is down, so I've used a one-month old
copy[4] of the wiki from 27Aug2021 to do the rST conversion.

[4] 
https://web.archive.org/web/20210827130706/https://wiki.qemu.org/Contribute/SubmitAPatch

Signed-off-by: Kashyap Chamarthy 
---
 docs/devel/submitting-a-patch.rst | 460 ++
 1 file changed, 460 insertions(+)
 create mode 100644 docs/devel/submitting-a-patch.rst

diff --git a/docs/devel/submitting-a-patch.rst 
b/docs/devel/submitting-a-patch.rst
new file mode 100644
index 00..1d85404438
--- /dev/null
+++ b/docs/devel/submitting-a-patch.rst
@@ -0,0 +1,460 @@
+==
+Submitting a Patch
+==
+
+QEMU welcomes contributions of code (either fixing bugs or adding new
+functionality). However, we get a lot of patches, and so we have some
+guidelines about submitting patches. If you follow these, you'll help
+make our task of code review easier and your patch is likely to be
+committed faster.
+
+This page seems very long, so if you are only trying to post a quick
+one-shot fix, the bare minimum we ask is that:
+
+-  You **must** provide a Signed-off-by: line (this is a hard
+   requirement because it's how you say "I'm legally okay to contribute
+   this and happy for it to go into QEMU", modeled after the `Linux
+   kernel 
`__
+   policy.) ``git commit -s`` or ``git format-patch -s`` will add one.
+-  All contributions to QEMU must be **sent as patches** to the
+   qemu-devel `mailing list `__. Patch contributions
+   should not be posted on the bug tracker, posted on forums, or
+   externally hosted and linked to. (We have other mailing lists too,
+   but all patches must go to qemu-devel, possibly with a Cc: to another
+   list.) ``git send-email`` works best for delivering the patch without
+   mangling it (`hints for setting it
+   up 
`__),
+   but attachments can be used as a last resort on a first-time
+   submission.
+-  You must read replies to your message, and be willing to act on them.
+   Note, however, that maintainers are often willing to manually fix up
+   first-time contributions, since there is a learning curve involved in
+   making an ideal patch submission.
+
+You do not have to subscribe to post (list policy is to reply-to-all to
+preserve CCs and keep non-subscribers in the loop on the threads they
+start), although you may find it easier as a subscriber to pick up good
+ideas from other posts. If you do subscribe, be prepared for a high
+volume of email, often over one thousand messages in a week. The list is
+moderated; first-time posts from an email address (whether or not you
+subscribed) may be subject to some delay while waiting for a moderator
+to whitelist your address.
+
+The larger your contribution is, or if you plan on becoming a long-term
+contributor, then the more important the rest of this page becomes.
+Reading the table of contents below should already give you an idea of
+the basic requirements. Use the table of contents as a reference, and
+read the parts that you have doubts about.
+
+.. _writing_your_patches:
+
+Writing your Patches
+
+
+.. _use_the_qemu_coding_style:
+
+Use the QEMU coding style
+-
+
+You can run run *scripts/checkpatch.pl * before submitting to
+check that you are in compliance with our coding standards. Be aware
+that ``checkpatch.pl`` is not infallible, though, especially where C
+preprocessor macros are involved; use some common sense too. See also:
+
+- `QEMU Coding Style
+  `__
+
+-  `Automate a checkpatch run on
+   commit 

[PATCH 2/3] docs: rSTify the "TrivialPatches" wiki

[Kashyap Chamarthy]

The original wiki is here[1].  I converted by copying the wiki source
into a .wiki file and convert to rST using `pandoc`:

$ pandoc -f Mediawiki -t rst trivial-patches.wiki -o trivial-patches.rst

[1] https://wiki.qemu.org/Contribute/TrivialPatches

Signed-off-by: Kashyap Chamarthy 
---
 docs/devel/trivial-patches.rst | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 docs/devel/trivial-patches.rst

diff --git a/docs/devel/trivial-patches.rst b/docs/devel/trivial-patches.rst
new file mode 100644
index 00..4ad0d25b9d
--- /dev/null
+++ b/docs/devel/trivial-patches.rst
@@ -0,0 +1,53 @@
+===
+Trivial Patches
+===
+
+Overview
+
+
+Trivial patches that change just a few lines of code sometimes languish
+on the mailing list even though they require only a small amount of
+review. This is often the case for patches that do not fall under an
+actively maintained subsystem and therefore fall through the cracks.
+
+The trivial patches team take on the task of reviewing and building pull
+requests for patches that:
+
+- Do not fall under an actively maintained subsystem.
+- Are single patches or short series (max 2-4 patches).
+- Only touch a few lines of code.
+
+**You should hint that your patch is a candidate by CCing
+qemu-triv...@nongnu.org.**
+
+Repositories
+
+
+Since the trivial patch team rotates maintainership there is only one
+active repository at a time:
+
+- git://git.corpit.ru/qemu.git trivial-patches - `browse 
`__
+- git://github.com/vivier/qemu.git trivial-patches - `browse 
`__
+
+Workflow
+
+
+The trivial patches team rotates the duty of collecting trivial patches
+amongst its members. A team member's job is to:
+
+1. Identify trivial patches on the development mailing list.
+2. Review trivial patches, merge them into a git tree, and reply to state
+   that the patch is queued.
+3. Send pull requests to the development mailing list once a week.
+
+A single team member can be on duty as long as they like. The suggested
+time is 1 week before handing off to the next member.
+
+Team
+
+
+If you would like to join the trivial patches team, contact Michael
+Tokarev. The current team includes:
+
+- Michael Tokarev
+- `Laurent Vivier `__
-- 
2.31.1

Re: [PATCH v6 00/21] Add LoongArch linux-user emulation support

[WANG Xuerui]

Hi Song,

On 9/22/21 14:22, Song Gao wrote:

Hi, Richard.

On 09/21/2021 05:17 AM, Richard Henderson wrote:

On 9/17/21 1:12 AM, Song Gao wrote:

The 'o32' code has been deleted at the latest kernel [1]. This series only 
support
linux-user emulation.

I have now reviewed all but the linux-user/ portion.


Thank you!

I see that kernel upstreaming is in progress,

https://lore.kernel.org/linux-kernel/20210917035736.3934017-1-chenhua...@loongson.cn/

so hopefully this will be resolved soon.

Have you started working on system mode support for LoongArch, so that one may 
run that kernel?
Yes. We already support running the old kernel, but we don't support running 
the latest kernel yet.


(the reply was at the wrong quotation level, never mind though)

First of all, thanks for your contribution and continued engagement with 
the wider development community! That's what it takes to unlock the 
3A5000 and future products' so many possibilities.


As for the system emulation part, I have some questions though:

- How would you provide the necessary firmware bits? Ideally that would 
be some open-source reference implementation so people would be able to 
collaborate on that front, and to maybe customize for specialized needs 
(e.g. ultra-dense cloud use cases like with Firecracker).


- How is old/new kernel ABI affecting your system-level emulation 
compatibility? IIUC the underlying ISA and chip behavior should be the 
same, only difference would be the firmware-kernel ABI, but again it 
should be just a matter of substituting the right image.


- Would the resulting work support emulating both old-world and 
new-world systems? AFAIK those commercial distros who're VERY early 
adopters of LoongArch are given similarly early toolchains/kernels. They 
belong to the old-world as a result, and are very likely to be stuck on 
the old-world ABI for whole major versions before migrating, if at all 
possible. Closed-source/commercial software also risk being available 
only for the old-world, and it would be extremely important to provide 
some degree of interoperability so that we don't split the ecosystem.


Questions aside, you did a nice work so far; looking forward to your 
system emulation work!

Re: [PATCH v3 26/35] acpi: build_dsdt_microvm: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
Reviewed-by: Eric Auger 

Eric
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: marcel.apfelb...@gmail.com
> CC: kra...@redhat.com
> ---
>  hw/i386/acpi-microvm.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/i386/acpi-microvm.c b/hw/i386/acpi-microvm.c
> index 1a0f77b911..196d318499 100644
> --- a/hw/i386/acpi-microvm.c
> +++ b/hw/i386/acpi-microvm.c
> @@ -113,16 +113,16 @@ build_dsdt_microvm(GArray *table_data, BIOSLinker 
> *linker,
>  Aml *dsdt, *sb_scope, *scope, *pkg;
>  bool ambiguous;
>  Object *isabus;
> +AcpiTable table = { .sig = "DSDT", .rev = 2, .oem_id = x86ms->oem_id,
> +.oem_table_id = x86ms->oem_table_id };
>  
>  isabus = object_resolve_path_type("", TYPE_ISA_BUS, );
>  assert(isabus);
>  assert(!ambiguous);
>  
> +acpi_table_begin(, table_data);
>  dsdt = init_aml_allocator();
>  
> -/* Reserve space for header */
> -acpi_data_push(dsdt->buf, sizeof(AcpiTableHeader));
> -
>  sb_scope = aml_scope("_SB");
>  fw_cfg_add_acpi_dsdt(sb_scope, x86ms->fw_cfg);
>  isa_build_aml(ISA_BUS(isabus), sb_scope);
> @@ -144,11 +144,10 @@ build_dsdt_microvm(GArray *table_data, BIOSLinker 
> *linker,
>  aml_append(scope, aml_name_decl("_S5", pkg));
>  aml_append(dsdt, scope);
>  
> -/* copy AML table into ACPI tables blob and patch header there */
> +/* copy AML bytecode into ACPI tables blob */
>  g_array_append_vals(table_data, dsdt->buf->data, dsdt->buf->len);
> -build_header(linker, table_data,
> -(void *)(table_data->data + table_data->len - dsdt->buf->len),
> - "DSDT", dsdt->buf->len, 2, x86ms->oem_id, 
> x86ms->oem_table_id);
> +
> +acpi_table_end(linker, );
>  free_aml_allocator();
>  }
>  
> 

Re: [PATCH 0/2] virtiofsd: Add capability to block xattrs

[Dr. David Alan Gilbert]

* Vivek Goyal (vgo...@redhat.com) wrote:
> As of now we have a knob "-o xattr/no_xattr" which either enables
> all xattrs or disables all xattrs.

Hi Vivek,
  Thanks for this.

> We need something more fine grained where we can selectively disable
> only certain xattrs (and not all).
> 
> For example, in some cases we want to disable "security.selinux"
> xattr. This is equivalent to virtiofs not supporting security.selinux
> and guest kernel will fallback to a single label for whole fs
> (virtiofs_t).
> 
> So add an option "-o block_xattr=" which will allow
> specifying a list of xattrs to block.

This is quite interesting; I'd not noticed you had the exisitng blocking
mechanism, however, as discussed, I think my preference is if this could
be done as a modification of the xattrmap it would avoid another set of
options.

The mapping code already has 'type's of:

  prefix, ok, bad

I think you just need to add a 'reject' type
that produces the error code you need.

Dave

> Vivek Goyal (2):
>   virtiofsd: Add an array to keep track of blocked xattrs
>   virtiofsd: Add option "block_xattr=" to block certain xattrs
> 
>  docs/tools/virtiofsd.rst |  17 
>  tools/virtiofsd/helper.c |   3 +
>  tools/virtiofsd/passthrough_ll.c | 166 ---
>  3 files changed, 171 insertions(+), 15 deletions(-)
> 
> -- 
> 2.31.1
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v3 01/15] target/ppc: add user read functions for MMCR0 and MMCR2

[Matheus K. Ferst]

On 03/09/2021 17:31, Daniel Henrique Barboza wrote:

[E-MAIL EXTERNO] Não clique em links ou abra anexos, a menos que você possa 
confirmar o remetente e saber que o conteúdo é seguro. Em caso de e-mail 
suspeito entre imediatamente em contato com o DTI.

From: Gustavo Romero 

We're going to add PMU support for TCG PPC64 chips, based on IBM POWER8+
emulation and following PowerISA v3.1.

Let's start by handling the user read of UMMCR0 and UMMCR2. According to
PowerISA 3.1 these registers omit some of its bits from userspace.

CC: Gustavo Romero 
Signed-off-by: Gustavo Romero 
Signed-off-by: Daniel Henrique Barboza 
---
  target/ppc/cpu.h   | 10 ++
  target/ppc/cpu_init.c  |  4 ++--
  target/ppc/spr_tcg.h   |  2 ++
  target/ppc/translate.c | 37 +
  4 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 500205229c..f68bb8d8aa 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -342,6 +342,16 @@ typedef struct ppc_v3_pate_t {
  #define MSR_RI   1  /* Recoverable interrupt1
*/
  #define MSR_LE   0  /* Little-endian mode   1 hflags 
*/

+/* PMU bits */
+#define MMCR0_FCPPC_BIT(32) /* Freeze Counters  */
+#define MMCR0_PMAO  PPC_BIT(56) /* Perf Monitor Alert Ocurred */
+#define MMCR0_PMAE  PPC_BIT(37) /* Perf Monitor Alert Enable */
+#define MMCR0_EBE   PPC_BIT(43) /* Perf Monitor EBB Enable */
+#define MMCR0_FCECE PPC_BIT(38) /* FC on Enabled Cond or Event */
+#define MMCR0_PMCC  PPC_BITMASK(44, 45) /* PMC Control */
+/* MMCR0 userspace r/w mask */
+#define MMCR0_UREG_MASK (MMCR0_FC | MMCR0_PMAO | MMCR0_PMAE)
+
  /* LPCR bits */
  #define LPCR_VPM0 PPC_BIT(0)
  #define LPCR_VPM1 PPC_BIT(1)
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index ad7abc6041..9efc6c2d87 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -6867,7 +6867,7 @@ static void register_book3s_pmu_sup_sprs(CPUPPCState *env)
  static void register_book3s_pmu_user_sprs(CPUPPCState *env)
  {
  spr_register(env, SPR_POWER_UMMCR0, "UMMCR0",
- _read_ureg, SPR_NOACCESS,
+ _read_MMCR0_ureg, SPR_NOACCESS,
   _read_ureg, _write_ureg,
   0x);
  spr_register(env, SPR_POWER_UMMCR1, "UMMCR1",
@@ -6975,7 +6975,7 @@ static void register_power8_pmu_sup_sprs(CPUPPCState *env)
  static void register_power8_pmu_user_sprs(CPUPPCState *env)
  {
  spr_register(env, SPR_POWER_UMMCR2, "UMMCR2",
- _read_ureg, SPR_NOACCESS,
+ _read_MMCR2_ureg, SPR_NOACCESS,
   _read_ureg, _write_ureg,
   0x);
  spr_register(env, SPR_POWER_USIER, "USIER",
diff --git a/target/ppc/spr_tcg.h b/target/ppc/spr_tcg.h
index 0be5f347d5..30cb6c3fdc 100644
--- a/target/ppc/spr_tcg.h
+++ b/target/ppc/spr_tcg.h
@@ -32,6 +32,8 @@ void spr_write_lr(DisasContext *ctx, int sprn, int gprn);
  void spr_read_ctr(DisasContext *ctx, int gprn, int sprn);
  void spr_write_ctr(DisasContext *ctx, int sprn, int gprn);
  void spr_read_ureg(DisasContext *ctx, int gprn, int sprn);
+void spr_read_MMCR0_ureg(DisasContext *ctx, int gprn, int sprn);
+void spr_read_MMCR2_ureg(DisasContext *ctx, int gprn, int sprn);
  void spr_read_tbl(DisasContext *ctx, int gprn, int sprn);
  void spr_read_tbu(DisasContext *ctx, int gprn, int sprn);
  void spr_read_atbl(DisasContext *ctx, int gprn, int sprn);
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 171b216e17..b2ead144d1 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -519,6 +519,43 @@ void spr_read_ureg(DisasContext *ctx, int gprn, int sprn)
  gen_load_spr(cpu_gpr[gprn], sprn + 0x10);
  }

+void spr_read_MMCR0_ureg(DisasContext *ctx, int gprn, int sprn)
+{
+TCGv t0 = tcg_temp_new();
+
+/*
+ * Filter out all bits but FC, PMAO, and PMAE, according
+ * to ISA v3.1, in 10.4.4 Monitor Mode Control Register 0,
+ * fourth paragraph.
+ */
+gen_load_spr(t0, SPR_POWER_MMCR0);
+tcg_gen_andi_tl(t0, t0, MMCR0_UREG_MASK);
+tcg_gen_mov_tl(cpu_gpr[gprn], t0);


From the other patches, it seems that the focus is in the MMCR0[PMCC] = 
0b00 case, but I would note that the PMCC field description says that 
when MMCR0[PMCC] = 0b01, "Group A is not allowed to be read or written 
in problem state." If this case doesn't matter for this initial 
implementation, it'd be nice to leave a comment (XXX/TODO/etc.) saying 
that it's not handled. Otherwise, I think we'll need a helper or add 
both PMCC bits to hflags.



+
+tcg_temp_free(t0);
+}
+
+void spr_read_MMCR2_ureg(DisasContext *ctx, int gprn, int sprn)
+{
+TCGv t0 = tcg_temp_new();
+
+/*
+ * On read, filter out all bits that are not FCnP0 bits.
+ * When MMCR0[PMCC] is set to 0b10 or 0b11, providing
+ * problem state programs read/write access to 

Re: [PATCH v4 09/20] macfb: don't register declaration ROM

[Mark Cave-Ayland]

On 22/09/2021 12:15, BALATON Zoltan wrote:


On Wed, 22 Sep 2021, Mark Cave-Ayland wrote:

On 20/09/2021 21:01, Laurent Vivier wrote:

Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

The macfb device is an on-board framebuffer and so is initialised by the
system declaration ROM included within the MacOS toolbox ROM.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index d8183b9bbd..76808b69cc 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -383,10 +383,6 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)

  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
  }
  -const uint8_t macfb_rom[] = {
-    255, 0, 0, 0,
-};
-
  static void macfb_nubus_realize(DeviceState *dev, Error **errp)
  {
  NubusDevice *nd = NUBUS_DEVICE(dev);
@@ -399,8 +395,6 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
**errp)
  macfb_common_realize(dev, ms, errp);
  memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);
  memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
-
-    nubus_register_rom(nd, macfb_rom, sizeof(macfb_rom), 1, 9, 0xf);
  }
    static void macfb_sysbus_reset(DeviceState *d)



Will macfb continue to work with "-kernel" and without providing any MacOS ROM?


Yes indeed, since on the Quadra 800 the declaration ROM for the framebuffer is 
embedded within the MacOS toolbox ROM.


Even if you want to boot Linux but have no toolbox ROM? (As the ROM is not free and 
thus not included with QEMU one can assume that's a common use case to boot Linux 
with -kernel but without -bios; I think that's what Laurent was asking about).


Yes, correct. If you check earlier in the thread you can see Laurent confirms that no 
declaration ROM is present on a real Quadra 800. In the -kernel case all that happens 
is that the physical address of the framebuffer is passed to the kernel using 
bootinfo ready for use.



ATB,

Mark.

Re: ensuring a machine's buses have unique names

[BALATON Zoltan]

On Wed, 22 Sep 2021, Markus Armbruster wrote:

BALATON Zoltan  writes:


On Tue, 21 Sep 2021, Peter Maydell wrote:

On Wed, 15 Sept 2021 at 05:28, Markus Armbruster  wrote:


Peter Maydell  writes:

I'm not sure how best to sort this tangle out. We could:
 * make controller devices pass in NULL as bus name; this
   means that some bus names will change, which is an annoying
   breakage but for these minor bus types we can probably
   get away with it. This brings these buses into line with
   how we've been handling uniqueness for ide and scsi.


To gauge the breakage, we need a list of the affected bus names.


Looking through, there are a few single-use or special
purpose buses I'm going to ignore for now (eg vmbus, or
the s390 ones). The four big bus types where controllers
often specify a bus name and override the 'autogenerate
unique name' handling are pci, ssi, sd, and i2c. (pci mostly
gets away with it I expect by machines only having one pci
bus.) Of those, I've gone through i2c. These are all the
places where we create a specifically-named i2c bus (via
i2c_init_bus()), together with the affected boards:

  hw/arm/pxa2xx.c
   - the PXA SoC code creates both the intended-for-use
 i2c buses (which get auto-names) and also several i2c
 buses intended for internal board-code use only which
 are all given the same name "dummy".
 Boards: connex, verdex, tosa, mainstone, akita, spitz,
 borzoi, terrier, z2
  hw/arm/stellaris.c
   - The i2c controller names its bus "i2c". There is only one i2c
 controller on these boards, so no name conflicts.
 Boards: lm3s811evb, lm3s6965evb
  hw/display/ati.c
   - The ATI VGA device has an on-board i2c controller which it
 connects the DDC that holds the EDID information. The bus is
 always named "ati-vga.ddc", so if you have multiple of this
 PCI device in the system the buses have the same names.
  hw/display/sm501.c
   - Same as ATI, but the bus name is "sm501.i2c"
  hw/i2c/aspeed_i2c.c
   - This I2C controller has either 14 or 16 (!) different i2c
 buses, and it assigns them names "aspeed.i2c.N" for N = 0,1,2,...
 The board code mostly seems to use these to wire up various
 on-board i2c devices.
 Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
 swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
 tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc
  hw/i2c/bitbang_i2c.c
   - the "GPIO to I2C bridge" device always names its bus "i2c".
 Used only on musicpal, which only creates one of these buses.
 Boards: musicpal
  hw/i2c/exynos4210_i2c.c
   - This i2c controller always names its bus "i2c". There are 9
 of these controllers on the board, so they all have clashing
 names.
 Boards: nuri, smdkc210
  hw/i2c/i2c_mux_pca954x.c
   - This is an i2c multiplexer. All the child buses are named
 "i2c-bus". The multiplexer is used by the aspeed and npcm7xx
 boards. (There's a programmable way to get at individual
 downstream i2c buses despite the name clash; none of the boards
 using this multiplexer actually connect any devices downstream of
 it yet.)
 Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
 swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
 tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc,
 npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
  hw/i2c/mpc_i2c.c
   - This controller always names its bus "i2c". There is only one
 of these controllers in the machine.
 Boards: ppce500, mpc8544ds
  hw/i2c/npcm7xx_smbus.c
   - This controller always names its bus "i2c-bus". There are multiple
 controllers on the boards. The name also clashes with the one used
 by the pca954x muxes on these boards (see above).
 Boards: npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
  hw/i2c/pm_smbus.c
   - This is the PC SMBUS implementation (it is not a QOM device...)
 The bus is always called "i2c".
 Boards: haven't worked through; at least all the x86 PC-like
 boards, I guess
  hw/i2c/ppc4xx_i2c.c
   - This controller always names its bus "i2c". The taihu and
 ref405ep have only one controller, but sam460ex has two which
 will have non-unique names.
 Boards: taihu, ref405ep, sam460ex
  hw/i2c/versatile_i2c.c
   - This controller always names its bus "i2c". The MPS boards all
 have multiples of this controller with clashing names; the others
 have only one controller.
 Boards: mps2-an385, mps2-an386, mps2-an500, mps2-an511,
 mps2-an505, mps2-an521, mps3-an524, mps3-an547,
 realview-eb, realview-eb-mpcore, realview-pb-a8, realview-pbx-a9,
 versatileab, versatilepb, vexpress-a9, vexpress-a15

In a lot of these cases I suspect the i2c controllers are
provided either to allow connection of various internal-to-the-board
devices, or simply so that guest OS bootup code that initializes
the i2c controller doesn't fall over. However since there's
nothing 

Re: [PATCH v3 18/35] acpi: build_dmar_q35: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Igor Mammedov]

On Wed, 22 Sep 2021 11:19:05 +0200
Eric Auger  wrote:

> On 9/7/21 4:47 PM, Igor Mammedov wrote:
> > it replaces error-prone pointer arithmetic for build_header() API,
> > with 2 calls to start and finish table creation,
> > which hides offsets magic from API user.
> > 
> > While at it switch to build_append_int_noprefix() to build
> > table entries tables.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >   - rebase on top 26863366b29 (hw/i386/acpi-build: Add DMAR support to 
> > bypass iommu)
> >   - s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> > 
> > CC: wangxinga...@huawei.com
> > CC: marcel.apfelb...@gmail.com
> > ---
> >  include/hw/acpi/acpi-defs.h | 68 --
> >  hw/i386/acpi-build.c| 97 -
> >  2 files changed, 53 insertions(+), 112 deletions(-)
> > 
> > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> > index d293304f9c..c4f0a202e8 100644
> > --- a/include/hw/acpi/acpi-defs.h
> > +++ b/include/hw/acpi/acpi-defs.h
> > @@ -358,74 +358,6 @@ struct AcpiGenericTimerTable {
> >  } QEMU_PACKED;
> >  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
> >  
> > -/* DMAR - DMA Remapping table r2.2 */
> > -struct AcpiTableDmar {
> > -ACPI_TABLE_HEADER_DEF
> > -uint8_t host_address_width; /* Maximum DMA physical addressability */
> > -uint8_t flags;
> > -uint8_t reserved[10];
> > -} QEMU_PACKED;
> > -typedef struct AcpiTableDmar AcpiTableDmar;
> > -
> > -/* Masks for Flags field above */
> > -#define ACPI_DMAR_INTR_REMAP1
> > -#define ACPI_DMAR_X2APIC_OPT_OUT(1 << 1)
> > -
> > -/* Values for sub-structure type for DMAR */
> > -enum {
> > -ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,   /* DRHD */
> > -ACPI_DMAR_TYPE_RESERVED_MEMORY = 1, /* RMRR */
> > -ACPI_DMAR_TYPE_ATSR = 2,/* ATSR */
> > -ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,   /* RHSR */
> > -ACPI_DMAR_TYPE_ANDD = 4,/* ANDD */
> > -ACPI_DMAR_TYPE_RESERVED = 5 /* Reserved for furture use */
> > -};
> > -
> > -/*
> > - * Sub-structures for DMAR
> > - */
> > -
> > -/* Device scope structure for DRHD. */
> > -struct AcpiDmarDeviceScope {
> > -uint8_t entry_type;
> > -uint8_t length;
> > -uint16_t reserved;
> > -uint8_t enumeration_id;
> > -uint8_t bus;
> > -struct {
> > -uint8_t device;
> > -uint8_t function;
> > -} path[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiDmarDeviceScope AcpiDmarDeviceScope;
> > -
> > -/* Type 0: Hardware Unit Definition */
> > -struct AcpiDmarHardwareUnit {
> > -uint16_t type;
> > -uint16_t length;
> > -uint8_t flags;
> > -uint8_t reserved;
> > -uint16_t pci_segment;   /* The PCI Segment associated with this unit */
> > -uint64_t address;   /* Base address of remapping hardware register-set 
> > */
> > -AcpiDmarDeviceScope scope[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiDmarHardwareUnit AcpiDmarHardwareUnit;
> > -
> > -/* Type 2: Root Port ATS Capability Reporting Structure */
> > -struct AcpiDmarRootPortATS {
> > -uint16_t type;
> > -uint16_t length;
> > -uint8_t flags;
> > -uint8_t reserved;
> > -uint16_t pci_segment;
> > -AcpiDmarDeviceScope scope[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiDmarRootPortATS AcpiDmarRootPortATS;
> > -
> > -/* Masks for Flags field above */
> > -#define ACPI_DMAR_INCLUDE_PCI_ALL   1
> > -#define ACPI_DMAR_ATSR_ALL_PORTS1
> > -
> >  /*
> >   * Input Output Remapping Table (IORT)
> >   * Conforms to "IO Remapping Table System Software on ARM Platforms",
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index 51e0ba07b6..2875c4f393 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -2064,8 +2064,9 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
> > MachineState *machine)
> >  static void
> >  insert_scope(PCIBus *bus, PCIDevice *dev, void *opaque)
> >  {
> > +const size_t device_scope_size = 6 /* device scope structure */ +
> > + 2 /* 1 path entry */;
> >  GArray *scope_blob = opaque;
> > -AcpiDmarDeviceScope *scope = NULL;
> >  
> >  if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_BRIDGE)) {
> >  /* Dmar Scope Type: 0x02 for PCI Bridge */
> > @@ -2076,8 +2077,7 @@ insert_scope(PCIBus *bus, PCIDevice *dev, void 
> > *opaque)
> >  }
> >  
> >  /* length */
> > -build_append_int_noprefix(scope_blob,
> > -  sizeof(*scope) + sizeof(scope->path[0]), 1);
> > +build_append_int_noprefix(scope_blob, device_scope_size, 1);
> >  /* reserved */
> >  build_append_int_noprefix(scope_blob, 0, 2);
> >  /* enumeration_id */
> > @@ -2109,26 +2109,31 @@ dmar_host_bridges(Object *obj, void *opaque)
> >  }
> >  
> >  /*
> > - * VT-d spec 8.1 DMA Remapping Reporting Structure
> > - * (version Oct. 2014 or later)
> > + * Intel ® 

Re: [PATCH v3 24/35] acpi: x86: madt: use build_append_int_noprefix() API to compose MADT table

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> Drop usage of packed structures and explicit endian conversions
> when building MADT table for arm/x86 and use endian agnostic
> build_append_int_noprefix() API to build it.
> 
> Signed-off-by: Igor Mammedov 
> ---
> CC: marcel.apfelb...@gmail.com
> CC: eau...@redhat.com
> ---
>  include/hw/acpi/acpi-defs.h |  64 --
>  hw/i386/acpi-common.c   | 127 ++--
>  2 files changed, 65 insertions(+), 126 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index af4fa412a5..3f174ba208 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -165,17 +165,6 @@ typedef struct AcpiFacsDescriptorRev1 
> AcpiFacsDescriptorRev1;
>  
>  /* Values for Type in APIC sub-headers */
>  
> -#define ACPI_APIC_PROCESSOR  0
> -#define ACPI_APIC_IO 1
> -#define ACPI_APIC_XRUPT_OVERRIDE 2
> -#define ACPI_APIC_NMI3
> -#define ACPI_APIC_LOCAL_NMI  4
> -#define ACPI_APIC_ADDRESS_OVERRIDE   5
> -#define ACPI_APIC_IO_SAPIC   6
> -#define ACPI_APIC_LOCAL_SAPIC7
> -#define ACPI_APIC_XRUPT_SOURCE   8
> -#define ACPI_APIC_LOCAL_X2APIC   9
> -#define ACPI_APIC_LOCAL_X2APIC_NMI  10
>  #define ACPI_APIC_GENERIC_CPU_INTERFACE 11
>  #define ACPI_APIC_GENERIC_DISTRIBUTOR   12
>  #define ACPI_APIC_GENERIC_MSI_FRAME 13
> @@ -192,59 +181,6 @@ typedef struct AcpiFacsDescriptorRev1 
> AcpiFacsDescriptorRev1;
>  
>  /* Sub-structures for MADT */
>  
> -struct AcpiMadtProcessorApic {
> -ACPI_SUB_HEADER_DEF
> -uint8_t  processor_id;   /* ACPI processor id */
> -uint8_t  local_apic_id;  /* Processor's local APIC id */
> -uint32_t flags;
> -} QEMU_PACKED;
> -typedef struct AcpiMadtProcessorApic AcpiMadtProcessorApic;
> -
> -struct AcpiMadtIoApic {
> -ACPI_SUB_HEADER_DEF
> -uint8_t  io_apic_id; /* I/O APIC ID */
> -uint8_t  reserved;   /* Reserved - must be zero */
> -uint32_t address;/* APIC physical address */
> -uint32_t interrupt;  /* Global system interrupt where INTI
> - * lines start */
> -} QEMU_PACKED;
> -typedef struct AcpiMadtIoApic AcpiMadtIoApic;
> -
> -struct AcpiMadtIntsrcovr {
> -ACPI_SUB_HEADER_DEF
> -uint8_t  bus;
> -uint8_t  source;
> -uint32_t gsi;
> -uint16_t flags;
> -} QEMU_PACKED;
> -typedef struct AcpiMadtIntsrcovr AcpiMadtIntsrcovr;
> -
> -struct AcpiMadtLocalNmi {
> -ACPI_SUB_HEADER_DEF
> -uint8_t  processor_id;   /* ACPI processor id */
> -uint16_t flags;  /* MPS INTI flags */
> -uint8_t  lint;   /* Local APIC LINT# */
> -} QEMU_PACKED;
> -typedef struct AcpiMadtLocalNmi AcpiMadtLocalNmi;
> -
> -struct AcpiMadtProcessorX2Apic {
> -ACPI_SUB_HEADER_DEF
> -uint16_t reserved;
> -uint32_t x2apic_id;  /* Processor's local x2APIC ID */
> -uint32_t flags;
> -uint32_t uid;/* Processor object _UID */
> -} QEMU_PACKED;
> -typedef struct AcpiMadtProcessorX2Apic AcpiMadtProcessorX2Apic;
> -
> -struct AcpiMadtLocalX2ApicNmi {
> -ACPI_SUB_HEADER_DEF
> -uint16_t flags;  /* MPS INTI flags */
> -uint32_t uid;/* Processor object _UID */
> -uint8_t  lint;   /* Local APIC LINT# */
> -uint8_t  reserved[3];/* Local APIC LINT# */
> -} QEMU_PACKED;
> -typedef struct AcpiMadtLocalX2ApicNmi AcpiMadtLocalX2ApicNmi;
> -
>  struct AcpiMadtGenericCpuInterface {
>  ACPI_SUB_HEADER_DEF
>  uint16_t reserved;
> diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> index 7983a13a93..aa7b5c357e 100644
> --- a/hw/i386/acpi-common.c
> +++ b/hw/i386/acpi-common.c
> @@ -38,7 +38,9 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> bool force_enabled)
>  {
>  uint32_t apic_id = apic_ids->cpus[uid].arch_id;
> -uint32_t flags = apic_ids->cpus[uid].cpu != NULL || force_enabled ? 1 : 
> 0;
> +/* Flags – Local APIC Flags */
nit: move that comment at the place of the build_append_int_noprefix
> +uint32_t flags = apic_ids->cpus[uid].cpu != NULL || force_enabled ?
> + 1 /* Enabled */ : 0;
>  
>  /* ACPI spec says that LAPIC entry for non present
>   * CPU may be omitted from MADT or it must be marked
> @@ -47,24 +49,47 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
>   * should be put in MADT but kept disabled.
>   */
>  if (apic_id < 255) {
> -AcpiMadtProcessorApic *apic = acpi_data_push(entry, sizeof *apic);
> -
> -apic->type = ACPI_APIC_PROCESSOR;
> -apic->length = sizeof(*apic);
> -apic->processor_id = uid;
> -apic->local_apic_id = apic_id;
> -apic->flags = cpu_to_le32(flags);
> +/* Rev 1.0b, Table 5-13 Processor Local APIC 

Re: [PATCH v4 05/20] nubus: move slot bitmap checks from NubusDevice realize() to BusClass check_address()

[Mark Cave-Ayland]

On 20/09/2021 20:56, Laurent Vivier wrote:


Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

Allow Nubus to manage the slot allocations itself using the BusClass 
check_address()
virtual function rather than managing this during NubusDevice realize().

Signed-off-by: Mark Cave-Ayland 
---
  hw/nubus/nubus-bus.c| 37 +
  hw/nubus/nubus-device.c | 29 -
  2 files changed, 37 insertions(+), 29 deletions(-)

diff --git a/hw/nubus/nubus-bus.c b/hw/nubus/nubus-bus.c
index 404c1032e0..141876b579 100644
--- a/hw/nubus/nubus-bus.c
+++ b/hw/nubus/nubus-bus.c
@@ -87,11 +87,48 @@ static void nubus_init(Object *obj)
  nubus->slot_available_mask = MAKE_64BIT_MASK(0, 16);
  }
  
+static bool nubus_check_address(BusState *bus, DeviceState *dev, Error **errp)

+{
+NubusDevice *nd = NUBUS_DEVICE(dev);
+NubusBus *nubus = NUBUS_BUS(bus);
+uint16_t s;
+
+if (nd->slot == -1) {
+/* No slot specified, find first available free slot */
+s = ctz32(nubus->slot_available_mask);
+if (s != 32) {
+nd->slot = s;
+} else {
+error_setg(errp, "Cannot register nubus card, no free slot "
+ "available");
+return false;
+}
+} else {
+/* Slot specified, make sure the slot is available */
+if (!(nubus->slot_available_mask & BIT(nd->slot))) {
+error_setg(errp, "Cannot register nubus card, slot %d is "
+ "unavailable or already occupied", nd->slot);
+return false;
+}
+}
+
+if (nd->slot < NUBUS_FIRST_SLOT || nd->slot > NUBUS_LAST_SLOT) {
+error_setg(errp, "Cannot register nubus card, slot must be "
+ "between %d and %d", NUBUS_FIRST_SLOT,
+ NUBUS_LAST_SLOT);
+return false;
+}
+
+nubus->slot_available_mask &= ~BIT(nd->slot);
+return true;
+}
+
  static void nubus_class_init(ObjectClass *oc, void *data)
  {
  BusClass *bc = BUS_CLASS(oc);
  
  bc->realize = nubus_realize;

+bc->check_address = nubus_check_address;
  }
  
  static const TypeInfo nubus_bus_info = {

diff --git a/hw/nubus/nubus-device.c b/hw/nubus/nubus-device.c
index d91a1e4af3..7a32c8c95b 100644
--- a/hw/nubus/nubus-device.c
+++ b/hw/nubus/nubus-device.c
@@ -160,35 +160,6 @@ static void nubus_device_realize(DeviceState *dev, Error 
**errp)
  NubusDevice *nd = NUBUS_DEVICE(dev);
  char *name;
  hwaddr slot_offset;
-uint16_t s;
-
-if (nd->slot == -1) {
-/* No slot specified, find first available free slot */
-s = ctz32(nubus->slot_available_mask);
-if (s != 32) {
-nd->slot = s;
-} else {
-error_setg(errp, "Cannot register nubus card, no free slot "
- "available");
-return;
-}
-} else {
-/* Slot specified, make sure the slot is available */
-if (!(nubus->slot_available_mask & BIT(nd->slot))) {
-error_setg(errp, "Cannot register nubus card, slot %d is "
- "unavailable or already occupied", nd->slot);
-return;
-}
-}
-
-if (nd->slot < NUBUS_FIRST_SLOT || nd->slot > NUBUS_LAST_SLOT) {
-error_setg(errp, "Cannot register nubus card, slot must be "
- "between %d and %d", NUBUS_FIRST_SLOT,
- NUBUS_LAST_SLOT);
-return;
-}
-
-nubus->slot_available_mask &= ~BIT(nd->slot);
  
  /* Super */

  slot_offset = (nd->slot - 6) * NUBUS_SUPER_SLOT_SIZE;



For the code move (but I think it needs some update in patch 4):

Reviewed-by: Laurent Vivier 


Yes, that will be resolved by rebasing onto an updated patch 2.


ATB,

Mark.

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Daniel Henrique Barboza]

On 9/22/21 06:51, BALATON Zoltan wrote:

On Wed, 22 Sep 2021, Greg Kurz wrote:

On Tue, 21 Sep 2021 16:43:47 -0300
Daniel Henrique Barboza  wrote:


This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.



Not needed. A notion of minimal distance, which is obviously
synonymous to local, already exists in the "sysemu/numa.h"
header :

#define NUMA_DISTANCE_MIN 10


Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr_numa.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
index 58d5dc7084..039a0439c6 100644
--- a/hw/ppc/spapr_numa.c
+++ b/hw/ppc/spapr_numa.c
@@ -19,6 +19,9 @@
 /* Moved from hw/ppc/spapr_pci_nvlink2.c */
 #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))

+/* Macro to avoid hardcoding the local distance value */
+#define NUMA_LOCAL_DISTANCE 10
+
 /*
  * Retrieves max_dist_ref_points of the current NUMA affinity.
  */
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
 MachineState *ms = MACHINE(spapr);
 NodeInfo *numa_info = ms->numa_state->nodes;
 int nb_numa_nodes = ms->numa_state->num_nodes;
+    /* Lookup index table has an extra uint32_t with its length */
+    uint32_t lookup_index_table[nb_numa_nodes + 1];
 int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-    g_autofree uint32_t *lookup_index_table = NULL;
-    g_autofree uint32_t *distance_table = NULL;
-    int src, dst, i, distance_table_size;
-    uint8_t *node_distances;
+    /*
+ * Distance table is an uint8_t array with a leading uint32_t
+ * containing its length.
+ */
+    uint8_t distance_table[distance_table_entries + 4];
+    uint32_t *distance_table_length;
+    int src, dst, i;

 /*
  * ibm,numa-lookup-index-table: array with length and a
  * list of NUMA ids present in the guest.
  */
-    lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
 lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);

 for (i = 0; i < nb_numa_nodes; i++) {
@@ -518,8 +525,7 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
 }

 _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
- lookup_index_table,
- (nb_numa_nodes + 1) * sizeof(uint32_t)));
+ lookup_index_table, sizeof(lookup_index_table)));

 /*
  * ibm,numa-distance-table: contains all node distances. First
@@ -531,11 +537,10 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  * array because NUMA ids can be sparse (node 0 is the first,
  * node 8 is the second ...).
  */
-    distance_table = g_new0(uint32_t, distance_table_entries + 1);
-    distance_table[0] = cpu_to_be32(distance_table_entries);
+    distance_table_length = (uint32_t *)distance_table;
+    distance_table_length[0] = cpu_to_be32(distance_table_entries);

-    node_distances = (uint8_t *)_table[1];
-    i = 0;
+    i = 4;



A comment reminding why we're doing that wouldn't hurt, e.g.

/* Skip the array size (uint32_t) */


Then maybe instead of (or in addition to) a comment you could write 
sizeof(uint32_t) or sizeof(distance_rable[0]) instead of constant 4 to make 
this more explicit.


distance_table is an uint8_t array. sizeof(distance_table[0]) would return 1.

Doing i = sizeof(uint32_t) demands the reader to realize "this works because it 
is
skipping an uint32_t in an uint8_t array and sizeof(uint8_t) is 1".

I think it's clearer to just be explicit in the comment:


/* First 4 uint8_t contains the uint32_t array length */


Thanks,


Daniel




Regards,
BALATON Zoltan


With these fixed, especially using NUMA_DISTANCE_MIN, you
can add:

Reviewed-by: Greg Kurz 


 for (src = 0; src < nb_numa_nodes; src++) {
 for (dst = 0; dst < nb_numa_nodes; dst++) {
@@ -546,18 +551,16 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  * adding the numa_info to retrieve distance info from.
  */
 if (src == dst) {
-    node_distances[i++] = 10;
+    distance_table[i++] = NUMA_LOCAL_DISTANCE;
 continue;
 }

-    node_distances[i++] = numa_info[src].distance[dst];
+    distance_table[i++] = numa_info[src].distance[dst];
 }
 }

-    distance_table_size = 

Re: [PATCH v11 06/10] hvf: arm: Implement -cpu host

[Ard Biesheuvel]

On Thu, 16 Sept 2021 at 18:17, Peter Maydell  wrote:
>
> On Thu, 16 Sept 2021 at 17:05, Ard Biesheuvel  wrote:
> > I'd argue that compliance with the architecture means that the
> > software should not clear RES1 bits
>
> Architecturally, RES1 means that "software
>  * Must not rely on the bit reading as 1.
>  * Must use an SBOP policy to write to the bit."
> (SBOP=="should be 1 or preserved", ie you can preserve the existing value,
> as in "read register, change some bits, write back", or you can write a 1.)
>

OVMF preserves the bit, and does not reason or care about its value.
So in this sense, it is compliant.

> > but I don't think we can blame it
> > for not touching bits that were in in invalid state upon entry.
>
> SCTLR_EL1.SPAN == 0 is perfectly valid for a CPU that supports the
> PAN feature. It's just not the value OVMF wants, so OVMF should
> be setting it to what it does want. Also, as the first thing to
> run after reset (ie firmware) OVMF absolutely is responsible for
> dealing with system registers which have UNKNOWN values out of
> reset.
>

Fair enough. But I'd still suggest fixing this at both ends.
> Put another way, if you want to argue that this is an "invalid
> state" you need to point to the specification that defines
> the valid state that OVMF should see when it is handed control.
>
> -- PMM

Re: [PATCH v7 0/7] DEVICE_UNPLUG_GUEST_ERROR QAPI event

[Markus Armbruster]

Not yet merged.  David, would you like to do the pull request?

Re: [PATCH v7 0/7] DEVICE_UNPLUG_GUEST_ERROR QAPI event

[Markus Armbruster]

Markus Armbruster  writes:

> Not yet merged.  David, would you like to do the pull request?

Oops, there's v8.  Take that one of course.

Re: [PATCH v1] monitor: Consider "id" when rate-limiting MEMORY_DEVICE_SIZE_CHANGE qapi events

[David Hildenbrand]

On 22.09.21 14:11, Markus Armbruster wrote:

David Hildenbrand  writes:


We have to consider the device id, otherwise we'll lose some events for
unrelated devices. If the device does not have a device id (very unlikely),
the target of the notifications has to update the size of all devices
manually either way.

This was noticed by starting a VM with two virtio-mem devices that each
have a requested size > 0. The Linux guest will initialize both devices
in parallel, resulting in losing MEMORY_DEVICE_SIZE_CHANGE events for
one of the devices.


Fascinating.

Event rate limiting works as follows.

An event is rate-limited when monitor_qapi_event_conf[event].rate != 0.

When such an event arrives, it is held in a bucket until a timer
associated with the bucket expires.  Putting an event in an empty bucket
starts its timer.  Putting an event in a non-empty bucket replaces its
old contents.

The bucket to use for an event depends on its event type, and for some
events also on certain event arguments.

This patch solves the "MEMORY_DEVICE_SIZE_CHANGE events from different
devices eat each other" by splitting the event's bucket.


Right, that's how it's getting used in libvirt where we noticed it.



The split is imperfect: each device with a qdev ID gets its own bucket,
all devices without ID have to share a bucket.


Yes, it's far from perfect. Fortunately upper layers (libvirt) barely do 
that.




This is actually a flaw in the event's design: you can't distinguish
events from different devices without IDs.

To fix that flaw, add the QOM path to the event.


So the idea would be to extend the event by an optional QOM path 
(because it's an existing event), but always setting it internally?


Thanks!



You can then get a perfect bucket split: use the QOM path instead of
the qdev ID.

Related: [PATCH v8 5/7] qapi/qdev.json: add DEVICE_UNPLUG_GUEST_ERROR
QAPI event
Message-Id: <20210907004755.424931-6-danielhb...@gmail.com>
This deprecates MEM_UNPLUG_ERROR, which only provides a qdev ID in
favour of DEVICE_UNPLUG_GUEST_ERROR, which has a wider scope, and also
provides a QOM path.

Different tack: perhaps the rate limiting is too simplistic and overly
aggressive.  Its purpose is to avoid a flood.  Two events are not a
flood, even when one follows the other quickly.  Heck, even a dozen
aren't.



Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size 
changes")
Cc: "Dr. David Alan Gilbert"  (maintainer:Human Monitor 
(HMP))
Cc: Markus Armbruster  (supporter:QMP)
Cc: Michael S. Tsirkin 
Cc: Eric Blake 
Cc: Igor Mammedov 
Cc: Michal Privoznik 
Signed-off-by: David Hildenbrand 
---
  monitor/monitor.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/monitor/monitor.c b/monitor/monitor.c
index 46a171bca6..05c0b32b67 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -474,6 +474,11 @@ static unsigned int qapi_event_throttle_hash(const void 
*key)
  hash += g_str_hash(qdict_get_str(evstate->data, "node-name"));
  }
  
+if (evstate->event == QAPI_EVENT_MEMORY_DEVICE_SIZE_CHANGE &&

+qdict_get(evstate->data, "id")) {
+hash += g_str_hash(qdict_get_str(evstate->data, "id"));
+}
+
  return hash;
  }
  
@@ -496,6 +501,20 @@ static gboolean qapi_event_throttle_equal(const void *a, const void *b)

 qdict_get_str(evb->data, "node-name"));
  }
  
+if (eva->event == QAPI_EVENT_MEMORY_DEVICE_SIZE_CHANGE) {

+const bool id_a = qdict_get(eva->data, "id");
+const bool id_b = qdict_get(evb->data, "id");
+
+if (!id_a && !id_b) {
+return TRUE;
+} else if (id_a ^ id_b) {
+return FALSE;
+}
+
+return !strcmp(qdict_get_str(eva->data, "id"),
+   qdict_get_str(evb->data, "id"));
+}
+
  return TRUE;
  }


Patch looks sane, but I recommend to first add the QOM path to the
event, then use it instead of the qdev ID.


Yes, let me take a look how easy that will be :)


--
Thanks,

David / dhildenb

[PATCH 08/14] bsd-user/target_os_elf: If ELF_HWCAP2 is defined, publish it

[Warner Losh]

Some architecutres publish AT_HWCAP2 as well as AT_HWCAP. Those
architectures will define this in their target_arch_elf.h files.  If it
is defined, then publish it.

Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/target_os_elf.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsd-user/freebsd/target_os_elf.h b/bsd-user/freebsd/target_os_elf.h
index adcffd1ddb..e5ac8e8e50 100644
--- a/bsd-user/freebsd/target_os_elf.h
+++ b/bsd-user/freebsd/target_os_elf.h
@@ -112,6 +112,10 @@ static abi_ulong target_create_elf_tables(abi_ulong p, int 
argc, int envc,
 NEW_AUX_ENT(AT_ENTRY, load_bias + exec->e_entry);
 features = ELF_HWCAP;
 NEW_AUX_ENT(FREEBSD_AT_HWCAP, features);
+#ifdef ELF_HWCAP2
+features = ELF_HWCAP2;
+NEW_AUX_ENT(FREEBSD_AT_HWCAP2, features);
+#endif
 NEW_AUX_ENT(AT_UID, (abi_ulong)getuid());
 NEW_AUX_ENT(AT_EUID, (abi_ulong)geteuid());
 NEW_AUX_ENT(AT_GID, (abi_ulong)getgid());
-- 
2.32.0

Re: [PATCH v3 15/35] acpi: build_tpm_tcpa: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> While at it switch to build_append_int_noprefix() to build
> table entries (which also removes some manual offset
> calculations).
> 
> Signed-off-by: Igor Mammedov 
> ---
> v2:
>   * fix assert when starting QEMU with TPM 1.2
>   Stefan Berger 
> v3:
>  * fix invalid checksum, by putting acpi_table_composed()
>after pointer patching
>  * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: stef...@linux.vnet.ibm.com
> ---
>  include/hw/acpi/acpi-defs.h | 14 --
>  hw/i386/acpi-build.c| 38 ++---
>  2 files changed, 23 insertions(+), 29 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 4d8f8b34b0..3b42b138f0 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -418,20 +418,6 @@ struct AcpiSratProcessorGiccAffinity {
>  
>  typedef struct AcpiSratProcessorGiccAffinity AcpiSratProcessorGiccAffinity;
>  
> -/*
> - * TCPA Description Table
> - *
> - * Following Level 00, Rev 00.37 of specs:
> - * http://www.trustedcomputinggroup.org/resources/tcg_acpi_specification
> - */
> -struct Acpi20Tcpa {
> -ACPI_TABLE_HEADER_DEF/* ACPI common table header */
> -uint16_t platform_class;
> -uint32_t log_area_minimum_length;
> -uint64_t log_area_start_address;
> -} QEMU_PACKED;
> -typedef struct Acpi20Tcpa Acpi20Tcpa;
> -
>  /* DMAR - DMA Remapping table r2.2 */
>  struct AcpiTableDmar {
>  ACPI_TABLE_HEADER_DEF
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 7cfa0cf825..c329580cff 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1878,31 +1878,39 @@ build_hpet(GArray *table_data, BIOSLinker *linker, 
> const char *oem_id,
>  }
>  
>  #ifdef CONFIG_TPM
> +/*
> + * TCPA Description Table
> + *
> + * Following Level 00, Rev 00.37 of specs:
> + * http://www.trustedcomputinggroup.org/resources/tcg_acpi_specification
> + * 7.1.2 ACPI Table Layout
> + */
>  static void
>  build_tpm_tcpa(GArray *table_data, BIOSLinker *linker, GArray *tcpalog,
> const char *oem_id, const char *oem_table_id)
>  {
> -int tcpa_start = table_data->len;
> -Acpi20Tcpa *tcpa = acpi_data_push(table_data, sizeof *tcpa);
> -unsigned log_addr_size = sizeof(tcpa->log_area_start_address);
> -unsigned log_addr_offset =
> -(char *)>log_area_start_address - table_data->data;
> +unsigned log_addr_offset;
> +AcpiTable table = { .sig = "TCPA", .rev = 2,
> +.oem_id = oem_id, .oem_table_id = oem_table_id };
>  
> -tcpa->platform_class = cpu_to_le16(TPM_TCPA_ACPI_CLASS_CLIENT);
> -tcpa->log_area_minimum_length = cpu_to_le32(TPM_LOG_AREA_MINIMUM_SIZE);
> -acpi_data_push(tcpalog, le32_to_cpu(tcpa->log_area_minimum_length));
> +acpi_table_begin(, table_data);
> +/* Platform Class */
> +build_append_int_noprefix(table_data, TPM_TCPA_ACPI_CLASS_CLIENT, 2);
> +/* Log Area Minimum Length (LAML) */
> +build_append_int_noprefix(table_data, TPM_LOG_AREA_MINIMUM_SIZE, 4);
> +/* Log Area Start Address (LASA) */
> +log_addr_offset = table_data->len;
> +build_append_int_noprefix(table_data, 0, 8);
>  
> +/* allocate/reserve space for TPM log area */
> +acpi_data_push(tcpalog, TPM_LOG_AREA_MINIMUM_SIZE);
>  bios_linker_loader_alloc(linker, ACPI_BUILD_TPMLOG_FILE, tcpalog, 1,
>   false /* high memory */);
> -
>  /* log area start address to be filled by Guest linker */
> -bios_linker_loader_add_pointer(linker,
> -ACPI_BUILD_TABLE_FILE, log_addr_offset, log_addr_size,
> -ACPI_BUILD_TPMLOG_FILE, 0);
> +bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
> +log_addr_offset, 8, ACPI_BUILD_TPMLOG_FILE, 0);
>  
> -build_header(linker, table_data,
> - (void *)(table_data->data + tcpa_start),
> - "TCPA", sizeof(*tcpa), 2, oem_id, oem_table_id);
> +acpi_table_end(linker, );
>  }
>  #endif
>  
> 
Looks good to me

Reviewed-by: Eric Auger 

Eric

Re: [PATCH v3 12/35] acpi: vmgenid_build_acpi: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> ---
>  hw/acpi/vmgenid.c | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
> index 4f41a13ea0..95f94a2510 100644
> --- a/hw/acpi/vmgenid.c
> +++ b/hw/acpi/vmgenid.c
> @@ -29,6 +29,8 @@ void vmgenid_build_acpi(VmGenIdState *vms, GArray 
> *table_data, GArray *guid,
>  Aml *ssdt, *dev, *scope, *method, *addr, *if_ctx;
>  uint32_t vgia_offset;
>  QemuUUID guid_le;
> +AcpiTable table = { .sig = "SSDT", .rev = 1,
> +.oem_id = oem_id, .oem_table_id = "VMGENID" };
>  
>  /* Fill in the GUID values.  These need to be converted to little-endian
>   * first, since that's what the guest expects
> @@ -42,15 +44,12 @@ void vmgenid_build_acpi(VmGenIdState *vms, GArray 
> *table_data, GArray *guid,
>  g_array_insert_vals(guid, VMGENID_GUID_OFFSET, guid_le.data,
>  ARRAY_SIZE(guid_le.data));
>  
> -/* Put this in a separate SSDT table */
> +/* Put VMGNEID into a separate SSDT table */
> +acpi_table_begin(, table_data);
>  ssdt = init_aml_allocator();
>  
> -/* Reserve space for header */
> -acpi_data_push(ssdt->buf, sizeof(AcpiTableHeader));
> -
>  /* Storage for the GUID address */
> -vgia_offset = table_data->len +
> -build_append_named_dword(ssdt->buf, "VGIA");
> +vgia_offset = table_data->len + build_append_named_dword(ssdt->buf, 
> "VGIA");
not mandated but well

>  scope = aml_scope("\\_SB");
>  dev = aml_device("VGEN");
>  aml_append(dev, aml_name_decl("_HID", aml_string("QEMUVGID")));
> @@ -116,9 +115,8 @@ void vmgenid_build_acpi(VmGenIdState *vms, GArray 
> *table_data, GArray *guid,
>  ACPI_BUILD_TABLE_FILE, vgia_offset, sizeof(uint32_t),
>  VMGENID_GUID_FW_CFG_FILE, 0);
>  
> -build_header(linker, table_data,
> -(void *)(table_data->data + table_data->len - ssdt->buf->len),
> -"SSDT", ssdt->buf->len, 1, oem_id, "VMGENID");
> +/* must be called after above command to ensure correct table checksum */
ditto
> +acpi_table_end(linker, );
>  free_aml_allocator();
>  }
>  
> 
Reviewed-by: Eric Auger 

Eric

Re: [PATCH v2 00/19] Make image fleecing more usable

[Vladimir Sementsov-Ogievskiy]

ping )

27.08.2021 21:17, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

That continues "[PATCH RFC DRAFT 00/11] Make image fleecing more usable"
and supersedes "[PATCH v2 for-6.2 0/6] push backup with fleecing"

Supersedes: <20210804131750.127574-1-vsement...@virtuozzo.com>
Supersedes: <20210721140424.163701-1-vsement...@virtuozzo.com>

There several improvements to fleecing scheme:

1. support bitmap in copy-before-write filter

2. introduce fleecing block driver, which opens the door for a lot of
image fleecing improvements.
See "block: introduce fleecing block driver" commit message for
details.

3. support "push backup with fleecing" scheme, when backup job is a
client of common fleecing scheme. That helps when writes to final
backup target are slow and we don't want guest writes hang waiting
for copy-before-write operations to final target.

Vladimir Sementsov-Ogievskiy (19):
   block/block-copy: move copy_bitmap initialization to
 block_copy_state_new()
   block/dirty-bitmap: bdrv_merge_dirty_bitmap(): add return value
   block/block-copy: block_copy_state_new(): add bitmap parameter
   block/copy-before-write: add bitmap open parameter
   block/block-copy: add block_copy_reset()
   block: intoduce reqlist
   block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()
   block/reqlist: add reqlist_wait_all()
   block: introduce FleecingState class
   block: introduce fleecing block driver
   block/copy-before-write: support fleecing block driver
   block/block-copy: add write-unchanged mode
   block/copy-before-write: use write-unchanged in fleecing mode
   iotests/image-fleecing: add test-case for fleecing format node
   iotests.py: add qemu_io_pipe_and_status()
   iotests/image-fleecing: add test case with bitmap
   block: blk_root(): return non-const pointer
   qapi: backup: add immutable-source parameter
   iotests/image-fleecing: test push backup with fleecing

  qapi/block-core.json|  39 ++-
  block/fleecing.h| 151 
  include/block/block-copy.h  |   4 +-
  include/block/block_int.h   |   1 +
  include/block/dirty-bitmap.h|   4 +-
  include/block/reqlist.h |  75 ++
  include/qemu/hbitmap.h  |  11 +
  include/sysemu/block-backend.h  |   2 +-
  block/backup.c  |  61 -
  block/block-backend.c   |   2 +-
  block/block-copy.c  | 157 +---
  block/copy-before-write.c   |  70 +-
  block/dirty-bitmap.c|  15 +-
  block/fleecing-drv.c| 260 
  block/fleecing.c| 182 ++
  block/monitor/bitmap-qmp-cmds.c |   5 +-
  block/replication.c |   2 +-
  block/reqlist.c |  84 +++
  blockdev.c  |   1 +
  util/hbitmap.c  |  36 +++
  MAINTAINERS |   7 +-
  block/meson.build   |   3 +
  tests/qemu-iotests/iotests.py   |   4 +
  tests/qemu-iotests/tests/image-fleecing | 178 +++---
  tests/qemu-iotests/tests/image-fleecing.out | 221 -
  25 files changed, 1420 insertions(+), 155 deletions(-)
  create mode 100644 block/fleecing.h
  create mode 100644 include/block/reqlist.h
  create mode 100644 block/fleecing-drv.c
  create mode 100644 block/fleecing.c
  create mode 100644 block/reqlist.c




--
Best regards,
Vladimir

Re: [PATCH v3 19/35] acpi: build_waet: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: marcel.apfelb...@gmail.com
> ---
>  hw/i386/acpi-build.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 2875c4f393..45724469b0 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2201,10 +2201,10 @@ static void
>  build_waet(GArray *table_data, BIOSLinker *linker, const char *oem_id,
> const char *oem_table_id)
>  {
> -int waet_start = table_data->len;
> +AcpiTable table = { .sig = "WAET", .rev = 1, .oem_id = oem_id,
> +.oem_table_id = oem_table_id };
>  
> -/* WAET header */
> -acpi_data_push(table_data, sizeof(AcpiTableHeader));
> +acpi_table_begin(, table_data);
>  /*
>   * Set "ACPI PM timer good" flag.
>   *
> @@ -2213,9 +2213,7 @@ build_waet(GArray *table_data, BIOSLinker *linker, 
> const char *oem_id,
>   * Which avoids costly VMExits caused by guest re-reading it 
> unnecessarily.
>   */
>  build_append_int_noprefix(table_data, 1 << 1 /* ACPI PM timer good */, 
> 4);
> -
> -build_header(linker, table_data, (void *)(table_data->data + waet_start),
> - "WAET", table_data->len - waet_start, 1, oem_id, 
> oem_table_id);
> +acpi_table_end(linker, );
>  }
>  
>  /*
> 
an easy one

Reviewed-by: Eric Auger 

Eric

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[BALATON Zoltan]

On Wed, 22 Sep 2021, Greg Kurz wrote:

On Tue, 21 Sep 2021 16:43:47 -0300
Daniel Henrique Barboza  wrote:


This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.



Not needed. A notion of minimal distance, which is obviously
synonymous to local, already exists in the "sysemu/numa.h"
header :

#define NUMA_DISTANCE_MIN 10


Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr_numa.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
index 58d5dc7084..039a0439c6 100644
--- a/hw/ppc/spapr_numa.c
+++ b/hw/ppc/spapr_numa.c
@@ -19,6 +19,9 @@
 /* Moved from hw/ppc/spapr_pci_nvlink2.c */
 #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))

+/* Macro to avoid hardcoding the local distance value */
+#define NUMA_LOCAL_DISTANCE 10
+
 /*
  * Retrieves max_dist_ref_points of the current NUMA affinity.
  */
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
 MachineState *ms = MACHINE(spapr);
 NodeInfo *numa_info = ms->numa_state->nodes;
 int nb_numa_nodes = ms->numa_state->num_nodes;
+/* Lookup index table has an extra uint32_t with its length */
+uint32_t lookup_index_table[nb_numa_nodes + 1];
 int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-g_autofree uint32_t *lookup_index_table = NULL;
-g_autofree uint32_t *distance_table = NULL;
-int src, dst, i, distance_table_size;
-uint8_t *node_distances;
+/*
+ * Distance table is an uint8_t array with a leading uint32_t
+ * containing its length.
+ */
+uint8_t distance_table[distance_table_entries + 4];
+uint32_t *distance_table_length;
+int src, dst, i;

 /*
  * ibm,numa-lookup-index-table: array with length and a
  * list of NUMA ids present in the guest.
  */
-lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
 lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);

 for (i = 0; i < nb_numa_nodes; i++) {
@@ -518,8 +525,7 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
 }

 _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
- lookup_index_table,
- (nb_numa_nodes + 1) * sizeof(uint32_t)));
+ lookup_index_table, sizeof(lookup_index_table)));

 /*
  * ibm,numa-distance-table: contains all node distances. First
@@ -531,11 +537,10 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  * array because NUMA ids can be sparse (node 0 is the first,
  * node 8 is the second ...).
  */
-distance_table = g_new0(uint32_t, distance_table_entries + 1);
-distance_table[0] = cpu_to_be32(distance_table_entries);
+distance_table_length = (uint32_t *)distance_table;
+distance_table_length[0] = cpu_to_be32(distance_table_entries);

-node_distances = (uint8_t *)_table[1];
-i = 0;
+i = 4;



A comment reminding why we're doing that wouldn't hurt, e.g.

/* Skip the array size (uint32_t) */


Then maybe instead of (or in addition to) a comment you could write 
sizeof(uint32_t) or sizeof(distance_rable[0]) instead of constant 4 to 
make this more explicit.


Regards,
BALATON Zoltan


With these fixed, especially using NUMA_DISTANCE_MIN, you
can add:

Reviewed-by: Greg Kurz 


 for (src = 0; src < nb_numa_nodes; src++) {
 for (dst = 0; dst < nb_numa_nodes; dst++) {
@@ -546,18 +551,16 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  * adding the numa_info to retrieve distance info from.
  */
 if (src == dst) {
-node_distances[i++] = 10;
+distance_table[i++] = NUMA_LOCAL_DISTANCE;
 continue;
 }

-node_distances[i++] = numa_info[src].distance[dst];
+distance_table[i++] = numa_info[src].distance[dst];
 }
 }

-distance_table_size = distance_table_entries * sizeof(uint8_t) +
-  sizeof(uint32_t);
 _FDT(fdt_setprop(fdt, rtas, "ibm,numa-distance-table",
- distance_table, distance_table_size));
+ distance_table, sizeof(distance_table)));
 }

 /*

Re: Change TCG cache size?

[Alex Bennée]

Kenneth Adam Miller  writes:

> Hello all,
>
> I just want to ask this one question: if I change the qemu tcg cache
> size (TB_JMP_CACHE_SIZE), will that force any errors at run time?

Hopefully not - for both user-mode and softmmu we take some care to
ensure tb_jmp_cache_hash_func and tb_jmp_cache_hash_page return
appropriately masked values for the table lookup.

What has not been done since Emilio's work in 6f1653180f (tb-hash:
improve tb_jmp_cache hash function in user mode) is a deeper look at the
hit rate and bounce rate of the softmmu jump table hashing. Any
suggested changes will need some benchmarking to show what difference it
makes.

-- 
Alex Bennée

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Daniel Henrique Barboza]

On 9/22/21 08:17, Philippe Mathieu-Daudé wrote:

On 9/21/21 21:43, Daniel Henrique Barboza wrote:

This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/spapr_numa.c | 35 +++
  1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
index 58d5dc7084..039a0439c6 100644
--- a/hw/ppc/spapr_numa.c
+++ b/hw/ppc/spapr_numa.c
@@ -19,6 +19,9 @@
  /* Moved from hw/ppc/spapr_pci_nvlink2.c */
  #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))
+/* Macro to avoid hardcoding the local distance value */
+#define NUMA_LOCAL_DISTANCE 10
+
  /*
   * Retrieves max_dist_ref_points of the current NUMA affinity.
   */
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  MachineState *ms = MACHINE(spapr);
  NodeInfo *numa_info = ms->numa_state->nodes;
  int nb_numa_nodes = ms->numa_state->num_nodes;
+    /* Lookup index table has an extra uint32_t with its length */
+    uint32_t lookup_index_table[nb_numa_nodes + 1];
  int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-    g_autofree uint32_t *lookup_index_table = NULL;
-    g_autofree uint32_t *distance_table = NULL;
-    int src, dst, i, distance_table_size;
-    uint8_t *node_distances;


This should have be of ptrdiff_t type.


+    /*
+ * Distance table is an uint8_t array with a leading uint32_t
+ * containing its length.
+ */
+    uint8_t distance_table[distance_table_entries + 4];


The previous code seems better by using the heap, now we have
to worry about stack overflow...



Fair point.

Since no one asked for this change in previous reviews I guess it's fine to keep
using the heap.


Daniel





+    uint32_t *distance_table_length;


Please drop, ...


+    int src, dst, i;
  /*
   * ibm,numa-lookup-index-table: array with length and a
   * list of NUMA ids present in the guest.
   */
-    lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
  lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);
  for (i = 0; i < nb_numa_nodes; i++) {
@@ -518,8 +525,7 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
  }
  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
- lookup_index_table,
- (nb_numa_nodes + 1) * sizeof(uint32_t)));
+ lookup_index_table, sizeof(lookup_index_table)));
  /*
   * ibm,numa-distance-table: contains all node distances. First
@@ -531,11 +537,10 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
   * array because NUMA ids can be sparse (node 0 is the first,
   * node 8 is the second ...).
   */
-    distance_table = g_new0(uint32_t, distance_table_entries + 1);
-    distance_table[0] = cpu_to_be32(distance_table_entries);
+    distance_table_length = (uint32_t *)distance_table;
+    distance_table_length[0] = cpu_to_be32(distance_table_entries);


... and use instead:

    stl_be_p(distance_table, distance_table_entries);


-    node_distances = (uint8_t *)_table[1];
-    i = 0;
+    i = 4;
  for (src = 0; src < nb_numa_nodes; src++) {
  for (dst = 0; dst < nb_numa_nodes; dst++) {
@@ -546,18 +551,16 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
   * adding the numa_info to retrieve distance info from.
   */
  if (src == dst) {
-    node_distances[i++] = 10;
+    distance_table[i++] = NUMA_LOCAL_DISTANCE;
  continue;
  }
-    node_distances[i++] = numa_info[src].distance[dst];
+    distance_table[i++] = numa_info[src].distance[dst];
  }
  }
-    distance_table_size = distance_table_entries * sizeof(uint8_t) +
-  sizeof(uint32_t);
  _FDT(fdt_setprop(fdt, rtas, "ibm,numa-distance-table",
- distance_table, distance_table_size));
+ distance_table, sizeof(distance_table)));
  }
  /*

Re: [PATCH v4 17/20] nubus-bridge: make slot_available_mask a qdev property

[Mark Cave-Ayland]

On 20/09/2021 21:12, Laurent Vivier wrote:

Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

This is to allow Macintosh machines to further specify which slots are available
since the number of addressable slots may not match the number of physical slots
present in the machine.

Signed-off-by: Mark Cave-Ayland 
---
  hw/nubus/nubus-bridge.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/hw/nubus/nubus-bridge.c b/hw/nubus/nubus-bridge.c
index 1adda7f5a6..2c7c4ee121 100644
--- a/hw/nubus/nubus-bridge.c
+++ b/hw/nubus/nubus-bridge.c
@@ -21,11 +21,18 @@ static void nubus_bridge_init(Object *obj)
  qbus_create_inplace(bus, sizeof(s->bus), TYPE_NUBUS_BUS, DEVICE(s), NULL);
  }
  
+static Property nubus_bridge_properties[] = {

+DEFINE_PROP_UINT32("slot-available-mask", NubusBridge,
+   bus.slot_available_mask, 0x),


So you can remove the "nubus->slot_available_mask = MAKE_64BIT_MASK(0, 16);" in 
nubus_init()?


Ah yes, I can do that in v5.


+DEFINE_PROP_END_OF_LIST()
+};
+
  static void nubus_bridge_class_init(ObjectClass *klass, void *data)
  {
  DeviceClass *dc = DEVICE_CLASS(klass);
  
  dc->fw_name = "nubus";

+device_class_set_props(dc, nubus_bridge_properties);
  }
  
  static const TypeInfo nubus_bridge_info = {




Reviewed-by: Laurent Vivier 



ATB,

Mark.

Re: [RFC 0/5] VirtIO RDMA

[Junji Wei]

> On Sep 15, 2021, at 9:43 PM, Jason Gunthorpe  wrote:
> 
> On Thu, Sep 02, 2021 at 09:06:20PM +0800, Junji Wei wrote:
>> Hi all,
>> 
>> This RFC aims to reopen the discussion of Virtio RDMA.
>> Now this is based on Yuval Shaia's RFC "VirtIO RDMA"
>> which implemented a frame for Virtio RDMA and a simple
>> control path (Not sure if Yuval Shaia has any further
>> plan for it).
>> 
>> We try to extend this work and implement a simple
>> data-path and a completed control path. Now this can
>> work with SEND, RECV and REG_MR in kernel. There is a
>> simple test module in this patch that can communicate
>> with ibv_rc_pingpong in rdma-core.
>> 
>> During doing this work, we have found some problems and
>> would like to ask for some suggestions from community:
> 
> These seem like serious problems! Shouldn't these be solved before
> sending patches?
> 
>> 1. Each qp need two VQ, but qemu default only support 1024 VQ.
>>   I think it is possible to multiplex the VQ, since the
>>   cmd_post_send carry the qpn in request.
> 
> QPs and CQs need to have predictable fixed WQE sizes, I don't know how
> you can reasonably expect to map them to a shared queue.

Yes, it is a bad idea to multiplex the VQ. If we need more VQ,
we can extend QEMU and virtio spec.

>> 2. The virtio-rdma device's gid should equal to host rdma
>>   device's gid. This means that we cannot use gid cache in
>>   rdma subsystem. And theoretically the gid should also equal
>>   to the device's netdev's ip address, how can we deal with
>>   this conflict.
> 
> You have to follow the correct semantics, the GID flows from the guest
> into the host and updates the hosts GID table, not the other way
> around.

Sure, this is my misunderstanding.

>> 3. How to support DMA mr? The verbs in host cannot support it.
>>   And it seems hard to ping whole guest physical memory in qemu.
> 
> Either you have to trap the FRWR in the hypervisor and pin the memory,
> remap the MR, etc or you have to pin the entire guest and rely on
> something like memory windows to emulate FRWR.

We want to implement an emulated RDMA device in userspace. Since
we can directly access guest's physical memory in QEMU, it will be
easy to support DMA mr.

>> 4. The FRMR api need to set key of MR through IB_WR_REG_MR.
>>   But it is impossible to change a key of mr using uverbs.
> 
> FRMR is more like memory windows in user space, you can't support it
> using just regular MRs.

It is hard to support this using uverbs, but it is easy to support
with uRDMA that we can get full control of mrs.

>> 5. The GSI is not supported now. And we think it's a problem that
>>   when the host receive a GSI package, it doesn't know which
>>   device it belongs to.
> 
> Of course, GSI packets are not virtualized. You need to somehow
> capture GSI messages for the entire GID that the guest is using. We
> don't have any API to do this in userspace.

If we implement uRDMA device in QEMU, there is no need to distinguish
which device it belongs to, because there is only one device.

Thanks.

Junji

Re: [PATCH v3 18/35] acpi: build_dmar_q35: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> While at it switch to build_append_int_noprefix() to build
> table entries tables.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   - rebase on top 26863366b29 (hw/i386/acpi-build: Add DMAR support to bypass 
> iommu)
>   - s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: wangxinga...@huawei.com
> CC: marcel.apfelb...@gmail.com
> ---
>  include/hw/acpi/acpi-defs.h | 68 --
>  hw/i386/acpi-build.c| 97 -
>  2 files changed, 53 insertions(+), 112 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index d293304f9c..c4f0a202e8 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -358,74 +358,6 @@ struct AcpiGenericTimerTable {
>  } QEMU_PACKED;
>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>  
> -/* DMAR - DMA Remapping table r2.2 */
> -struct AcpiTableDmar {
> -ACPI_TABLE_HEADER_DEF
> -uint8_t host_address_width; /* Maximum DMA physical addressability */
> -uint8_t flags;
> -uint8_t reserved[10];
> -} QEMU_PACKED;
> -typedef struct AcpiTableDmar AcpiTableDmar;
> -
> -/* Masks for Flags field above */
> -#define ACPI_DMAR_INTR_REMAP1
> -#define ACPI_DMAR_X2APIC_OPT_OUT(1 << 1)
> -
> -/* Values for sub-structure type for DMAR */
> -enum {
> -ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,   /* DRHD */
> -ACPI_DMAR_TYPE_RESERVED_MEMORY = 1, /* RMRR */
> -ACPI_DMAR_TYPE_ATSR = 2,/* ATSR */
> -ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,   /* RHSR */
> -ACPI_DMAR_TYPE_ANDD = 4,/* ANDD */
> -ACPI_DMAR_TYPE_RESERVED = 5 /* Reserved for furture use */
> -};
> -
> -/*
> - * Sub-structures for DMAR
> - */
> -
> -/* Device scope structure for DRHD. */
> -struct AcpiDmarDeviceScope {
> -uint8_t entry_type;
> -uint8_t length;
> -uint16_t reserved;
> -uint8_t enumeration_id;
> -uint8_t bus;
> -struct {
> -uint8_t device;
> -uint8_t function;
> -} path[];
> -} QEMU_PACKED;
> -typedef struct AcpiDmarDeviceScope AcpiDmarDeviceScope;
> -
> -/* Type 0: Hardware Unit Definition */
> -struct AcpiDmarHardwareUnit {
> -uint16_t type;
> -uint16_t length;
> -uint8_t flags;
> -uint8_t reserved;
> -uint16_t pci_segment;   /* The PCI Segment associated with this unit */
> -uint64_t address;   /* Base address of remapping hardware register-set */
> -AcpiDmarDeviceScope scope[];
> -} QEMU_PACKED;
> -typedef struct AcpiDmarHardwareUnit AcpiDmarHardwareUnit;
> -
> -/* Type 2: Root Port ATS Capability Reporting Structure */
> -struct AcpiDmarRootPortATS {
> -uint16_t type;
> -uint16_t length;
> -uint8_t flags;
> -uint8_t reserved;
> -uint16_t pci_segment;
> -AcpiDmarDeviceScope scope[];
> -} QEMU_PACKED;
> -typedef struct AcpiDmarRootPortATS AcpiDmarRootPortATS;
> -
> -/* Masks for Flags field above */
> -#define ACPI_DMAR_INCLUDE_PCI_ALL   1
> -#define ACPI_DMAR_ATSR_ALL_PORTS1
> -
>  /*
>   * Input Output Remapping Table (IORT)
>   * Conforms to "IO Remapping Table System Software on ARM Platforms",
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 51e0ba07b6..2875c4f393 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2064,8 +2064,9 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
> MachineState *machine)
>  static void
>  insert_scope(PCIBus *bus, PCIDevice *dev, void *opaque)
>  {
> +const size_t device_scope_size = 6 /* device scope structure */ +
> + 2 /* 1 path entry */;
>  GArray *scope_blob = opaque;
> -AcpiDmarDeviceScope *scope = NULL;
>  
>  if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_BRIDGE)) {
>  /* Dmar Scope Type: 0x02 for PCI Bridge */
> @@ -2076,8 +2077,7 @@ insert_scope(PCIBus *bus, PCIDevice *dev, void *opaque)
>  }
>  
>  /* length */
> -build_append_int_noprefix(scope_blob,
> -  sizeof(*scope) + sizeof(scope->path[0]), 1);
> +build_append_int_noprefix(scope_blob, device_scope_size, 1);
>  /* reserved */
>  build_append_int_noprefix(scope_blob, 0, 2);
>  /* enumeration_id */
> @@ -2109,26 +2109,31 @@ dmar_host_bridges(Object *obj, void *opaque)
>  }
>  
>  /*
> - * VT-d spec 8.1 DMA Remapping Reporting Structure
> - * (version Oct. 2014 or later)
> + * Intel ® Virtualization Technology for Directed I/O
> + * Architecture Specification. Revision 3.3
> + * 8.1 DMA Remapping Reporting Structure
>   */
>  static void
>  build_dmar_q35(GArray *table_data, BIOSLinker *linker, const char *oem_id,
> const char *oem_table_id)
>  {
> -int dmar_start = table_data->len;
> -
> -

Re: [RFC v7] virtio/vsock: add two more queues for datagram types

[Stefano Garzarella]

On Wed, Sep 22, 2021 at 12:00:24AM +, Jiang Wang wrote:

Datagram sockets are connectionless and unreliable.
The sender does not know the capacity of the receiver
and may send more packets than the receiver can handle.

Add two more dedicate virtqueues for datagram sockets,
so that it will not unfairly steal resources from
stream and future connection-oriented sockets.

The two new virtqueues are enabled by default and will
be removed if the guest does not support. This will help
migration work.

btw: enable_dgram argument in vhost_vsock_common_realize
is redundant for now, but will be used later when we
want to disable DGRAM feature bit for old versions.

Signed-off-by: Jiang Wang 
---
v1 -> v2: use qemu cmd option to control number of queues,
   removed configuration settings for dgram.
v2 -> v3: use ioctl to get features and decide number of
   virt queues, instead of qemu cmd option.
v3 -> v4: change DGRAM feature bit value to 2. Add an argument
   in vhost_vsock_common_realize to indicate dgram is supported or not.
v4 -> v5: don't open dev to get vhostfd. Removed leftover definition of
   enable_dgram
v5 -> v6: fix style errors. Imporve error handling of
   vhost_vsock_dgram_supported. Rename MAX_VQS_WITH_DGRAM and another one.
v6 -> v7: Always enable dgram for vhost-user and vhost kernel.
   Delete unused virtqueues at the beginning of
   vhost_vsock_common_start for migration. Otherwise, migration will fail.

hw/virtio/vhost-user-vsock.c  |  2 +-
hw/virtio/vhost-vsock-common.c| 32 +--
hw/virtio/vhost-vsock.c   |  6 +++-
include/hw/virtio/vhost-vsock-common.h|  6 ++--
include/hw/virtio/vhost-vsock.h   |  3 ++
include/standard-headers/linux/virtio_vsock.h |  1 +
6 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/hw/virtio/vhost-user-vsock.c b/hw/virtio/vhost-user-vsock.c
index 6095ed7349..9823a2f3bd 100644
--- a/hw/virtio/vhost-user-vsock.c
+++ b/hw/virtio/vhost-user-vsock.c
@@ -105,7 +105,7 @@ static void vuv_device_realize(DeviceState *dev, Error 
**errp)
return;
}

-vhost_vsock_common_realize(vdev, "vhost-user-vsock");
+vhost_vsock_common_realize(vdev, "vhost-user-vsock", true);

vhost_dev_set_config_notifier(>vhost_dev, _ops);

diff --git a/hw/virtio/vhost-vsock-common.c b/hw/virtio/vhost-vsock-common.c
index 4ad6e234ad..7d89b4d242 100644
--- a/hw/virtio/vhost-vsock-common.c
+++ b/hw/virtio/vhost-vsock-common.c
@@ -26,6 +26,18 @@ int vhost_vsock_common_start(VirtIODevice *vdev)
int ret;
int i;

+if (!virtio_has_feature(vdev->guest_features, VIRTIO_VSOCK_F_DGRAM)) {
+struct vhost_virtqueue *vqs;
+virtio_delete_queue(vvc->dgram_recv_vq);
+virtio_delete_queue(vvc->dgram_trans_vq);
+


Are you sure it works removing queues here?
The event_queue would always be #4, but the guest will use #2 which 
we're removing.



+vqs = vvc->vhost_dev.vqs;
+vvc->vhost_dev.nvqs = MAX_VQS_WITHOUT_DGRAM;
+vvc->vhost_dev.vqs = g_new0(struct vhost_virtqueue,
+   vvc->vhost_dev.nvqs);
+g_free(vqs);
+}
+
if (!k->set_guest_notifiers) {
error_report("binding does not support guest notifiers");
return -ENOSYS;
@@ -196,9 +208,11 @@ int vhost_vsock_common_post_load(void *opaque, int 
version_id)
return 0;
}

-void vhost_vsock_common_realize(VirtIODevice *vdev, const char *name)
+void vhost_vsock_common_realize(VirtIODevice *vdev, const char *name,
+   bool enable_dgram)

  ^
It seems always true, and also unused.


{
VHostVSockCommon *vvc = VHOST_VSOCK_COMMON(vdev);
+int nvqs = MAX_VQS_WITH_DGRAM;

virtio_init(vdev, name, VIRTIO_ID_VSOCK,
sizeof(struct virtio_vsock_config));
@@ -209,12 +223,17 @@ void vhost_vsock_common_realize(VirtIODevice *vdev, const 
char *name)
vvc->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
   vhost_vsock_common_handle_output);

+vvc->dgram_recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
+  vhost_vsock_common_handle_output);
+vvc->dgram_trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
+  vhost_vsock_common_handle_output);
+
/* The event queue belongs to QEMU */
vvc->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
   vhost_vsock_common_handle_output);

-vvc->vhost_dev.nvqs = ARRAY_SIZE(vvc->vhost_vqs);
-vvc->vhost_dev.vqs = vvc->vhost_vqs;
+vvc->vhost_dev.nvqs = nvqs;
+vvc->vhost_dev.vqs = g_new0(struct vhost_virtqueue, vvc->vhost_dev.nvqs);

vvc->post_load_timer = NULL;
}
@@ -227,6 +246,13 @@ void vhost_vsock_common_unrealize(VirtIODevice *vdev)

virtio_delete_queue(vvc->recv_vq);

Re: [PATCH v3 17/35] acpi: use build_append_int_noprefix() API to compose SRAT table

[Igor Mammedov]

On Wed, 22 Sep 2021 10:55:20 +0200
Eric Auger  wrote:

> On 9/7/21 4:47 PM, Igor Mammedov wrote:
> > Drop usage of packed structures and explicit endian conversions
> > when building SRAT tables for arm/x86 and use endian agnostic
> > build_append_int_noprefix() API to build it.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >  * rebase on top of (e77af21a7a2 hw/i386/acpi-build: Get NUMA information 
> > from struct NumaState)
> > CC: xiaoguangrong.e...@gmail.com
> > CC: shannon.zha...@gmail.com
> > CC: peter.mayd...@linaro.org
> > CC: marcel.apfelb...@gmail.com
> > CC: qemu-...@nongnu.org
> > CC: drjo...@redhat.com
> > CC: eau...@redhat.com
> > ---
> >  include/hw/acpi/acpi-defs.h | 49 ---
> >  include/hw/acpi/aml-build.h |  2 +-
> >  hw/acpi/aml-build.c | 24 
> >  hw/acpi/nvdimm.c|  4 +-
> >  hw/arm/virt-acpi-build.c| 29 --
> >  hw/i386/acpi-build.c| 78 +
> >  6 files changed, 80 insertions(+), 106 deletions(-)
> > 
> > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> > index 5826ee04b6..d293304f9c 100644
> > --- a/include/hw/acpi/acpi-defs.h
> > +++ b/include/hw/acpi/acpi-defs.h
> > @@ -358,55 +358,6 @@ struct AcpiGenericTimerTable {
> >  } QEMU_PACKED;
> >  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
> >  
> > -#define ACPI_SRAT_PROCESSOR_APIC 0
> > -#define ACPI_SRAT_MEMORY 1
> > -#define ACPI_SRAT_PROCESSOR_x2APIC   2
> > -#define ACPI_SRAT_PROCESSOR_GICC 3
> > -
> > -struct AcpiSratProcessorAffinity {
> > -ACPI_SUB_HEADER_DEF
> > -uint8_t proximity_lo;
> > -uint8_t local_apic_id;
> > -uint32_tflags;
> > -uint8_t local_sapic_eid;
> > -uint8_t proximity_hi[3];
> > -uint32_treserved;
> > -} QEMU_PACKED;
> > -typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
> > -
> > -struct AcpiSratProcessorX2ApicAffinity {
> > -ACPI_SUB_HEADER_DEF
> > -uint16_treserved;
> > -uint32_tproximity_domain;
> > -uint32_tx2apic_id;
> > -uint32_tflags;
> > -uint32_tclk_domain;
> > -uint32_treserved2;
> > -} QEMU_PACKED;
> > -typedef struct AcpiSratProcessorX2ApicAffinity 
> > AcpiSratProcessorX2ApicAffinity;
> > -
> > -struct AcpiSratMemoryAffinity {
> > -ACPI_SUB_HEADER_DEF
> > -uint32_tproximity;
> > -uint16_treserved1;
> > -uint64_tbase_addr;
> > -uint64_trange_length;
> > -uint32_treserved2;
> > -uint32_tflags;
> > -uint32_treserved3[2];
> > -} QEMU_PACKED;
> > -typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
> > -
> > -struct AcpiSratProcessorGiccAffinity {
> > -ACPI_SUB_HEADER_DEF
> > -uint32_tproximity;
> > -uint32_tacpi_processor_uid;
> > -uint32_tflags;
> > -uint32_tclock_domain;
> > -} QEMU_PACKED;
> > -
> > -typedef struct AcpiSratProcessorGiccAffinity AcpiSratProcessorGiccAffinity;
> > -
> >  /* DMAR - DMA Remapping table r2.2 */
> >  struct AcpiTableDmar {
> >  ACPI_TABLE_HEADER_DEF
> > diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> > index 4242382399..6e1f42e119 100644
> > --- a/include/hw/acpi/aml-build.h
> > +++ b/include/hw/acpi/aml-build.h
> > @@ -487,7 +487,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet 
> > *range_set, uint32_t io_offset,
> > uint32_t mmio32_offset, uint64_t mmio64_offset,
> > uint16_t bus_nr_offset);
> >  
> > -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> > +void build_srat_memory(GArray *table_data, uint64_t base,
> > uint64_t len, int node, MemoryAffinityFlags flags);
> >  
> >  void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
> > diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> > index 5e8bfb631c..050fdb3f37 100644
> > --- a/hw/acpi/aml-build.c
> > +++ b/hw/acpi/aml-build.c
> > @@ -1936,15 +1936,25 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, 
> > GArray *table_offsets,
> >  acpi_table_end(linker, );
> >  }
> >  
> > -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> > +/*
> > + * ACPI spec, Revision 4.0
> > + * 5.2.16.2 Memory Affinity Structure
> > + */
> > +void build_srat_memory(GArray *table_data, uint64_t base,
> > uint64_t len, int node, MemoryAffinityFlags flags)
> >  {
> > -numamem->type = ACPI_SRAT_MEMORY;
> > -numamem->length = sizeof(*numamem);
> > -numamem->proximity = cpu_to_le32(node);
> > -numamem->flags = cpu_to_le32(flags);
> > -numamem->base_addr = cpu_to_le64(base);
> > -numamem->range_length = cpu_to_le64(len);
> > +build_append_int_noprefix(table_data, 1, 1); /* Type */
> > +build_append_int_noprefix(table_data, 40, 1); /* Length */
> > +build_append_int_noprefix(table_data, node, 4); /* Proximity Domain */
> > +  

Re: [PATCH v4 09/20] macfb: don't register declaration ROM

[Mark Cave-Ayland]

On 20/09/2021 21:01, Laurent Vivier wrote:


Le 17/09/2021 à 09:50, Mark Cave-Ayland a écrit :

The macfb device is an on-board framebuffer and so is initialised by the
system declaration ROM included within the MacOS toolbox ROM.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index d8183b9bbd..76808b69cc 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -383,10 +383,6 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)
  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
  }
  
-const uint8_t macfb_rom[] = {

-255, 0, 0, 0,
-};
-
  static void macfb_nubus_realize(DeviceState *dev, Error **errp)
  {
  NubusDevice *nd = NUBUS_DEVICE(dev);
@@ -399,8 +395,6 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
**errp)
  macfb_common_realize(dev, ms, errp);
  memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);
  memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
-
-nubus_register_rom(nd, macfb_rom, sizeof(macfb_rom), 1, 9, 0xf);
  }
  
  static void macfb_sysbus_reset(DeviceState *d)




Will macfb continue to work with "-kernel" and without providing any MacOS ROM?


Yes indeed, since on the Quadra 800 the declaration ROM for the framebuffer is 
embedded within the MacOS toolbox ROM.



ATB,

Mark.

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[BALATON Zoltan]

On Wed, 22 Sep 2021, Daniel Henrique Barboza wrote:

On 9/22/21 06:51, BALATON Zoltan wrote:

On Wed, 22 Sep 2021, Greg Kurz wrote:

On Tue, 21 Sep 2021 16:43:47 -0300
Daniel Henrique Barboza  wrote:


This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.



Not needed. A notion of minimal distance, which is obviously
synonymous to local, already exists in the "sysemu/numa.h"
header :

#define NUMA_DISTANCE_MIN 10


Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr_numa.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
index 58d5dc7084..039a0439c6 100644
--- a/hw/ppc/spapr_numa.c
+++ b/hw/ppc/spapr_numa.c
@@ -19,6 +19,9 @@
 /* Moved from hw/ppc/spapr_pci_nvlink2.c */
 #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))

+/* Macro to avoid hardcoding the local distance value */
+#define NUMA_LOCAL_DISTANCE 10
+
 /*
  * Retrieves max_dist_ref_points of the current NUMA affinity.
  */
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,

 MachineState *ms = MACHINE(spapr);
 NodeInfo *numa_info = ms->numa_state->nodes;
 int nb_numa_nodes = ms->numa_state->num_nodes;
+    /* Lookup index table has an extra uint32_t with its length */
+    uint32_t lookup_index_table[nb_numa_nodes + 1];
 int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-    g_autofree uint32_t *lookup_index_table = NULL;
-    g_autofree uint32_t *distance_table = NULL;
-    int src, dst, i, distance_table_size;
-    uint8_t *node_distances;
+    /*
+ * Distance table is an uint8_t array with a leading uint32_t
+ * containing its length.
+ */
+    uint8_t distance_table[distance_table_entries + 4];
+    uint32_t *distance_table_length;
+    int src, dst, i;

 /*
  * ibm,numa-lookup-index-table: array with length and a
  * list of NUMA ids present in the guest.
  */
-    lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
 lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);

 for (i = 0; i < nb_numa_nodes; i++) {
@@ -518,8 +525,7 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,

 }

 _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
- lookup_index_table,
- (nb_numa_nodes + 1) * sizeof(uint32_t)));
+ lookup_index_table, sizeof(lookup_index_table)));

 /*
  * ibm,numa-distance-table: contains all node distances. First
@@ -531,11 +537,10 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,

  * array because NUMA ids can be sparse (node 0 is the first,
  * node 8 is the second ...).
  */
-    distance_table = g_new0(uint32_t, distance_table_entries + 1);
-    distance_table[0] = cpu_to_be32(distance_table_entries);
+    distance_table_length = (uint32_t *)distance_table;
+    distance_table_length[0] = cpu_to_be32(distance_table_entries);

-    node_distances = (uint8_t *)_table[1];
-    i = 0;
+    i = 4;



A comment reminding why we're doing that wouldn't hurt, e.g.

/* Skip the array size (uint32_t) */


Then maybe instead of (or in addition to) a comment you could write 
sizeof(uint32_t) or sizeof(distance_rable[0]) instead of constant 4 to make 
this more explicit.


distance_table is an uint8_t array. sizeof(distance_table[0]) would return 1.


Yes, sorry I was looking at uint32_t *distance_table_length; instead of 
the array definition.


Doing i = sizeof(uint32_t) demands the reader to realize "this works because 
it is

skipping an uint32_t in an uint8_t array and sizeof(uint8_t) is 1".

I think it's clearer to just be explicit in the comment:


/* First 4 uint8_t contains the uint32_t array length */


That explains it better (although a bit confusing, if you need the length 
why don't you have a struct with the length and the array instead of 
sroring it in the array when that's a different type, unless this is some 
data structure defined that way, I don't know what this is all about). But 
I don't really care, adding this comment is fine.


Regards,
BALATON Zoltan

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Greg Kurz]

On Wed, 22 Sep 2021 13:17:32 +0200
Philippe Mathieu-Daudé  wrote:

> On 9/21/21 21:43, Daniel Henrique Barboza wrote:
> > This patch has a handful of modifications for the recent added
> > FORM2 support:
> > 
> > - there is no particular reason for both 'lookup_index_table' and
> > 'distance_table' to be allocated in the heap, since their sizes are
> > known right at the start of the function. Use static allocation in
> > them to spare a couple of g_new0() calls;
> > 
> > - to not allocate more than the necessary size in 'distance_table'. At
> > this moment the array is oversized due to allocating uint32_t for all
> > elements, when most of them fits in an uint8_t;
> > 
> > - create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
> > distance value.
> > 
> > Signed-off-by: Daniel Henrique Barboza 
> > ---
> >   hw/ppc/spapr_numa.c | 35 +++
> >   1 file changed, 19 insertions(+), 16 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
> > index 58d5dc7084..039a0439c6 100644
> > --- a/hw/ppc/spapr_numa.c
> > +++ b/hw/ppc/spapr_numa.c
> > @@ -19,6 +19,9 @@
> >   /* Moved from hw/ppc/spapr_pci_nvlink2.c */
> >   #define SPAPR_GPU_NUMA_ID   (cpu_to_be32(1))
> >   
> > +/* Macro to avoid hardcoding the local distance value */
> > +#define NUMA_LOCAL_DISTANCE 10
> > +
> >   /*
> >* Retrieves max_dist_ref_points of the current NUMA affinity.
> >*/
> > @@ -500,17 +503,21 @@ static void 
> > spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
> >   MachineState *ms = MACHINE(spapr);
> >   NodeInfo *numa_info = ms->numa_state->nodes;
> >   int nb_numa_nodes = ms->numa_state->num_nodes;
> > +/* Lookup index table has an extra uint32_t with its length */
> > +uint32_t lookup_index_table[nb_numa_nodes + 1];
> >   int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
> > -g_autofree uint32_t *lookup_index_table = NULL;
> > -g_autofree uint32_t *distance_table = NULL;
> > -int src, dst, i, distance_table_size;
> > -uint8_t *node_distances;
> 
> This should have be of ptrdiff_t type.
> 

Why ? I don't see pointer subtraction in the code.

> > +/*
> > + * Distance table is an uint8_t array with a leading uint32_t
> > + * containing its length.
> > + */
> > +uint8_t distance_table[distance_table_entries + 4];
> 
> The previous code seems better by using the heap, now we have
> to worry about stack overflow...
> 

Indeed the size of this array could be up to 16k + 4. I guess
Philippe's point make sense. David's request was to use uint8_t
instead of uin32t_t, not to drop g_new0(). Please revert to
using the heap.

lookup_index_table[] can _only_ grow up to 516 bytes, which is
less problematic, but it doesn't hurt either to allocate it
on the heap. Not changing that would make this patch simpler.

> > +uint32_t *distance_table_length;
> 
> Please drop, ...
> 
> > +int src, dst, i;
> >   
> >   /*
> >* ibm,numa-lookup-index-table: array with length and a
> >* list of NUMA ids present in the guest.
> >*/
> > -lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
> >   lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);
> >   
> >   for (i = 0; i < nb_numa_nodes; i++) {
> > @@ -518,8 +525,7 @@ static void 
> > spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
> >   }
> >   
> >   _FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
> > - lookup_index_table,
> > - (nb_numa_nodes + 1) * sizeof(uint32_t)));
> > + lookup_index_table, sizeof(lookup_index_table)));
> >   
> >   /*
> >* ibm,numa-distance-table: contains all node distances. First
> > @@ -531,11 +537,10 @@ static void 
> > spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
> >* array because NUMA ids can be sparse (node 0 is the first,
> >* node 8 is the second ...).
> >*/
> > -distance_table = g_new0(uint32_t, distance_table_entries + 1);
> > -distance_table[0] = cpu_to_be32(distance_table_entries);
> > +distance_table_length = (uint32_t *)distance_table;
> > +distance_table_length[0] = cpu_to_be32(distance_table_entries);
> 
> ... and use instead:
> 
> stl_be_p(distance_table, distance_table_entries);
> 

+1

> > -node_distances = (uint8_t *)_table[1];
> > -i = 0;
> > +i = 4;
> >   
> >   for (src = 0; src < nb_numa_nodes; src++) {
> >   for (dst = 0; dst < nb_numa_nodes; dst++) {
> > @@ -546,18 +551,16 @@ static void 
> > spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
> >* adding the numa_info to retrieve distance info from.
> >*/
> >   if (src == dst) {
> > -node_distances[i++] = 10;
> > +distance_table[i++] = NUMA_LOCAL_DISTANCE;
> >   continue;
> >   }
> >   
> 

Re: [PATCH v1] monitor: Consider "id" when rate-limiting MEMORY_DEVICE_SIZE_CHANGE qapi events

[Markus Armbruster]

David Hildenbrand  writes:

> We have to consider the device id, otherwise we'll lose some events for
> unrelated devices. If the device does not have a device id (very unlikely),
> the target of the notifications has to update the size of all devices
> manually either way.
>
> This was noticed by starting a VM with two virtio-mem devices that each
> have a requested size > 0. The Linux guest will initialize both devices
> in parallel, resulting in losing MEMORY_DEVICE_SIZE_CHANGE events for
> one of the devices.

Fascinating.

Event rate limiting works as follows.

An event is rate-limited when monitor_qapi_event_conf[event].rate != 0.

When such an event arrives, it is held in a bucket until a timer
associated with the bucket expires.  Putting an event in an empty bucket
starts its timer.  Putting an event in a non-empty bucket replaces its
old contents.

The bucket to use for an event depends on its event type, and for some
events also on certain event arguments.

This patch solves the "MEMORY_DEVICE_SIZE_CHANGE events from different
devices eat each other" by splitting the event's bucket.

The split is imperfect: each device with a qdev ID gets its own bucket,
all devices without ID have to share a bucket.

This is actually a flaw in the event's design: you can't distinguish
events from different devices without IDs.

To fix that flaw, add the QOM path to the event.

You can then get a perfect bucket split: use the QOM path instead of
the qdev ID.

Related: [PATCH v8 5/7] qapi/qdev.json: add DEVICE_UNPLUG_GUEST_ERROR
QAPI event
Message-Id: <20210907004755.424931-6-danielhb...@gmail.com>
This deprecates MEM_UNPLUG_ERROR, which only provides a qdev ID in
favour of DEVICE_UNPLUG_GUEST_ERROR, which has a wider scope, and also
provides a QOM path.

Different tack: perhaps the rate limiting is too simplistic and overly
aggressive.  Its purpose is to avoid a flood.  Two events are not a
flood, even when one follows the other quickly.  Heck, even a dozen
aren't.

>
> Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size 
> changes")
> Cc: "Dr. David Alan Gilbert"  (maintainer:Human Monitor 
> (HMP))
> Cc: Markus Armbruster  (supporter:QMP)
> Cc: Michael S. Tsirkin 
> Cc: Eric Blake 
> Cc: Igor Mammedov 
> Cc: Michal Privoznik 
> Signed-off-by: David Hildenbrand 
> ---
>  monitor/monitor.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/monitor/monitor.c b/monitor/monitor.c
> index 46a171bca6..05c0b32b67 100644
> --- a/monitor/monitor.c
> +++ b/monitor/monitor.c
> @@ -474,6 +474,11 @@ static unsigned int qapi_event_throttle_hash(const void 
> *key)
>  hash += g_str_hash(qdict_get_str(evstate->data, "node-name"));
>  }
>  
> +if (evstate->event == QAPI_EVENT_MEMORY_DEVICE_SIZE_CHANGE &&
> +qdict_get(evstate->data, "id")) {
> +hash += g_str_hash(qdict_get_str(evstate->data, "id"));
> +}
> +
>  return hash;
>  }
>  
> @@ -496,6 +501,20 @@ static gboolean qapi_event_throttle_equal(const void *a, 
> const void *b)
> qdict_get_str(evb->data, "node-name"));
>  }
>  
> +if (eva->event == QAPI_EVENT_MEMORY_DEVICE_SIZE_CHANGE) {
> +const bool id_a = qdict_get(eva->data, "id");
> +const bool id_b = qdict_get(evb->data, "id");
> +
> +if (!id_a && !id_b) {
> +return TRUE;
> +} else if (id_a ^ id_b) {
> +return FALSE;
> +}
> +
> +return !strcmp(qdict_get_str(eva->data, "id"),
> +   qdict_get_str(evb->data, "id"));
> +}
> +
>  return TRUE;
>  }

Patch looks sane, but I recommend to first add the QOM path to the
event, then use it instead of the qdev ID.

Re: [PATCH v3 17/35] acpi: use build_append_int_noprefix() API to compose SRAT table

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> Drop usage of packed structures and explicit endian conversions
> when building SRAT tables for arm/x86 and use endian agnostic
> build_append_int_noprefix() API to build it.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>  * rebase on top of (e77af21a7a2 hw/i386/acpi-build: Get NUMA information 
> from struct NumaState)
> CC: xiaoguangrong.e...@gmail.com
> CC: shannon.zha...@gmail.com
> CC: peter.mayd...@linaro.org
> CC: marcel.apfelb...@gmail.com
> CC: qemu-...@nongnu.org
> CC: drjo...@redhat.com
> CC: eau...@redhat.com
> ---
>  include/hw/acpi/acpi-defs.h | 49 ---
>  include/hw/acpi/aml-build.h |  2 +-
>  hw/acpi/aml-build.c | 24 
>  hw/acpi/nvdimm.c|  4 +-
>  hw/arm/virt-acpi-build.c| 29 --
>  hw/i386/acpi-build.c| 78 +
>  6 files changed, 80 insertions(+), 106 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 5826ee04b6..d293304f9c 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -358,55 +358,6 @@ struct AcpiGenericTimerTable {
>  } QEMU_PACKED;
>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>  
> -#define ACPI_SRAT_PROCESSOR_APIC 0
> -#define ACPI_SRAT_MEMORY 1
> -#define ACPI_SRAT_PROCESSOR_x2APIC   2
> -#define ACPI_SRAT_PROCESSOR_GICC 3
> -
> -struct AcpiSratProcessorAffinity {
> -ACPI_SUB_HEADER_DEF
> -uint8_t proximity_lo;
> -uint8_t local_apic_id;
> -uint32_tflags;
> -uint8_t local_sapic_eid;
> -uint8_t proximity_hi[3];
> -uint32_treserved;
> -} QEMU_PACKED;
> -typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
> -
> -struct AcpiSratProcessorX2ApicAffinity {
> -ACPI_SUB_HEADER_DEF
> -uint16_treserved;
> -uint32_tproximity_domain;
> -uint32_tx2apic_id;
> -uint32_tflags;
> -uint32_tclk_domain;
> -uint32_treserved2;
> -} QEMU_PACKED;
> -typedef struct AcpiSratProcessorX2ApicAffinity 
> AcpiSratProcessorX2ApicAffinity;
> -
> -struct AcpiSratMemoryAffinity {
> -ACPI_SUB_HEADER_DEF
> -uint32_tproximity;
> -uint16_treserved1;
> -uint64_tbase_addr;
> -uint64_trange_length;
> -uint32_treserved2;
> -uint32_tflags;
> -uint32_treserved3[2];
> -} QEMU_PACKED;
> -typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
> -
> -struct AcpiSratProcessorGiccAffinity {
> -ACPI_SUB_HEADER_DEF
> -uint32_tproximity;
> -uint32_tacpi_processor_uid;
> -uint32_tflags;
> -uint32_tclock_domain;
> -} QEMU_PACKED;
> -
> -typedef struct AcpiSratProcessorGiccAffinity AcpiSratProcessorGiccAffinity;
> -
>  /* DMAR - DMA Remapping table r2.2 */
>  struct AcpiTableDmar {
>  ACPI_TABLE_HEADER_DEF
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 4242382399..6e1f42e119 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -487,7 +487,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet 
> *range_set, uint32_t io_offset,
> uint32_t mmio32_offset, uint64_t mmio64_offset,
> uint16_t bus_nr_offset);
>  
> -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> +void build_srat_memory(GArray *table_data, uint64_t base,
> uint64_t len, int node, MemoryAffinityFlags flags);
>  
>  void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 5e8bfb631c..050fdb3f37 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1936,15 +1936,25 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, 
> GArray *table_offsets,
>  acpi_table_end(linker, );
>  }
>  
> -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> +/*
> + * ACPI spec, Revision 4.0
> + * 5.2.16.2 Memory Affinity Structure
> + */
> +void build_srat_memory(GArray *table_data, uint64_t base,
> uint64_t len, int node, MemoryAffinityFlags flags)
>  {
> -numamem->type = ACPI_SRAT_MEMORY;
> -numamem->length = sizeof(*numamem);
> -numamem->proximity = cpu_to_le32(node);
> -numamem->flags = cpu_to_le32(flags);
> -numamem->base_addr = cpu_to_le64(base);
> -numamem->range_length = cpu_to_le64(len);
> +build_append_int_noprefix(table_data, 1, 1); /* Type */
> +build_append_int_noprefix(table_data, 40, 1); /* Length */
> +build_append_int_noprefix(table_data, node, 4); /* Proximity Domain */
> +build_append_int_noprefix(table_data, 0, 2); /* Reserved */
> +build_append_int_noprefix(table_data, base, 4); /* Base Address Low */
> +/* Base Address High */
> +build_append_int_noprefix(table_data, base >> 32, 4);
> +build_append_int_noprefix(table_data, len, 4); /* Length Low */
> +  

Re: [PATCH v3 20/35] acpi: build_amd_iommu: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: marcel.apfelb...@gmail.com
> ---
>  hw/i386/acpi-build.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 45724469b0..9f888d5a2c 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2319,12 +2319,12 @@ build_amd_iommu(GArray *table_data, BIOSLinker 
> *linker, const char *oem_id,
>  const char *oem_table_id)
>  {
>  int ivhd_table_len = 24;
> -int iommu_start = table_data->len;
>  AMDVIState *s = AMD_IOMMU_DEVICE(x86_iommu_get_default());
>  GArray *ivhd_blob = g_array_new(false, true, 1);
> +AcpiTable table = { .sig = "IVRS", .rev = 1, .oem_id = oem_id,
> +.oem_table_id = oem_table_id };
>  
> -/* IVRS header */
> -acpi_data_push(table_data, sizeof(AcpiTableHeader));
> +acpi_table_begin(, table_data);
>  /* IVinfo - IO virtualization information common to all
>   * IOMMU units in a system
>   */
> @@ -2409,10 +2409,7 @@ build_amd_iommu(GArray *table_data, BIOSLinker 
> *linker, const char *oem_id,
>   0x48,  /* special 
> device */
>   8);
>  }
> -
> -build_header(linker, table_data, (void *)(table_data->data + 
> iommu_start),
> - "IVRS", table_data->len - iommu_start, 1, oem_id,
> - oem_table_id);
> +acpi_table_end(linker, );
>  }
>  
>  typedef
> 
Reviewed-by: Eric Auger 

Eric

Re: [PATCH v3 22/35] acpi: x86: remove dead code

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 
> ---
>  include/hw/acpi/acpi-defs.h | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index c7fa5caa06..af4fa412a5 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -163,19 +163,6 @@ struct AcpiFacsDescriptorRev1 {
>  } QEMU_PACKED;
>  typedef struct AcpiFacsDescriptorRev1 AcpiFacsDescriptorRev1;
>  
> -/*
> - * Differentiated System Description Table (DSDT)
> - */
> -
> -/*
> - * MADT values and structures
> - */
> -
> -/* Values for MADT PCATCompat */
> -
> -#define ACPI_DUAL_PIC0
> -#define ACPI_MULTIPLE_APIC   1
> -
>  /* Values for Type in APIC sub-headers */
>  
>  #define ACPI_APIC_PROCESSOR  0
> 

Reviewed-by: Eric Auger 

Eric

Re: [PATCH v3 23/35] acpi: x86: set enabled when composing _MAT entries

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> Instead of composing disabled _MAT entry and then later on
> patching it to enabled for hotpluggbale CPUs in DSDT,
> set it to enabled at the time _MAT entry is built.
> 
> It will allow to drop usage of packed structures in
> following patches when build_madt() is switched to use
> build_append_int_noprefix() API.
> 
> Signed-off-by: Igor Mammedov 
> ---
> CC: marcel.apfelb...@gmail.com
> ---
>  include/hw/acpi/acpi_dev_interface.h |  3 ++-
>  include/hw/i386/pc.h |  6 +++---
>  hw/acpi/acpi-x86-stub.c  |  3 ++-
>  hw/acpi/cpu.c| 17 ++---
>  hw/i386/acpi-common.c| 18 ++
>  5 files changed, 15 insertions(+), 32 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi_dev_interface.h 
> b/include/hw/acpi/acpi_dev_interface.h
> index 769ff55c7e..ea6056ab92 100644
> --- a/include/hw/acpi/acpi_dev_interface.h
> +++ b/include/hw/acpi/acpi_dev_interface.h
> @@ -53,6 +53,7 @@ struct AcpiDeviceIfClass {
>  void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
>  void (*send_event)(AcpiDeviceIf *adev, AcpiEventStatusBits ev);
>  void (*madt_cpu)(AcpiDeviceIf *adev, int uid,
> - const CPUArchIdList *apic_ids, GArray *entry);
> + const CPUArchIdList *apic_ids, GArray *entry,
> + bool force_enabled);
>  };
>  #endif
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 4d2e35a152..82cf7b7e30 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -187,10 +187,10 @@ bool pc_system_ovmf_table_find(const char *entry, 
> uint8_t **data,
> int *data_len);
>  void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size);
>  
> -
> -/* acpi-build.c */
> +/* hw/i386/acpi-common.c */
>  void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> -   const CPUArchIdList *apic_ids, GArray *entry);
> +   const CPUArchIdList *apic_ids, GArray *entry,
> +   bool force_enabled);
>  
>  extern GlobalProperty pc_compat_6_1[];
>  extern const size_t pc_compat_6_1_len;
> diff --git a/hw/acpi/acpi-x86-stub.c b/hw/acpi/acpi-x86-stub.c
> index e9e46c5c5f..3df1e090f4 100644
> --- a/hw/acpi/acpi-x86-stub.c
> +++ b/hw/acpi/acpi-x86-stub.c
> @@ -3,7 +3,8 @@
>  #include "hw/i386/acpi-build.h"
>  
>  void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> -   const CPUArchIdList *apic_ids, GArray *entry)
> +   const CPUArchIdList *apic_ids, GArray *entry,
> +   bool force_enabled)
>  {
>  }
>  
> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
> index f82e9512fd..b20903ea30 100644
> --- a/hw/acpi/cpu.c
> +++ b/hw/acpi/cpu.c
> @@ -669,21 +669,8 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
> CPUHotplugFeatures opts,
>  
>  /* build _MAT object */
>  assert(adevc && adevc->madt_cpu);
> -adevc->madt_cpu(adev, i, arch_ids, madt_buf);
> -switch (madt_buf->data[0]) {
> -case ACPI_APIC_PROCESSOR: {
> -AcpiMadtProcessorApic *apic = (void *)madt_buf->data;
> -apic->flags = cpu_to_le32(1);
> -break;
> -}
> -case ACPI_APIC_LOCAL_X2APIC: {
> -AcpiMadtProcessorX2Apic *apic = (void *)madt_buf->data;
> -apic->flags = cpu_to_le32(1);
> -break;
> -}
> -default:
> -assert(0);
> -}
> +adevc->madt_cpu(adev, i, arch_ids, madt_buf,
> +true); /* set enabled flag */
>  aml_append(dev, aml_name_decl("_MAT",
>  aml_buffer(madt_buf->len, (uint8_t *)madt_buf->data)));
>  g_array_free(madt_buf, true);
> diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> index a0cde1d874..7983a13a93 100644
> --- a/hw/i386/acpi-common.c
> +++ b/hw/i386/acpi-common.c
> @@ -34,9 +34,11 @@
>  #include "acpi-common.h"
>  
>  void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> -   const CPUArchIdList *apic_ids, GArray *entry)
> +   const CPUArchIdList *apic_ids, GArray *entry,
> +   bool force_enabled)
>  {
>  uint32_t apic_id = apic_ids->cpus[uid].arch_id;
> +uint32_t flags = apic_ids->cpus[uid].cpu != NULL || force_enabled ? 1 : 
> 0;
>  
>  /* ACPI spec says that LAPIC entry for non present
>   * CPU may be omitted from MADT or it must be marked
> @@ -51,11 +53,7 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
>  apic->length = sizeof(*apic);
>  apic->processor_id = uid;
>  apic->local_apic_id = apic_id;
> -if (apic_ids->cpus[uid].cpu != NULL) {
> -apic->flags = cpu_to_le32(1);
> -} else {
> -apic->flags = cpu_to_le32(0);
> -   

Re: [PATCH v3 03/15] target/ppc: PMU basic cycle count for pseries TCG

[Matheus K. Ferst]

On 03/09/2021 17:31, Daniel Henrique Barboza wrote:

[E-MAIL EXTERNO] Não clique em links ou abra anexos, a menos que você possa 
confirmar o remetente e saber que o conteúdo é seguro. Em caso de e-mail 
suspeito entre imediatamente em contato com o DTI.

This patch adds the barebones of the PMU logic by enabling cycle
counting, done via the performance monitor counter 6. The overall logic
goes as follows:

- a helper is added to control the PMU state on each MMCR0 write. This
allows for the PMU to start/stop as the frozen counter bit (MMCR0_FC)
is cleared or set;

- MMCR0 reg initial value is set to 0x8000 (MMCR0_FC set) to avoid
having to spin the PMU right at system init;

- the intended usage is to freeze the counters by setting MMCR0_FC, do
any additional setting of events to be counted via MMCR1 (not
implemented yet) and enable the PMU by zeroing MMCR0_FC. Software must
freeze counters to read the results - on the fly reading of the PMCs
will return the starting value of each one.

Since there will be more PMU exclusive code to be added next, put the
PMU logic in its own helper to keep all in the same place. The name of
the new helper file, power8_pmu.c, is an indicative that the PMU logic
has been tested with the IBM POWER chip family, POWER8 being the oldest
version tested. This doesn't mean that this PMU logic will break with
any other PPC64 chip that implements Book3s, but since we can't assert
that this PMU will work with all available Book3s emulated processors
we're choosing to be explicit.

Signed-off-by: Daniel Henrique Barboza 
---





diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 0babde3131..c3e2e3d329 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -401,6 +401,24 @@ void spr_write_generic(DisasContext *ctx, int sprn, int 
gprn)
  spr_store_dump_spr(sprn);
  }

+#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
+void spr_write_MMCR0(DisasContext *ctx, int sprn, int gprn)
+{
+/*
+ * helper_store_mmcr0 will make clock based operations that
+ * will cause 'bad icount read' errors if we do not execute
+ * gen_icount_io_start() beforehand.
+ */
+gen_icount_io_start(ctx);
+gen_helper_store_mmcr0(cpu_env, cpu_gpr[gprn]);
+}
+#else
+void spr_write_MMCR0(DisasContext *ctx, int sprn, int gprn)
+{
+spr_write_generic(ctx, sprn, gprn);
+}
+#endif
+
  #if !defined(CONFIG_USER_ONLY)
  void spr_write_generic32(DisasContext *ctx, int sprn, int gprn)
  {
@@ -596,7 +614,10 @@ void spr_write_MMCR0_ureg(DisasContext *ctx, int sprn, int 
gprn)
  tcg_gen_andi_tl(t1, t1, ~(MMCR0_UREG_MASK));
  /* Keep all other bits intact */
  tcg_gen_or_tl(t1, t1, t0);
-gen_store_spr(SPR_POWER_MMCR0, t1);
+
+/* Overwrite cpu_gpr[gprn] and use spr_write_MMCR0() */
+tcg_gen_mov_tl(cpu_gpr[gprn], t1);
+spr_write_MMCR0(ctx, sprn + 0x10, gprn);


IIUC, this makes writing to MMCR0 change the GPR value and expose the 
unfiltered content of the SPR to problem state. It might be better to 
call the helper directly or create another method that takes a TCGv as 
an argument and call it from spr_write_MMCR0_ureg and spr_write_MMCR0.




  tcg_temp_free(t0);
  tcg_temp_free(t1);
--
2.31.1




--
Matheus K. Ferst
Instituto de Pesquisas ELDORADO 
Analista de Software Júnior
Aviso Legal - Disclaimer 

[PATCH 1/3] docs: rSTify the "SpellCheck" wiki

[Kashyap Chamarthy]

The original wiki is here[1].  I converted by copying the wiki source[2]
into a .wiki file and convert to rST using `pandoc`:

$ pandoc -f Mediawiki -t rst spell-check.wiki -o spell-check.rst

[1] https://wiki.qemu.org/Contribute/SpellCheck
[2] 
https://web.archive.org/web/20170721031029/http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch=edit

Signed-off-by: Kashyap Chamarthy 
---
 docs/devel/spell-check.rst | 29 +
 1 file changed, 29 insertions(+)
 create mode 100644 docs/devel/spell-check.rst

diff --git a/docs/devel/spell-check.rst b/docs/devel/spell-check.rst
new file mode 100644
index 00..998cd7ef51
--- /dev/null
+++ b/docs/devel/spell-check.rst
@@ -0,0 +1,29 @@
+===
+Spell Check
+===
+
+QEMU uses British or American English in code and documentation. There
+are some typical spelling bugs which can be easily avoided by using
+tools like codespell.
+
+codespell is a python script which detects (and optionally fixes) the
+most common spelling bugs.
+
+If you installed codespell in your HOME directory, it can be called from
+the QEMU source directory like this::
+
+~/bin/codespell.py -d -r -s -x scripts/codespell.exclude -q 2 
~/share/codespell/dictionary.txt
+
+``-x scripts/codespell.exclude`` excludes some known lines from the check
+and needs a file which is not yet committed.
+
+.. _external_links:
+
+External Links
+--
+
+-  http://packages.profusion.mobi/codespell/ (download)
+-  http://git.profusion.mobi/cgit.cgi/lucas/codespell/ (git repository)
+-  https://github.com/lucasdemarchi/codespell (alternate git repository)
+-  
http://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
+-  http://grammar.yourdictionary.com/spelling-and-word-lists/misspelled.html
-- 
2.31.1

[PATCH 0/3] rSTify SubmitAPatch, TrivialPatches, and SpellCheck wiki pages

[Kashyap Chamarthy]

As of writing this, qemu.org is down, so I've used a one-month old
copy[1] of the wiki from 27Aug2021 to do the rST conversion.

My main motivation was to convert SubmitAPatch (when Peter Maydell
pointed out on IRC that it's still on the wiki).  But it links to a
couple more small wiki pages; so I converted them too:

  - SpellCheck: https://wiki.qemu.org/Contribute/SpellCheck
  - TrivialPatches: https://wiki.qemu.org/Contribute/TrivialPatches

[1] 
https://web.archive.org/web/20210827130706/https://wiki.qemu.org/Contribute/SubmitAPatch

Kashyap Chamarthy (3):
  docs: rSTify the "SpellCheck" wiki
  docs: rSTify the "TrivialPatches" wiki
  docs: rSTify the "SubmitAPatch" wiki

 docs/devel/spell-check.rst|  29 ++
 docs/devel/submitting-a-patch.rst | 460 ++
 docs/devel/trivial-patches.rst|  53 
 3 files changed, 542 insertions(+)
 create mode 100644 docs/devel/spell-check.rst
 create mode 100644 docs/devel/submitting-a-patch.rst
 create mode 100644 docs/devel/trivial-patches.rst

-- 
2.31.1

[PATCH 07/14] bsd-user/target_os_elf.h: Remove fallback ELF_HWCAP and reorder

[Warner Losh]

All architectures have a ELF_HWCAP, so remove the fallback ifdef.
Place ELF_HWCAP in the same order as on native FreeBSD.

Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/target_os_elf.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/bsd-user/freebsd/target_os_elf.h b/bsd-user/freebsd/target_os_elf.h
index 2d03a883aa..adcffd1ddb 100644
--- a/bsd-user/freebsd/target_os_elf.h
+++ b/bsd-user/freebsd/target_os_elf.h
@@ -38,10 +38,6 @@
 #define ELF_PLATFORM (NULL)
 #endif
 
-#ifndef ELF_HWCAP
-#define ELF_HWCAP 0
-#endif
-
 /* XXX Look at the other conflicting AT_* values. */
 #define FREEBSD_AT_NCPUS 19
 #define FREEBSD_AT_HWCAP 25
@@ -114,12 +110,12 @@ static abi_ulong target_create_elf_tables(abi_ulong p, 
int argc, int envc,
 NEW_AUX_ENT(AT_FLAGS, (abi_ulong)0);
 NEW_AUX_ENT(FREEBSD_AT_NCPUS, (abi_ulong)bsd_get_ncpu());
 NEW_AUX_ENT(AT_ENTRY, load_bias + exec->e_entry);
+features = ELF_HWCAP;
+NEW_AUX_ENT(FREEBSD_AT_HWCAP, features);
 NEW_AUX_ENT(AT_UID, (abi_ulong)getuid());
 NEW_AUX_ENT(AT_EUID, (abi_ulong)geteuid());
 NEW_AUX_ENT(AT_GID, (abi_ulong)getgid());
 NEW_AUX_ENT(AT_EGID, (abi_ulong)getegid());
-features = ELF_HWCAP;
-NEW_AUX_ENT(FREEBSD_AT_HWCAP, features);
 target_auxents = sp; /* Note where the aux entries are in the target */
 #ifdef ARCH_DLINFO
 /*
-- 
2.32.0

[PATCH 04/14] bsd-user: export get_errno and is_error from syscall.c

[Warner Losh]

Make get_errno and is_error global so files other than syscall.c can use
them.

Signed-off-by: Warner Losh 
---
 bsd-user/qemu.h|  4 
 bsd-user/syscall.c | 10 +-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 522d6c4031..22fc3a6c30 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -235,6 +235,10 @@ extern unsigned long target_dflssiz;
 extern unsigned long target_maxssiz;
 extern unsigned long target_sgrowsiz;
 
+/* syscall.c */
+abi_long get_errno(abi_long ret);
+int is_error(abi_long ret);
+
 /* user access */
 
 #define VERIFY_READ  PAGE_READ
diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 372836d44d..a579d52ede 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -33,18 +33,18 @@
 static abi_ulong target_brk;
 static abi_ulong target_original_brk;
 
-static inline abi_long get_errno(abi_long ret)
+abi_long get_errno(abi_long ret)
 {
-if (ret == -1)
+if (ret == -1) {
 /* XXX need to translate host -> target errnos here */
 return -(errno);
-else
-return ret;
+}
+return ret;
 }
 
 #define target_to_host_bitmask(x, tbl) (x)
 
-static inline int is_error(abi_long ret)
+int is_error(abi_long ret)
 {
 return (abi_ulong)ret >= (abi_ulong)(-4096);
 }
-- 
2.32.0

Re: [PATCH v2] spapr/xive: Fix kvm_xive_source_reset trace event

[Cédric Le Goater]

On 9/22/21 09:06, Greg Kurz wrote:

On Wed, 22 Sep 2021 09:02:05 +0200
Cédric Le Goater  wrote:


The trace event was placed in the wrong routine. Move it under
kvmppc_xive_source_reset_one().

Fixes: 4e960974d4ee ("xive: Add trace events")
Signed-off-by: Cédric Le Goater 
---


Reviewed-by: Greg Kurz 


Thanks,

C.




  hw/intc/spapr_xive_kvm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index beb904d5bdee..bf43ffb54018 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -236,6 +236,8 @@ int kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
  SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
  uint64_t state = 0;
  
+trace_kvm_xive_source_reset(srcno);

+
  assert(xive->fd != -1);
  
  if (xive_source_irq_is_lsi(xsrc, srcno)) {

@@ -328,8 +330,6 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t offset,
  return xive_esb_rw(xsrc, srcno, offset, data, 1);
  }
  
-trace_kvm_xive_source_reset(srcno);

-
  /*
   * Special Load EOI handling for LSI sources. Q bit is never set
   * and the interrupt should be re-triggered if the level is still

[PATCH 03/14] bsd-user: TARGET_RESET define is unused, remove it

[Warner Losh]

Signed-off-by: Warner Losh 
---
 bsd-user/i386/target_arch_cpu.h   | 2 --
 bsd-user/x86_64/target_arch_cpu.h | 2 --
 2 files changed, 4 deletions(-)

diff --git a/bsd-user/i386/target_arch_cpu.h b/bsd-user/i386/target_arch_cpu.h
index 978e8066af..b28602adbb 100644
--- a/bsd-user/i386/target_arch_cpu.h
+++ b/bsd-user/i386/target_arch_cpu.h
@@ -23,8 +23,6 @@
 
 #define TARGET_DEFAULT_CPU_MODEL "qemu32"
 
-#define TARGET_CPU_RESET(cpu)
-
 static inline void target_cpu_init(CPUX86State *env,
 struct target_pt_regs *regs)
 {
diff --git a/bsd-user/x86_64/target_arch_cpu.h 
b/bsd-user/x86_64/target_arch_cpu.h
index 5f5ee602f9..5172b230f0 100644
--- a/bsd-user/x86_64/target_arch_cpu.h
+++ b/bsd-user/x86_64/target_arch_cpu.h
@@ -23,8 +23,6 @@
 
 #define TARGET_DEFAULT_CPU_MODEL "qemu64"
 
-#define TARGET_CPU_RESET(cpu)
-
 static inline void target_cpu_init(CPUX86State *env,
 struct target_pt_regs *regs)
 {
-- 
2.32.0

[PATCH v2] spapr/xive: Fix kvm_xive_source_reset trace event

[Cédric Le Goater]

The trace event was placed in the wrong routine. Move it under
kvmppc_xive_source_reset_one().

Fixes: 4e960974d4ee ("xive: Add trace events")
Signed-off-by: Cédric Le Goater 
---
 hw/intc/spapr_xive_kvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index beb904d5bdee..bf43ffb54018 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -236,6 +236,8 @@ int kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
 SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 uint64_t state = 0;
 
+trace_kvm_xive_source_reset(srcno);
+
 assert(xive->fd != -1);
 
 if (xive_source_irq_is_lsi(xsrc, srcno)) {
@@ -328,8 +330,6 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t offset,
 return xive_esb_rw(xsrc, srcno, offset, data, 1);
 }
 
-trace_kvm_xive_source_reset(srcno);
-
 /*
  * Special Load EOI handling for LSI sources. Q bit is never set
  * and the interrupt should be re-triggered if the level is still
-- 
2.31.1

Re: [PATCH v2] iotests/check: move long options to double dash

[Vladimir Sementsov-Ogievskiy]

ping.

Patch is reviewed)

03.09.2021 15:00, Vladimir Sementsov-Ogievskiy wrote:

So, the change:

   -makecheck -> --makecheck
   -gdb   -> --gdb
   -valgrind  -> --valgrind
   -misalign  -> --misalign
   -nocache   -> --nocache
   -qcow2 (and other formats) -> --qcow2
   -file (and other protocols) -> --file

Motivation:

1. check scripts uses ArgumentParser to parse options, which supports
combining of short options. So using one dash for long options is a
bit ambiguous.

2. Several long options are already have double dash:
   --dry-run, --color, --groups, --exclude-groups, --start-from

3. -misalign is used to add --misalign option (two dashes) to qemu-io

4. qemu-io and qemu-nbd has --nocache option (two dashes)

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

v2: cover more things, update also format and protocol options

  docs/devel/testing.rst   | 12 ++--
  .gitlab-ci.d/buildtest.yml   |  4 ++--
  tests/check-block.sh |  2 +-
  tests/qemu-iotests/README|  7 ---
  tests/qemu-iotests/check | 14 +++---
  tests/qemu-iotests/common.rc |  4 ++--
  6 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 4a0abbf23d..907b18a600 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -153,16 +153,16 @@ with arguments:
  .. code::
  
# test with qcow2 format

-  ./check -qcow2
+  ./check --qcow2
# or test a different protocol
-  ./check -nbd
+  ./check --nbd
  
  It's also possible to list test numbers explicitly:
  
  .. code::
  
# run selected cases with qcow2 format

-  ./check -qcow2 001 030 153
+  ./check --qcow2 001 030 153
  
  Cache mode can be selected with the "-c" option, which may help reveal bugs

  that are specific to certain cache mode.
@@ -229,7 +229,7 @@ Debugging a test case
  The following options to the ``check`` script can be useful when debugging
  a failing test:
  
-* ``-gdb`` wraps every QEMU invocation in a ``gdbserver``, which waits for a

+* ``--gdb`` wraps every QEMU invocation in a ``gdbserver``, which waits for a
connection from a gdb client.  The options given to ``gdbserver`` (e.g. the
address on which to listen for connections) are taken from the 
``$GDB_OPTIONS``
environment variable.  By default (if ``$GDB_OPTIONS`` is empty), it 
listens on
@@ -237,10 +237,10 @@ a failing test:
It is possible to connect to it for example with
``gdb -iex "target remote $addr"``, where ``$addr`` is the address
``gdbserver`` listens on.
-  If the ``-gdb`` option is not used, ``$GDB_OPTIONS`` is ignored,
+  If the ``--gdb`` option is not used, ``$GDB_OPTIONS`` is ignored,
regardless of whether it is set or not.
  
-* ``-valgrind`` attaches a valgrind instance to QEMU. If it detects

+* ``--valgrind`` attaches a valgrind instance to QEMU. If it detects
warnings, it will print and save the log in
``$TEST_DIR/.valgrind``.
The final command line will be ``valgrind --log-file=$TEST_DIR/
diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index e74998efb9..139c27554d 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -303,10 +303,10 @@ build-tcg-disabled:
  - make check-unit
  - make check-qapi-schema
  - cd tests/qemu-iotests/
-- ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 048
+- ./check --raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 048
  052 063 077 086 101 104 106 113 148 150 151 152 157 159 160 163
  170 171 183 184 192 194 208 221 226 227 236 253 277 image-fleecing
-- ./check -qcow2 028 051 056 057 058 065 068 082 085 091 095 096 102 122
+- ./check --qcow2 028 051 056 057 058 065 068 082 085 091 095 096 102 122
  124 132 139 142 144 145 151 152 155 157 165 194 196 200 202
  208 209 216 218 227 234 246 247 248 250 254 255 257 258
  260 261 262 263 264 270 272 273 277 279 image-fleecing
diff --git a/tests/check-block.sh b/tests/check-block.sh
index f86cb863de..cff1263c0b 100755
--- a/tests/check-block.sh
+++ b/tests/check-block.sh
@@ -77,7 +77,7 @@ export PYTHONUTF8=1
  
  ret=0

  for fmt in $format_list ; do
-${PYTHON} ./check -makecheck -$fmt $group || ret=1
+${PYTHON} ./check --makecheck --$fmt $group || ret=1
  done
  
  exit $ret

diff --git a/tests/qemu-iotests/README b/tests/qemu-iotests/README
index 6079b401ae..8e1f3e19c3 100644
--- a/tests/qemu-iotests/README
+++ b/tests/qemu-iotests/README
@@ -10,9 +10,10 @@ but no actual block drivers like ide, scsi or virtio.
  
  * Usage
  
-Just run ./check to run all tests for the raw image format, or ./check

--qcow2 to test the qcow2 image format.  The output of ./check -h explains
-additional options to test further image formats or I/O methods.
+Just run ./check to run all tests for the raw image format,
+or ./check --qcow2 to test the qcow2 image format.  The output of
+./check -h 

[PATCH 11/14] bsd-user/sysarch: Move to using do_freebsd_arch_sysarch interface

[Warner Losh]

Convert the #ifdef'd i386 code to calling the i386 sysarch code we have
living in i386,x86_64/target_arch_sysarch.h do_freebsd_arch_sysarch
rather than having a separate copy. This is in preparation to remove it
entirely.

Signed-Off-By: Warner Losh 
---
 bsd-user/syscall.c | 45 +
 1 file changed, 1 insertion(+), 44 deletions(-)

diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index a579d52ede..9bc72501b2 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -91,50 +91,7 @@ static abi_long do_obreak(abi_ulong new_brk)
 #if defined(TARGET_I386)
 static abi_long do_freebsd_sysarch(CPUX86State *env, int op, abi_ulong parms)
 {
-abi_long ret = 0;
-abi_ulong val;
-int idx;
-
-switch (op) {
-#ifdef TARGET_ABI32
-case TARGET_FREEBSD_I386_SET_GSBASE:
-case TARGET_FREEBSD_I386_SET_FSBASE:
-if (op == TARGET_FREEBSD_I386_SET_GSBASE)
-#else
-case TARGET_FREEBSD_AMD64_SET_GSBASE:
-case TARGET_FREEBSD_AMD64_SET_FSBASE:
-if (op == TARGET_FREEBSD_AMD64_SET_GSBASE)
-#endif
-idx = R_GS;
-else
-idx = R_FS;
-if (get_user(val, parms, abi_ulong))
-return -TARGET_EFAULT;
-cpu_x86_load_seg(env, idx, 0);
-env->segs[idx].base = val;
-break;
-#ifdef TARGET_ABI32
-case TARGET_FREEBSD_I386_GET_GSBASE:
-case TARGET_FREEBSD_I386_GET_FSBASE:
-if (op == TARGET_FREEBSD_I386_GET_GSBASE)
-#else
-case TARGET_FREEBSD_AMD64_GET_GSBASE:
-case TARGET_FREEBSD_AMD64_GET_FSBASE:
-if (op == TARGET_FREEBSD_AMD64_GET_GSBASE)
-#endif
-idx = R_GS;
-else
-idx = R_FS;
-val = env->segs[idx].base;
-if (put_user(val, parms, abi_ulong))
-return -TARGET_EFAULT;
-break;
-/* XXX handle the others... */
-default:
-ret = -TARGET_EINVAL;
-break;
-}
-return ret;
+do_freebsd_arch_sysarch(env, op, parms);
 }
 #endif
 
-- 
2.32.0

Re: ensuring a machine's buses have unique names

[Cédric Le Goater]

On 9/22/21 09:02, Markus Armbruster wrote:

Peter Maydell  writes:


On Wed, 15 Sept 2021 at 05:28, Markus Armbruster  wrote:


Peter Maydell  writes:

I'm not sure how best to sort this tangle out. We could:
  * make controller devices pass in NULL as bus name; this
means that some bus names will change, which is an annoying
breakage but for these minor bus types we can probably
get away with it. This brings these buses into line with
how we've been handling uniqueness for ide and scsi.


To gauge the breakage, we need a list of the affected bus names.


Looking through, there are a few single-use or special
purpose buses I'm going to ignore for now (eg vmbus, or
the s390 ones). The four big bus types where controllers
often specify a bus name and override the 'autogenerate
unique name' handling are pci, ssi, sd, and i2c. (pci mostly
gets away with it I expect by machines only having one pci
bus.) Of those, I've gone through i2c. These are all the
places where we create a specifically-named i2c bus (via
i2c_init_bus()), together with the affected boards:

hw/arm/pxa2xx.c
 - the PXA SoC code creates both the intended-for-use
   i2c buses (which get auto-names) and also several i2c
   buses intended for internal board-code use only which
   are all given the same name "dummy".
   Boards: connex, verdex, tosa, mainstone, akita, spitz,
   borzoi, terrier, z2
hw/arm/stellaris.c
 - The i2c controller names its bus "i2c". There is only one i2c
   controller on these boards, so no name conflicts.
   Boards: lm3s811evb, lm3s6965evb
hw/display/ati.c
 - The ATI VGA device has an on-board i2c controller which it
   connects the DDC that holds the EDID information. The bus is
   always named "ati-vga.ddc", so if you have multiple of this
   PCI device in the system the buses have the same names.
hw/display/sm501.c
 - Same as ATI, but the bus name is "sm501.i2c"
hw/i2c/aspeed_i2c.c
 - This I2C controller has either 14 or 16 (!) different i2c
   buses, and it assigns them names "aspeed.i2c.N" for N = 0,1,2,...
   The board code mostly seems to use these to wire up various
   on-board i2c devices.
   Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
   swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
   tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc
hw/i2c/bitbang_i2c.c
 - the "GPIO to I2C bridge" device always names its bus "i2c".
   Used only on musicpal, which only creates one of these buses.
   Boards: musicpal
hw/i2c/exynos4210_i2c.c
 - This i2c controller always names its bus "i2c". There are 9
   of these controllers on the board, so they all have clashing
   names.
   Boards: nuri, smdkc210
hw/i2c/i2c_mux_pca954x.c
 - This is an i2c multiplexer. All the child buses are named
   "i2c-bus". The multiplexer is used by the aspeed and npcm7xx
   boards. (There's a programmable way to get at individual
   downstream i2c buses despite the name clash; none of the boards
   using this multiplexer actually connect any devices downstream of
   it yet.)
   Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
   swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
   tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc,
   npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
hw/i2c/mpc_i2c.c
 - This controller always names its bus "i2c". There is only one
   of these controllers in the machine.
   Boards: ppce500, mpc8544ds
hw/i2c/npcm7xx_smbus.c
 - This controller always names its bus "i2c-bus". There are multiple
   controllers on the boards. The name also clashes with the one used
   by the pca954x muxes on these boards (see above).
   Boards: npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
hw/i2c/pm_smbus.c
 - This is the PC SMBUS implementation (it is not a QOM device...)
   The bus is always called "i2c".
   Boards: haven't worked through; at least all the x86 PC-like
   boards, I guess
hw/i2c/ppc4xx_i2c.c
 - This controller always names its bus "i2c". The taihu and
   ref405ep have only one controller, but sam460ex has two which
   will have non-unique names.
   Boards: taihu, ref405ep, sam460ex
hw/i2c/versatile_i2c.c
 - This controller always names its bus "i2c". The MPS boards all
   have multiples of this controller with clashing names; the others
   have only one controller.
   Boards: mps2-an385, mps2-an386, mps2-an500, mps2-an511,
   mps2-an505, mps2-an521, mps3-an524, mps3-an547,
   realview-eb, realview-eb-mpcore, realview-pb-a8, realview-pbx-a9,
   versatileab, versatilepb, vexpress-a9, vexpress-a15

In a lot of these cases I suspect the i2c controllers are
provided either to allow connection of various internal-to-the-board
devices, or simply so that guest OS 

[PATCH 02/14] bsd-user/strace.list: Remove support for FreeBSD versions older than 12.0

[Warner Losh]

Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/strace.list | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/bsd-user/freebsd/strace.list b/bsd-user/freebsd/strace.list
index b01b5f36e8..275d2dbe27 100644
--- a/bsd-user/freebsd/strace.list
+++ b/bsd-user/freebsd/strace.list
@@ -33,10 +33,6 @@
 { TARGET_FREEBSD_NR___syscall, "__syscall", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR___sysctl, "__sysctl", NULL, print_sysctl, NULL },
 { TARGET_FREEBSD_NR__umtx_op, "_umtx_op", "%s(%#x, %d, %d, %#x, %#x)", NULL, 
NULL },
-#if defined(__FreeBSD_version) && __FreeBSD_version < 100
-{ TARGET_FREEBSD_NR__umtx_lock, "__umtx_lock", NULL, NULL, NULL },
-{ TARGET_FREEBSD_NR__umtx_unlock, "__umtx_unlock", NULL, NULL, NULL },
-#endif
 { TARGET_FREEBSD_NR_accept, "accept", "%s(%d,%#x,%#x)", NULL, NULL },
 { TARGET_FREEBSD_NR_accept4, "accept4", "%s(%d,%d,%#x,%#x)", NULL, NULL },
 { TARGET_FREEBSD_NR_access, "access", "%s(\"%s\",%#o)", NULL, NULL },
@@ -49,10 +45,6 @@
 { TARGET_FREEBSD_NR_cap_fcntls_get, "cap_fcntls_get", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_cap_fcntls_limit, "cap_fcntls_limit", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_cap_getmode, "cap_getmode", NULL, NULL, NULL },
-#if defined(__FreeBSD_version) && __FreeBSD_version < 100
-{ TARGET_FREEBSD_NR_cap_getrights, "cap_getrights", NULL, NULL, NULL },
-{ TARGET_FREEBSD_NR_cap_new, "cap_new", NULL, NULL, NULL },
-#endif
 { TARGET_FREEBSD_NR_cap_ioctls_get, "cap_ioctls_get", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_cap_ioctls_limit, "cap_ioctls_limit", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_cap_rights_limit, "cap_rights_limit", NULL, NULL, NULL },
@@ -146,9 +138,6 @@
 { TARGET_FREEBSD_NR_freebsd11_kevent, "freebsd11_kevent", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_kevent, "kevent", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_kill, "kill", NULL, NULL, NULL },
-#if defined(__FreeBSD_version) && __FreeBSD_version < 100
-{ TARGET_FREEBSD_NR_killpg, "killpg", NULL, NULL, NULL },
-#endif
 { TARGET_FREEBSD_NR_kqueue, "kqueue", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_ktrace, "ktrace", NULL, NULL, NULL },
 { TARGET_FREEBSD_NR_lchown, "lchown", NULL, NULL, NULL },
-- 
2.32.0

[PATCH 12/14] bsd-user/sysarch: Provide a per-arch framework for sysarch syscall

[Warner Losh]

Add the missing glue to pull in do_freebsd_sysarch to call
do_freebsd_arch_sysarch. Put it in os-sys.c, which will be used for
sysctl and sysarch system calls because they are mostly arch specific.

Signed-off-by: Stacey Son 
Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/meson.build |  3 +++
 bsd-user/freebsd/os-sys.c| 28 
 bsd-user/meson.build |  6 ++
 bsd-user/qemu.h  |  3 +++
 bsd-user/syscall.c   |  7 ---
 5 files changed, 40 insertions(+), 7 deletions(-)
 create mode 100644 bsd-user/freebsd/meson.build
 create mode 100644 bsd-user/freebsd/os-sys.c

diff --git a/bsd-user/freebsd/meson.build b/bsd-user/freebsd/meson.build
new file mode 100644
index 00..4b69cca7b9
--- /dev/null
+++ b/bsd-user/freebsd/meson.build
@@ -0,0 +1,3 @@
+bsd_user_ss.add(files(
+  'os-sys.c',
+))
diff --git a/bsd-user/freebsd/os-sys.c b/bsd-user/freebsd/os-sys.c
new file mode 100644
index 00..756b024305
--- /dev/null
+++ b/bsd-user/freebsd/os-sys.c
@@ -0,0 +1,28 @@
+/*
+ *  FreeBSD sysctl() and sysarch() system call emulation
+ *
+ *  Copyright (c) 2013-15 Stacey D. Son
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program 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 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.h"
+#include "target_arch_sysarch.h"
+
+/* sysarch() is architecture dependent. */
+abi_long do_freebsd_sysarch(void *cpu_env, abi_long arg1, abi_long arg2)
+{
+
+return do_freebsd_arch_sysarch(cpu_env, arg1, arg2);
+}
diff --git a/bsd-user/meson.build b/bsd-user/meson.build
index 0369549340..561913de05 100644
--- a/bsd-user/meson.build
+++ b/bsd-user/meson.build
@@ -8,3 +8,9 @@ bsd_user_ss.add(files(
   'syscall.c',
   'uaccess.c',
 ))
+
+# Pull in the OS-specific build glue, if any
+if fs.exists(targetos)
+   subdir(targetos)
+endif
+
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 4ee57b91f0..3dde381d5d 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -239,6 +239,9 @@ extern unsigned long target_sgrowsiz;
 abi_long get_errno(abi_long ret);
 int is_error(abi_long ret);
 
+/* os-sys.c */
+abi_long do_freebsd_sysarch(void *cpu_env, abi_long arg1, abi_long arg2);
+
 /* user access */
 
 #define VERIFY_READ  PAGE_READ
diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 9bc72501b2..9f51563abd 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -88,13 +88,6 @@ static abi_long do_obreak(abi_ulong new_brk)
 return 0;
 }
 
-#if defined(TARGET_I386)
-static abi_long do_freebsd_sysarch(CPUX86State *env, int op, abi_ulong parms)
-{
-do_freebsd_arch_sysarch(env, op, parms);
-}
-#endif
-
 #ifdef __FreeBSD__
 /*
  * XXX this uses the undocumented oidfmt interface to find the kind of
-- 
2.32.0

[PATCH 09/14] bsd-user: Remove used from TaskState

[Warner Losh]

The used field of TaskState is write only. Eliminate it.

Signed-off-by: Warner Losh 
---
 bsd-user/main.c | 1 -
 bsd-user/qemu.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/bsd-user/main.c b/bsd-user/main.c
index 48643eeabc..ee84554854 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -210,7 +210,6 @@ void init_task_state(TaskState *ts)
 {
 int i;
 
-ts->used = 1;
 ts->first_free = ts->sigqueue_table;
 for (i = 0; i < MAX_SIGQUEUE_SIZE - 1; i++) {
 ts->sigqueue_table[i].next = >sigqueue_table[i + 1];
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 22fc3a6c30..431c5cfc03 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -92,7 +92,6 @@ typedef struct TaskState {
 
 struct TaskState *next;
 struct bsd_binprm *bprm;
-int used; /* non zero if used */
 struct image_info *info;
 
 struct emulated_sigtable sigtab[TARGET_NSIG];
-- 
2.32.0

[PATCH 14/14] bsd-user/signal: Create a dummy signal queueing function

[Warner Losh]

Create dummy signal queueing function so we can start to integrate other
architectures (at the cost of signals remaining broken) to tame the
dependency graph a bit and to bring in signals in a more controlled
fashion.

Signed-off-by: Warner Losh 
---
 bsd-user/qemu.h   | 1 +
 bsd-user/signal.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 5a2fd87e44..85d1f8fd2a 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -209,6 +209,7 @@ void process_pending_signals(CPUArchState *cpu_env);
 void signal_init(void);
 long do_sigreturn(CPUArchState *env);
 long do_rt_sigreturn(CPUArchState *env);
+int queue_signal(CPUArchState *env, int sig, target_siginfo_t *info);
 abi_long do_sigaltstack(abi_ulong uss_addr, abi_ulong uoss_addr, abi_ulong sp);
 
 /* mmap.c */
diff --git a/bsd-user/signal.c b/bsd-user/signal.c
index ad6d935569..4e7f618944 100644
--- a/bsd-user/signal.c
+++ b/bsd-user/signal.c
@@ -19,6 +19,14 @@
 #include "qemu/osdep.h"
 
 #include "qemu.h"
+/*
+ * Queue a signal so that it will be send to the virtual CPU as soon as
+ * possible.
+ */
+int queue_signal(CPUArchState *env, int sig, target_siginfo_t *info)
+{
+return 1;
+}
 
 void signal_init(void)
 {
-- 
2.32.0

Re: [PATCH v2] spapr/xive: Fix kvm_xive_source_reset trace event

[Greg Kurz]

On Wed, 22 Sep 2021 09:02:05 +0200
Cédric Le Goater  wrote:

> The trace event was placed in the wrong routine. Move it under
> kvmppc_xive_source_reset_one().
> 
> Fixes: 4e960974d4ee ("xive: Add trace events")
> Signed-off-by: Cédric Le Goater 
> ---

Reviewed-by: Greg Kurz 

>  hw/intc/spapr_xive_kvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index beb904d5bdee..bf43ffb54018 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -236,6 +236,8 @@ int kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
> srcno, Error **errp)
>  SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
>  uint64_t state = 0;
>  
> +trace_kvm_xive_source_reset(srcno);
> +
>  assert(xive->fd != -1);
>  
>  if (xive_source_irq_is_lsi(xsrc, srcno)) {
> @@ -328,8 +330,6 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
> uint32_t offset,
>  return xive_esb_rw(xsrc, srcno, offset, data, 1);
>  }
>  
> -trace_kvm_xive_source_reset(srcno);
> -
>  /*
>   * Special Load EOI handling for LSI sources. Q bit is never set
>   * and the interrupt should be re-triggered if the level is still

Re: [PATCH v15] qapi: introduce 'query-x86-cpuid' QMP command.

[Vladimir Sementsov-Ogievskiy]

Ping.

Hi! Any chance for this to land?

The solution is very simple now: we don't modify any logic and just export 
kvm_cpuid2 entries as simple and flat QAPI list. What's the problem with it?

If any doubts, we can go with x- prefix for a new command.

16.08.2021 17:51, Valeriy Vdovin wrote:

From: Valeriy Vdovin 

Introducing new QMP command 'query-x86-cpuid'. This command can be used to
get virtualized cpu model info generated by QEMU during VM initialization in
the form of cpuid representation.

Diving into more details about virtual CPU generation: QEMU first parses '-cpu'
command line option. From there it takes the name of the model as the basis for
feature set of the new virtual CPU. After that it uses trailing '-cpu' options,
that state if additional cpu features should be present on the virtual CPU or
excluded from it (tokens '+'/'-' or '=on'/'=off').
After that QEMU checks if the host's cpu can actually support the derived
feature set and applies host limitations to it.
After this initialization procedure, virtual CPU has it's model and
vendor names, and a working feature set and is ready for identification
instructions such as CPUID.

To learn exactly how virtual CPU is presented to the guest machine via CPUID
instruction, new QMP command can be used. By calling 'query-x86-cpuid'
command, one can get a full listing of all CPUID leaves with subleaves which are
supported by the initialized virtual CPU.

Other than debug, the command is useful in cases when we would like to
utilize QEMU's virtual CPU initialization routines and put the retrieved
values into kernel CPUID overriding mechanics for more precise control
over how various processes perceive its underlying hardware with
container processes as a good example.

The command is specific to x86. It is currenly only implemented for KVM 
acceleator.

Output format:
The output is a plain list of leaf/subleaf argument combinations, that
return 4 words in registers EAX, EBX, ECX, EDX.

Use example:
qmp_request: {
   "execute": "query-x86-cpuid"
}

qmp_response: {
   "return": [
 {
   "eax": 1073741825,
   "edx": 77,
   "in-eax": 1073741824,
   "ecx": 1447775574,
   "ebx": 1263359563
 },
 {
   "eax": 16777339,
   "edx": 0,
   "in-eax": 1073741825,
   "ecx": 0,
   "ebx": 0
 },
 {
   "eax": 13,
   "edx": 1231384169,
   "in-eax": 0,
   "ecx": 1818588270,
   "ebx": 1970169159
 },
 {
   "eax": 198354,
   "edx": 126614527,
   "in-eax": 1,
   "ecx": 2176328193,
   "ebx": 2048
 },
 
 {
   "eax": 12328,
   "edx": 0,
   "in-eax": 2147483656,
   "ecx": 0,
   "ebx": 0
 }
   ]
}

Signed-off-by: Valeriy Vdovin 
---
v2: - Removed leaf/subleaf iterators.
 - Modified cpu_x86_cpuid to return false in cases when count is
   greater than supported subleaves.
v3: - Fixed structure name coding style.
 - Added more comments
 - Ensured buildability for non-x86 targets.
v4: - Fixed cpu_x86_cpuid return value logic and handling of 0xA leaf.
 - Fixed comments.
 - Removed target check in qmp_query_cpu_model_cpuid.
v5: - Added error handling code in qmp_query_cpu_model_cpuid
v6: - Fixed error handling code. Added method to query_error_class
v7: - Changed implementation in favor of cached cpuid_data for
   KVM_SET_CPUID2
v8: - Renamed qmp method to query-kvm-cpuid and some fields in response.
 - Modified documentation to qmp method
 - Removed helper struct declaration
v9: - Renamed 'in_eax' / 'in_ecx' fields to 'in-eax' / 'in-ecx'
 - Pasted more complete response to commit message.
v10:
 - Subject changed
 - Fixes in commit message
 - Small fixes in QMP command docs
v11:
 - Added explanation about CONFIG_KVM to the commit message.
v12:
 - Changed title from query-kvm-cpuid to query-x86-cpuid
 - Removed CONFIG_KVM ifdefs
 - Added detailed error messages for some stub/unimplemented cases.
v13:
 - Tagged with since 6.2
v14:
 - Rebased to latest master 632eda54043d6f26ff87dac16233e14b4708b967
 - Added note about error return cases in api documentation.
v15:
 - Rearranged nested if statements.
 - Made use of kvm_enabled() instead of custom function.
 - Removed generated typedefs
 - Added indentation to qapi docementation.

  qapi/machine-target.json   | 46 ++
  softmmu/cpus.c |  2 +-
  target/i386/kvm/kvm-stub.c |  9 
  target/i386/kvm/kvm.c  | 44 
  tests/qtest/qmp-cmd-test.c |  1 +
  5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index e7811654b7..75398bc1a4 100644
--- a/qapi/machine-target.json
+++ b/qapi/machine-target.json
@@ -329,3 +329,49 @@
  ##
  { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) 

Re: [PATCH v6 00/11] 64bit block-layer: part II

[Vladimir Sementsov-Ogievskiy]

Ping)

Not reviewed: 6,7,10

03.09.2021 13:27, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

Sorry for a long delay:(  Finally, here is v6.

v6: rebase on new rbd handlers and backup-top renamed to copy-before-write. 
Also:

01: add Eric's r-b
 tweak commit msg to not mention sheepdog
02: add Eric's r-b
03: tweak commit msg
 drop extra type conversion in raw_co_pwrite_zeroes

04: vvfat: no write_target_commit() anymore
 nvme: fix over-80 line
 type conversion in raw_co_pwrite_zeroes() now dropped in 03

05: tweak commit msg
 add Eric's r-b

06: update comment

07: tweak commit msg, grammar and typos in comments
 don't add extra empty line
 handle also qemu_rbd_co_pwrite_zeroes

08: tweak commit msg, add Eric's r-b
09: tweak commit msg, add Eric's r-b
10: add rbd, drop sheepdog
 add assertion to iscsi_co_pdiscard()
11: tweak commit msg, add Eric's r-b

Vladimir Sementsov-Ogievskiy (11):
   block/io: bring request check to bdrv_co_(read,write)v_vmstate
   qcow2: check request on vmstate save/load path
   block: use int64_t instead of uint64_t in driver read handlers
   block: use int64_t instead of uint64_t in driver write handlers
   block: use int64_t instead of uint64_t in copy_range driver handlers
   block: make BlockLimits::max_pwrite_zeroes 64bit
   block: use int64_t instead of int in driver write_zeroes handlers
   block/io: allow 64bit write-zeroes requests
   block: make BlockLimits::max_pdiscard 64bit
   block: use int64_t instead of int in driver discard handlers
   block/io: allow 64bit discard requests



--
Best regards,
Vladimir

[PATCH 05/14] bsd-user/errno_defs.h: Add internal error numbers

[Warner Losh]

From: Stacey Son 

To emulate signals and interrupted system calls, we need to have the
same mechanisms we have in the kernel, including these errno values.

Signed-off-by: Stacey Son 
Signed-off-by: Warner Losh 
---
 bsd-user/errno_defs.h | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/bsd-user/errno_defs.h b/bsd-user/errno_defs.h
index 1efa502a12..b538dd93da 100644
--- a/bsd-user/errno_defs.h
+++ b/bsd-user/errno_defs.h
@@ -1,6 +1,3 @@
-/*  $OpenBSD: errno.h,v 1.20 2007/09/03 14:37:52 millert Exp $  */
-/*  $NetBSD: errno.h,v 1.10 1996/01/20 01:33:53 jtc Exp $   */
-
 /*
  * Copyright (c) 1982, 1986, 1989, 1993
  *  The Regents of the University of California.  All rights reserved.
@@ -37,6 +34,9 @@
  *  @(#)errno.h 8.5 (Berkeley) 1/21/94
  */
 
+#ifndef _ERRNO_DEFS_H_
+#define _ERRNO_DEFS_H_
+
 #define TARGET_EPERM1   /* Operation not permitted */
 #define TARGET_ENOENT   2   /* No such file or directory */
 #define TARGET_ESRCH3   /* No such process */
@@ -147,3 +147,11 @@
 #define TARGET_EIDRM89  /* Identifier removed */
 #define TARGET_ENOMSG   90  /* No message of desired type 
*/
 #define TARGET_ELAST90  /* Must be equal largest errno 
*/
+
+/* Internal errors: */
+#define TARGET_EJUSTRETURN  254 /* Just return without
+   modifing regs */
+#define TARGET_ERESTART 255 /* Restart syscall */
+#define TARGET_ERESTARTSYS  TARGET_ERESTART /* Linux compat */
+
+#endif /* !  _ERRNO_DEFS_H_ */
-- 
2.32.0

Re: [PATCH] nvdimm: release the correct device list

[Michael S. Tsirkin]

On Fri, Sep 17, 2021 at 02:59:33PM +0200, Igor Mammedov wrote:
> On Mon, 13 Sep 2021 06:40:01 +
> "lizhij...@fujitsu.com"  wrote:
> 
> > ping again
> 
> Michael,
> 
> can you include this in your next pull req, please?

ok

> > 
> > 
> > 
> > On 30/08/2021 09:04, Li Zhijian wrote:
> > > ping
> > >
> > >
> > > On 03/08/2021 12:00, Li, Zhijian wrote:  
> > >> ping
> > >>
> > >> Any body could help to review/queue this patch ?
> > >>
> > >>
> > >>
> > >> On 2021/6/29 22:05, Igor Mammedov wrote:  
> > >>> On Thu, 24 Jun 2021 19:04:15 +0800
> > >>> Li Zhijian  wrote:
> > >>>  
> >  Signed-off-by: Li Zhijian   
> > >>> Reviewed-by: Igor Mammedov 
> > >>>  
> >  ---
> >    hw/acpi/nvdimm.c | 12 ++--
> >    1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> >  diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> >  index e3d5fe19392..ff317263e85 100644
> >  --- a/hw/acpi/nvdimm.c
> >  +++ b/hw/acpi/nvdimm.c
> >  @@ -355,10 +355,10 @@ nvdimm_build_structure_caps(GArray *structures, 
> >  uint32_t capabilities)
> >      static GArray *nvdimm_build_device_structure(NVDIMMState *state)
> >    {
> >  -    GSList *device_list = nvdimm_get_device_list();
> >  +    GSList *device_list, *list = nvdimm_get_device_list();
> >    GArray *structures = g_array_new(false, true /* clear */, 1);
> >    -    for (; device_list; device_list = device_list->next) {
> >  +    for (device_list = list; device_list; device_list = 
> >  device_list->next) {
> >    DeviceState *dev = device_list->data;
> >      /* build System Physical Address Range Structure. */
> >  @@ -373,7 +373,7 @@ static GArray 
> >  *nvdimm_build_device_structure(NVDIMMState *state)
> >    /* build NVDIMM Control Region Structure. */
> >    nvdimm_build_structure_dcr(structures, dev);
> >    }
> >  -    g_slist_free(device_list);
> >  +    g_slist_free(list);
> >      if (state->persistence) {
> >    nvdimm_build_structure_caps(structures, state->persistence);
> >  @@ -1339,9 +1339,9 @@ static void nvdimm_build_ssdt(GArray 
> >  *table_offsets, GArray *table_data,
> >      void nvdimm_build_srat(GArray *table_data)
> >    {
> >  -    GSList *device_list = nvdimm_get_device_list();
> >  +    GSList *device_list, *list = nvdimm_get_device_list();
> >    -    for (; device_list; device_list = device_list->next) {
> >  +    for (device_list = list; device_list; device_list = 
> >  device_list->next) {
> >    AcpiSratMemoryAffinity *numamem = NULL;
> >    DeviceState *dev = device_list->data;
> >    Object *obj = OBJECT(dev);
> >  @@ -1356,7 +1356,7 @@ void nvdimm_build_srat(GArray *table_data)
> >    build_srat_memory(numamem, addr, size, node,
> >      MEM_AFFINITY_ENABLED | 
> >  MEM_AFFINITY_NON_VOLATILE);
> >    }
> >  -    g_slist_free(device_list);
> >  +    g_slist_free(list);
> >    }
> >      void nvdimm_build_acpi(GArray *table_offsets, GArray *table_data,  
> > >>>
> > >>>  
> > >>
> > >>
> > >>  
> > >  

Re: [PATCH v2] block: drop BLK_PERM_GRAPH_MOD

[Vladimir Sementsov-Ogievskiy]

Ping)

Patch is reviewed.

02.09.2021 12:37, Vladimir Sementsov-Ogievskiy wrote:

First, this permission never protected a node from being changed, as
generic child-replacing functions don't check it.

Second, it's a strange thing: it presents a permission of parent node
to change its child. But generally, children are replaced by different
mechanisms, like jobs or qmp commands, not by nodes.

Graph-mod permission is hard to understand. All other permissions
describe operations which done by parent node on its child: read,
write, resize. Graph modification operations are something completely
different.

The only place where BLK_PERM_GRAPH_MOD is used as "perm" (not shared
perm) is mirror_start_job, for s->target. Still modern code should use
bdrv_freeze_backing_chain() to protect from graph modification, if we
don't do it somewhere it may be considered as a bug. So, it's a bit
risky to drop GRAPH_MOD, and analyzing of possible loss of protection
is hard. But one day we should do it, let's do it now.

One more bit of information is that locking the corresponding byte in
file-posix doesn't make sense at all.

Signed-off-by: Vladimir Sementsov-Ogievskiy



--
Best regards,
Vladimir

[PATCH 00/14] bsd-user: misc cleanup for aarch64 import

[Warner Losh]

Prepare for aarch64 support (the next architecture to be upstreamed). As the
aarch64 emulation is more complete, it relies on a number of different items.
In some cases, I've pulled in the full support from bsd-user fork. In other
cases I've created a simple stub (as is the case for signals, which have
independent changes pending, so I wanted to be as minimal as possible.  Since
all pre-12.2 support was purged from the bsd-user fork, go ahead and remove it
here. FreeBSD 11.x goes ouft of support at the end of the month. Remove what
little multi-version support that's in upstream.

The aarch64 patch set will be published soon after some of the dust settles.

Stacey Son (1):
  bsd-user/errno_defs.h: Add internal error numbers

Warner Losh (13):
  bsd-user/target_os-user.h: Remove support for FreeBSD older than 12.0
  bsd-user/strace.list: Remove support for FreeBSD versions older than
12.0
  bsd-user: TARGET_RESET define is unused, remove it
  bsd-user: export get_errno and is_error from syscall.c
  bsd-user: move TARGET_MC_GET_CLEAR_RET to target_os_signal.h
  bsd-user/target_os_elf.h: Remove fallback ELF_HWCAP and reorder
  bsd-user/target_os_elf: If ELF_HWCAP2 is defined, publish it
  bsd-user: Remove used from TaskState
  bsd-user: Add stop_all_tasks
  bsd-user/sysarch: Move to using do_freebsd_arch_sysarch interface
  bsd-user/sysarch: Provide a per-arch framework for sysarch syscall
  bsd-user: Rename sigqueue to qemu_sigqueue
  bsd-user/signal: Create a dummy signal queueing function

 bsd-user/errno_defs.h|  14 +++-
 bsd-user/freebsd/meson.build |   3 +
 bsd-user/freebsd/os-sys.c|  28 
 bsd-user/freebsd/strace.list |  11 ---
 bsd-user/freebsd/target_os_elf.h |  12 ++--
 bsd-user/freebsd/target_os_signal.h  |   3 +
 bsd-user/freebsd/target_os_user.h| 100 +--
 bsd-user/i386/target_arch_cpu.h  |   2 -
 bsd-user/i386/target_arch_signal.h   |   2 -
 bsd-user/main.c  |  10 ++-
 bsd-user/meson.build |   6 ++
 bsd-user/qemu.h  |  24 ---
 bsd-user/signal.c|   8 +++
 bsd-user/syscall.c   |  60 ++--
 bsd-user/x86_64/target_arch_cpu.h|   2 -
 bsd-user/x86_64/target_arch_signal.h |   2 -
 16 files changed, 96 insertions(+), 191 deletions(-)
 create mode 100644 bsd-user/freebsd/meson.build
 create mode 100644 bsd-user/freebsd/os-sys.c

-- 
2.32.0

Re: [PATCH v6 00/21] Add LoongArch linux-user emulation support

[Song Gao]

Hi, Richard.

On 09/21/2021 05:17 AM, Richard Henderson wrote:
> On 9/17/21 1:12 AM, Song Gao wrote:
>> The 'o32' code has been deleted at the latest kernel [1]. This series only 
>> support
>> linux-user emulation.
> 
> I have now reviewed all but the linux-user/ portion.
> 
Thank you!
> I see that kernel upstreaming is in progress,
> 
> https://lore.kernel.org/linux-kernel/20210917035736.3934017-1-chenhua...@loongson.cn/
> 
> so hopefully this will be resolved soon.
> 
> Have you started working on system mode support for LoongArch, so that one 
> may run that kernel?
> Yes. We already support running the old kernel, but we don't support running 
> the latest kernel yet.

Song Gao
thanks
> 
> r~

Re: [PATCH] nbd/client: Request larger block status by default

[Vladimir Sementsov-Ogievskiy]

21.09.2021 23:00, Eric Blake wrote:

On Tue, Sep 21, 2021 at 10:12:02PM +0300, Vladimir Sementsov-Ogievskiy wrote:

21.09.2021 21:08, Eric Blake wrote:

On Tue, Sep 21, 2021 at 08:25:11PM +0300, Vladimir Sementsov-Ogievskiy wrote:

21.09.2021 19:17, Eric Blake wrote:

Now that commit 5a1cfd21 has clarified that a driver's block_status
can report larger *pnum than in the original request, we can take
advantage of that in the NBD driver.  Rather that limiting our request
to the server based on the maximum @bytes our caller mentioned, we
instead ask for as much status as possible (the minimum of our 4G
limit or the rest of the export); the server will still only give us
one extent in its answer (because we are using NBD_CMD_FLAG_REQ_ONE),
but now the block layer's caching of data areas can take advantage of
cases where the server gives us a large answer to avoid the need for
future NBD_CMD_BLOCK_STATUS calls.

Signed-off-by: Eric Blake 
---




I remember we already discussed that, but can't find.

The problem is that it's not for free:

In server code in blockstatus_to_extents, we loop though the disk, trying to 
merge extents of the same type.

With full allocated qcow2, we'll have to load all L2 tables and handle them, to merge all 
block status into one big "allocated" extent.



We don't have to loop that far.  The NBD protocol allows the server to
stop looping at whatever point makes sense, as long as it makes
progress.


Maybe, we need some additional negotiation flag, to allow BLOCK_STATUS command 
with NBD_CMD_FLAG_REQ_ONE flag to return an extent larger than required when 
that information is available for free?


That's already the case when FLAG_REQ_ONE is not present.  The reason
that REQ_ONE clamps things at the requested limit is because older
qemu had a bug that it rejected the server sending extra information,
even when that info was free.



That's one possibility.  Another does not add anything to the NBD
protocol, but instead limits the code that tries to loop over block
status to deteremine a larger "allocated" answer to return to instead
stop looping after a finite number of extents have been merged
together.



In this case we should answer a question: when to stop looping? I'm not sure we 
can simply drop the loop:

For example, for compressed clusters, bdrv_co_block_status() will return them 
one-by-one, and sending them one by one to the wire, when user requested large 
range would be inefficient.
Or should we change block-status behavior for compressed clusters? And may be 
add flag to block_status() that we are not interested in valid_offset, so it 
can return an extent corresponding to the whole L2 table chunk (if all entries 
are allocated, but not consecutive)?


Currently, bdrv_co_block_status() takes 'bool want_zero' that says
what the client wants.  Maybe it's worth expanding that into an enum
or bitmask to allow finer-grained client requests (the notion of
whether valid_offset matters to the caller IS relevant for deciding
when to clamp vs. loop).


I think, sooner or later we'll do it anyway






Hmm. So, if not update spec, we'll have to "fix" implementation. That means actually, 
that we should update spec anyway, at least to note that: "clients tend to request large 
regions in hope that server will not spend too much time to serve them but instead return shorter 
answer"..


I'm really hoping we don't have to tweak the NBD spec on this one, but
rather improve the quality of implementation in qemu.



And you'll never have guarantee, that some another (non-qemu) NBD server will 
not try to satisfy the whole request in on go.


That's true, but the NBD spec has always tried to encourage servers to
provide more information when it was free, but to give up early if it
gets too expensive.  It's a judgment call on where that line lies, and
may indeed be different between different servers.


Hmm. Okay.

Still, if we go the way this patch suggests, we'll need at least improve our 
server implementation of NBD_BLOCK_STATUS around qcow2.






In other words:

1. We want block_status of some region
2. If there some free information available about larger region we are happy to 
cache it

With your solution, we just request a lot larger region, so we lose information 
of [1]. That means that sever can't imagine, how much of requested region is 
really needed, i.e. if we do some additional work to return more information 
(still within boundaries of the request) will it be:
  - good work to minimize network traffic
OR
  - extra work, waste server time, client will cache this information but 
probably never use (or even lose it soon, as our cache is very simple)

With additional negotiation flag we don't lose [1], i.e how much client wants 
now.


So, for me, modifying the protocol looks nicer..

Another approach is do request without NBD_CMD_FLAG_REQ_ONE and handle several 
extents.


_This_ idea is nicer.  It allows the client to request an actual
length it is interested in 

Re: [PATCH v6 0/5] block/nbd: drop connection_co

[Vladimir Sementsov-Ogievskiy]

ping)

Only one patch is not reviewed. But the biggest one :(

02.09.2021 13:38, Vladimir Sementsov-Ogievskiy wrote:

v6:
01,02: add Eric's r-b
03: make new interface clearer
04,05: rebased on updated 03

Vladimir Sementsov-Ogievskiy (5):
   block/nbd: nbd_channel_error() shutdown channel unconditionally
   block/nbd: move nbd_recv_coroutines_wake_all() up
   block/nbd: refactor nbd_recv_coroutines_wake_all()
   block/nbd: drop connection_co
   block/nbd: check that received handle is valid

  block/nbd.c  | 412 +++
  nbd/client.c |   2 -
  2 files changed, 121 insertions(+), 293 deletions(-)




--
Best regards,
Vladimir

[PATCH 01/14] bsd-user/target_os-user.h: Remove support for FreeBSD older than 12.0

[Warner Losh]

Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/target_os_user.h | 100 +-
 1 file changed, 1 insertion(+), 99 deletions(-)

diff --git a/bsd-user/freebsd/target_os_user.h 
b/bsd-user/freebsd/target_os_user.h
index 95b1fa9f99..19892c5071 100644
--- a/bsd-user/freebsd/target_os_user.h
+++ b/bsd-user/freebsd/target_os_user.h
@@ -61,15 +61,7 @@ struct target_sockaddr_storage {
 /*
  * from sys/user.h
  */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 1200031
 #define TARGET_KI_NSPARE_INT2
-#elif defined(__FreeBSD_version) && __FreeBSD_version >= 110
-#define TARGET_KI_NSPARE_INT4
-#elif defined(__FreeBSD_version) && __FreeBSD_version >= 100
-#define TARGET_KI_NSPARE_INT7
-#else
-#define TARGET_KI_NSPARE_INT9
-#endif /* ! __FreeBSD_version >= 100 */
 #define TARGET_KI_NSPARE_LONG   12
 #define TARGET_KI_NSPARE_PTR6
 
@@ -116,11 +108,7 @@ struct target_kinfo_proc {
 int32_t ki_tsid;/* Terminal session ID */
 int16_t ki_jobc;/* job control counter */
 int16_t ki_spare_short1;/* unused (just here for alignment) */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 1200031
 int32_t ki_tdev__freebsd11; /* controlling tty dev */
-#else
-int32_t ki_tdev;/* controlling tty dev */
-#endif
 target_sigset_t ki_siglist; /* Signals arrived but not delivered */
 target_sigset_t ki_sigmask; /* Current signal mask */
 target_sigset_t ki_sigignore;   /* Signals being ignored */
@@ -164,45 +152,24 @@ struct target_kinfo_proc {
 int8_t  ki_nice;/* Process "nice" value */
 charki_lock;/* Process lock (prevent swap) count */
 charki_rqindex; /* Run queue index */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 110
 u_char  ki_oncpu_old;   /* Which cpu we are on (legacy) */
 u_char  ki_lastcpu_old; /* Last cpu we were on (legacy) */
-#else
-u_char  ki_oncpu;   /* Which cpu we are on */
-u_char  ki_lastcpu; /* Last cpu we were on */
-#endif /* ! __FreeBSD_version >= 110 */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 90
 charki_tdname[TARGET_TDNAMLEN + 1];  /* thread name */
-#else
-charki_ocomm[TARGET_TDNAMLEN + 1];   /* thread name */
-#endif /* ! __FreeBSD_version >= 90 */
 charki_wmesg[TARGET_WMESGLEN + 1];   /* wchan message */
 charki_login[TARGET_LOGNAMELEN + 1]; /* setlogin name */
 charki_lockname[TARGET_LOCKNAMELEN + 1]; /* lock name */
 charki_comm[TARGET_COMMLEN + 1]; /* command name */
 charki_emul[TARGET_KI_EMULNAMELEN + 1];  /* emulation name */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 90
 charki_loginclass[TARGET_LOGINCLASSLEN + 1]; /* login class */
-#endif /* ! __FreeBSD_version >= 90 */
 
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 90
 charki_sparestrings[50];/* spare string space */
-#else
-charki_sparestrings[68];/* spare string space */
-#endif /* ! __FreeBSD_version >= 90 */
 int32_t ki_spareints[TARGET_KI_NSPARE_INT]; /* spare room for growth */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 1200031
- uint64_t ki_tdev;  /* controlling tty dev */
-#endif
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 110
+uint64_t ki_tdev;  /* controlling tty dev */
 int32_t ki_oncpu;   /* Which cpu we are on */
 int32_t ki_lastcpu; /* Last cpu we were on */
 int32_t ki_tracer;  /* Pid of tracing process */
-#endif /* __FreeBSD_version >= 110 */
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 90
 int32_t ki_flag2;   /* P2_* flags */
 int32_t ki_fibnum;  /* Default FIB number */
-#endif /* ! __FreeBSD_version >= 90 */
 uint32_tki_cr_flags;/* Credential flags */
 int32_t ki_jid; /* Process jail ID */
 int32_t ki_numthreads;  /* XXXKSE number of threads in total */
@@ -234,18 +201,8 @@ struct target_kinfo_file {
 int32_t  kf_flags;  /* Flags. */
 int32_t  kf_pad0;  /* Round to 64 bit alignment. */
 int64_t  kf_offset;  /* Seek location. */
-#if defined(__FreeBSD_version) && __FreeBSD_version < 1200031
-int32_t  kf_vnode_type;  /* Vnode type. */
-int32_t  kf_sock_domain;  /* Socket domain. */
-int32_t  kf_sock_type;  /* Socket type. */
-int32_t  kf_sock_protocol; /* Socket protocol. */
-struct target_sockaddr_storage kf_sa_local; /* Socket address. */
-struct target_sockaddr_storage kf_sa_peer; /* Peer address. */
-#endif
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 90
 union {
 struct {
-#if defined(__FreeBSD_version) && __FreeBSD_version >= 1200031
 

[PATCH 06/14] bsd-user: move TARGET_MC_GET_CLEAR_RET to target_os_signal.h

[Warner Losh]

Move TARGET_MC_GET_CLEAR_RET to freebsd/target_os_signal.h since it's
FreeBSD-wide.

Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/target_os_signal.h  | 3 +++
 bsd-user/i386/target_arch_signal.h   | 2 --
 bsd-user/x86_64/target_arch_signal.h | 2 --
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/bsd-user/freebsd/target_os_signal.h 
b/bsd-user/freebsd/target_os_signal.h
index 3ed454e086..9fcdfce003 100644
--- a/bsd-user/freebsd/target_os_signal.h
+++ b/bsd-user/freebsd/target_os_signal.h
@@ -1,6 +1,9 @@
 #ifndef _TARGET_OS_SIGNAL_H_
 #define _TARGET_OS_SIGNAL_H_
 
+/* FreeBSD's sys/ucontex.h defines this */
+#define TARGET_MC_GET_CLEAR_RET 0x0001
+
 #include "target_os_siginfo.h"
 #include "target_arch_signal.h"
 
diff --git a/bsd-user/i386/target_arch_signal.h 
b/bsd-user/i386/target_arch_signal.h
index 9812c6b034..a90750d602 100644
--- a/bsd-user/i386/target_arch_signal.h
+++ b/bsd-user/i386/target_arch_signal.h
@@ -27,8 +27,6 @@
 #define TARGET_MINSIGSTKSZ  (512 * 4)   /* min sig stack size */
 #define TARGET_SIGSTKSZ (MINSIGSTKSZ + 32768)   /* recommended size */
 
-#define TARGET_MC_GET_CLEAR_RET 0x0001
-
 struct target_sigcontext {
 /* to be added */
 };
diff --git a/bsd-user/x86_64/target_arch_signal.h 
b/bsd-user/x86_64/target_arch_signal.h
index 4c1ff0e5ba..4bb753b08b 100644
--- a/bsd-user/x86_64/target_arch_signal.h
+++ b/bsd-user/x86_64/target_arch_signal.h
@@ -27,8 +27,6 @@
 #define TARGET_MINSIGSTKSZ  (512 * 4)   /* min sig stack size */
 #define TARGET_SIGSTKSZ (MINSIGSTKSZ + 32768)   /* recommended size */
 
-#define TARGET_MC_GET_CLEAR_RET 0x0001
-
 struct target_sigcontext {
 /* to be added */
 };
-- 
2.32.0

[PATCH 13/14] bsd-user: Rename sigqueue to qemu_sigqueue

[Warner Losh]

To avoid a name clash with FreeBSD's sigqueue data structure in
signalvar.h, rename sigqueue to qemu_sigqueue. This sturcture
is currently defined, but unused.

Signed-off-by: Warner Losh 
---
 bsd-user/qemu.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 3dde381d5d..5a2fd87e44 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -73,15 +73,15 @@ struct image_info {
 
 #define MAX_SIGQUEUE_SIZE 1024
 
-struct sigqueue {
-struct sigqueue *next;
+struct qemu_sigqueue {
+struct qemu_sigqueue *next;
+target_siginfo_t info;
 };
 
 struct emulated_sigtable {
 int pending; /* true if signal is pending */
-struct sigqueue *first;
-/* in order to always have memory for the first signal, we put it here */
-struct sigqueue info;
+struct qemu_sigqueue *first;
+struct qemu_sigqueue info; /* Put first signal info here */
 };
 
 /*
@@ -95,8 +95,8 @@ typedef struct TaskState {
 struct image_info *info;
 
 struct emulated_sigtable sigtab[TARGET_NSIG];
-struct sigqueue sigqueue_table[MAX_SIGQUEUE_SIZE]; /* siginfo queue */
-struct sigqueue *first_free; /* first free siginfo queue entry */
+struct qemu_sigqueue sigqueue_table[MAX_SIGQUEUE_SIZE]; /* siginfo queue */
+struct qemu_sigqueue *first_free; /* first free siginfo queue entry */
 int signal_pending; /* non zero if a signal may be pending */
 
 uint8_t stack[];
-- 
2.32.0

[PATCH 10/14] bsd-user: Add stop_all_tasks

[Warner Losh]

Similar to the same function in linux-user: this stops all the current tasks.

Signed-off-by: Stacey Son 
Signed-off-by: Warner Losh 
---
 bsd-user/main.c | 9 +
 bsd-user/qemu.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/bsd-user/main.c b/bsd-user/main.c
index ee84554854..cb5ea40236 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -195,6 +195,15 @@ static void usage(void)
 
 __thread CPUState *thread_cpu;
 
+void stop_all_tasks(void)
+{
+/*
+ * We trust when using NPTL (pthreads) start_exclusive() handles thread
+ * stopping correctly.
+ */
+start_exclusive();
+}
+
 bool qemu_cpu_is_self(CPUState *cpu)
 {
 return thread_cpu == cpu;
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 431c5cfc03..4ee57b91f0 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -103,6 +103,7 @@ typedef struct TaskState {
 } __attribute__((aligned(16))) TaskState;
 
 void init_task_state(TaskState *ts);
+void stop_all_tasks(void);
 extern const char *qemu_uname_release;
 
 /*
-- 
2.32.0

Re: ensuring a machine's buses have unique names

[Markus Armbruster]

Peter Maydell  writes:

> On Wed, 15 Sept 2021 at 05:28, Markus Armbruster  wrote:
>>
>> Peter Maydell  writes:
>> > I'm not sure how best to sort this tangle out. We could:
>> >  * make controller devices pass in NULL as bus name; this
>> >means that some bus names will change, which is an annoying
>> >breakage but for these minor bus types we can probably
>> >get away with it. This brings these buses into line with
>> >how we've been handling uniqueness for ide and scsi.
>>
>> To gauge the breakage, we need a list of the affected bus names.
>
> Looking through, there are a few single-use or special
> purpose buses I'm going to ignore for now (eg vmbus, or
> the s390 ones). The four big bus types where controllers
> often specify a bus name and override the 'autogenerate
> unique name' handling are pci, ssi, sd, and i2c. (pci mostly
> gets away with it I expect by machines only having one pci
> bus.) Of those, I've gone through i2c. These are all the
> places where we create a specifically-named i2c bus (via
> i2c_init_bus()), together with the affected boards:
>
>hw/arm/pxa2xx.c
> - the PXA SoC code creates both the intended-for-use
>   i2c buses (which get auto-names) and also several i2c
>   buses intended for internal board-code use only which
>   are all given the same name "dummy".
>   Boards: connex, verdex, tosa, mainstone, akita, spitz,
>   borzoi, terrier, z2
>hw/arm/stellaris.c
> - The i2c controller names its bus "i2c". There is only one i2c
>   controller on these boards, so no name conflicts.
>   Boards: lm3s811evb, lm3s6965evb
>hw/display/ati.c
> - The ATI VGA device has an on-board i2c controller which it
>   connects the DDC that holds the EDID information. The bus is
>   always named "ati-vga.ddc", so if you have multiple of this
>   PCI device in the system the buses have the same names.
>hw/display/sm501.c
> - Same as ATI, but the bus name is "sm501.i2c"
>hw/i2c/aspeed_i2c.c
> - This I2C controller has either 14 or 16 (!) different i2c
>   buses, and it assigns them names "aspeed.i2c.N" for N = 0,1,2,...
>   The board code mostly seems to use these to wire up various
>   on-board i2c devices.
>   Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
>   swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
>   tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc
>hw/i2c/bitbang_i2c.c
> - the "GPIO to I2C bridge" device always names its bus "i2c".
>   Used only on musicpal, which only creates one of these buses.
>   Boards: musicpal
>hw/i2c/exynos4210_i2c.c
> - This i2c controller always names its bus "i2c". There are 9
>   of these controllers on the board, so they all have clashing
>   names.
>   Boards: nuri, smdkc210
>hw/i2c/i2c_mux_pca954x.c
> - This is an i2c multiplexer. All the child buses are named
>   "i2c-bus". The multiplexer is used by the aspeed and npcm7xx
>   boards. (There's a programmable way to get at individual
>   downstream i2c buses despite the name clash; none of the boards
>   using this multiplexer actually connect any devices downstream of
>   it yet.)
>   Boards: palmetto-bmc, supermicrox11-bmc, ast2500-evb, romulus-bmc,
>   swift-bmc, sonorapass-bmc, witherspoon-bmc, ast2600-evb,
>   tacoma-bmc, g220a-bmc, quanta-q71l-bmc, rainier-bmc,
>   npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
>hw/i2c/mpc_i2c.c
> - This controller always names its bus "i2c". There is only one
>   of these controllers in the machine.
>   Boards: ppce500, mpc8544ds
>hw/i2c/npcm7xx_smbus.c
> - This controller always names its bus "i2c-bus". There are multiple
>   controllers on the boards. The name also clashes with the one used
>   by the pca954x muxes on these boards (see above).
>   Boards: npcm750-evb, quanta-gsj, quanta-gbs-bmc, kudo-bmc
>hw/i2c/pm_smbus.c
> - This is the PC SMBUS implementation (it is not a QOM device...)
>   The bus is always called "i2c".
>   Boards: haven't worked through; at least all the x86 PC-like
>   boards, I guess
>hw/i2c/ppc4xx_i2c.c
> - This controller always names its bus "i2c". The taihu and
>   ref405ep have only one controller, but sam460ex has two which
>   will have non-unique names.
>   Boards: taihu, ref405ep, sam460ex
>hw/i2c/versatile_i2c.c
> - This controller always names its bus "i2c". The MPS boards all
>   have multiples of this controller with clashing names; the others
>   have only one controller.
>   Boards: mps2-an385, mps2-an386, mps2-an500, mps2-an511,
>   mps2-an505, mps2-an521, mps3-an524, mps3-an547,
>   realview-eb, realview-eb-mpcore, realview-pb-a8, realview-pbx-a9,
>   versatileab, versatilepb, vexpress-a9, vexpress-a15
>
> In a lot of these cases I suspect the i2c controllers are
> provided either to 

Re: [PATCH v3 16/35] acpi: arm/x86: build_srat: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

Hi Igor,

On 9/7/21 4:47 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
nit: also removes AcpiSystemResourceAffinityTable and use
build_append_int_noprefix for reserved fields
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: shannon.zha...@gmail.com
> CC: peter.mayd...@linaro.org
> CC: marcel.apfelb...@gmail.com
> CC: qemu-...@nongnu.org
> CC: drjo...@redhat.com
> CC: eau...@redhat.com
> ---
>  include/hw/acpi/acpi-defs.h | 11 ---
>  hw/arm/virt-acpi-build.c| 15 +++
>  hw/i386/acpi-build.c| 18 +++---
>  3 files changed, 14 insertions(+), 30 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 3b42b138f0..5826ee04b6 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -358,17 +358,6 @@ struct AcpiGenericTimerTable {
>  } QEMU_PACKED;
>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>  
> -/*
> - * SRAT (NUMA topology description) table
Missing version reference if any
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#system-resource-affinity-table-srat
5.2.16. System Resource Affinity Table (SRAT)

> - */
> -
> -struct AcpiSystemResourceAffinityTable {
> -ACPI_TABLE_HEADER_DEF
> -uint32_treserved1;
> -uint32_treserved2[2];
> -} QEMU_PACKED;
> -typedef struct AcpiSystemResourceAffinityTable 
> AcpiSystemResourceAffinityTable;
> -
>  #define ACPI_SRAT_PROCESSOR_APIC 0
>  #define ACPI_SRAT_MEMORY 1
>  #define ACPI_SRAT_PROCESSOR_x2APIC   2
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 037cc1fd82..21efe7fe34 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -477,18 +477,19 @@ build_spcr(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  static void
>  build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>  {
> -AcpiSystemResourceAffinityTable *srat;
>  AcpiSratProcessorGiccAffinity *core;
>  AcpiSratMemoryAffinity *numamem;
> -int i, srat_start;
> +int i;
>  uint64_t mem_base;
>  MachineClass *mc = MACHINE_GET_CLASS(vms);
>  MachineState *ms = MACHINE(vms);
>  const CPUArchIdList *cpu_list = mc->possible_cpu_arch_ids(ms);
> +AcpiTable table = { .sig = "SRAT", .rev = 3, .oem_id = vms->oem_id,
> +.oem_table_id = vms->oem_table_id };
>  
> -srat_start = table_data->len;
> -srat = acpi_data_push(table_data, sizeof(*srat));
> -srat->reserved1 = cpu_to_le32(1);
> +acpi_table_begin(, table_data);
> +build_append_int_noprefix(table_data, 1, 4); /* Reserved */
> +build_append_int_noprefix(table_data, 0, 8); /* Reserved */
>  
>  for (i = 0; i < cpu_list->len; ++i) {
>  core = acpi_data_push(table_data, sizeof(*core));
> @@ -522,9 +523,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENABLED);
>  }
>  
> -build_header(linker, table_data, (void *)(table_data->data + srat_start),
> - "SRAT", table_data->len - srat_start, 3, vms->oem_id,
> - vms->oem_table_id);
> +acpi_table_end(linker, );
>  }
>  
>  /* GTDT */
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index c329580cff..41c0a63b30 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1920,11 +1920,10 @@ build_tpm_tcpa(GArray *table_data, BIOSLinker 
> *linker, GArray *tcpalog,
>  static void
>  build_srat(GArray *table_data, BIOSLinker *linker, MachineState *machine)
>  {
> -AcpiSystemResourceAffinityTable *srat;
>  AcpiSratMemoryAffinity *numamem;
>  
>  int i;
> -int srat_start, numa_start, slots;
> +int numa_start, slots;
>  uint64_t mem_len, mem_base, next_base;
>  MachineClass *mc = MACHINE_GET_CLASS(machine);
>  X86MachineState *x86ms = X86_MACHINE(machine);
> @@ -1935,11 +1934,12 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
> MachineState *machine)
>  ram_addr_t hotplugabble_address_space_size =
>  object_property_get_int(OBJECT(pcms), PC_MACHINE_DEVMEM_REGION_SIZE,
>  NULL);
> +AcpiTable table = { .sig = "SRAT", .rev = 1, .oem_id = x86ms->oem_id,
> +.oem_table_id = x86ms->oem_table_id };
>  
> -srat_start = table_data->len;
> -
> -srat = acpi_data_push(table_data, sizeof *srat);
> -srat->reserved1 = cpu_to_le32(1);
> +acpi_table_begin(, table_data);
> +build_append_int_noprefix(table_data, 1, 4); /* Reserved */
> +build_append_int_noprefix(table_data, 0, 8); /* Reserved */
>  
>  for (i = 0; i < apic_ids->len; 

Re: [PATCH v7 00/11] qcow2: fix parallel rewrite and discard (reqlist)

[Vladimir Sementsov-Ogievskiy]

Ping.

Hi Kevin!

Could you look at description in cover-letter and 07-09, and say do you like the approach 
in general? Then I can resend with reqlist included and without "Based-on".

Or do you still prefer the solution with RWLock?

I don't like RWLock-based blocking solution, because:

1. Mirror does discards in parallel with other requests, so blocking discard 
may decrease mirror performance
2. Backup (in push-backup-with-fleecing scheme) will do discards on temporary 
image, again blocking discard is bad in this case
3. block-commit and block-stream will at some moment do discard-after-copy to 
not waste disk space
4. It doesn't seem possible to pass ownership on RWLock to task coroutine (as 
we can't lock it in one coroutine and release in another)


04.09.2021 19:24, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

This is a new (third :)) variant of solving the problem in qcow2 that we
lack synchronisation in reallocating host clusters with refcount=0 and
guest reads/writes that may still be in progress on these clusters.

Previous version was
"[PATCH v6 00/12] qcow2: fix parallel rewrite and discard (lockless)"
Supersedes: <20210422163046.442932-1-vsement...@virtuozzo.com>

Key features of new solution:

1. Simpler data structure: requests list instead of "dynamic refcount"
concept. What is good is that request list data structure is
implemented and used in other my series. So we can improve and reuse
it.

2. Don't care about discrads: my previous attempts were complicated by
trying to postpone discards when we have in-flight operations on
cluster which refcounts becomes 0. Don't bother with it anymore.
Nothing bad in discard: it similar as when guest does simultaneous
writes into same cluster: we don't care to serialize these writes.
So keep discards as is.

So now the whole fix may be described in one sentence: don't consider a
host cluster "free" (for allocation) if there are still some in-flight
guest operations on it.

What patches are:

1-2: simple additions to reqlist (see also *)

3: test. It's unchanged since previous solution

4-5: simpler refactorings

6-7: implement guest requests tracking in qcow2

8: refactoring for [9]
9: BUG FIX: use request tracking to avoid reallocating clusters under
guest operation

10-11: improvement if request tracking to avoid extra small critical
sections that were added in [7]

[*]:
For this series to work we also need
  "[PATCH v2 06/19] block: intoduce reqlist":
Based-on: <20210827181808.311670-7-vsement...@virtuozzo.com>

Still, note that we use only simple core of reqlist and don't use its
coroutine-related features. That probably means that I should split a
kind of BlockReqListBase data structure out of BlockReqList, and then
will have separate

CoBlockReqList for "[PATCH v2 00/19] Make image fleecing more usable"
series and Qcow2ReqList for this series..

But that a side question.

Vladimir Sementsov-Ogievskiy (11):
   block/reqlist: drop extra assertion
   block/reqlist: add reqlist_new_req() and reqlist_free_req()
   iotests: add qcow2-discard-during-rewrite
   qcow2: introduce qcow2_parse_compressed_cluster_descriptor()
   qcow2: refactor qcow2_co_preadv_task() to have one return
   qcow2: prepare for tracking guest io requests in data_file
   qcow2: track guest io requests in data_file
   qcow2: introduce is_cluster_free() helper
   qcow2: don't reallocate host clusters under guest operation
   block/reqlist: implement reqlist_mark_req_invalid()
   qcow2: use reqlist_mark_req_invalid()

  block/qcow2.h |  15 ++-
  include/block/reqlist.h   |  33 ++
  block/qcow2-cluster.c |  45 ++-
  block/qcow2-refcount.c|  34 +-
  block/qcow2.c | 112 +-
  block/reqlist.c   |  25 +++-
  .../tests/qcow2-discard-during-rewrite|  72 +++
  .../tests/qcow2-discard-during-rewrite.out|  21 
  8 files changed, 310 insertions(+), 47 deletions(-)
  create mode 100755 tests/qemu-iotests/tests/qcow2-discard-during-rewrite
  create mode 100644 tests/qemu-iotests/tests/qcow2-discard-during-rewrite.out




--
Best regards,
Vladimir

Re: [PATCH v3 28/35] acpi: arm: virt: build_iort: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Eric Auger]

Hi Igor,

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> it replaces error-prone pointer arithmetic for build_header() API,
> with 2 calls to start and finish table creation,
> which hides offsets magic from API user.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * fix conflicts due to
>   42e0f050e3a51 'hw/arm/virt-acpi-build: Add IORT support to bypass 
> SMMUv3'
>   *  * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> 
> CC: drjo...@redhat.com
> CC: peter.mayd...@linaro.org
> CC: shannon.zha...@gmail.com
> CC: qemu-...@nongnu.org
> CC: eau...@redhat.com
> ---
>  include/hw/acpi/acpi-defs.h | 14 
>  hw/arm/virt-acpi-build.c| 45 -
>  2 files changed, 19 insertions(+), 40 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index bcada37601..195f90caf6 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -188,20 +188,6 @@ struct AcpiGenericTimerTable {
>  } QEMU_PACKED;
>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>  
> -/*
> - * Input Output Remapping Table (IORT)
> - * Conforms to "IO Remapping Table System Software on ARM Platforms",
> - * Document number: ARM DEN 0049B, October 2015
> - */
> -
> -struct AcpiIortTable {
> -ACPI_TABLE_HEADER_DEF /* ACPI common table header */
> -uint32_t node_count;
> -uint32_t node_offset;
> -uint32_t reserved;
> -} QEMU_PACKED;
> -typedef struct AcpiIortTable AcpiIortTable;
> -
>  /*
>   * IORT node types
>   */
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 4b9687439d..bceb1b3b7e 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -273,22 +273,29 @@ static int iort_idmap_compare(gconstpointer a, 
> gconstpointer b)
>  return idmap_a->input_base - idmap_b->input_base;
>  }
>  
> +/*
> + * Input Output Remapping Table (IORT)
> + * Conforms to "IO Remapping Table System Software on ARM Platforms",
> + * Document number: ARM DEN 0049B, October 2015
> + */
>  static void
>  build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>  {
> -int i, nb_nodes, rc_mapping_count, iort_start = table_data->len;
> +int i, nb_nodes, rc_mapping_count;
>  AcpiIortIdMapping *idmap;
>  AcpiIortItsGroup *its;
> -AcpiIortTable *iort;
>  AcpiIortSmmu3 *smmu;
> -size_t node_size, iort_node_offset, iort_length, smmu_offset = 0;
>  AcpiIortRC *rc;
> +const uint32_t iort_node_offset = 48;
> +size_t node_size, smmu_offset = 0;
>  GArray *smmu_idmaps = g_array_new(false, true, 
> sizeof(AcpiIortIdMapping));
>  GArray *its_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
>  
> -iort = acpi_data_push(table_data, sizeof(*iort));
> +AcpiTable table = { .sig = "IORT", .rev = 0, .oem_id = vms->oem_id,
> +.oem_table_id = vms->oem_table_id };
>  
>  if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> +
forgot this minor comment
nit: spurious change

Eric
>  AcpiIortIdMapping next_range = {0};
>  
>  object_child_foreach_recursive(object_get_root(),
> @@ -325,18 +332,16 @@ build_iort(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  rc_mapping_count = 1;
>  }
>  
> -iort_length = sizeof(*iort);
> -iort->node_count = cpu_to_le32(nb_nodes);
> -/*
> - * Use a copy in case table_data->data moves during acpi_data_push
> - * operations.
> - */
> -iort_node_offset = sizeof(*iort);
> -iort->node_offset = cpu_to_le32(iort_node_offset);
> +/* Table 2 The IORT */
> +acpi_table_begin(, table_data);
> +/* Number of IORT Nodes */
> +build_append_int_noprefix(table_data, nb_nodes, 4);
> +/* Offset to Array of IORT Nodes */
> +build_append_int_noprefix(table_data, iort_node_offset, 4);
> +build_append_int_noprefix(table_data, 0, 4); /* Reserved */
>  
>  /* ITS group node */
>  node_size =  sizeof(*its) + sizeof(uint32_t);
> -iort_length += node_size;
>  its = acpi_data_push(table_data, node_size);
>  
>  its->type = ACPI_IORT_NODE_ITS_GROUP;
> @@ -350,7 +355,6 @@ build_iort(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  /* SMMUv3 node */
>  smmu_offset = iort_node_offset + node_size;
>  node_size = sizeof(*smmu) + sizeof(*idmap);
> -iort_length += node_size;
>  smmu = acpi_data_push(table_data, node_size);
>  
>  smmu->type = ACPI_IORT_NODE_SMMU_V3;
> @@ -375,7 +379,6 @@ build_iort(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  
>  /* Root Complex Node */
>  node_size = sizeof(*rc) + sizeof(*idmap) * rc_mapping_count;
> -iort_length += node_size;
>  rc = acpi_data_push(table_data, node_size);
>  
>  rc->type = ACPI_IORT_NODE_PCI_ROOT_COMPLEX;
> @@ -424,19 +427,9 @@ build_iort(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  

Re: [PATCH 2/3] docs: rSTify the "TrivialPatches" wiki

[Philippe Mathieu-Daudé]

Hi Kashyap,

On 9/22/21 14:10, Kashyap Chamarthy wrote:

The original wiki is here[1].  I converted by copying the wiki source
into a .wiki file and convert to rST using `pandoc`:

 $ pandoc -f Mediawiki -t rst trivial-patches.wiki -o 
trivial-patches.rst

[1] https://wiki.qemu.org/Contribute/TrivialPatches

Signed-off-by: Kashyap Chamarthy 
---
  docs/devel/trivial-patches.rst | 53 ++
  1 file changed, 53 insertions(+)
  create mode 100644 docs/devel/trivial-patches.rst

diff --git a/docs/devel/trivial-patches.rst b/docs/devel/trivial-patches.rst
new file mode 100644
index 00..4ad0d25b9d
--- /dev/null
+++ b/docs/devel/trivial-patches.rst
@@ -0,0 +1,53 @@
+===
+Trivial Patches
+===
+
+Overview
+
+
+Trivial patches that change just a few lines of code sometimes languish
+on the mailing list even though they require only a small amount of
+review. This is often the case for patches that do not fall under an
+actively maintained subsystem and therefore fall through the cracks.
+
+The trivial patches team take on the task of reviewing and building pull
+requests for patches that:
+
+- Do not fall under an actively maintained subsystem.
+- Are single patches or short series (max 2-4 patches).
+- Only touch a few lines of code.
+
+**You should hint that your patch is a candidate by CCing
+qemu-triv...@nongnu.org.**
+
+Repositories
+
+
+Since the trivial patch team rotates maintainership there is only one
+active repository at a time:
+
+- git://git.corpit.ru/qemu.git trivial-patches - `browse 
`__
+- git://github.com/vivier/qemu.git trivial-patches - `browse 
`__
+
+Workflow
+
+
+The trivial patches team rotates the duty of collecting trivial patches
+amongst its members. A team member's job is to:
+
+1. Identify trivial patches on the development mailing list.
+2. Review trivial patches, merge them into a git tree, and reply to state
+   that the patch is queued.
+3. Send pull requests to the development mailing list once a week.
+
+A single team member can be on duty as long as they like. The suggested
+time is 1 week before handing off to the next member.
+
+Team
+
+
+If you would like to join the trivial patches team, contact Michael
+Tokarev. The current team includes:
+
+- Michael Tokarev
+- `Laurent Vivier `__


I asked Michael if he could send a qemu-trivial@ pullreq last month
when Laurent was on PTO and he said he hasn't done it in years.

Indeed:

$ git log --committer='Michael Tokarev'
commit 9a232487aab8a7640ff8853d7d8d7c27106b44f8
Date:   Fri Apr 13 18:45:45 2018 +0200

So I think you are trying to commit obsolete information.

Anyway, up to Michael to adjust.

Thanks for rstifying the doc :)

Phil.

[RFC PATCH] spapr/xive: Allocate vCPU IPIs from local context

[Cédric Le Goater]

When QEMU switches to the XIVE interrupt mode, it creates all possible
guest interrupts at the level of the KVM device. These interrupts are
backed by real HW interrupts from the IPI interrupt pool of the XIVE
controller.

Currently, this is done from the QEMU main thread, which results in
allocating all interrupts from the chip on which QEMU is running. IPIs
are not distributed across the system and the load is not well
balanced across the interrupt controllers.

To improve distribution on the system, we should try to allocate the
underlying HW IPI from the vCPU context. This also benefits to
configurations using CPU pinning. In this case, the HW IPI is
allocated on the local chip, rerouting between interrupt controllers
is reduced and performance improved.

This moves the initialization of the vCPU IPIs from reset time to the
H_INT_SET_SOURCE_CONFIG hcall which is called from the vCPU context.
But this needs some extra checks in the sequences getting and setting
the source states to make sure a valid HW IPI is backing the guest
interrupt. For that, we check if a target was configured in the END in
case of a vCPU IPI.

Signed-off-by: Cédric Le Goater 
---

 I have tested different SMT configurations, kernel_irqchip=off/on,
 did some migrations, CPU hotplug, etc. It's not enough and I would
 like more testing but, at least, it is not making anymore the bad
 assumption vCPU id = IPI number.

 Comments ? 

 hw/intc/spapr_xive.c | 17 +
 hw/intc/spapr_xive_kvm.c | 36 +++-
 2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 6f31ce74f198..2dc594a720b1 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -1089,6 +1089,23 @@ static target_ulong h_int_set_source_config(PowerPCCPU 
*cpu,
 if (spapr_xive_in_kernel(xive)) {
 Error *local_err = NULL;
 
+/*
+ * Initialize the vCPU IPIs from the vCPU context to allocate
+ * the backing HW IPI on the local chip. This improves
+ * distribution of the IPIs in the system and when the vCPUs
+ * are pinned, it reduces rerouting between interrupt
+ * controllers for better performance.
+ */
+if (lisn < SPAPR_XIRQ_BASE) {
+XiveSource *xsrc = >source;
+
+kvmppc_xive_source_reset_one(xsrc, lisn, _err);
+if (local_err) {
+error_report_err(local_err);
+return H_HARDWARE;
+}
+}
+
 kvmppc_xive_set_source_config(xive, lisn, _eas, _err);
 if (local_err) {
 error_report_err(local_err);
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 53731d158625..1607a59e9483 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -254,7 +254,12 @@ static int kvmppc_xive_source_reset(XiveSource *xsrc, 
Error **errp)
 SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 int i;
 
-for (i = 0; i < xsrc->nr_irqs; i++) {
+/*
+ * vCPU IPIs are initialized at the KVM level when configured by
+ * H_INT_SET_SOURCE_CONFIG.
+ */
+
+for (i = SPAPR_XIRQ_BASE; i < xsrc->nr_irqs; i++) {
 int ret;
 
 if (!xive_eas_is_valid(>eat[i])) {
@@ -342,6 +347,27 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t offset,
 }
 }
 
+static bool xive_source_is_initialized(SpaprXive *xive, int lisn)
+{
+assert(lisn < xive->nr_irqs);
+
+if (!xive_eas_is_valid(>eat[lisn])) {
+return false;
+}
+
+/*
+ * vCPU IPIs are initialized at the KVM level when configured by
+ * H_INT_SET_SOURCE_CONFIG, in which case, we should have a valid
+ * target (server, priority) in the END.
+ */
+if (lisn < SPAPR_XIRQ_BASE) {
+return !!xive_get_field64(EAS_END_INDEX, xive->eat[lisn].w);
+}
+
+/* Device sources */
+return true;
+}
+
 static void kvmppc_xive_source_get_state(XiveSource *xsrc)
 {
 SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
@@ -350,7 +376,7 @@ static void kvmppc_xive_source_get_state(XiveSource *xsrc)
 for (i = 0; i < xsrc->nr_irqs; i++) {
 uint8_t pq;
 
-if (!xive_eas_is_valid(>eat[i])) {
+if (!xive_source_is_initialized(xive, i)) {
 continue;
 }
 
@@ -533,7 +559,7 @@ static void kvmppc_xive_change_state_handler(void *opaque, 
bool running,
 uint8_t pq;
 uint8_t old_pq;
 
-if (!xive_eas_is_valid(>eat[i])) {
+if (!xive_source_is_initialized(xive, i)) {
 continue;
 }
 
@@ -561,7 +587,7 @@ static void kvmppc_xive_change_state_handler(void *opaque, 
bool running,
 for (i = 0; i < xsrc->nr_irqs; i++) {
 uint8_t pq;
 
-if (!xive_eas_is_valid(>eat[i])) {
+if (!xive_source_is_initialized(xive, i)) {
 continue;
 }
 
@@ -666,7 +692,7 @@ int kvmppc_xive_post_load(SpaprXive *xive, int version_id)
 
 /* 

Re: [PATCH v2 14/30] tcg/loongarch64: Implement bswap32_i32/bswap32_i64/bswap64_i64

[Richard Henderson]

On 9/21/21 1:18 PM, WANG Xuerui wrote:

+case INDEX_op_bswap32_i32:
+/* All 32-bit values are computed sign-extended in the register.  */
+a2 = TCG_BSWAP_OS;
+/* fallthrough */
+case INDEX_op_bswap32_i64:
+tcg_out_opc_revb_2w(s, a0, a1);
+if (a2 & TCG_BSWAP_OS) {
+tcg_out_ext32s(s, a0, a0);
+} else if ((a2 & (TCG_BSWAP_IZ | TCG_BSWAP_OZ)) == TCG_BSWAP_OZ) {
+tcg_out_ext32u(s, a0, a0);
+}
+break;


Looks good so far, so:
Reviewed-by: Richard Henderson 

We'll also want INDEX_op_bswap16_{i32,i64}.  This should look just like bswap32_i64, 
except with revb_2h and ext16{s,u}.



r~

Re: [PATCH v2 15/30] tcg/loongarch64: Implement clz/ctz ops

[Richard Henderson]

On 9/21/21 1:19 PM, WANG Xuerui wrote:

Signed-off-by: WANG Xuerui
---
  tcg/loongarch64/tcg-target-con-set.h |  1 +
  tcg/loongarch64/tcg-target.c.inc | 42 
  2 files changed, 43 insertions(+)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 16/30] tcg/loongarch64: Implement shl/shr/sar/rotl/rotr ops

[Richard Henderson]

On 9/21/21 1:19 PM, WANG Xuerui wrote:

Signed-off-by: WANG Xuerui
---
  tcg/loongarch64/tcg-target-con-set.h |  1 +
  tcg/loongarch64/tcg-target.c.inc | 91 
  2 files changed, 92 insertions(+)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 20/30] tcg/loongarch64: Implement setcond ops

[Richard Henderson]

On 9/21/21 1:19 PM, WANG Xuerui wrote:

+static void tcg_out_setcond(TCGContext *s, TCGCond cond, TCGReg ret,
+TCGReg arg1, TCGReg arg2, bool c1, bool c2)
+{
+TCGReg tmp;
+
+if (c1) {
+tcg_debug_assert(arg1 == 0);
+}
+if (c2) {
+tcg_debug_assert(arg2 == 0);
+}


You don't need to work quite this hard.  Only the second argument will be constant.  If 
both are constant, we will have folded the operation away.  If the first argument was 
constant, we will swap the condition.



+switch (cond) {
+case TCG_COND_EQ:
+if (c1) {
+tmp = arg2;
+} else if (c2) {
+tmp = arg1;
+} else {
+tcg_out_opc_sub_d(s, ret, arg1, arg2);


if (!c2) {
...
}

Otherwise,
Reviewed-by: Richard Henderson 


r~

Re: [PATCH v2 3/3] dump-guest-memory: Block live migration

[Marc-André Lureau]

Hi

On Thu, Aug 26, 2021 at 11:01 PM Peter Xu  wrote:

> Both dump-guest-memory and live migration caches vm state at the beginning.
> Either of them entering the other one will cause race on the vm state, and
> even
> more severe on that (please refer to the crash report in the bug link).
>
> Let's block live migration in dump-guest-memory, and that'll also block
> dump-guest-memory if it detected that we're during a live migration.
>
> Side note: migrate_del_blocker() can be called even if the blocker is not
> inserted yet, so it's safe to unconditionally delete that blocker in
> dump_cleanup (g_slist_remove allows no-entry-found case).
>
> Suggested-by: Dr. David Alan Gilbert 
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1996609
> Signed-off-by: Peter Xu 
> ---
>  dump/dump.c | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/dump/dump.c b/dump/dump.c
> index ab625909f3..9c1c1fb738 100644
> --- a/dump/dump.c
> +++ b/dump/dump.c
> @@ -29,6 +29,7 @@
>  #include "qemu/error-report.h"
>  #include "qemu/main-loop.h"
>  #include "hw/misc/vmcoreinfo.h"
> +#include "migration/blocker.h"
>
>  #ifdef TARGET_X86_64
>  #include "win_dump.h"
> @@ -47,6 +48,8 @@
>
>  #define MAX_GUEST_NOTE_SIZE (1 << 20) /* 1MB should be enough */
>
> +static Error *dump_migration_blocker;
> +
>  #define ELF_NOTE_SIZE(hdr_size, name_size, desc_size)   \
>  ((DIV_ROUND_UP((hdr_size), 4) + \
>DIV_ROUND_UP((name_size), 4) +\
> @@ -101,6 +104,7 @@ static int dump_cleanup(DumpState *s)
>  qemu_mutex_unlock_iothread();
>  }
>  }
> +migrate_del_blocker(dump_migration_blocker);
>
>  return 0;
>  }
> @@ -1927,11 +1931,6 @@ void qmp_dump_guest_memory(bool paging, const char
> *file,
>  Error *local_err = NULL;
>  bool detach_p = false;
>
> -if (runstate_check(RUN_STATE_INMIGRATE)) {
>

This INMIGRATE check,

-error_setg(errp, "Dump not allowed during incoming migration.");
> -return;
> -}
> -
>  /* if there is a dump in background, we should wait until the dump
>   * finished */
>  if (dump_in_progress()) {
> @@ -2005,6 +2004,21 @@ void qmp_dump_guest_memory(bool paging, const char
> *file,
>  return;
>  }
>
> +if (!dump_migration_blocker) {
> +error_setg(_migration_blocker,
> +   "Live migration disabled: dump-guest-memory in
> progress");
> +}
> +
> +/*
> + * Allows even for -only-migratable, but forbid migration during the
> + * process of dump guest memory.
> + */
> +if (migrate_add_blocker_internal(dump_migration_blocker, errp)) {
>

is now handled here with migration_is_idle() ?

I am not familiar enough with the run & migration states intricacies here

+/* Remember to release the fd before passing it over to dump state
> */
> +close(fd);
> +return;
> +}
> +
>  s = _state_global;
>  dump_state_prepare(s);
>
> --
> 2.31.1
>
>
>

-- 
Marc-André Lureau

Re: [PATCH v2 09/30] tcg/loongarch64: Implement tcg_out_mov and tcg_out_movi

[Richard Henderson]

On 9/22/21 8:16 AM, WANG Xuerui wrote:

Hi Richard,

On 9/22/21 12:25, Richard Henderson wrote:

On 9/21/21 1:18 PM, WANG Xuerui wrote:

+    /* Test for PC-relative values that can be loaded faster.  */
+    intptr_t pc_offset = val - (uintptr_t)s->code_ptr;


This isn't quite right for split r^x code buffer.
You should have seen this with --enable-debug-tcg...

You need pc_offset = tcg_pcrel_diff(s, (void *)val).

Indeed; I just realized TCG debugging isn't fully enabled with --enable-debug 
only.


Um... it should be.

Re: [PATCH v3 17/35] acpi: use build_append_int_noprefix() API to compose SRAT table

[Eric Auger]

On 9/22/21 12:02 PM, Igor Mammedov wrote:
> On Wed, 22 Sep 2021 10:55:20 +0200
> Eric Auger  wrote:
> 
>> On 9/7/21 4:47 PM, Igor Mammedov wrote:
>>> Drop usage of packed structures and explicit endian conversions
>>> when building SRAT tables for arm/x86 and use endian agnostic
>>> build_append_int_noprefix() API to build it.
>>>
>>> Signed-off-by: Igor Mammedov 
>>> ---
>>> v3:
>>>  * rebase on top of (e77af21a7a2 hw/i386/acpi-build: Get NUMA information 
>>> from struct NumaState)
>>> CC: xiaoguangrong.e...@gmail.com
>>> CC: shannon.zha...@gmail.com
>>> CC: peter.mayd...@linaro.org
>>> CC: marcel.apfelb...@gmail.com
>>> CC: qemu-...@nongnu.org
>>> CC: drjo...@redhat.com
>>> CC: eau...@redhat.com
>>> ---
>>>  include/hw/acpi/acpi-defs.h | 49 ---
>>>  include/hw/acpi/aml-build.h |  2 +-
>>>  hw/acpi/aml-build.c | 24 
>>>  hw/acpi/nvdimm.c|  4 +-
>>>  hw/arm/virt-acpi-build.c| 29 --
>>>  hw/i386/acpi-build.c| 78 +
>>>  6 files changed, 80 insertions(+), 106 deletions(-)
>>>
>>> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
>>> index 5826ee04b6..d293304f9c 100644
>>> --- a/include/hw/acpi/acpi-defs.h
>>> +++ b/include/hw/acpi/acpi-defs.h
>>> @@ -358,55 +358,6 @@ struct AcpiGenericTimerTable {
>>>  } QEMU_PACKED;
>>>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>>>  
>>> -#define ACPI_SRAT_PROCESSOR_APIC 0
>>> -#define ACPI_SRAT_MEMORY 1
>>> -#define ACPI_SRAT_PROCESSOR_x2APIC   2
>>> -#define ACPI_SRAT_PROCESSOR_GICC 3
>>> -
>>> -struct AcpiSratProcessorAffinity {
>>> -ACPI_SUB_HEADER_DEF
>>> -uint8_t proximity_lo;
>>> -uint8_t local_apic_id;
>>> -uint32_tflags;
>>> -uint8_t local_sapic_eid;
>>> -uint8_t proximity_hi[3];
>>> -uint32_treserved;
>>> -} QEMU_PACKED;
>>> -typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
>>> -
>>> -struct AcpiSratProcessorX2ApicAffinity {
>>> -ACPI_SUB_HEADER_DEF
>>> -uint16_treserved;
>>> -uint32_tproximity_domain;
>>> -uint32_tx2apic_id;
>>> -uint32_tflags;
>>> -uint32_tclk_domain;
>>> -uint32_treserved2;
>>> -} QEMU_PACKED;
>>> -typedef struct AcpiSratProcessorX2ApicAffinity 
>>> AcpiSratProcessorX2ApicAffinity;
>>> -
>>> -struct AcpiSratMemoryAffinity {
>>> -ACPI_SUB_HEADER_DEF
>>> -uint32_tproximity;
>>> -uint16_treserved1;
>>> -uint64_tbase_addr;
>>> -uint64_trange_length;
>>> -uint32_treserved2;
>>> -uint32_tflags;
>>> -uint32_treserved3[2];
>>> -} QEMU_PACKED;
>>> -typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
>>> -
>>> -struct AcpiSratProcessorGiccAffinity {
>>> -ACPI_SUB_HEADER_DEF
>>> -uint32_tproximity;
>>> -uint32_tacpi_processor_uid;
>>> -uint32_tflags;
>>> -uint32_tclock_domain;
>>> -} QEMU_PACKED;
>>> -
>>> -typedef struct AcpiSratProcessorGiccAffinity AcpiSratProcessorGiccAffinity;
>>> -
>>>  /* DMAR - DMA Remapping table r2.2 */
>>>  struct AcpiTableDmar {
>>>  ACPI_TABLE_HEADER_DEF
>>> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
>>> index 4242382399..6e1f42e119 100644
>>> --- a/include/hw/acpi/aml-build.h
>>> +++ b/include/hw/acpi/aml-build.h
>>> @@ -487,7 +487,7 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet 
>>> *range_set, uint32_t io_offset,
>>> uint32_t mmio32_offset, uint64_t mmio64_offset,
>>> uint16_t bus_nr_offset);
>>>  
>>> -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
>>> +void build_srat_memory(GArray *table_data, uint64_t base,
>>> uint64_t len, int node, MemoryAffinityFlags flags);
>>>  
>>>  void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
>>> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
>>> index 5e8bfb631c..050fdb3f37 100644
>>> --- a/hw/acpi/aml-build.c
>>> +++ b/hw/acpi/aml-build.c
>>> @@ -1936,15 +1936,25 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, 
>>> GArray *table_offsets,
>>>  acpi_table_end(linker, );
>>>  }
>>>  
>>> -void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
>>> +/*
>>> + * ACPI spec, Revision 4.0
>>> + * 5.2.16.2 Memory Affinity Structure
>>> + */
>>> +void build_srat_memory(GArray *table_data, uint64_t base,
>>> uint64_t len, int node, MemoryAffinityFlags flags)
>>>  {
>>> -numamem->type = ACPI_SRAT_MEMORY;
>>> -numamem->length = sizeof(*numamem);
>>> -numamem->proximity = cpu_to_le32(node);
>>> -numamem->flags = cpu_to_le32(flags);
>>> -numamem->base_addr = cpu_to_le64(base);
>>> -numamem->range_length = cpu_to_le64(len);
>>> +build_append_int_noprefix(table_data, 1, 1); /* Type */
>>> +build_append_int_noprefix(table_data, 40, 1); /* Length */
>>> +

[PATCH v2 0/1] fixes in spapr_numa_FORM2_write_rtas_tables()

[Daniel Henrique Barboza]

Hi,

This new version contains suggestions from Greg, Phillipe and Zoltan
that were made in the v1.

Changes from v1:
- keep the heap allocation of both arrays;
- use stl_be_p();
- use sizeof(uint32_t) instead of hardcoding '4' when skipping the
length;
- use the existing NUMA_DISTANCE_MIN macro.
- v1 link: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05464.html


Daniel Henrique Barboza (1):
  spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

 hw/ppc/spapr_numa.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

-- 
2.31.1

Re: [PATCH] spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables()

[Philippe Mathieu-Daudé]

On 9/22/21 13:52, Greg Kurz wrote:

On Wed, 22 Sep 2021 13:17:32 +0200
Philippe Mathieu-Daudé  wrote:


On 9/21/21 21:43, Daniel Henrique Barboza wrote:

This patch has a handful of modifications for the recent added
FORM2 support:

- there is no particular reason for both 'lookup_index_table' and
'distance_table' to be allocated in the heap, since their sizes are
known right at the start of the function. Use static allocation in
them to spare a couple of g_new0() calls;

- to not allocate more than the necessary size in 'distance_table'. At
this moment the array is oversized due to allocating uint32_t for all
elements, when most of them fits in an uint8_t;

- create a NUMA_LOCAL_DISTANCE macro to avoid hardcoding the local
distance value.

Signed-off-by: Daniel Henrique Barboza 
---
   hw/ppc/spapr_numa.c | 35 +++
   1 file changed, 19 insertions(+), 16 deletions(-)



   /*
* Retrieves max_dist_ref_points of the current NUMA affinity.
*/
@@ -500,17 +503,21 @@ static void 
spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
   MachineState *ms = MACHINE(spapr);
   NodeInfo *numa_info = ms->numa_state->nodes;
   int nb_numa_nodes = ms->numa_state->num_nodes;
+/* Lookup index table has an extra uint32_t with its length */
+uint32_t lookup_index_table[nb_numa_nodes + 1];
   int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
-g_autofree uint32_t *lookup_index_table = NULL;
-g_autofree uint32_t *distance_table = NULL;
-int src, dst, i, distance_table_size;
-uint8_t *node_distances;


This should have be of ptrdiff_t type.



Why ? I don't see pointer subtraction in the code.


Oops, you are right.

Re: ensuring a machine's buses have unique names

[Markus Armbruster]

BALATON Zoltan  writes:

> On Wed, 22 Sep 2021, Markus Armbruster wrote:
>> BALATON Zoltan  writes:
>>> To me it looks like device code can't really set a globally unique
>>> name on creating the bus without getting some help from upper
>>> levels. So maybe naming busses should be done by qdev (or whatever is
>>> handling this) instead of passing the name as an argument to
>>> qbus_create or only use that name as a unique component within the
>>> device and append it to a unique name for the device.
>>
>> Have you read the whole thread?  qdev does come up with a name when
>
> No I haven't. This just got my attention because I'm responsible for
> adding ati-vga.ddc and sm501.i2c and some ppc440 stuff so I was
> wondering what could I do better bur otherwise I did not check the
> whole thread so just ignore what I said if it's not useful in this
> context.

I wouldn't call it "not useful".

What you could do better in future code: pass a null bus name.  This is
not obvious.  As Peter noted "we created a family of easy-to-misuse
APIs".

[...]

Re: [PATCH v6 00/11] 64bit block-layer: part II

[Eric Blake]

On Wed, Sep 22, 2021 at 10:52:20AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Ping)
> 
> Not reviewed: 6,7,10

Also on my list to see what I can get in this week's NBD pull request.

> 
> 03.09.2021 13:27, Vladimir Sementsov-Ogievskiy wrote:
> > Hi all!
> > 
> > Sorry for a long delay:(  Finally, here is v6.
> > 

> > Vladimir Sementsov-Ogievskiy (11):
> >block/io: bring request check to bdrv_co_(read,write)v_vmstate
> >qcow2: check request on vmstate save/load path
> >block: use int64_t instead of uint64_t in driver read handlers
> >block: use int64_t instead of uint64_t in driver write handlers
> >block: use int64_t instead of uint64_t in copy_range driver handlers
> >block: make BlockLimits::max_pwrite_zeroes 64bit
> >block: use int64_t instead of int in driver write_zeroes handlers
> >block/io: allow 64bit write-zeroes requests
> >block: make BlockLimits::max_pdiscard 64bit
> >block: use int64_t instead of int in driver discard handlers
> >block/io: allow 64bit discard requests
> 
> 
> -- 
> Best regards,
> Vladimir
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[PATCH] 9pfs: fix wrong I/O block size in Rgetattr

[Christian Schoenebeck]

When client sent a 9p Tgetattr request then the wrong I/O block
size value was returned by 9p server; instead of host file
system's I/O block size it should rather return an I/O block
size according to 9p session's 'msize' value, because the value
returned to client should be an "optimum" block size for I/O
(i.e. to maximize performance), it should not reflect the actual
physical block size of the underlying storage media.

The I/O block size of a host filesystem is typically 4k, so the
value returned was far too low for good 9p I/O performance.

This patch adds stat_to_iounit() with a similar approach as the
existing get_iounit() function.

Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/9p.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index c857b31321..708b030474 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1262,6 +1262,25 @@ static int coroutine_fn stat_to_v9stat(V9fsPDU *pdu, 
V9fsPath *path,
 #define P9_STATS_ALL   0x3fffULL /* Mask for All fields above */
 
 
+static int32_t stat_to_iounit(const V9fsPDU *pdu, const struct stat *stbuf)
+{
+int32_t iounit = 0;
+V9fsState *s = pdu->s;
+
+/*
+ * iounit should be multiples of st_blksize (host filesystem block size)
+ * as well as less than (client msize - P9_IOHDRSZ)
+ */
+if (stbuf->st_blksize) {
+iounit = stbuf->st_blksize;
+iounit *= (s->msize - P9_IOHDRSZ) / stbuf->st_blksize;
+}
+if (!iounit) {
+iounit = s->msize - P9_IOHDRSZ;
+}
+return iounit;
+}
+
 static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct stat *stbuf,
 V9fsStatDotl *v9lstat)
 {
@@ -1273,7 +1292,7 @@ static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct 
stat *stbuf,
 v9lstat->st_gid = stbuf->st_gid;
 v9lstat->st_rdev = stbuf->st_rdev;
 v9lstat->st_size = stbuf->st_size;
-v9lstat->st_blksize = stbuf->st_blksize;
+v9lstat->st_blksize = stat_to_iounit(pdu, stbuf);
 v9lstat->st_blocks = stbuf->st_blocks;
 v9lstat->st_atime_sec = stbuf->st_atime;
 v9lstat->st_atime_nsec = stbuf->st_atim.tv_nsec;
-- 
2.20.1

Re: [PATCH v3 29/35] acpi: arm/virt: convert build_iort() to endian agnostic build_append_FOO() API

[Igor Mammedov]

On Wed, 22 Sep 2021 15:26:49 +0200
Eric Auger  wrote:

I'll fix patch up as suggested,
though there is a question, see below

> On 9/7/21 4:48 PM, Igor Mammedov wrote:
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >   * practically rewritten, due to conflicts wiht bypass iommu feature
> >
> > CC: drjo...@redhat.com
> > CC: peter.mayd...@linaro.org
> > CC: shannon.zha...@gmail.com
> > CC: qemu-...@nongnu.org
> > CC: wangxinga...@huawei.com
> > CC: Eric Auger 
> > ---
> >  include/hw/acpi/acpi-defs.h |  71 ---
> >  hw/arm/virt-acpi-build.c| 167 
> >  2 files changed, 91 insertions(+), 147 deletions(-)
> >
> > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> > index 195f90caf6..6f2f08a9de 100644
> > --- a/include/hw/acpi/acpi-defs.h
> > +++ b/include/hw/acpi/acpi-defs.h
> > @@ -188,75 +188,4 @@ struct AcpiGenericTimerTable {
> >  } QEMU_PACKED;
> >  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
> >  
> > -/*
> > - * IORT node types
> > - */
> > -
> > -#define ACPI_IORT_NODE_HEADER_DEF   /* Node format common fields */ \
> > -uint8_t  type;  \
> > -uint16_t length;\
> > -uint8_t  revision;  \
> > -uint32_t reserved;  \
> > -uint32_t mapping_count; \
> > -uint32_t mapping_offset;
> > -
> > -/* Values for node Type above */
> > -enum {
> > -ACPI_IORT_NODE_ITS_GROUP = 0x00,
> > -ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
> > -ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
> > -ACPI_IORT_NODE_SMMU = 0x03,
> > -ACPI_IORT_NODE_SMMU_V3 = 0x04
> > -};
> > -
> > -struct AcpiIortIdMapping {
> > -uint32_t input_base;
> > -uint32_t id_count;
> > -uint32_t output_base;
> > -uint32_t output_reference;
> > -uint32_t flags;
> > -} QEMU_PACKED;
> > -typedef struct AcpiIortIdMapping AcpiIortIdMapping;
> > -
> > -struct AcpiIortMemoryAccess {
> > -uint32_t cache_coherency;
> > -uint8_t  hints;
> > -uint16_t reserved;
> > -uint8_t  memory_flags;
> > -} QEMU_PACKED;
> > -typedef struct AcpiIortMemoryAccess AcpiIortMemoryAccess;
> > -
> > -struct AcpiIortItsGroup {
> > -ACPI_IORT_NODE_HEADER_DEF
> > -uint32_t its_count;
> > -uint32_t identifiers[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiIortItsGroup AcpiIortItsGroup;
> > -
> > -#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE 1
> > -
> > -struct AcpiIortSmmu3 {
> > -ACPI_IORT_NODE_HEADER_DEF
> > -uint64_t base_address;
> > -uint32_t flags;
> > -uint32_t reserved2;
> > -uint64_t vatos_address;
> > -uint32_t model;
> > -uint32_t event_gsiv;
> > -uint32_t pri_gsiv;
> > -uint32_t gerr_gsiv;
> > -uint32_t sync_gsiv;
> > -AcpiIortIdMapping id_mapping_array[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiIortSmmu3 AcpiIortSmmu3;
> > -
> > -struct AcpiIortRC {
> > -ACPI_IORT_NODE_HEADER_DEF
> > -AcpiIortMemoryAccess memory_properties;
> > -uint32_t ats_attribute;
> > -uint32_t pci_segment_number;
> > -AcpiIortIdMapping id_mapping_array[];
> > -} QEMU_PACKED;
> > -typedef struct AcpiIortRC AcpiIortRC;
> > -
> >  #endif
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index bceb1b3b7e..4c682e7b09 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -240,6 +240,28 @@ static void acpi_dsdt_add_tpm(Aml *scope, 
> > VirtMachineState *vms)
> >  }
> >  #endif
> >  
> > +#define ID_MAPPING_ENTRY_SIZE 20
> > +#define SMMU_V3_ENTRY_SIZE 60
> > +#define ROOT_COMPLEX_ENTRY_SIZE 32
> > +#define IORT_NODE_OFFSET 48
> > +
> > +static void build_iort_id_mapping(GArray *table_data, uint32_t input_base,
> > +  uint32_t id_count, uint32_t out_ref)
> > +{
> > +/* Identity RID mapping covering the whole input RID range */
> > +build_append_int_noprefix(table_data, input_base, 4); /* Input base */
> > +build_append_int_noprefix(table_data, id_count, 4); /* Number of IDs */
> > +build_append_int_noprefix(table_data, input_base, 4); /* Output base */
> > +build_append_int_noprefix(table_data, out_ref, 4); /* Output Reference 
> > */
> > +build_append_int_noprefix(table_data, 0, 4); /* Flags */
> > +}
> > +
> > +struct AcpiIortIdMapping {
> > +uint32_t input_base;
> > +uint32_t id_count;
> > +};
> > +typedef struct AcpiIortIdMapping AcpiIortIdMapping;
> > +
> >  /* Build the iort ID mapping to SMMUv3 for a given PCI host bridge */
> >  static int
> >  iort_host_bridges(Object *obj, void *opaque)
> > @@ -281,18 +303,17 @@ static int iort_idmap_compare(gconstpointer a, 
> > gconstpointer b)
> >  static void
> >  build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> >  {
> > -int i, nb_nodes, rc_mapping_count;
> > -AcpiIortIdMapping *idmap;
> > -AcpiIortItsGroup *its;
> > -AcpiIortSmmu3 *smmu;
> > -AcpiIortRC *rc;
> > +int i, rc_mapping_count;
> >  const uint32_t 

Re: [PATCH v3 11/35] acpi: nvdimm_build_ssdt: use acpi_table_begin()/acpi_table_end() instead of build_header()

[Igor Mammedov]

On Mon, 20 Sep 2021 18:41:30 +0200
Eric Auger  wrote:

> Hi Igor,
> 
> On 9/7/21 4:47 PM, Igor Mammedov wrote:
> > it replaces error-prone pointer arithmetic for build_header() API,
> > with 2 calls to start and finish table creation,
> > which hides offsets magic from API user.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >   * s/acpi_init_table|acpi_table_composed/acpi_table_begin|acpi_table_end/
> > 
> > CC: xiaoguangrong.e...@gmail.com
> > ---
> >  hw/acpi/nvdimm.c | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> > index 15f6ca82ca..e050b47c2b 100644
> > --- a/hw/acpi/nvdimm.c
> > +++ b/hw/acpi/nvdimm.c
> > @@ -1274,14 +1274,15 @@ static void nvdimm_build_ssdt(GArray 
> > *table_offsets, GArray *table_data,
> >NVDIMMState *nvdimm_state,
> >uint32_t ram_slots, const char *oem_id)
> >  {
> > +int mem_addr_offset;
> >  Aml *ssdt, *sb_scope, *dev;
> > -int mem_addr_offset, nvdimm_ssdt;
> > +AcpiTable table = { .sig = "SSDT", .rev = 1,
> > +.oem_id = oem_id, .oem_table_id = "NVDIMM" };
> >  
> >  acpi_add_table(table_offsets, table_data);
> >  
> > +acpi_table_begin(, table_data);
> >  ssdt = init_aml_allocator();
> > -acpi_data_push(ssdt->buf, sizeof(AcpiTableHeader));
> > -
> >  sb_scope = aml_scope("\\_SB");
> >  
> >  dev = aml_device("NVDR");
> > @@ -1310,8 +1311,6 @@ static void nvdimm_build_ssdt(GArray *table_offsets, 
> > GArray *table_data,
> >  aml_append(sb_scope, dev);
> >  aml_append(ssdt, sb_scope);
> >  
> > -nvdimm_ssdt = table_data->len;
> > -
> >  /* copy AML table into ACPI tables blob and patch header there */
> >  g_array_append_vals(table_data, ssdt->buf->data, ssdt->buf->len);
> >  mem_addr_offset = build_append_named_dword(table_data,
> > @@ -1323,10 +1322,13 @@ static void nvdimm_build_ssdt(GArray 
> > *table_offsets, GArray *table_data,
> >  bios_linker_loader_add_pointer(linker,
> >  ACPI_BUILD_TABLE_FILE, mem_addr_offset, sizeof(uint32_t),
> >  NVDIMM_DSM_MEM_FILE, 0);
> > -build_header(linker, table_data,
> > -(void *)(table_data->data + nvdimm_ssdt),
> > - "SSDT", table_data->len - nvdimm_ssdt, 1, oem_id, 
> > "NVDIMM");
> >  free_aml_allocator();
> > +/*
> > + * must be executed as the last so that pointer patching command above
> > + * would be executed by guest before it recalculates checksum which 
> > were
> > + * scheduled by acpi_table_composed()  
> s/acpi_table_composed/acpi_table_end.
fixed it up:

/*  
 
 * must be executed as the last so that pointer patching command above  
 
 * would be executed by guest before it recalculated checksum which were
 
 * scheduled by acpi_table_end()
 
 */ 
 
> also the sentence may need some rewording.
> 
> Wonder if that kind of comment still is useful. Maybe this should be put
> once in the doc comment of acpi_table_end() in [PATCH v3 01/35] acpi:
> add helper routines to initialize ACPI tables, for future users to pay
> attention that it shall be called at the very end.

I'll keep comment for now, and add patch to add something similar to
acpi_table_end() later or drop it if I come up with a way to actually
enforce expected linker order.

 
> Besides
> 
> Reviewed-by: Eric Auger 
> 
> Eric
> 
> 
> > + */
> > +acpi_table_end(linker, );
> >  }
> >  
> >  void nvdimm_build_srat(GArray *table_data)
> >   
> 

[RFC PATCH] tests/docker: add a debian-native image and make available

[Alex Bennée]

This image is intended for building whatever the native versions of
QEMU are for the host architecture. This will hopefully be an aid for
3rd parties who want to be able to build QEMU themselves without
redoing all the dependencies themselves.

We disable the registry because we currently don't have multi-arch
support there.

Signed-off-by: Alex Bennée 
Cc: Anders Roxell 
---
 tests/docker/Makefile.include |  4 ++
 tests/docker/common.rc| 10 +++-
 tests/docker/dockerfiles/debian-native.docker | 49 +++
 3 files changed, 61 insertions(+), 2 deletions(-)
 create mode 100644 tests/docker/dockerfiles/debian-native.docker

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 3b03763186..2f276cc4b2 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -145,6 +145,10 @@ docker-image-debian-s390x-cross: docker-image-debian10
 docker-image-debian-sh4-cross: docker-image-debian10
 docker-image-debian-sparc64-cross: docker-image-debian10
 
+# The native build should never use the registry
+docker-image-debian-native: DOCKER_REGISTRY=
+
+
 #
 # The build rule for hexagon-cross is special in so far for most of
 # the time we don't want to build it. While dockers caching does avoid
diff --git a/tests/docker/common.rc b/tests/docker/common.rc
index c5cc33d366..e6f8cee0d6 100755
--- a/tests/docker/common.rc
+++ b/tests/docker/common.rc
@@ -12,8 +12,14 @@
 # the top-level directory.
 
 # This might be set by ENV of a docker container... it is always
-# overriden by TARGET_LIST if the user sets it.
-DEF_TARGET_LIST=${DEF_TARGET_LIST:-"x86_64-softmmu,aarch64-softmmu"}
+# overriden by TARGET_LIST if the user sets it. We special case
+# "none" to allow for other options like --disable-tcg to restrict the
+# builds we eventually do.
+if test "$DEF_TARGET_LIST" = "none"; then
+DEF_TARGET_LIST=""
+else
+DEF_TARGET_LIST=${DEF_TARGET_LIST:-"x86_64-softmmu,aarch64-softmmu"}
+fi
 
 requires_binary()
 {
diff --git a/tests/docker/dockerfiles/debian-native.docker 
b/tests/docker/dockerfiles/debian-native.docker
new file mode 100644
index 00..efd55cb6e0
--- /dev/null
+++ b/tests/docker/dockerfiles/debian-native.docker
@@ -0,0 +1,49 @@
+#
+# Docker Debian Native
+#
+# This this intended to build QEMU on native host systems. Debian is
+# chosen due to the broadest range on supported host systems for QEMU.
+#
+# This docker target is based on the docker.io Debian Bullseye base
+# image rather than QEMU's base because we would otherwise confuse the
+# build grabbing stuff from the registry built for other
+# architectures.
+#
+FROM docker.io/library/debian:bullseye-slim
+MAINTAINER Alex Bennée 
+
+# Duplicate deb line as deb-src
+RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> 
/etc/apt/sources.list
+
+# Install common build utilities
+RUN apt update && \
+DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata
+
+RUN apt update && \
+DEBIAN_FRONTEND=noninteractive eatmydata \
+apt build-dep -yy --arch-only qemu
+
+RUN apt update && \
+DEBIAN_FRONTEND=noninteractive eatmydata \
+apt install -y --no-install-recommends \
+cscope \
+genisoimage \
+exuberant-ctags \
+global \
+libbz2-dev \
+liblzo2-dev \
+libgcrypt20-dev \
+libfdt-dev \
+librdmacm-dev \
+libsasl2-dev \
+libsnappy-dev \
+libvte-dev \
+netcat-openbsd \
+ninja-build \
+openssh-client \
+python3-numpy \
+python3-opencv \
+python3-venv
+
+ENV QEMU_CONFIGURE_OPTS $QEMU_CONFIGURE_OPTS
+ENV DEF_TARGET_LIST "none"
-- 
2.30.2

Re: [PATCH v11 06/10] hvf: arm: Implement -cpu host

[Peter Maydell]

On Wed, 22 Sept 2021 at 12:41, Ard Biesheuvel  wrote:
>
> On Thu, 16 Sept 2021 at 18:17, Peter Maydell  wrote:
> >
> > On Thu, 16 Sept 2021 at 17:05, Ard Biesheuvel  wrote:
> > > I'd argue that compliance with the architecture means that the
> > > software should not clear RES1 bits
> >
> > Architecturally, RES1 means that "software
> >  * Must not rely on the bit reading as 1.
> >  * Must use an SBOP policy to write to the bit."
> > (SBOP=="should be 1 or preserved", ie you can preserve the existing value,
> > as in "read register, change some bits, write back", or you can write a 1.)
> >
>
> OVMF preserves the bit, and does not reason or care about its value.
> So in this sense, it is compliant.

Hmm. Alex, can you give more details about what fails here ?

> > > but I don't think we can blame it
> > > for not touching bits that were in in invalid state upon entry.
> >
> > SCTLR_EL1.SPAN == 0 is perfectly valid for a CPU that supports the
> > PAN feature. It's just not the value OVMF wants, so OVMF should
> > be setting it to what it does want. Also, as the first thing to
> > run after reset (ie firmware) OVMF absolutely is responsible for
> > dealing with system registers which have UNKNOWN values out of
> > reset.
> >
>
> Fair enough. But I'd still suggest fixing this at both ends.

Yes, the version of this code that we committed sets SPAN to 1.
(This argument is mostly about what the comment justifying that
value should say :-))

-- PMM

[PATCH 2/2] tests/qapi-schema: Make test-qapi.py -u work when files are absent

[Markus Armbruster]

test-qapi.py -u updates the expected files.  Since it fails when they
are absent, users have to create them manually before they can use
test-qapi.py to fill in the contents, say for a new test.  Silly.
Improve -u to create them.

Signed-off-by: Markus Armbruster 
---
 tests/qapi-schema/test-qapi.py | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qapi.py
index 2e384f5efd..c717a7a90b 100755
--- a/tests/qapi-schema/test-qapi.py
+++ b/tests/qapi-schema/test-qapi.py
@@ -132,6 +132,17 @@ def test_frontend(fname):
 print('section=%s\n%s' % (section.name, section.text))
 
 
+def open_test_result(dir_name, file_name, update):
+mode = 'r+' if update else 'r'
+try:
+fp = open(os.path.join(dir_name, file_name), mode)
+except FileNotFoundError:
+if not update:
+raise
+fp = open(os.path.join(dir_name, file_name), 'w+')
+return fp
+
+
 def test_and_diff(test_name, dir_name, update):
 sys.stdout = StringIO()
 try:
@@ -148,10 +159,9 @@ def test_and_diff(test_name, dir_name, update):
 sys.stdout.close()
 sys.stdout = sys.__stdout__
 
-mode = 'r+' if update else 'r'
 try:
-outfp = open(os.path.join(dir_name, test_name + '.out'), mode)
-errfp = open(os.path.join(dir_name, test_name + '.err'), mode)
+outfp = open_test_result(dir_name, test_name + '.out', update)
+errfp = open_test_result(dir_name, test_name + '.err', update)
 expected_out = outfp.readlines()
 expected_err = errfp.readlines()
 except OSError as err:
-- 
2.31.1

[PATCH 1/2] tests/qapi-schema: Use Python OSError instead of outmoded IOError

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 tests/qapi-schema/test-qapi.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qapi.py
index 73cffae2b6..2e384f5efd 100755
--- a/tests/qapi-schema/test-qapi.py
+++ b/tests/qapi-schema/test-qapi.py
@@ -154,7 +154,7 @@ def test_and_diff(test_name, dir_name, update):
 errfp = open(os.path.join(dir_name, test_name + '.err'), mode)
 expected_out = outfp.readlines()
 expected_err = errfp.readlines()
-except IOError as err:
+except OSError as err:
 print("%s: can't open '%s': %s"
   % (sys.argv[0], err.filename, err.strerror),
   file=sys.stderr)
@@ -180,7 +180,7 @@ def test_and_diff(test_name, dir_name, update):
 errfp.truncate(0)
 errfp.seek(0)
 errfp.writelines(actual_err)
-except IOError as err:
+except OSError as err:
 print("%s: can't write '%s': %s"
   % (sys.argv[0], err.filename, err.strerror),
   file=sys.stderr)
-- 
2.31.1

Re: [PATCH 1/3] docs: rSTify the "SpellCheck" wiki

[Peter Maydell]

On Wed, 22 Sept 2021 at 13:11, Kashyap Chamarthy  wrote:
>
> The original wiki is here[1].  I converted by copying the wiki source[2]
> into a .wiki file and convert to rST using `pandoc`:
>
> $ pandoc -f Mediawiki -t rst spell-check.wiki -o spell-check.rst
>
> [1] https://wiki.qemu.org/Contribute/SpellCheck
> [2] 
> https://web.archive.org/web/20170721031029/http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch=edit
>
> Signed-off-by: Kashyap Chamarthy 
> ---
>  docs/devel/spell-check.rst | 29 +
>  1 file changed, 29 insertions(+)
>  create mode 100644 docs/devel/spell-check.rst
>
> diff --git a/docs/devel/spell-check.rst b/docs/devel/spell-check.rst
> new file mode 100644
> index 00..998cd7ef51
> --- /dev/null
> +++ b/docs/devel/spell-check.rst
> @@ -0,0 +1,29 @@
> +===
> +Spell Check
> +===
> +
> +QEMU uses British or American English in code and documentation. There
> +are some typical spelling bugs which can be easily avoided by using
> +tools like codespell.
> +
> +codespell is a python script which detects (and optionally fixes) the
> +most common spelling bugs.
> +
> +If you installed codespell in your HOME directory, it can be called from
> +the QEMU source directory like this::
> +
> +~/bin/codespell.py -d -r -s -x scripts/codespell.exclude -q 2 
> ~/share/codespell/dictionary.txt
> +
> +``-x scripts/codespell.exclude`` excludes some known lines from the check
> +and needs a file which is not yet committed.

This command doesn't actually work, because there is no
scripts/codespell.exclude in the source tree. It also
assumes you have a ~/share/codespell/dictionary.txt in your
home directory.

I think Stefan proposed a patch adding the excludelist file to
the source repository back when he wrote this wiki page a decade
ago, but it did not get through code review.

thanks
-- PMM

Re: [PATCH 0/3] rSTify SubmitAPatch, TrivialPatches, and SpellCheck wiki pages

[Kashyap Chamarthy]

On Wed, Sep 22, 2021 at 02:05:24PM +0100, Peter Maydell wrote:
> On Wed, 22 Sept 2021 at 13:11, Kashyap Chamarthy  wrote:
> >
> > As of writing this, qemu.org is down, so I've used a one-month old
> > copy[1] of the wiki from 27Aug2021 to do the rST conversion.
> 
> The wiki is now back up, and it says the most recent change to
> any of these 3 pages was May 2021, so there shouldn't be any
> recent changes missed by using that old copy.

Saves a re-spin; thanks for checking. :)

-- 
/kashyap

Re: [PATCH v3 29/35] acpi: arm/virt: convert build_iort() to endian agnostic build_append_FOO() API

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>   * practically rewritten, due to conflicts wiht bypass iommu feature
>
> CC: drjo...@redhat.com
> CC: peter.mayd...@linaro.org
> CC: shannon.zha...@gmail.com
> CC: qemu-...@nongnu.org
> CC: wangxinga...@huawei.com
> CC: Eric Auger 
> ---
>  include/hw/acpi/acpi-defs.h |  71 ---
>  hw/arm/virt-acpi-build.c| 167 
>  2 files changed, 91 insertions(+), 147 deletions(-)
>
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 195f90caf6..6f2f08a9de 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -188,75 +188,4 @@ struct AcpiGenericTimerTable {
>  } QEMU_PACKED;
>  typedef struct AcpiGenericTimerTable AcpiGenericTimerTable;
>  
> -/*
> - * IORT node types
> - */
> -
> -#define ACPI_IORT_NODE_HEADER_DEF   /* Node format common fields */ \
> -uint8_t  type;  \
> -uint16_t length;\
> -uint8_t  revision;  \
> -uint32_t reserved;  \
> -uint32_t mapping_count; \
> -uint32_t mapping_offset;
> -
> -/* Values for node Type above */
> -enum {
> -ACPI_IORT_NODE_ITS_GROUP = 0x00,
> -ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
> -ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
> -ACPI_IORT_NODE_SMMU = 0x03,
> -ACPI_IORT_NODE_SMMU_V3 = 0x04
> -};
> -
> -struct AcpiIortIdMapping {
> -uint32_t input_base;
> -uint32_t id_count;
> -uint32_t output_base;
> -uint32_t output_reference;
> -uint32_t flags;
> -} QEMU_PACKED;
> -typedef struct AcpiIortIdMapping AcpiIortIdMapping;
> -
> -struct AcpiIortMemoryAccess {
> -uint32_t cache_coherency;
> -uint8_t  hints;
> -uint16_t reserved;
> -uint8_t  memory_flags;
> -} QEMU_PACKED;
> -typedef struct AcpiIortMemoryAccess AcpiIortMemoryAccess;
> -
> -struct AcpiIortItsGroup {
> -ACPI_IORT_NODE_HEADER_DEF
> -uint32_t its_count;
> -uint32_t identifiers[];
> -} QEMU_PACKED;
> -typedef struct AcpiIortItsGroup AcpiIortItsGroup;
> -
> -#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE 1
> -
> -struct AcpiIortSmmu3 {
> -ACPI_IORT_NODE_HEADER_DEF
> -uint64_t base_address;
> -uint32_t flags;
> -uint32_t reserved2;
> -uint64_t vatos_address;
> -uint32_t model;
> -uint32_t event_gsiv;
> -uint32_t pri_gsiv;
> -uint32_t gerr_gsiv;
> -uint32_t sync_gsiv;
> -AcpiIortIdMapping id_mapping_array[];
> -} QEMU_PACKED;
> -typedef struct AcpiIortSmmu3 AcpiIortSmmu3;
> -
> -struct AcpiIortRC {
> -ACPI_IORT_NODE_HEADER_DEF
> -AcpiIortMemoryAccess memory_properties;
> -uint32_t ats_attribute;
> -uint32_t pci_segment_number;
> -AcpiIortIdMapping id_mapping_array[];
> -} QEMU_PACKED;
> -typedef struct AcpiIortRC AcpiIortRC;
> -
>  #endif
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index bceb1b3b7e..4c682e7b09 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -240,6 +240,28 @@ static void acpi_dsdt_add_tpm(Aml *scope, 
> VirtMachineState *vms)
>  }
>  #endif
>  
> +#define ID_MAPPING_ENTRY_SIZE 20
> +#define SMMU_V3_ENTRY_SIZE 60
> +#define ROOT_COMPLEX_ENTRY_SIZE 32
> +#define IORT_NODE_OFFSET 48
> +
> +static void build_iort_id_mapping(GArray *table_data, uint32_t input_base,
> +  uint32_t id_count, uint32_t out_ref)
> +{
> +/* Identity RID mapping covering the whole input RID range */
> +build_append_int_noprefix(table_data, input_base, 4); /* Input base */
> +build_append_int_noprefix(table_data, id_count, 4); /* Number of IDs */
> +build_append_int_noprefix(table_data, input_base, 4); /* Output base */
> +build_append_int_noprefix(table_data, out_ref, 4); /* Output Reference */
> +build_append_int_noprefix(table_data, 0, 4); /* Flags */
> +}
> +
> +struct AcpiIortIdMapping {
> +uint32_t input_base;
> +uint32_t id_count;
> +};
> +typedef struct AcpiIortIdMapping AcpiIortIdMapping;
> +
>  /* Build the iort ID mapping to SMMUv3 for a given PCI host bridge */
>  static int
>  iort_host_bridges(Object *obj, void *opaque)
> @@ -281,18 +303,17 @@ static int iort_idmap_compare(gconstpointer a, 
> gconstpointer b)
>  static void
>  build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>  {
> -int i, nb_nodes, rc_mapping_count;
> -AcpiIortIdMapping *idmap;
> -AcpiIortItsGroup *its;
> -AcpiIortSmmu3 *smmu;
> -AcpiIortRC *rc;
> +int i, rc_mapping_count;
>  const uint32_t iort_node_offset = 48;
can be replaced by IORT_NODE_OFFSET now
>  size_t node_size, smmu_offset = 0;
> +AcpiIortIdMapping *idmap;
>  GArray *smmu_idmaps = g_array_new(false, true, 
> sizeof(AcpiIortIdMapping));
>  GArray *its_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
>  
>  AcpiTable table = { .sig = "IORT", .rev = 0, .oem_id = vms->oem_id,
>  .oem_table_id = 

Re: [PATCH v3 34/35] acpi: remove no longer used build_header()

[Eric Auger]

On 9/7/21 4:48 PM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 
Reviewed-by: Eric Auger 

Eric
> ---
>  include/hw/acpi/acpi-defs.h | 25 -
>  include/hw/acpi/aml-build.h |  4 
>  hw/acpi/aml-build.c | 23 ---
>  3 files changed, 52 deletions(-)
> 
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 1a0774edd6..ee733840aa 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -48,31 +48,6 @@ typedef struct AcpiRsdpData {
>  unsigned *xsdt_tbl_offset;
>  } AcpiRsdpData;
>  
> -/* Table structure from Linux kernel (the ACPI tables are under the
> -   BSD license) */
> -
> -
> -#define ACPI_TABLE_HEADER_DEF   /* ACPI common table header */ \
> -uint32_t signature;  /* ACPI signature (4 ASCII characters) */ \
> -uint32_t length; /* Length of table, in bytes, including 
> header */ \
> -uint8_t  revision;   /* ACPI Specification minor version # 
> */ \
> -uint8_t  checksum;   /* To make sum of entire table == 0 */ \
> -uint8_t  oem_id[6] \
> - QEMU_NONSTRING; /* OEM identification */ \
> -uint8_t  oem_table_id[8] \
> - QEMU_NONSTRING; /* OEM table identification */ \
> -uint32_t oem_revision;   /* OEM revision number */ \
> -uint8_t  asl_compiler_id[4] \
> - QEMU_NONSTRING; /* ASL compiler vendor ID */ \
> -uint32_t asl_compiler_revision;  /* ASL compiler revision number */
> -
> -
> -/* ACPI common table header */
> -struct AcpiTableHeader {
> -ACPI_TABLE_HEADER_DEF
> -} QEMU_PACKED;
> -typedef struct AcpiTableHeader AcpiTableHeader;
> -
>  struct AcpiGenericAddress {
>  uint8_t space_id;/* Address space where struct or register 
> exists */
>  uint8_t bit_width;   /* Size in bits of given register */
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 6f3d1de1b1..b8272c239a 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -445,10 +445,6 @@ void acpi_table_begin(AcpiTable *desc, GArray *array);
>   */
>  void acpi_table_end(BIOSLinker *linker, AcpiTable *table);
>  
> -void
> -build_header(BIOSLinker *linker, GArray *table_data,
> - AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
> - const char *oem_id, const char *oem_table_id);
>  void *acpi_data_push(GArray *table_data, unsigned size);
>  unsigned acpi_data_len(GArray *table);
>  void acpi_add_table(GArray *table_offsets, GArray *table_data);
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 4135b385e5..b261ecfbc1 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1754,29 +1754,6 @@ void acpi_table_end(BIOSLinker *linker, AcpiTable 
> *desc)
>  desc->table_offset, table_len, desc->table_offset + checksum_offset);
>  }
>  
> -void
> -build_header(BIOSLinker *linker, GArray *table_data,
> - AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
> - const char *oem_id, const char *oem_table_id)
> -{
> -unsigned tbl_offset = (char *)h - table_data->data;
> -unsigned checksum_offset = (char *)>checksum - table_data->data;
> -memcpy(>signature, sig, 4);
> -h->length = cpu_to_le32(len);
> -h->revision = rev;
> -
> -strpadcpy((char *)h->oem_id, sizeof h->oem_id, oem_id, ' ');
> -strpadcpy((char *)h->oem_table_id, sizeof h->oem_table_id,
> -  oem_table_id, ' ');
> -
> -h->oem_revision = cpu_to_le32(1);
> -memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME8, 4);
> -h->asl_compiler_revision = cpu_to_le32(1);
> -/* Checksum to be filled in by Guest linker */
> -bios_linker_loader_add_checksum(linker, ACPI_BUILD_TABLE_FILE,
> -tbl_offset, len, checksum_offset);
> -}
> -
>  void *acpi_data_push(GArray *table_data, unsigned size)
>  {
>  unsigned off = table_data->len;
>