Re: [PATCH] contrib/vhost-user-blk: Clean up deallocation of VuVirtqElement

[Markus Armbruster]

Raphael Norwitz  writes:

> On Thu, Jun 30, 2022 at 10:52:19AM +0200, Markus Armbruster wrote:
>> We allocate VuVirtqElement with g_malloc() in
>> virtqueue_alloc_element(), but free it with free() in
>> vhost-user-blk.c.  Harmless, but use g_free() anyway.
>> 
>> One of the calls is guarded by a "not null" condition.  Useless,
>> because it cannot be null (it's dereferenced right before), and even
>
> NIT: if it

Yes.

>> it it could be, free() and g_free() do the right thing.  Drop the
>> conditional.
>> 
>
> Reviewed-by: Raphael Norwitz 
>
>> Fixes: Coverity CID 1490290
>> Signed-off-by: Markus Armbruster 
>> ---
>> Not even compile-tested, because I can't figure out how this thing is
>> supposed to be built.  Its initial commit message says "make
>> vhost-user-blk", but that doesn't work anymore.
>> 
>
> make contrib/vhost-user-blk/vhost-user-blk works for me.

Could we use a contrib/README with an explanation what "contrib" means,
and how to build and use the stuff there?

Thanks!

Re: [PATCH v3 14/14] hw/arm/aspeed: Add oby35-cl machine

[Cédric Le Goater]

On 7/1/22 01:06, Peter Delevoryas wrote:

On Thu, Jun 30, 2022 at 06:42:52PM +0200, Cédric Le Goater wrote:

On 6/30/22 18:15, Peter Delevoryas wrote:

On Thu, Jun 30, 2022 at 01:02:54PM +0200, Cédric Le Goater wrote:

On 6/30/22 06:51, Peter Delevoryas wrote:

From: Peter Delevoryas 

The fby35 machine includes 4 server boards, each of which has a "bridge
interconnect" (BIC). This chip abstracts the pinout for the server board
into a single endpoint that the baseboard management controller (BMC)
can talk to using IPMB.

This commit adds a machine for testing the BIC on the server board. It
runs OpenBIC (https://github.com/facebook/openbic) and the server board
is called CraterLake, so the code name is oby35-cl. There's also a
variant of the baseboard that replaces the BMC with a BIC, but that
machine is not included here.

A test image can be built from https://github.com/facebook/openbic using
the instructions in the README.md to build the meta-facebook/yv35-cl
recipe, or retrieved from my Github:

   wget 
https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.17.01/Y35BCL.elf

And you can run this machine with the following command:

   qemu-system-arm -machine oby35-cl -nographic -kernel Y35BCL.elf

It should produce output like the following:

   [00:00:00.005,000]  usb_dc_aspeed: select ep[0x81] as IN endpoint
   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x82] as IN endpoint
   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x1] as IN 
endpoint
   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x2] as IN 
endpoint
   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x3] as OUT endpoint
   *** Booting Zephyr OS build v00.01.05  ***
   Hello, welcome to yv35 craterlake 2022.25.1
   BIC class type(class-1), 1ou present status(0), 2ou present status(0), 
board revision(0x1)
   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
   [init_drive_type] sensor 0x14 post sensor read failed!

   [init_drive_type] sensor 0x30 post sensor read failed!
   [init_drive_type] sensor 0x39 post sensor read failed!
   ipmi_init
   [set_DC_status] gpio number(15) status(0)
   [set_post_status] gpio number(1) status(1)
   uart:~$ [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
odr=0x38, str=0x44

   [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
 invalid
   [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
   [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
odr=0x38, str=0x44

   [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
 invalid
   [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
   uart:~$ BIC Ready

Signed-off-by: Peter Delevoryas 


LGTM.

That said I would prefer to introduce the machine first and then
populate with devices.


Ohh ok, I'll submit the machine definition separately all by itself and then
submit any extra devices like the CPLD or ME afterwards.


I have kept the "full system" in my tree for now :

   cb4481ae1812 aspeed: Add AST2600 (BMC) to fby35  (full system)
   c155bf27d3e7 aspeed: Make aspeed_board_init_flashes public (trivial)
   3f5485fa88b9 

Re: [PATCH v3 10/14] hw/sensor: Add Renesas ISL69259 device model

[Cédric Le Goater]

On 6/30/22 21:16, Titus Rwantare wrote:

On Wed, 29 Jun 2022 at 23:30, Cédric Le Goater  wrote:


On 6/30/22 06:51, Peter Delevoryas wrote:

From: Peter Delevoryas 

This adds the ISL69259, using all the same functionality as the existing
ISL69260 but overriding the IC_DEVICE_ID.

Signed-off-by: Peter Delevoryas 
---
   hw/sensor/isl_pmbus_vr.c | 28 
   1 file changed, 28 insertions(+)

diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
index 799ea9d89e..853d70536f 100644
--- a/hw/sensor/isl_pmbus_vr.c
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -119,6 +119,18 @@ static void raa228000_exit_reset(Object *obj)
   pmdev->pages[0].read_temperature_3 = 0;
   }

+static void isl69259_exit_reset(Object *obj)
+{
+ISLState *s = ISL69260(obj);
+static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2, 0x49, 0x3c};


This looks like an ISLClass attribute to me. In which case, you wouldn't need 
the
reset handler nor the 'ic_device_id_len' field.

Thanks,

C.


I asked for this because, so far, I've been doing all the register
defaults in reset handlers, including read-only registers.
I don't mind either way, but it seemed preferable to have the devices
consistent.


Sure. Fine for me.

Thanks,

C.

Re: [PATCH 3/3] aspeed: sbc: Allow per-machine settings

[Peter Delevoryas]

On Fri, Jul 01, 2022 at 07:23:58AM +0200, Cédric Le Goater wrote:
> On 7/1/22 03:36, Peter Delevoryas wrote:
> > On Tue, Jun 28, 2022 at 05:47:40PM +0200, Cédric Le Goater wrote:
> > > From: Joel Stanley 
> > > 
> > > In order to correctly report secure boot running firmware the values
> > > of certain registers must be set.
> > > 
> > > We don't yet have documentation from ASPEED on what they mean. The
> > > meaning is inferred from u-boot's use of them.
> > > 
> > > Introduce properties so the settings can be configured per-machine.
> > > 
> > > Signed-off-by: Joel Stanley 
> > > Signed-off-by: Cédric Le Goater 
> > > ---
> > >   include/hw/misc/aspeed_sbc.h | 13 
> > >   hw/misc/aspeed_sbc.c | 41 ++--
> > >   2 files changed, 52 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/hw/misc/aspeed_sbc.h b/include/hw/misc/aspeed_sbc.h
> > > index 67e43b53ecc3..405e6782b97a 100644
> > > --- a/include/hw/misc/aspeed_sbc.h
> > > +++ b/include/hw/misc/aspeed_sbc.h
> > > @@ -17,9 +17,22 @@ OBJECT_DECLARE_TYPE(AspeedSBCState, AspeedSBCClass, 
> > > ASPEED_SBC)
> > >   #define ASPEED_SBC_NR_REGS (0x93c >> 2)
> > > +#define QSR_AES BIT(27)
> > > +#define QSR_RSA1024 (0x0 << 12)
> > > +#define QSR_RSA2048 (0x1 << 12)
> > > +#define QSR_RSA3072 (0x2 << 12)
> > > +#define QSR_RSA4096 (0x3 << 12)
> > > +#define QSR_SHA224  (0x0 << 10)
> > > +#define QSR_SHA256  (0x1 << 10)
> > > +#define QSR_SHA384  (0x2 << 10)
> > > +#define QSR_SHA512  (0x3 << 10)
> > > +
> > >   struct AspeedSBCState {
> > >   SysBusDevice parent;
> > > +bool emmc_abr;
> > > +uint32_t signing_settings;
> > > +
> > >   MemoryRegion iomem;
> > >   uint32_t regs[ASPEED_SBC_NR_REGS];
> > > diff --git a/hw/misc/aspeed_sbc.c b/hw/misc/aspeed_sbc.c
> > > index bfa8b81d01c7..3946e6179bdd 100644
> > > --- a/hw/misc/aspeed_sbc.c
> > > +++ b/hw/misc/aspeed_sbc.c
> > > @@ -11,6 +11,7 @@
> > >   #include "qemu/osdep.h"
> > >   #include "qemu/log.h"
> > >   #include "qemu/error-report.h"
> > > +#include "hw/qdev-properties.h"
> > >   #include "hw/misc/aspeed_sbc.h"
> > >   #include "qapi/error.h"
> > >   #include "migration/vmstate.h"
> > > @@ -19,6 +20,27 @@
> > >   #define R_STATUS(0x014 / 4)
> > >   #define R_QSR   (0x040 / 4)
> > > +/* R_STATUS */
> > > +#define ABR_EN  BIT(14) /* Mirrors SCU510[11] */
> > > +#define ABR_IMAGE_SOURCEBIT(13)
> > > +#define SPI_ABR_IMAGE_SOURCEBIT(12)
> > > +#define SB_CRYPTO_KEY_EXP_DONE  BIT(11)
> > > +#define SB_CRYPTO_BUSY  BIT(10)
> > > +#define OTP_WP_EN   BIT(9)
> > > +#define OTP_ADDR_WP_EN  BIT(8)
> > > +#define LOW_SEC_KEY_EN  BIT(7)
> > > +#define SECURE_BOOT_EN  BIT(6)
> > > +#define UART_BOOT_ENBIT(5)
> > > +/* bit 4 reserved*/
> > > +#define OTP_CHARGE_PUMP_READY   BIT(3)
> > > +#define OTP_IDLEBIT(2)
> > > +#define OTP_MEM_IDLEBIT(1)
> > > +#define OTP_COMPARE_STATUS  BIT(0)
> > > +
> > > +/* QSR */
> > > +#define QSR_RSA_MASK   (0x3 << 12)
> > > +#define QSR_HASH_MASK  (0x3 << 10)
> > > +
> > >   static uint64_t aspeed_sbc_read(void *opaque, hwaddr addr, unsigned int 
> > > size)
> > >   {
> > >   AspeedSBCState *s = ASPEED_SBC(opaque);
> > > @@ -80,8 +102,17 @@ static void aspeed_sbc_reset(DeviceState *dev)
> > >   memset(s->regs, 0, sizeof(s->regs));
> > >   /* Set secure boot enabled with RSA4096_SHA256 and enable eMMC ABR 
> > > */
> > > -s->regs[R_STATUS] = 0x44C6;
> > > -s->regs[R_QSR] = 0x07C07C89;
> > > +s->regs[R_STATUS] = OTP_IDLE | OTP_MEM_IDLE;
> > > +
> > > +if (s->emmc_abr) {
> > > +s->regs[R_STATUS] &= ABR_EN;
> > > +}
> > > +
> > > +if (s->signing_settings) {
> > > +s->regs[R_STATUS] &= SECURE_BOOT_EN;
> > > +}
> > > +
> > > +s->regs[R_QSR] = s->signing_settings;
> > >   }
> > >   static void aspeed_sbc_realize(DeviceState *dev, Error **errp)
> > > @@ -105,6 +136,11 @@ static const VMStateDescription vmstate_aspeed_sbc = 
> > > {
> > >   }
> > >   };
> > > +static Property aspeed_sbc_properties[] = {
> > > +DEFINE_PROP_BOOL("emmc-abr", AspeedSBCState, emmc_abr, 0),
> > > +DEFINE_PROP_UINT32("signing-settings", AspeedSBCState, 
> > > signing_settings, 0),
> > > +};
> > 
> > This needs a DEFINE_PROP_END_OF_LIST(), I bisected to this commit in 
> > Cedric's
> > aspeed-7.1 branch.
> 
> Ah you did also ! Sorry I should have told. The problem only showed
> on f35 using clang, and I didn't notice until I pushed the branch
> on gitlab yersterday.

Oh glad you noticed too, it's no problem.

> 
> > Reviewed-by: Peter Delevoryas 
> > Tested-by: Peter Delevoryas 
> 
> I will include the patch in the next PR.

That's great, thanks!

> 
> Thanks,
> 
> C.
> 
> 
> 

Re: [PATCH 3/3] aspeed: sbc: Allow per-machine settings

[Cédric Le Goater]

On 7/1/22 03:36, Peter Delevoryas wrote:

On Tue, Jun 28, 2022 at 05:47:40PM +0200, Cédric Le Goater wrote:

From: Joel Stanley 

In order to correctly report secure boot running firmware the values
of certain registers must be set.

We don't yet have documentation from ASPEED on what they mean. The
meaning is inferred from u-boot's use of them.

Introduce properties so the settings can be configured per-machine.

Signed-off-by: Joel Stanley 
Signed-off-by: Cédric Le Goater 
---
  include/hw/misc/aspeed_sbc.h | 13 
  hw/misc/aspeed_sbc.c | 41 ++--
  2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/hw/misc/aspeed_sbc.h b/include/hw/misc/aspeed_sbc.h
index 67e43b53ecc3..405e6782b97a 100644
--- a/include/hw/misc/aspeed_sbc.h
+++ b/include/hw/misc/aspeed_sbc.h
@@ -17,9 +17,22 @@ OBJECT_DECLARE_TYPE(AspeedSBCState, AspeedSBCClass, 
ASPEED_SBC)
  
  #define ASPEED_SBC_NR_REGS (0x93c >> 2)
  
+#define QSR_AES BIT(27)

+#define QSR_RSA1024 (0x0 << 12)
+#define QSR_RSA2048 (0x1 << 12)
+#define QSR_RSA3072 (0x2 << 12)
+#define QSR_RSA4096 (0x3 << 12)
+#define QSR_SHA224  (0x0 << 10)
+#define QSR_SHA256  (0x1 << 10)
+#define QSR_SHA384  (0x2 << 10)
+#define QSR_SHA512  (0x3 << 10)
+
  struct AspeedSBCState {
  SysBusDevice parent;
  
+bool emmc_abr;

+uint32_t signing_settings;
+
  MemoryRegion iomem;
  
  uint32_t regs[ASPEED_SBC_NR_REGS];

diff --git a/hw/misc/aspeed_sbc.c b/hw/misc/aspeed_sbc.c
index bfa8b81d01c7..3946e6179bdd 100644
--- a/hw/misc/aspeed_sbc.c
+++ b/hw/misc/aspeed_sbc.c
@@ -11,6 +11,7 @@
  #include "qemu/osdep.h"
  #include "qemu/log.h"
  #include "qemu/error-report.h"
+#include "hw/qdev-properties.h"
  #include "hw/misc/aspeed_sbc.h"
  #include "qapi/error.h"
  #include "migration/vmstate.h"
@@ -19,6 +20,27 @@
  #define R_STATUS(0x014 / 4)
  #define R_QSR   (0x040 / 4)
  
+/* R_STATUS */

+#define ABR_EN  BIT(14) /* Mirrors SCU510[11] */
+#define ABR_IMAGE_SOURCEBIT(13)
+#define SPI_ABR_IMAGE_SOURCEBIT(12)
+#define SB_CRYPTO_KEY_EXP_DONE  BIT(11)
+#define SB_CRYPTO_BUSY  BIT(10)
+#define OTP_WP_EN   BIT(9)
+#define OTP_ADDR_WP_EN  BIT(8)
+#define LOW_SEC_KEY_EN  BIT(7)
+#define SECURE_BOOT_EN  BIT(6)
+#define UART_BOOT_ENBIT(5)
+/* bit 4 reserved*/
+#define OTP_CHARGE_PUMP_READY   BIT(3)
+#define OTP_IDLEBIT(2)
+#define OTP_MEM_IDLEBIT(1)
+#define OTP_COMPARE_STATUS  BIT(0)
+
+/* QSR */
+#define QSR_RSA_MASK   (0x3 << 12)
+#define QSR_HASH_MASK  (0x3 << 10)
+
  static uint64_t aspeed_sbc_read(void *opaque, hwaddr addr, unsigned int size)
  {
  AspeedSBCState *s = ASPEED_SBC(opaque);
@@ -80,8 +102,17 @@ static void aspeed_sbc_reset(DeviceState *dev)
  memset(s->regs, 0, sizeof(s->regs));
  
  /* Set secure boot enabled with RSA4096_SHA256 and enable eMMC ABR */

-s->regs[R_STATUS] = 0x44C6;
-s->regs[R_QSR] = 0x07C07C89;
+s->regs[R_STATUS] = OTP_IDLE | OTP_MEM_IDLE;
+
+if (s->emmc_abr) {
+s->regs[R_STATUS] &= ABR_EN;
+}
+
+if (s->signing_settings) {
+s->regs[R_STATUS] &= SECURE_BOOT_EN;
+}
+
+s->regs[R_QSR] = s->signing_settings;
  }
  
  static void aspeed_sbc_realize(DeviceState *dev, Error **errp)

@@ -105,6 +136,11 @@ static const VMStateDescription vmstate_aspeed_sbc = {
  }
  };
  
+static Property aspeed_sbc_properties[] = {

+DEFINE_PROP_BOOL("emmc-abr", AspeedSBCState, emmc_abr, 0),
+DEFINE_PROP_UINT32("signing-settings", AspeedSBCState, signing_settings, 
0),
+};


This needs a DEFINE_PROP_END_OF_LIST(), I bisected to this commit in Cedric's
aspeed-7.1 branch.


Ah you did also ! Sorry I should have told. The problem only showed
on f35 using clang, and I didn't notice until I pushed the branch
on gitlab yersterday.


Reviewed-by: Peter Delevoryas 
Tested-by: Peter Delevoryas 


I will include the patch in the next PR.

Thanks,

C.



+
  static void aspeed_sbc_class_init(ObjectClass *klass, void *data)
  {
  DeviceClass *dc = DEVICE_CLASS(klass);
@@ -112,6 +148,7 @@ static void aspeed_sbc_class_init(ObjectClass *klass, void 
*data)
  dc->realize = aspeed_sbc_realize;
  dc->reset = aspeed_sbc_reset;
  dc->vmsd = _aspeed_sbc;
+device_class_set_props(dc, aspeed_sbc_properties);
  }
  
  static const TypeInfo aspeed_sbc_info = {

--
2.35.3

Re: [PATCH] contrib/vhost-user-blk: Clean up deallocation of VuVirtqElement

[Raphael Norwitz]

On Thu, Jun 30, 2022 at 10:52:19AM +0200, Markus Armbruster wrote:
> We allocate VuVirtqElement with g_malloc() in
> virtqueue_alloc_element(), but free it with free() in
> vhost-user-blk.c.  Harmless, but use g_free() anyway.
> 
> One of the calls is guarded by a "not null" condition.  Useless,
> because it cannot be null (it's dereferenced right before), and even

NIT: if it

> it it could be, free() and g_free() do the right thing.  Drop the
> conditional.
> 

Reviewed-by: Raphael Norwitz 

> Fixes: Coverity CID 1490290
> Signed-off-by: Markus Armbruster 
> ---
> Not even compile-tested, because I can't figure out how this thing is
> supposed to be built.  Its initial commit message says "make
> vhost-user-blk", but that doesn't work anymore.
> 

make contrib/vhost-user-blk/vhost-user-blk works for me.

>  contrib/vhost-user-blk/vhost-user-blk.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/contrib/vhost-user-blk/vhost-user-blk.c 
> b/contrib/vhost-user-blk/vhost-user-blk.c
> index 9cb78ca1d0..d6932a2645 100644
> --- a/contrib/vhost-user-blk/vhost-user-blk.c
> +++ b/contrib/vhost-user-blk/vhost-user-blk.c
> @@ -106,10 +106,7 @@ static void vub_req_complete(VubReq *req)
>req->size + 1);
>  vu_queue_notify(vu_dev, req->vq);
>  
> -if (req->elem) {
> -free(req->elem);
> -}
> -
> +g_free(req->elem);
>  g_free(req);
>  }
>  
> @@ -243,7 +240,7 @@ static int vub_virtio_process_req(VubDev *vdev_blk,
>  /* refer to hw/block/virtio_blk.c */
>  if (elem->out_num < 1 || elem->in_num < 1) {
>  fprintf(stderr, "virtio-blk request missing headers\n");
> -free(elem);
> +g_free(elem);
>  return -1;
>  }
>  
> @@ -325,7 +322,7 @@ static int vub_virtio_process_req(VubDev *vdev_blk,
>  return 0;
>  
>  err:
> -free(elem);
> +g_free(elem);
>  g_free(req);
>  return -1;
>  }
> -- 
> 2.35.3
> 

Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests)

[Thomas Huth]

On 28/06/2022 15.53, Ani Sinha wrote:



On Tue, Jun 28, 2022 at 19:15 Peter Maydell > wrote:


On Tue, 28 Jun 2022 at 14:23, Ani Sinha mailto:a...@anisinha.ca>> wrote:
 > On Tue, Jun 28, 2022 at 6:25 PM Daniel P. Berrangé
mailto:berra...@redhat.com>> wrote:
 > > This proposed biosbits test also involves a considerable download.
 >
 > I do not think 50 MB is "considerable" . Last time I tried to run
 > avocado tests, my laptop ran out of disk space!

I think 50MB is pretty big. It might be smaller than some other
avocado tests, but it's not exactly the "no binary involved"
that most qtests are.


Well bios-tables-test uses the binary blobs of the acpi tables. Only 
difference is that in this case, we could maintain them within  the qemu 
tree. In this case the blob in slightly larger and comes from a third party. 
That is the difference.


"slightly larger" ... it apparently contains already a complete grub and 
python 2.7 interpreter ... I'd consider that as *much* larger than the ~ 2k 
loc bios-tables-test ;-)



Very few 'make check' tests even run code in the guest.

So bits test is similar here. It runs code in the guest vm.


The qtests that run some TCG code only use some few lines of code. The tests 
that run third party firmware images are the avocado tests.



There are definitely some awkwardnesses with 'check-avocado',
but we should work on fixing those, not use them as a reason
to refuse to put tests into the avocado tests if that's where
they fit best.

I think this test fits best in the qtrst not with the integration test 
framework.


I disagree. Third party binary blob tests are certainly nothing for the 
qtest directory.


Very few path developers will ever run it and wrote new tests for 
it if we have it there. I would be terribly discouraged if that’s where this 
test landed.


I see your point - I'm also hardly ever running whole "make check-avocado" 
since it's too slow/fat/broken. But using this as a reason to stick your 
test into the qtest framework also does not work/scale: Being one of the 
s390x maintainers - What if I now also want my s390x related tests to be 
executed by everybody? The kernel + initrd images from 
tests/avocado/machine_s390_ccw_virtio.py are also not that big, ca. 50 MiB 
each. Should I now move that out of the avocade directory, too, and force 
everybody to consume it via a submodule? Then who's next? QEMU has 21 target 
architectures, if every maintainers adds a 50 MiB test to the tree, we're at 
more than a gigabyte of data already that you'd have to download before you 
were able to run "make check". This simply does not scale.


So the avocado framework is currently still the best place that we have for 
such tests. You just have to get used to consume it via "tags" instead of 
running the whole "make check-avocado" suite. For example, being a s390x 
maintainer, I'm only running:


 make check-venv
 ./tests/venv/bin/avocado run -t arch:s390x tests/avocado/

and that finishes within some few minutes and only downloads some few 
hundreds of megabytes. You could do something similar with acpi. You could 
even wrap it in a "make check-avocado-acpi" target if you don't like to 
execute avocado directly.


I even wouldn't mind if you put your python stuff in a new directory like 
tests/pytests/ for example, as long as it downloads your binaries separately 
- as I wrote in another mail, the avocado framework rather looks like an 
oddball in our test framework nowadays since it uses a separate test runner 
and not the meson test harness, so having a new approach for python-based 
tests is maybe even a good idea. I just really want to avoid that this goes 
into tests/qtest (since it really does not belong there), and please don't 
add more external stuff via git submodules, that's really the wrong approach 
for this.


 Thomas

Re: [PULL 00/14] (Mostly) build system changes for 2022-06-24

[Paolo Bonzini]

Il ven 1 lug 2022, 02:26 Richard Henderson 
ha scritto:

> >> Does that mean that Ubuntu installs GCC without a 32-bit libgcc.a?
> >
> > I think they package it in a separate package, eg lib32gcc-9-dev
> > (adjust package name to suit gcc version).
>
> It's there, as Peter says, but it's not installed with the build-essential
> meta-package,
> and the crossbuild-essential-i386 package installs a different libgcc.
>

Ok I will try using ld -r to detect the presence of libgcc.

Paolo


>
> r~
>
>

Re: Why we should avoid new submodules if possible

[Thomas Huth]

On 29/06/2022 08.28, Ani Sinha wrote:

On Tue, Jun 28, 2022 at 11:30 PM Michael S. Tsirkin  wrote:


On Tue, Jun 28, 2022 at 05:15:05PM +0100, Daniel P. Berrangé wrote:

FYI, the reason much of this is intentionally NOT under the /qemu-project
gitlab namespace is that we did not want to be responsible for distributing
arbitrary binary blobs/images. That in turn makes the QEMU project responsible
for license compliance, which is non-trivial todo correctly for much of this
stuff. As such it is highly desirable to delegate both the hosting the
binaries and source to the third party who builds it.


This might be understadable for random guest OS images which include tons of 
stuff
and are thus hard to audit.  But not to biosbits which has its own
license (more or less bsd) + gpl for grub:
https://github.com/biosbits/bits/blob/master/COPYING


These are all the dependencies:
https://github.com/biosbits/bits/tree/master/deps

We can go through the licenses for each and make a determination. The
audit would be lost easier because there is a bounded number of
dependencies for bits.


That's quite a bit of dependencies already ... I don't think that we should 
put the burden of keeping up with the licenses of those projects to the QEMU 
project. So just make sure that the binaries are available somewhere and 
then include your test into the avocado framework or download via curl/wget 
as suggested in other mails.


 Thomas

[PATCH] qga: add command 'guest-get-cpustats'

[zhenwei pi]

A vCPU thread always reaches 100% utilization when:
- guest uses idle=poll
- disable HLT vm-exit
- enable MWAIT

Add new guest agent command 'guest-get-cpustats' to get guest CPU
statistics, we can know the guest workload and how busy the CPU is.

Signed-off-by: zhenwei pi 
---
 qga/commands-posix.c | 72 
 qga/commands-win32.c |  6 
 qga/qapi-schema.json | 49 ++
 3 files changed, 127 insertions(+)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 0469dc409d..2847023876 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -2893,6 +2893,73 @@ GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error 
**errp)
 return guest_get_diskstats(errp);
 }
 
+GuestCpuStatsList *qmp_guest_get_cpustats(Error **errp)
+{
+GuestCpuStatsList *head = NULL, **tail = 
+const char *cpustats = "/proc/stat";
+FILE *fp;
+size_t n;
+char *line = NULL;
+
+fp = fopen(cpustats, "r");
+if (fp  == NULL) {
+error_setg_errno(errp, errno, "open(\"%s\")", cpustats);
+return NULL;
+}
+
+while (getline(, , fp) != -1) {
+GuestCpuStats *cpustat = NULL;
+int i;
+unsigned long user, system, idle, iowait, irq, softirq, steal, guest;
+unsigned long nice, guest_nice;
+char name[64];
+
+i = sscanf(line, "%s %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu",
+   name, , , , , , , ,
+   , , _nice);
+
+/* drop "cpu 1 2 3 ...", get "cpuX 1 2 3 ..." only */
+if (strncmp(name, "cpu", 3) || (name[3] == '\0')) {
+continue;
+}
+
+cpustat = g_new0(GuestCpuStats, 1);
+cpustat->cpu = atoi([3]);
+cpustat->has_user = true;
+cpustat->user = user * 10;
+cpustat->has_system = true;
+cpustat->system = system * 10;
+cpustat->has_idle = true;
+cpustat->idle = idle * 10;
+
+/* Linux version >= 2.6 */
+if (i > 5) {
+cpustat->has_iowait = true;
+cpustat->iowait = iowait * 10;
+cpustat->has_irq = true;
+cpustat->irq = irq * 10;
+cpustat->has_softirq = true;
+cpustat->softirq = softirq * 10;
+}
+
+if (i > 8) {
+cpustat->has_steal = true;
+cpustat->steal = steal * 10;
+}
+
+if (i > 9) {
+cpustat->has_guest = true;
+cpustat->guest = guest * 10;
+}
+
+QAPI_LIST_APPEND(tail, cpustat);
+}
+
+free(line);
+fclose(fp);
+return head;
+}
+
 #else /* defined(__linux__) */
 
 void qmp_guest_suspend_disk(Error **errp)
@@ -3247,6 +3314,11 @@ GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error 
**errp)
 return NULL;
 }
 
+GuestCpuStatsList *qmp_guest_get_cpustats(Error **errp)
+{
+error_setg(errp, QERR_UNSUPPORTED);
+return NULL;
+}
 
 #endif /* CONFIG_FSFREEZE */
 
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 36f94c0f9c..7ed7664715 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -2543,3 +2543,9 @@ GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error 
**errp)
 error_setg(errp, QERR_UNSUPPORTED);
 return NULL;
 }
+
+GuestCpuStatsList *qmp_guest_get_cpustats(Error **errp)
+{
+error_setg(errp, QERR_UNSUPPORTED);
+return NULL;
+}
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index 9fa20e791b..4859c887b2 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -1576,3 +1576,52 @@
 { 'command': 'guest-get-diskstats',
   'returns': ['GuestDiskStatsInfo']
 }
+
+##
+# @GuestCpuStats:
+#
+# Get statistics of each CPU in millisecond.
+#
+# @cpu: CPU index in guest OS
+#
+# @user: CPU time of user mode
+#
+# @system: CPU time of system mode
+#
+# @idle: CPU time of idle state
+#
+# @iowait: CPU time waiting IO
+#
+# @irq: CPU time of hardware interrupt
+#
+# @softirq: CPU time of soft interrupt
+#
+# @steal: CPU time stolen by host
+#
+# @guest: CPU time of running guest mode
+#
+# Since: 7.1
+##
+{ 'struct': 'GuestCpuStats',
+  'data': {'cpu': 'int',
+   '*user': 'uint64',
+   '*system': 'uint64',
+   '*idle': 'uint64',
+   '*iowait': 'uint64',
+   '*irq': 'uint64',
+   '*softirq': 'uint64',
+   '*steal': 'uint64',
+   '*guest': 'uint64'
+   } }
+
+##
+# @guest-get-cpustats:
+#
+# Retrieve information about CPU stats.
+# Returns: List of CPU stats of guest.
+#
+# Since: 7.1
+##
+{ 'command': 'guest-get-cpustats',
+  'returns': ['GuestCpuStats']
+}
-- 
2.20.1

[PATCH] hw/intc: loongarch_pch_msi: Fix msi vector convertion

[Mao Bibo]

Loongarch pch msi intc connects to extioi controller, the range of irq number
is 64-255. Here adds irqbase property for loongarch pch msi controller, we can
get irq offset from view of pch_msi controller with the method:
  msi vector (from view of upper extioi intc) - irqbase

Signed-off-by: Mao Bibo 
---
 hw/intc/loongarch_pch_msi.c | 22 --
 hw/loongarch/loongson3.c|  1 +
 include/hw/intc/loongarch_pch_msi.h |  2 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/hw/intc/loongarch_pch_msi.c b/hw/intc/loongarch_pch_msi.c
index 74bcdbdb48..b36d6d76e4 100644
--- a/hw/intc/loongarch_pch_msi.c
+++ b/hw/intc/loongarch_pch_msi.c
@@ -23,9 +23,14 @@ static uint64_t loongarch_msi_mem_read(void *opaque, hwaddr 
addr, unsigned size)
 static void loongarch_msi_mem_write(void *opaque, hwaddr addr,
 uint64_t val, unsigned size)
 {
-LoongArchPCHMSI *s = LOONGARCH_PCH_MSI(opaque);
-int irq_num = val & 0xff;
+LoongArchPCHMSI *s = (LoongArchPCHMSI *)opaque;
+int irq_num;
 
+/*
+ * vector number is irq number from upper extioi intc
+ * need subtract irq base to get msi vector offset
+ */
+irq_num = (val & 0xff) - s->irq_base;
 trace_loongarch_msi_set_irq(irq_num);
 assert(irq_num < PCH_MSI_IRQ_NUM);
 qemu_set_irq(s->pch_msi_irq[irq_num], 1);
@@ -58,11 +63,24 @@ static void loongarch_pch_msi_init(Object *obj)
 qdev_init_gpio_in(DEVICE(obj), pch_msi_irq_handler, PCH_MSI_IRQ_NUM);
 }
 
+static Property loongarch_msi_properties[] = {
+DEFINE_PROP_UINT32("msi_irq_base", LoongArchPCHMSI, irq_base, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void loongarch_pch_msi_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+device_class_set_props(dc, loongarch_msi_properties);
+}
+
 static const TypeInfo loongarch_pch_msi_info = {
 .name  = TYPE_LOONGARCH_PCH_MSI,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(LoongArchPCHMSI),
 .instance_init = loongarch_pch_msi_init,
+.class_init= loongarch_pch_msi_class_init,
 };
 
 static void loongarch_pch_msi_register_types(void)
diff --git a/hw/loongarch/loongson3.c b/hw/loongarch/loongson3.c
index bd20ebbb78..403dd91e11 100644
--- a/hw/loongarch/loongson3.c
+++ b/hw/loongarch/loongson3.c
@@ -267,6 +267,7 @@ static void loongarch_irq_init(LoongArchMachineState *lams)
 }
 
 pch_msi = qdev_new(TYPE_LOONGARCH_PCH_MSI);
+qdev_prop_set_uint32(pch_msi, "msi_irq_base", PCH_MSI_IRQ_START);
 d = SYS_BUS_DEVICE(pch_msi);
 sysbus_realize_and_unref(d, _fatal);
 sysbus_mmio_map(d, 0, LS7A_PCH_MSI_ADDR_LOW);
diff --git a/include/hw/intc/loongarch_pch_msi.h 
b/include/hw/intc/loongarch_pch_msi.h
index f668bfca7a..6d67560dea 100644
--- a/include/hw/intc/loongarch_pch_msi.h
+++ b/include/hw/intc/loongarch_pch_msi.h
@@ -17,4 +17,6 @@ struct LoongArchPCHMSI {
 SysBusDevice parent_obj;
 qemu_irq pch_msi_irq[PCH_MSI_IRQ_NUM];
 MemoryRegion msi_mmio;
+/* irq base passed to upper extioi intc */
+unsigned int irq_base;
 };
-- 
2.27.0

[PATCH] include/qemu/host-utils: Remove unused code in the *_overflow wrappers

[Thomas Huth]

According to commit cec07c0b612975 the code in the #else paths was required
for GCC < 5.0 and Clang < 3.8. We don't support such old compilers
at all anymore, so we can remove these lines now. We keep the wrapper
function, though, since they are easier to read and help to make sure that
the parameters have the right types.

Signed-off-by: Thomas Huth 
---
 include/qemu/host-utils.h | 65 ---
 1 file changed, 65 deletions(-)

diff --git a/include/qemu/host-utils.h b/include/qemu/host-utils.h
index bc743f5e32..29f3a99878 100644
--- a/include/qemu/host-utils.h
+++ b/include/qemu/host-utils.h
@@ -376,12 +376,7 @@ static inline uint64_t uabs64(int64_t v)
  */
 static inline bool sadd32_overflow(int32_t x, int32_t y, int32_t *ret)
 {
-#if __has_builtin(__builtin_add_overflow) || __GNUC__ >= 5
 return __builtin_add_overflow(x, y, ret);
-#else
-*ret = x + y;
-return ((*ret ^ x) & ~(x ^ y)) < 0;
-#endif
 }
 
 /**
@@ -394,12 +389,7 @@ static inline bool sadd32_overflow(int32_t x, int32_t y, 
int32_t *ret)
  */
 static inline bool sadd64_overflow(int64_t x, int64_t y, int64_t *ret)
 {
-#if __has_builtin(__builtin_add_overflow) || __GNUC__ >= 5
 return __builtin_add_overflow(x, y, ret);
-#else
-*ret = x + y;
-return ((*ret ^ x) & ~(x ^ y)) < 0;
-#endif
 }
 
 /**
@@ -412,12 +402,7 @@ static inline bool sadd64_overflow(int64_t x, int64_t y, 
int64_t *ret)
  */
 static inline bool uadd32_overflow(uint32_t x, uint32_t y, uint32_t *ret)
 {
-#if __has_builtin(__builtin_add_overflow) || __GNUC__ >= 5
 return __builtin_add_overflow(x, y, ret);
-#else
-*ret = x + y;
-return *ret < x;
-#endif
 }
 
 /**
@@ -430,12 +415,7 @@ static inline bool uadd32_overflow(uint32_t x, uint32_t y, 
uint32_t *ret)
  */
 static inline bool uadd64_overflow(uint64_t x, uint64_t y, uint64_t *ret)
 {
-#if __has_builtin(__builtin_add_overflow) || __GNUC__ >= 5
 return __builtin_add_overflow(x, y, ret);
-#else
-*ret = x + y;
-return *ret < x;
-#endif
 }
 
 /**
@@ -449,12 +429,7 @@ static inline bool uadd64_overflow(uint64_t x, uint64_t y, 
uint64_t *ret)
  */
 static inline bool ssub32_overflow(int32_t x, int32_t y, int32_t *ret)
 {
-#if __has_builtin(__builtin_sub_overflow) || __GNUC__ >= 5
 return __builtin_sub_overflow(x, y, ret);
-#else
-*ret = x - y;
-return ((*ret ^ x) & (x ^ y)) < 0;
-#endif
 }
 
 /**
@@ -468,12 +443,7 @@ static inline bool ssub32_overflow(int32_t x, int32_t y, 
int32_t *ret)
  */
 static inline bool ssub64_overflow(int64_t x, int64_t y, int64_t *ret)
 {
-#if __has_builtin(__builtin_sub_overflow) || __GNUC__ >= 5
 return __builtin_sub_overflow(x, y, ret);
-#else
-*ret = x - y;
-return ((*ret ^ x) & (x ^ y)) < 0;
-#endif
 }
 
 /**
@@ -487,12 +457,7 @@ static inline bool ssub64_overflow(int64_t x, int64_t y, 
int64_t *ret)
  */
 static inline bool usub32_overflow(uint32_t x, uint32_t y, uint32_t *ret)
 {
-#if __has_builtin(__builtin_sub_overflow) || __GNUC__ >= 5
 return __builtin_sub_overflow(x, y, ret);
-#else
-*ret = x - y;
-return x < y;
-#endif
 }
 
 /**
@@ -506,12 +471,7 @@ static inline bool usub32_overflow(uint32_t x, uint32_t y, 
uint32_t *ret)
  */
 static inline bool usub64_overflow(uint64_t x, uint64_t y, uint64_t *ret)
 {
-#if __has_builtin(__builtin_sub_overflow) || __GNUC__ >= 5
 return __builtin_sub_overflow(x, y, ret);
-#else
-*ret = x - y;
-return x < y;
-#endif
 }
 
 /**
@@ -524,13 +484,7 @@ static inline bool usub64_overflow(uint64_t x, uint64_t y, 
uint64_t *ret)
  */
 static inline bool smul32_overflow(int32_t x, int32_t y, int32_t *ret)
 {
-#if __has_builtin(__builtin_mul_overflow) || __GNUC__ >= 5
 return __builtin_mul_overflow(x, y, ret);
-#else
-int64_t z = (int64_t)x * y;
-*ret = z;
-return *ret != z;
-#endif
 }
 
 /**
@@ -543,14 +497,7 @@ static inline bool smul32_overflow(int32_t x, int32_t y, 
int32_t *ret)
  */
 static inline bool smul64_overflow(int64_t x, int64_t y, int64_t *ret)
 {
-#if __has_builtin(__builtin_mul_overflow) || __GNUC__ >= 5
 return __builtin_mul_overflow(x, y, ret);
-#else
-uint64_t hi, lo;
-muls64(, , x, y);
-*ret = lo;
-return hi != ((int64_t)lo >> 63);
-#endif
 }
 
 /**
@@ -563,13 +510,7 @@ static inline bool smul64_overflow(int64_t x, int64_t y, 
int64_t *ret)
  */
 static inline bool umul32_overflow(uint32_t x, uint32_t y, uint32_t *ret)
 {
-#if __has_builtin(__builtin_mul_overflow) || __GNUC__ >= 5
 return __builtin_mul_overflow(x, y, ret);
-#else
-uint64_t z = (uint64_t)x * y;
-*ret = z;
-return z > UINT32_MAX;
-#endif
 }
 
 /**
@@ -582,13 +523,7 @@ static inline bool umul32_overflow(uint32_t x, uint32_t y, 
uint32_t *ret)
  */
 static inline bool umul64_overflow(uint64_t x, uint64_t y, uint64_t *ret)
 {
-#if __has_builtin(__builtin_mul_overflow) || __GNUC__ >= 5
 return __builtin_mul_overflow(x, y, ret);
-#else
-uint64_t hi;
-mulu64(ret, , x, y);
-return hi != 0;
-#endif
 }
 
 

Re: [PATCH 5/5] multifd: Only sync once each full round of memory

[Leonardo Brás]

Hello Juan,

On Tue, 2022-06-21 at 16:05 +0200, Juan Quintela wrote:
> We need to add a new flag to mean to sync at that point.
> Notice that we still synchronize at the end of setup and at the end of
> complete stages.
> 
> Signed-off-by: Juan Quintela 
> ---
>  migration/migration.c |  2 +-
>  migration/ram.c   | 42 ++
>  2 files changed, 31 insertions(+), 13 deletions(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 3f79df0b70..6627787fc2 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -4283,7 +4283,7 @@ static Property migration_properties[] = {
>    DEFAULT_MIGRATE_ANNOUNCE_STEP),
>  /* We will change to false when we introduce the new mechanism */
>  DEFINE_PROP_BOOL("multifd-sync-each-iteration", MigrationState,
> -  multifd_sync_each_iteration, true),
> +  multifd_sync_each_iteration, false),
>  
>  /* Migration capabilities */
>  DEFINE_PROP_MIG_CAP("x-xbzrle", MIGRATION_CAPABILITY_XBZRLE),
> diff --git a/migration/ram.c b/migration/ram.c
> index 2c7289edad..6792986565 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -81,6 +81,7 @@
>  #define RAM_SAVE_FLAG_XBZRLE   0x40
>  /* 0x80 is reserved in migration.h start with 0x100 next */
>  #define RAM_SAVE_FLAG_COMPRESS_PAGE    0x100
> +#define RAM_SAVE_FLAG_MULTIFD_SYNC 0x200
>  
>  XBZRLECacheStats xbzrle_counters;
>  
> @@ -1482,6 +1483,7 @@ retry:
>   * associated with the search process.
>   *
>   * Returns:
> + *    <0: An error happened
>   * 0: no page found, give up
>   * 1: no page found, retry
>   * 2: page found
> @@ -1510,6 +1512,13 @@ static int find_dirty_block(RAMState *rs,
> PageSearchStatus *pss)
>  pss->page = 0;
>  pss->block = QLIST_NEXT_RCU(pss->block, next);
>  if (!pss->block) {
> +    if (!migrate_multifd_sync_each_iteration()) {
> +    int ret = multifd_send_sync_main(rs->f);
> +    if (ret < 0) {
> +    return ret;
> +    }
> +    qemu_put_be64(rs->f, RAM_SAVE_FLAG_MULTIFD_SYNC);
> +    }
>  /*
>   * If memory migration starts over, we will meet a dirtied page
>   * which may still exists in compression threads's ring, so we
> @@ -2273,7 +2282,8 @@ static int ram_find_and_save_block(RAMState *rs)
>  if (!get_queued_page(rs, )) {
>  /* priority queue empty, so just search for something dirty */
>  int res = find_dirty_block(rs, );
> -    if (res == 0) {
> +    if (res <= 0) {
> +    pages = res;
>  break;
>  } else if (res == 1)
>  continue;
> @@ -2943,11 +2953,13 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
>  ram_control_before_iterate(f, RAM_CONTROL_SETUP);
>  ram_control_after_iterate(f, RAM_CONTROL_SETUP);
>  
> -    if (migrate_multifd_sync_each_iteration()) {
> -    ret =  multifd_send_sync_main(f);
> -    if (ret < 0) {
> -    return ret;
> -    }

(1) IIUC, the above lines were changed in 2/5 to be reverted now.
Is that correct? was it expected?

> +    ret =  multifd_send_sync_main(f);
> +    if (ret < 0) {
> +    return ret;
> +    }
> +
> +    if (!migrate_multifd_sync_each_iteration()) {
> +    qemu_put_be64(f, RAM_SAVE_FLAG_MULTIFD_SYNC);

(2) I have done some testing with this patchset (because of MSG_ZEROCOPY) and it
seems this part here is breaking migration from this build to 'older' builds
(same commits except for this patchset):

qemu-system-x86_64: Unknown combination of migration flags: 0x200
qemu-system-x86_64: error while loading state section id 2(ram)
qemu-system-x86_64: load of migration failed: Invalid argument

Which makes sense, since there is no RAM_SAVE_FLAG_MULTIFD_SYNC in older
versions. Is this expected / desired ?

Strange enough, it seems to be breaking even with this set in the sending part: 
--global migration.multifd-sync-each-iteration=on

Was the idea of this config to allow migration to older qemu builds?


>  }
>  qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
>  qemu_fflush(f);
> @@ -3127,13 +3139,14 @@ static int ram_save_complete(QEMUFile *f, void
> *opaque)
>  return ret;
>  }
>  
> -    if (migrate_multifd_sync_each_iteration()) {
> -    ret = multifd_send_sync_main(rs->f);
> -    if (ret < 0) {
> -    return ret;
> -    }
> +    ret = multifd_send_sync_main(rs->f);
> +    if (ret < 0) {
> +    return ret;
>  }

(3) Same as (1)

>  
> +    if (migrate_multifd_sync_each_iteration()) {
> +    qemu_put_be64(f, RAM_SAVE_FLAG_MULTIFD_SYNC);
> +    }
>  qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
>  qemu_fflush(f);
>  
> @@ -3800,7 +3813,9 @@ int ram_load_postcopy(QEMUFile *f)
>  }
>  

Re: [PATCH 3/3] gitlab: honour QEMU_CI variable in edk2/opensbi jobs

[Richard Henderson]

On 6/29/22 22:36, Daniel P. Berrangé wrote:

+# In forks, if QEMU_CI=1 is set, then create manual job
+# if the branch/tag starts with 'edk2'
+- if: '$QEMU_CI == "1" && $CI_PROJECT_NAMESPACE != "qemu-project" && 
$CI_COMMIT_REF_NAME =~ /^edk2/'
+  when: manual
+
+# In forks, if QEMU_CI=1 is set, then create manual job
+# if last commit msg contains 'EDK2' (case insensitive)
+- if: '$QEMU_CI == "1" && $CI_PROJECT_NAMESPACE != "qemu-project" && 
$CI_COMMIT_MESSAGE =~ /edk2/i'
+  when: on_success


manual on last line?


r~

Re: [PATCH 2/3] gitlab: tweak comments in edk2/opensbi jobs

[Richard Henderson]

On 6/29/22 22:36, Daniel P. Berrangé wrote:

Get rid of comments stating the obvious and re-arrange remaining
comments. The opensbi split of rules for file matches is also
merged into one rule.

Signed-off-by: Daniel P. Berrangé
---
  .gitlab-ci.d/edk2.yml| 14 --
  .gitlab-ci.d/opensbi.yml | 15 ---
  2 files changed, 16 insertions(+), 13 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 1/3] gitlab: normalize indentation in edk2/opensbi rules

[Richard Henderson]

On 6/29/22 22:36, Daniel P. Berrangé wrote:

The edk2/opensbi gitlab CI config was using single space indents
which is not consistent with the rest of the gitlab CI config
files.

Signed-off-by: Daniel P. Berrangé
---
  .gitlab-ci.d/edk2.yml| 108 +++---
  .gitlab-ci.d/opensbi.yml | 110 +++
  2 files changed, 109 insertions(+), 109 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH] scripts: check if .git exists before checking submodule status

[Richard Henderson]

On 6/29/22 21:38, Daniel P. Berrangé wrote:

Currently we check status of each submodule, before actually checking
if we're in a git repo. These status commands will all fail, but we
are hiding their output so we don't see it currently.

Signed-off-by: Daniel P. Berrangé
---
  scripts/git-submodule.sh | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 3/3] aspeed: sbc: Allow per-machine settings

[Peter Delevoryas]

On Tue, Jun 28, 2022 at 05:47:40PM +0200, Cédric Le Goater wrote:
> From: Joel Stanley 
> 
> In order to correctly report secure boot running firmware the values
> of certain registers must be set.
> 
> We don't yet have documentation from ASPEED on what they mean. The
> meaning is inferred from u-boot's use of them.
> 
> Introduce properties so the settings can be configured per-machine.
> 
> Signed-off-by: Joel Stanley 
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/misc/aspeed_sbc.h | 13 
>  hw/misc/aspeed_sbc.c | 41 ++--
>  2 files changed, 52 insertions(+), 2 deletions(-)
> 
> diff --git a/include/hw/misc/aspeed_sbc.h b/include/hw/misc/aspeed_sbc.h
> index 67e43b53ecc3..405e6782b97a 100644
> --- a/include/hw/misc/aspeed_sbc.h
> +++ b/include/hw/misc/aspeed_sbc.h
> @@ -17,9 +17,22 @@ OBJECT_DECLARE_TYPE(AspeedSBCState, AspeedSBCClass, 
> ASPEED_SBC)
>  
>  #define ASPEED_SBC_NR_REGS (0x93c >> 2)
>  
> +#define QSR_AES BIT(27)
> +#define QSR_RSA1024 (0x0 << 12)
> +#define QSR_RSA2048 (0x1 << 12)
> +#define QSR_RSA3072 (0x2 << 12)
> +#define QSR_RSA4096 (0x3 << 12)
> +#define QSR_SHA224  (0x0 << 10)
> +#define QSR_SHA256  (0x1 << 10)
> +#define QSR_SHA384  (0x2 << 10)
> +#define QSR_SHA512  (0x3 << 10)
> +
>  struct AspeedSBCState {
>  SysBusDevice parent;
>  
> +bool emmc_abr;
> +uint32_t signing_settings;
> +
>  MemoryRegion iomem;
>  
>  uint32_t regs[ASPEED_SBC_NR_REGS];
> diff --git a/hw/misc/aspeed_sbc.c b/hw/misc/aspeed_sbc.c
> index bfa8b81d01c7..3946e6179bdd 100644
> --- a/hw/misc/aspeed_sbc.c
> +++ b/hw/misc/aspeed_sbc.c
> @@ -11,6 +11,7 @@
>  #include "qemu/osdep.h"
>  #include "qemu/log.h"
>  #include "qemu/error-report.h"
> +#include "hw/qdev-properties.h"
>  #include "hw/misc/aspeed_sbc.h"
>  #include "qapi/error.h"
>  #include "migration/vmstate.h"
> @@ -19,6 +20,27 @@
>  #define R_STATUS(0x014 / 4)
>  #define R_QSR   (0x040 / 4)
>  
> +/* R_STATUS */
> +#define ABR_EN  BIT(14) /* Mirrors SCU510[11] */
> +#define ABR_IMAGE_SOURCEBIT(13)
> +#define SPI_ABR_IMAGE_SOURCEBIT(12)
> +#define SB_CRYPTO_KEY_EXP_DONE  BIT(11)
> +#define SB_CRYPTO_BUSY  BIT(10)
> +#define OTP_WP_EN   BIT(9)
> +#define OTP_ADDR_WP_EN  BIT(8)
> +#define LOW_SEC_KEY_EN  BIT(7)
> +#define SECURE_BOOT_EN  BIT(6)
> +#define UART_BOOT_ENBIT(5)
> +/* bit 4 reserved*/
> +#define OTP_CHARGE_PUMP_READY   BIT(3)
> +#define OTP_IDLEBIT(2)
> +#define OTP_MEM_IDLEBIT(1)
> +#define OTP_COMPARE_STATUS  BIT(0)
> +
> +/* QSR */
> +#define QSR_RSA_MASK   (0x3 << 12)
> +#define QSR_HASH_MASK  (0x3 << 10)
> +
>  static uint64_t aspeed_sbc_read(void *opaque, hwaddr addr, unsigned int size)
>  {
>  AspeedSBCState *s = ASPEED_SBC(opaque);
> @@ -80,8 +102,17 @@ static void aspeed_sbc_reset(DeviceState *dev)
>  memset(s->regs, 0, sizeof(s->regs));
>  
>  /* Set secure boot enabled with RSA4096_SHA256 and enable eMMC ABR */
> -s->regs[R_STATUS] = 0x44C6;
> -s->regs[R_QSR] = 0x07C07C89;
> +s->regs[R_STATUS] = OTP_IDLE | OTP_MEM_IDLE;
> +
> +if (s->emmc_abr) {
> +s->regs[R_STATUS] &= ABR_EN;
> +}
> +
> +if (s->signing_settings) {
> +s->regs[R_STATUS] &= SECURE_BOOT_EN;
> +}
> +
> +s->regs[R_QSR] = s->signing_settings;
>  }
>  
>  static void aspeed_sbc_realize(DeviceState *dev, Error **errp)
> @@ -105,6 +136,11 @@ static const VMStateDescription vmstate_aspeed_sbc = {
>  }
>  };
>  
> +static Property aspeed_sbc_properties[] = {
> +DEFINE_PROP_BOOL("emmc-abr", AspeedSBCState, emmc_abr, 0),
> +DEFINE_PROP_UINT32("signing-settings", AspeedSBCState, signing_settings, 
> 0),
> +};

This needs a DEFINE_PROP_END_OF_LIST(), I bisected to this commit in Cedric's
aspeed-7.1 branch.

Reviewed-by: Peter Delevoryas 
Tested-by: Peter Delevoryas 

> +
>  static void aspeed_sbc_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -112,6 +148,7 @@ static void aspeed_sbc_class_init(ObjectClass *klass, 
> void *data)
>  dc->realize = aspeed_sbc_realize;
>  dc->reset = aspeed_sbc_reset;
>  dc->vmsd = _aspeed_sbc;
> +device_class_set_props(dc, aspeed_sbc_properties);
>  }
>  
>  static const TypeInfo aspeed_sbc_info = {
> -- 
> 2.35.3
> 
> 

Re: [PATCH v2] io_uring: fix short read slow path

[Dominique Martinet]

Dominique Martinet wrote on Fri, Jul 01, 2022 at 07:52:31AM +0900:
> Stefano Garzarella wrote on Thu, Jun 30, 2022 at 05:49:21PM +0200:
> > > so when we ask for more we issue an extra short reads, making sure we go
> > > through the two short reads path.
> > > (Unfortunately I wasn't quite sure what to fiddle with to issue short
> > > reads in the first place, I tried cutting one of the iovs short in
> > > luring_do_submit() but I must not have been doing it properly as I ended
> > > up with 0 return values which are handled by filling in with 0 (reads
> > > after eof) and that didn't work well)
> > 
> > Do you remember the kernel version where you first saw these problems?
> 
> Since you're quoting my paragraph about testing two short reads, I've
> never seen any that I know of; but there's also no reason these couldn't
> happen.
> 
> Single short reads have been happening for me with O_DIRECT (cache=none)
> on btrfs for a while, but unfortunately I cannot remember which was the
> first kernel I've seen this on -- I think rather than a kernel update it
> was due to file manipulations that made the file eligible for short
> reads in the first place (I started running deduplication on the backing
> file)
> 
> The older kernel I have installed right now is 5.16 and that can
> reproduce it --  I'll give my laptop some work over the weekend to test
> still maintained stable branches if that's useful.

I can confirm the same behavior happens with 5.4.202
I'm not sure about older kernels as my io_uring test that reproduces
short reads just doesn't start on these, but for all intent and purposes
we can probably say this has just always been possible.

The fix Filipe sent me unfortunately doesn't apply as far back as 5.4
(btrfs_get_blocks_direct had no flags argument back then, that got
introduced with conversion to dio in 5.8), but should probably work as
is for 5.10/15 kernels.

-- 
Dominique

Re: [PULL 00/27] aspeed queue

[Richard Henderson]

On 6/30/22 16:53, Cédric Le Goater wrote:

The following changes since commit 621745c4f349ac09b72706c46febee983abca916:

   Merge tag 'trivial-branch-for-7.1-pull-request' of 
https://gitlab.com/laurent_vivier/qemu into staging (2022-06-30 04:49:40 +0530)

are available in the Git repository at:

   https://github.com/legoater/qemu/ tags/pull-aspeed-20220630

for you to fetch changes up to 55c57023b740c29151d42600af9ac43ba00e56cc:

   hw/misc/aspeed: Add PECI controller (2022-06-30 09:21:14 +0200)


aspeed queue:

* m25p80 improvements (Iris)
* Code cleanup in preparation of multi SoC machine (Peter)
* New MAX31785 model (Mahesh)
* New Qualcomm machines (Jae and Graeme)
* Core I2C slave mode (Klaus)
* Aspeed I2C slave mode for old and new register interface (Peter and Klaus)
* New Aspeed PECI model (Peter)
* Various small fixes


Applied, thanks.  Please update https://wiki.qemu.org/ChangeLog/7.1 as 
appropriate.


r~





Cédric Le Goater (4):
   aspeed: Set the dram container at the SoC level
   aspeed/scu: Add trace events for read ops
   aspeed/i2c: Change trace event for NORMAL_STOP states
   aspeed/smc: Fix potential overflow

Graeme Gregory (1):
   hw/arm/aspeed: add Qualcomm Firework BMC machine

Iris Chen (2):
   hw: m25p80: add WP# pin and SRWD bit for write protection
   hw: m25p80: add tests for write protect (WP# and SRWD bit)

Jae Hyun Yoo (2):
   hw/arm/aspeed: add support for the Qualcomm DC-SCM v1 board
   hw/arm/aspeed: firework: add I2C MUXes for VR channels

Joel Stanley (1):
   aspeed/hace: Accumulative mode supported

Klaus Jensen (3):
   hw/i2c: support multiple masters
   hw/i2c: add asynchronous send
   hw/i2c/aspeed: add slave device in old register mode

Maheswara Kurapati (4):
   hw/i2c: pmbus: Page #255 is valid page for read requests.
   hw/sensor: add Maxim MAX31785 device
   hw/arm/aspeed: Add MAX31785 Fan controllers
   hw/arm/aspeed: firework: Add Thermal Diodes

Peter Delevoryas (10):
   aspeed: Set CPU memory property explicitly
   aspeed: Add memory property to Aspeed SoC
   aspeed: Remove usage of sysbus_mmio_map
   aspeed: Map unimplemented devices in SoC memory
   aspeed: Remove use of qemu_get_cpu
   hw/i2c/aspeed: Fix R_I2CD_FUN_CTRL reference
   hw/i2c/aspeed: Fix DMA len write-enable bit handling
   hw/i2c/aspeed: Fix MASTER_EN missing error message
   hw/i2c/aspeed: Add new-registers DMA slave mode RX support
   hw/misc/aspeed: Add PECI controller

  include/hw/arm/aspeed_soc.h   |  16 ++
  include/hw/i2c/aspeed_i2c.h   |  11 +
  include/hw/i2c/i2c.h  |  30 +++
  include/hw/misc/aspeed_peci.h |  29 +++
  hw/arm/aspeed.c   | 136 +++---
  hw/arm/aspeed_ast10x0.c   |  59 +++--
  hw/arm/aspeed_ast2600.c   | 104 +---
  hw/arm/aspeed_soc.c   | 143 ---
  hw/arm/pxa2xx.c   |   2 +
  hw/block/m25p80.c |  82 --
  hw/display/sii9022.c  |   2 +
  hw/display/ssd0303.c  |   2 +
  hw/i2c/aspeed_i2c.c   | 236 ++---
  hw/i2c/core.c |  70 +-
  hw/i2c/pmbus_device.c |   6 +-
  hw/i2c/smbus_slave.c  |   4 +
  hw/misc/aspeed_hace.c |   6 +-
  hw/misc/aspeed_peci.c | 152 +++
  hw/misc/aspeed_scu.c  |   2 +
  hw/nvram/eeprom_at24c.c   |   2 +
  hw/sensor/lsm303dlhc_mag.c|   2 +
  hw/sensor/max31785.c  | 573 ++
  hw/ssi/aspeed_smc.c   |   4 +-
  tests/qtest/aspeed_smc-test.c |  62 +
  hw/arm/Kconfig|   2 +
  hw/i2c/trace-events   |   2 +
  hw/misc/meson.build   |   3 +-
  hw/misc/trace-events  |   6 +
  hw/sensor/Kconfig |   4 +
  hw/sensor/meson.build |   1 +
  30 files changed, 1573 insertions(+), 180 deletions(-)
  create mode 100644 include/hw/misc/aspeed_peci.h
  create mode 100644 hw/misc/aspeed_peci.c
  create mode 100644 hw/sensor/max31785.c

Re: [PATCH v6 6/8] KVM: Handle page fault for private memory

[Xiaoyao Li]

On 7/1/2022 6:21 AM, Michael Roth wrote:

On Thu, Jun 30, 2022 at 12:14:13PM -0700, Vishal Annapurve wrote:

With transparent_hugepages=always setting I see issues with the
current implementation.

Scenario:
1) Guest accesses a gfn range 0x800-0xa00 as private
2) Guest calls mapgpa to convert the range 0x84d-0x86e as shared
3) Guest tries to access recently converted memory as shared for the first time
Guest VM shutdown is observed after step 3 -> Guest is unable to
proceed further since somehow code section is not as expected

Corresponding KVM trace logs after step 3:
VCPU-0-61883   [078] . 72276.115679: kvm_page_fault: address
84d000 error_code 4
VCPU-0-61883   [078] . 72276.127005: kvm_mmu_spte_requested: gfn
84d pfn 100b4a4d level 2
VCPU-0-61883   [078] . 72276.127008: kvm_tdp_mmu_spte_changed: as
id 0 gfn 800 level 2 old_spte 100b1b16827 new_spte 100b4a00ea7
VCPU-0-61883   [078] . 72276.127009: kvm_mmu_prepare_zap_page: sp
gen 0 gfn 800 l1 8-byte q0 direct wux nxe ad root 0 sync
VCPU-0-61883   [078] . 72276.127009: kvm_tdp_mmu_spte_changed: as
id 0 gfn 800 level 1 old_spte 1003eb27e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 801 level 1 old_spte 10056cc8e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 802 level 1 old_spte 10056fa2e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 803 level 1 old_spte 0 new_spte 5a0

  VCPU-0-61883   [078] . 72276.127089: kvm_tdp_mmu_spte_changed: as
id 0 gfn 9ff level 1 old_spte 100a43f4e67 new_spte 5a0
  VCPU-0-61883   [078] . 72276.127090: kvm_mmu_set_spte: gfn 800
spte 100b4a00ea7 (rwxu) level 2 at 10052fa5020
  VCPU-0-61883   [078] . 72276.127091: kvm_fpu: unload

Looks like with transparent huge pages enabled kvm tried to handle the
shared memory fault on 0x84d gfn by coalescing nearby 4K pages
to form a contiguous 2MB page mapping at gfn 0x800, since level 2 was
requested in kvm_mmu_spte_requested.
This caused the private memory contents from regions 0x800-0x84c and
0x86e-0xa00 to get unmapped from the guest leading to guest vm
shutdown.


Interesting... seems like that wouldn't be an issue for non-UPM SEV, since
the private pages would still be mapped as part of that 2M mapping, and
it's completely up to the guest as to whether it wants to access as
private or shared. But for UPM it makes sense this would cause issues.



Does getting the mapping level as per the fault access type help
address the above issue? Any such coalescing should not cross between
private to
shared or shared to private memory regions.


Doesn't seem like changing the check to fault->is_private would help in
your particular case, since the subsequent host_pfn_mapping_level() call
only seems to limit the mapping level to whatever the mapping level is
for the HVA in the host page table.

Seems like with UPM we need some additional handling here that also
checks that the entire 2M HVA range is backed by non-private memory.

Non-UPM SNP hypervisor patches already have a similar hook added to
host_pfn_mapping_level() which implements such a check via RMP table, so
UPM might need something similar:

   
https://github.com/AMDESE/linux/commit/ae4475bc740eb0b9d031a76412b0117339794139

-Mike



For TDX, we try to track the page type (shared, private, mixed) of each 
gfn at given level. Only when the type is shared/private, can it be 
mapped at that level. When it's mixed, i.e., it contains both shared 
pages and private pages at given level, it has to go to next smaller level.


https://github.com/intel/tdx/commit/ed97f4042eb69a210d9e972ccca6a84234028cad

Re: [PULL 00/14] (Mostly) build system changes for 2022-06-24

[Richard Henderson]

On 6/30/22 23:02, Peter Maydell wrote:

On Thu, 30 Jun 2022 at 18:14, Paolo Bonzini  wrote:




Il ven 24 giu 2022, 17:57 Richard Henderson  ha 
scritto:


But then the i386 cross-compiler isn't used:



Yeah, that was intentional. In theory a softmmu target is freestanding and does 
not need anything beyond the compiler install, so configure defaults to the 
native compiler, which is biarch. That however assumes that the compiler 
install includes the libgcc for both architectures.

Does that mean that Ubuntu installs GCC without a 32-bit libgcc.a?


I think they package it in a separate package, eg lib32gcc-9-dev
(adjust package name to suit gcc version).


It's there, as Peter says, but it's not installed with the build-essential meta-package, 
and the crossbuild-essential-i386 package installs a different libgcc.



r~

[PATCH 1/3] hw/i2c/pmbus: Add idle state to return 0xff's

[Peter Delevoryas]

From: Peter Delevoryas 

Signed-off-by: Peter Delevoryas 
Reviewed-by: Titus Rwantare 
---
 hw/i2c/pmbus_device.c | 9 +
 include/hw/i2c/pmbus_device.h | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/hw/i2c/pmbus_device.c b/hw/i2c/pmbus_device.c
index 62885fa6a1..f89fea65f3 100644
--- a/hw/i2c/pmbus_device.c
+++ b/hw/i2c/pmbus_device.c
@@ -261,6 +261,11 @@ void pmbus_check_limits(PMBusDevice *pmdev)
 }
 }
 
+void pmbus_idle(PMBusDevice *pmdev)
+{
+pmdev->code = PMBUS_IDLE_STATE;
+}
+
 /* assert the status_cml error upon receipt of malformed command */
 static void pmbus_cml_error(PMBusDevice *pmdev)
 {
@@ -984,6 +989,10 @@ static uint8_t pmbus_receive_byte(SMBusDevice *smd)
 }
 break;
 
+case PMBUS_IDLE_STATE:
+pmbus_send8(pmdev, PMBUS_ERR_BYTE);
+break;
+
 case PMBUS_CLEAR_FAULTS:  /* Send Byte */
 case PMBUS_PAGE_PLUS_WRITE:   /* Block Write-only */
 case PMBUS_STORE_DEFAULT_ALL: /* Send Byte */
diff --git a/include/hw/i2c/pmbus_device.h b/include/hw/i2c/pmbus_device.h
index 0f4d6b3fad..93f5d57c9d 100644
--- a/include/hw/i2c/pmbus_device.h
+++ b/include/hw/i2c/pmbus_device.h
@@ -155,6 +155,7 @@ enum pmbus_registers {
 PMBUS_MFR_MAX_TEMP_1= 0xC0, /* R/W word */
 PMBUS_MFR_MAX_TEMP_2= 0xC1, /* R/W word */
 PMBUS_MFR_MAX_TEMP_3= 0xC2, /* R/W word */
+PMBUS_IDLE_STATE= 0xFF,
 };
 
 /* STATUS_WORD */
@@ -527,6 +528,12 @@ int pmbus_page_config(PMBusDevice *pmdev, uint8_t 
page_index, uint64_t flags);
  */
 void pmbus_check_limits(PMBusDevice *pmdev);
 
+/**
+ * Enter an idle state where only the PMBUS_ERR_BYTE will be returned
+ * indefinitely until a new command is issued.
+ */
+void pmbus_idle(PMBusDevice *pmdev);
+
 extern const VMStateDescription vmstate_pmbus_device;
 
 #define VMSTATE_PMBUS_DEVICE(_field, _state) {   \
-- 
2.37.0

[PATCH 3/3] hw/sensor: Add Renesas ISL69259 device model

[Peter Delevoryas]

From: Peter Delevoryas 

This adds the ISL69259, using all the same functionality as the existing
ISL69260 but overriding the IC_DEVICE_ID.

Signed-off-by: Peter Delevoryas 
Reviewed-by: Titus Rwantare 
---
 hw/sensor/isl_pmbus_vr.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
index 799ea9d89e..eb344dd5a9 100644
--- a/hw/sensor/isl_pmbus_vr.c
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -119,6 +119,18 @@ static void raa228000_exit_reset(Object *obj)
 pmdev->pages[0].read_temperature_3 = 0;
 }
 
+static void isl69259_exit_reset(Object *obj)
+{
+ISLState *s = ISL69260(obj);
+static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2, 0x49, 0x3c};
+g_assert(sizeof(ic_device_id) <= sizeof(s->ic_device_id));
+
+isl_pmbus_vr_exit_reset(obj);
+
+s->ic_device_id_len = sizeof(ic_device_id);
+memcpy(s->ic_device_id, ic_device_id, sizeof(ic_device_id));
+}
+
 static void isl_pmbus_vr_add_props(Object *obj, uint64_t *flags, uint8_t pages)
 {
 PMBusDevice *pmdev = PMBUS_DEVICE(obj);
@@ -257,6 +269,21 @@ static void raa229004_class_init(ObjectClass *klass, void 
*data)
 isl_pmbus_vr_class_init(klass, data, 2);
 }
 
+static void isl69259_class_init(ObjectClass *klass, void *data)
+{
+ResettableClass *rc = RESETTABLE_CLASS(klass);
+DeviceClass *dc = DEVICE_CLASS(klass);
+dc->desc = "Renesas ISL69259 Digital Multiphase Voltage Regulator";
+rc->phases.exit = isl69259_exit_reset;
+isl_pmbus_vr_class_init(klass, data, 2);
+}
+
+static const TypeInfo isl69259_info = {
+.name = TYPE_ISL69259,
+.parent = TYPE_ISL69260,
+.class_init = isl69259_class_init,
+};
+
 static const TypeInfo isl69260_info = {
 .name = TYPE_ISL69260,
 .parent = TYPE_PMBUS_DEVICE,
@@ -283,6 +310,7 @@ static const TypeInfo raa228000_info = {
 
 static void isl_pmbus_vr_register_types(void)
 {
+type_register_static(_info);
 type_register_static(_info);
 type_register_static(_info);
 type_register_static(_info);
-- 
2.37.0

[PATCH 0/3] hw/sensor: Add ISL69259 with IC_DEVICE_ID

[Peter Delevoryas]

From: Peter Delevoryas 

Resubmitting these patches separately after having included
and partially reviewd them here:

- https://lore.kernel.org/qemu-devel/20220630045133.32251-9...@pjd.dev/
- https://lore.kernel.org/qemu-devel/20220630045133.32251-10...@pjd.dev/
- https://lore.kernel.org/qemu-devel/20220630045133.32251-11...@pjd.dev/

I added Titus's reviewed-by tags, but Cedric still had one outstanding
issue:

- 
https://lore.kernel.org/qemu-devel/293da11c-dde2-e646-c754-820720c41...@kaod.org/

But Titus had a response to that issue, so we may or may not ignore it:

- 
https://lore.kernel.org/qemu-devel/CAMvPwGpZZgAd2RHXmvmxfgyTyVGd6Rx+avj=E24NWc0masdc=a...@mail.gmail.com/

Changes since then:
- Replaced g_assert_cmphex with g_assert to avoid portability issues.

Thanks,
Peter

Peter Delevoryas (3):
  hw/i2c/pmbus: Add idle state to return 0xff's
  hw/sensor: Add IC_DEVICE_ID to ISL voltage regulators
  hw/sensor: Add Renesas ISL69259 device model

 hw/i2c/pmbus_device.c|  9 +++
 hw/sensor/isl_pmbus_vr.c | 40 
 include/hw/i2c/pmbus_device.h|  7 ++
 include/hw/sensor/isl_pmbus_vr.h |  5 
 4 files changed, 61 insertions(+)

-- 
2.37.0

[PATCH 2/3] hw/sensor: Add IC_DEVICE_ID to ISL voltage regulators

[Peter Delevoryas]

From: Peter Delevoryas 

This commit adds a passthrough for PMBUS_IC_DEVICE_ID to allow Renesas
voltage regulators to return the integrated circuit device ID if they
would like to.

The behavior is very device specific, so it hasn't been added to the
general PMBUS model. Additionally, if the device ID hasn't been set,
then the voltage regulator will respond with the error byte value.  The
guest error message will change slightly for IC_DEVICE_ID with this
commit.

Signed-off-by: Peter Delevoryas 
Reviewed-by: Titus Rwantare 
---
 hw/sensor/isl_pmbus_vr.c | 12 
 include/hw/sensor/isl_pmbus_vr.h |  5 +
 2 files changed, 17 insertions(+)

diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
index e11e028884..799ea9d89e 100644
--- a/hw/sensor/isl_pmbus_vr.c
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -15,6 +15,18 @@
 
 static uint8_t isl_pmbus_vr_read_byte(PMBusDevice *pmdev)
 {
+ISLState *s = ISL69260(pmdev);
+
+switch (pmdev->code) {
+case PMBUS_IC_DEVICE_ID:
+if (!s->ic_device_id_len) {
+break;
+}
+pmbus_send(pmdev, s->ic_device_id, s->ic_device_id_len);
+pmbus_idle(pmdev);
+return 0;
+}
+
 qemu_log_mask(LOG_GUEST_ERROR,
   "%s: reading from unsupported register: 0x%02x\n",
   __func__, pmdev->code);
diff --git a/include/hw/sensor/isl_pmbus_vr.h b/include/hw/sensor/isl_pmbus_vr.h
index 3e47ff7e48..aa2c2767df 100644
--- a/include/hw/sensor/isl_pmbus_vr.h
+++ b/include/hw/sensor/isl_pmbus_vr.h
@@ -12,12 +12,17 @@
 #include "hw/i2c/pmbus_device.h"
 #include "qom/object.h"
 
+#define TYPE_ISL69259   "isl69259"
 #define TYPE_ISL69260   "isl69260"
 #define TYPE_RAA228000  "raa228000"
 #define TYPE_RAA229004  "raa229004"
+#define ISL_MAX_IC_DEVICE_ID_LEN 16
 
 struct ISLState {
 PMBusDevice parent;
+
+uint8_t ic_device_id[ISL_MAX_IC_DEVICE_ID_LEN];
+uint8_t ic_device_id_len;
 };
 
 OBJECT_DECLARE_SIMPLE_TYPE(ISLState, ISL69260)
-- 
2.37.0

Re: [PATCH v3 14/14] hw/arm/aspeed: Add oby35-cl machine

[Peter Delevoryas]

On Thu, Jun 30, 2022 at 06:42:52PM +0200, Cédric Le Goater wrote:
> On 6/30/22 18:15, Peter Delevoryas wrote:
> > On Thu, Jun 30, 2022 at 01:02:54PM +0200, Cédric Le Goater wrote:
> > > On 6/30/22 06:51, Peter Delevoryas wrote:
> > > > From: Peter Delevoryas 
> > > > 
> > > > The fby35 machine includes 4 server boards, each of which has a "bridge
> > > > interconnect" (BIC). This chip abstracts the pinout for the server board
> > > > into a single endpoint that the baseboard management controller (BMC)
> > > > can talk to using IPMB.
> > > > 
> > > > This commit adds a machine for testing the BIC on the server board. It
> > > > runs OpenBIC (https://github.com/facebook/openbic) and the server board
> > > > is called CraterLake, so the code name is oby35-cl. There's also a
> > > > variant of the baseboard that replaces the BMC with a BIC, but that
> > > > machine is not included here.
> > > > 
> > > > A test image can be built from https://github.com/facebook/openbic using
> > > > the instructions in the README.md to build the meta-facebook/yv35-cl
> > > > recipe, or retrieved from my Github:
> > > > 
> > > >   wget 
> > > > https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.17.01/Y35BCL.elf
> > > > 
> > > > And you can run this machine with the following command:
> > > > 
> > > >   qemu-system-arm -machine oby35-cl -nographic -kernel Y35BCL.elf
> > > > 
> > > > It should produce output like the following:
> > > > 
> > > >   [00:00:00.005,000]  usb_dc_aspeed: select ep[0x81] as IN 
> > > > endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x82] as IN 
> > > > endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x1] as 
> > > > IN endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x2] as 
> > > > IN endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x3] as OUT 
> > > > endpoint
> > > >   *** Booting Zephyr OS build v00.01.05  ***
> > > >   Hello, welcome to yv35 craterlake 2022.25.1
> > > >   BIC class type(class-1), 1ou present status(0), 2ou present 
> > > > status(0), board revision(0x1)
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   [init_drive_type] sensor 0x14 post sensor read failed!
> > > > 
> > > >   [init_drive_type] sensor 0x30 post sensor read failed!
> > > >   [init_drive_type] sensor 0x39 post sensor read failed!
> > > >   ipmi_init
> > > >   [set_DC_status] gpio number(15) status(0)
> > > >   [set_post_status] gpio number(1) status(1)
> > > >   uart:~$ [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, 
> > > > idr=0x2c, odr=0x38, str=0x44
> > > > 
> > > >   [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP 
> > > > magic  invalid
> > > >   [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read 
> > > > failed: -22
> > > >   [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
> 

Re: [PATCH v2] io_uring: fix short read slow path

[Dominique Martinet]

Stefano Garzarella wrote on Thu, Jun 30, 2022 at 05:49:21PM +0200:
> > so when we ask for more we issue an extra short reads, making sure we go
> > through the two short reads path.
> > (Unfortunately I wasn't quite sure what to fiddle with to issue short
> > reads in the first place, I tried cutting one of the iovs short in
> > luring_do_submit() but I must not have been doing it properly as I ended
> > up with 0 return values which are handled by filling in with 0 (reads
> > after eof) and that didn't work well)
> 
> Do you remember the kernel version where you first saw these problems?

Since you're quoting my paragraph about testing two short reads, I've
never seen any that I know of; but there's also no reason these couldn't
happen.

Single short reads have been happening for me with O_DIRECT (cache=none)
on btrfs for a while, but unfortunately I cannot remember which was the
first kernel I've seen this on -- I think rather than a kernel update it
was due to file manipulations that made the file eligible for short
reads in the first place (I started running deduplication on the backing
file)

The older kernel I have installed right now is 5.16 and that can
reproduce it --  I'll give my laptop some work over the weekend to test
still maintained stable branches if that's useful.

-- 
Dominique

Re: [PATCH v2 0/3] python/qemu/machine: fix potential hang in QMP accept

[John Snow]

On Thu, Jun 30, 2022 at 8:34 AM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> As reported earlier by Richard Henderson ("virgl avocado hang" thread), 
> avocado
> tests may hang when QEMU exits before the QMP connection is established.
>
> v2:
>  - use a socketpair() for QMP (instead of async concurrent code from v1) as
>suggested by Daniel Berrange.
>  - should not regress (hopefully)
>
> Marc-André Lureau (3):
>   python/qmp/protocol: add open_with_socket()
>   python/qmp/legacy: make QEMUMonitorProtocol accept a socket
>   python/qemu/machine: use socketpair() for QMP by default
>
>  python/qemu/machine/machine.py | 24 
>  python/qemu/qmp/legacy.py  | 18 +++---
>  python/qemu/qmp/protocol.py| 25 -
>  3 files changed, 51 insertions(+), 16 deletions(-)
>
> --
> 2.37.0.rc0
>

For anything that touches python/qemu/qmp/*, may I please ask that you
submit them to https://gitlab.com/qemu-project/python-qemu-qmp ?

(I'll review them in the meantime on-list just in the interest of
moving things along.)

--js

Re: [PATCH 2/2] python/qemu/machine: accept QMP connection asynchronously

[John Snow]

On Thu, Jun 30, 2022 at 4:23 AM Daniel P. Berrangé  wrote:
>
> On Wed, Jun 29, 2022 at 07:54:08PM -0400, John Snow wrote:
> > On Tue, Jun 28, 2022 at 10:17 AM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Tue, Jun 28, 2022 at 05:49:39PM +0400, marcandre.lur...@redhat.com 
> > > wrote:
> > > > From: Marc-André Lureau 
> > > >
> > > > QMP accept is currently synchronous. If qemu dies before the connection
> > > > is established, it will wait there. Instead turn the code to do
> > > > concurrently accept() and wait(). Returns when the first task is
> > > > completed to determine whether a connection was established.
> > >
> > > If the spawned QEMU process was given -daemonize, won't this code
> > > mistakenly think the subprocess has quit ?
> >
> > Do we use daemonize with this code anywhere? Is it important that we
> > are able to?
>
> Well what's the intended breadth of use cases this code wants to
> target ?

Well, I dunno. I'm going to say that machine.py is something that will
probably stay in-tree as an ad-hoc testing utility. I have some
thoughts about growing it into something "just a little bit more than
that", but I think we can cross that bridge when we get there. I will
probably do like what I did for QMP: write a replacement, test it with
our existing test infrastructure, then do a drop-in switcheroo.

>
> If you don't daemonize QEMU, then QEMU will (likely) get killed off
> when the parent python process terminates. That can be ok for adhoc
> testing scenarios where the QEMU process is transient and throwaway,
> or for using QEMU as an embedded technology (think libguestfs). If
> you want your QEMU to run full OS workloads, then generally you won't
> want it to die when the mgmt app is restarted (eg for software upgrade),
> whereupon you want to daemonize.
>

Yeah, I think that's a case that I wasn't invested in managing.
Certainly it's an expansion of scope.

> > Many of the shutdown routines I wrote expect to work directly with a
> > launched process ... at least, that expectation exists in my head. I
> > suppose a lot of this code may actually just coincidentally work with
> > -daemonize and I wouldn't have noticed. I certainly haven't been
> > testing it explicitly. I definitely make no accommodations for it, so
> > I would expect some stale processes in various cases at a minimum.
>
> Looking at the code it probably works by accident - the shutdown()
> methods kinda assumes we're talking to a direct child, but it'll
> happen to work right now as it'll simply cleanup the defunct
> intermediate child, while QEMU stays running.
>

That's my conclusion, yes.

> > If we want to expand to accommodate this feature, can we do that
> > later? Machine needs a bit of a remodel anyway. (I want to write an
> > 'idiomatic' asyncio version to match the QMP lib. I have some
> > questions to work out WRT which portions of this appliance can be
> > upstreamed and which need to remain only in our testing tree. We can
> > talk about those pieces later, just throwing it out there that it's on
> > my list.)
>
> The machine class is probably the part that looks least ready to be
> published as an API on pypi. Its code really shows its origins as an
> adhoc testing framework, rather than a general purpose API for running
> and managing QEMU from python.

I agree.

It might still be useful in some form, eventually, to use as supported
example code of showing how you can launch QEMU and interact with it
via QMP. In the current form, though, it's definitely just ad-hoc nuts
and bolts for the test suite. I am fine with keeping it like that for
purposes of review and maintenance, etc.

--js

Re: [PATCH v6 6/8] KVM: Handle page fault for private memory

[Michael Roth]

On Thu, Jun 30, 2022 at 12:14:13PM -0700, Vishal Annapurve wrote:
> With transparent_hugepages=always setting I see issues with the
> current implementation.
> 
> Scenario:
> 1) Guest accesses a gfn range 0x800-0xa00 as private
> 2) Guest calls mapgpa to convert the range 0x84d-0x86e as shared
> 3) Guest tries to access recently converted memory as shared for the first 
> time
> Guest VM shutdown is observed after step 3 -> Guest is unable to
> proceed further since somehow code section is not as expected
> 
> Corresponding KVM trace logs after step 3:
> VCPU-0-61883   [078] . 72276.115679: kvm_page_fault: address
> 84d000 error_code 4
> VCPU-0-61883   [078] . 72276.127005: kvm_mmu_spte_requested: gfn
> 84d pfn 100b4a4d level 2
> VCPU-0-61883   [078] . 72276.127008: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 800 level 2 old_spte 100b1b16827 new_spte 100b4a00ea7
> VCPU-0-61883   [078] . 72276.127009: kvm_mmu_prepare_zap_page: sp
> gen 0 gfn 800 l1 8-byte q0 direct wux nxe ad root 0 sync
> VCPU-0-61883   [078] . 72276.127009: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 800 level 1 old_spte 1003eb27e67 new_spte 5a0
> VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 801 level 1 old_spte 10056cc8e67 new_spte 5a0
> VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 802 level 1 old_spte 10056fa2e67 new_spte 5a0
> VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 803 level 1 old_spte 0 new_spte 5a0
> 
>  VCPU-0-61883   [078] . 72276.127089: kvm_tdp_mmu_spte_changed: as
> id 0 gfn 9ff level 1 old_spte 100a43f4e67 new_spte 5a0
>  VCPU-0-61883   [078] . 72276.127090: kvm_mmu_set_spte: gfn 800
> spte 100b4a00ea7 (rwxu) level 2 at 10052fa5020
>  VCPU-0-61883   [078] . 72276.127091: kvm_fpu: unload
> 
> Looks like with transparent huge pages enabled kvm tried to handle the
> shared memory fault on 0x84d gfn by coalescing nearby 4K pages
> to form a contiguous 2MB page mapping at gfn 0x800, since level 2 was
> requested in kvm_mmu_spte_requested.
> This caused the private memory contents from regions 0x800-0x84c and
> 0x86e-0xa00 to get unmapped from the guest leading to guest vm
> shutdown.

Interesting... seems like that wouldn't be an issue for non-UPM SEV, since
the private pages would still be mapped as part of that 2M mapping, and
it's completely up to the guest as to whether it wants to access as
private or shared. But for UPM it makes sense this would cause issues.

> 
> Does getting the mapping level as per the fault access type help
> address the above issue? Any such coalescing should not cross between
> private to
> shared or shared to private memory regions.

Doesn't seem like changing the check to fault->is_private would help in
your particular case, since the subsequent host_pfn_mapping_level() call
only seems to limit the mapping level to whatever the mapping level is
for the HVA in the host page table.

Seems like with UPM we need some additional handling here that also
checks that the entire 2M HVA range is backed by non-private memory.

Non-UPM SNP hypervisor patches already have a similar hook added to
host_pfn_mapping_level() which implements such a check via RMP table, so
UPM might need something similar:

  
https://github.com/AMDESE/linux/commit/ae4475bc740eb0b9d031a76412b0117339794139

-Mike

> 
> > > > host_level = host_pfn_mapping_level(kvm, gfn, pfn, slot);
> > > > return min(host_level, max_level);
> > > >  }
> > >
> 
> Regards,
> Vishal

Re: [PATCH v3 10/14] hw/sensor: Add Renesas ISL69259 device model

[Peter Delevoryas]

On Thu, Jun 30, 2022 at 12:16:05PM -0700, Titus Rwantare wrote:
> On Wed, 29 Jun 2022 at 21:52, Peter Delevoryas  wrote:
> >
> > From: Peter Delevoryas 
> >
> > This adds the ISL69259, using all the same functionality as the existing
> > ISL69260 but overriding the IC_DEVICE_ID.
> >
> > Signed-off-by: Peter Delevoryas 
> > ---
> >  hw/sensor/isl_pmbus_vr.c | 28 
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
> > index 799ea9d89e..853d70536f 100644
> > --- a/hw/sensor/isl_pmbus_vr.c
> > +++ b/hw/sensor/isl_pmbus_vr.c
> > @@ -119,6 +119,18 @@ static void raa228000_exit_reset(Object *obj)
> >  pmdev->pages[0].read_temperature_3 = 0;
> >  }
> >
> > +static void isl69259_exit_reset(Object *obj)
> > +{
> > +ISLState *s = ISL69260(obj);
> > +static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2, 0x49, 
> > 0x3c};
> > +g_assert_cmphex(sizeof(ic_device_id), <=, sizeof(s->ic_device_id));
> > +
> 
> This generates an error from the checkpatch script:
> Checking 0010-hw-sensor-Add-Renesas-ISL69259-device-model.patch...
> ERROR: Use g_assert or g_assert_not_reached
> #27: FILE: hw/sensor/isl_pmbus_vr.c:126:
> +g_assert_cmphex(sizeof(ic_device_id), <=, sizeof(s->ic_device_id));

Argghhh I should have caught this, thanks. I'll replace it with g_assert. I
didn't realize there was some kind of portability issue with using
g_assert_cmphex in non-test code.

> 
> otherwise, LGTM.

That's great! Thanks for the review. I'll let you and Cedric sort
out if we want to make IC_DEVICE_ID a class property or keep it
in exit_reset as everything else class-specific is right now.

I'll still resubmit the patches as a separate series though with
the g_assert fix and your reviewed-by tags.

> 
> 
> Titus

Re: [PATCH v2] target/ppc: Return default CPU for max CPU

[Víctor Colombo]

On 28/06/2022 17:55, Murilo Opsfelder Araujo wrote:

All ppc CPUs represent hardware that exists in the real world, i.e.: we
do not have a "max" CPU with all possible emulated features enabled.
Return the default CPU type for the machine because that has greater
chance of being useful as the "max" CPU.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1038
Cc: Cédric Le Goater 
Cc: Daniel Henrique Barboza 
Cc: Daniel P. Berrangé 
Cc: Greg Kurz 
Cc: Matheus K. Ferst 
Cc: Thomas Huth 
Signed-off-by: Murilo Opsfelder Araujo 
Signed-off-by: Fabiano Rosas 
---
v2:
- Return the default CPU of the machine instead of hard-coded alias.

v1: 
https://lore.kernel.org/qemu-devel/20220531172711.94564-1-muri...@linux.ibm.com/

  target/ppc/cpu-models.c |  1 -
  target/ppc/cpu_init.c   | 19 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
index 976be5e0d1..05589eb21d 100644
--- a/target/ppc/cpu-models.c
+++ b/target/ppc/cpu-models.c
@@ -879,7 +879,6 @@ PowerPCCPUAlias ppc_cpu_aliases[] = {
  { "755", "755_v2.8" },
  { "goldfinger", "755_v2.8" },
  { "7400", "7400_v2.9" },
-{ "max", "7400_v2.9" },
  { "g4",  "7400_v2.9" },
  { "7410", "7410_v1.4" },
  { "nitro", "7410_v1.4" },
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index c16cb8dbe7..8ee0b7c785 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -47,6 +47,10 @@
  #include "spr_common.h"
  #include "power8-pmu.h"

+#ifndef CONFIG_USER_ONLY
+#include "hw/boards.h"
+#endif
+
  /* #define PPC_DEBUG_SPR */
  /* #define USE_APPLE_GDB */

@@ -6963,6 +6967,21 @@ static ObjectClass *ppc_cpu_class_by_name(const char 
*name)
  }
  }

+/*
+ * All ppc CPUs represent hardware that exists in the real world, i.e.: we
+ * do not have a "max" CPU with all possible emulated features enabled.
+ * Return the default CPU type for the machine because that has greater
+ * chance of being useful as the "max" CPU.
+ */
+#if !defined(CONFIG_USER_ONLY)
+if (strcmp(name, "max") == 0) {
+MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
+if (mc) {
+return object_class_by_name(mc->default_cpu_type);
+}
+}
+#endif
+
  cpu_model = g_ascii_strdown(name, -1);
  p = ppc_cpu_lookup_alias(cpu_model);
  if (p) {
--
2.36.1




Reviewed-by: Víctor Colombo 

Best regards,

--
Víctor Cora Colombo
Instituto de Pesquisas ELDORADO
Aviso Legal - Disclaimer 

[PATCH 5/9] target/ppc: use Error pointer in kvmppc_get_clockfreq()

[Daniel Henrique Barboza]

Callers will then be able to handle any errors that might happen when
reading the clock frequency.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/e500.c  | 2 +-
 hw/ppc/ppc440_bamboo.c | 2 +-
 hw/ppc/sam460ex.c  | 2 +-
 hw/ppc/spapr.c | 2 +-
 target/ppc/kvm.c   | 4 ++--
 target/ppc/kvm_ppc.h   | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 7f7f5b3452..4b4e99ef3c 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -405,7 +405,7 @@ static int ppce500_load_device_tree(PPCE500MachineState 
*pms,
 
 if (kvm_enabled()) {
 /* Read out host's frequencies */
-clock_freq = kvmppc_get_clockfreq();
+clock_freq = kvmppc_get_clockfreq(NULL);
 tb_freq = kvmppc_get_tbfreq();
 
 /* indicate KVM hypercall interface */
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index d5973f2484..d23f881d9d 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -107,7 +107,7 @@ static int bamboo_load_device_tree(hwaddr addr,
  * the correct frequencies. */
 if (kvm_enabled()) {
 tb_freq = kvmppc_get_tbfreq();
-clock_freq = kvmppc_get_clockfreq();
+clock_freq = kvmppc_get_clockfreq(NULL);
 }
 
 qemu_fdt_setprop_cell(fdt, "/cpus/cpu@0", "clock-frequency",
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 2f24598f55..4d25cb2c2e 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -179,7 +179,7 @@ static int sam460ex_load_device_tree(hwaddr addr,
  * the correct frequencies. */
 if (kvm_enabled()) {
 tb_freq = kvmppc_get_tbfreq();
-clock_freq = kvmppc_get_clockfreq();
+clock_freq = kvmppc_get_clockfreq(NULL);
 }
 
 qemu_fdt_setprop_cell(fdt, "/cpus/cpu@0", "clock-frequency",
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index fd4942e881..f66e3cbe38 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -654,7 +654,7 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
offset,
0x, 0x};
 uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq()
 : SPAPR_TIMEBASE_FREQ;
-uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq() : 10;
+uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq(NULL) : 10;
 uint32_t page_sizes_prop[64];
 size_t page_sizes_prop_size;
 unsigned int smp_threads = ms->smp.threads;
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index c218380eb7..2accd1f946 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1945,9 +1945,9 @@ static uint64_t kvmppc_read_int_cpu_dt(const char 
*propname, Error **errp)
 return kvmppc_read_int_dt(tmp, errp);
 }
 
-uint64_t kvmppc_get_clockfreq(void)
+uint64_t kvmppc_get_clockfreq(Error **errp)
 {
-return kvmppc_read_int_cpu_dt("clock-frequency", NULL);
+return kvmppc_read_int_cpu_dt("clock-frequency", errp);
 }
 
 static int kvmppc_get_dec_bits(void)
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index ee9325bf9a..b05aedb9f8 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -14,7 +14,7 @@
 #ifdef CONFIG_KVM
 
 uint32_t kvmppc_get_tbfreq(void);
-uint64_t kvmppc_get_clockfreq(void);
+uint64_t kvmppc_get_clockfreq(Error **errp);
 bool kvmppc_get_host_model(char **buf);
 bool kvmppc_get_host_serial(char **buf);
 int kvmppc_get_hasidle(CPUPPCState *env);
-- 
2.36.1

[PATCH 0/9] cleanup error handling in kvmppc_read_int_cpu_dt()

[Daniel Henrique Barboza]

Hi,

This series is a cleanup that fixes the issues observed by Markus
Armbruster in the review of jianchunfu's patch:

https://lists.gnu.org/archive/html/qemu-devel/2022-06/msg05393.html

I've also included jianchunfu's patch, with the relevant bits, in the
series.


Daniel Henrique Barboza (8):
  target/ppc/kvm.c: do not return -1 on uint64_t return
  target/ppc: add errp to kvmppc_read_int_cpu_dt()
  target/ppc: use g_autofree in kvmppc_read_int_cpu_dt()
  target/ppc: use Error pointer in kvmppc_get_clockfreq()
  ppc440_bamboo.c: handle clock freq read error in load_device_tree
  sam460ex.c: use CPU_FREQ if unable to read DT clock
  e500.c: use PLATFORM_CLK_FREQ_HZ if unable to read clock freq from DT
  spapr.c: handle clock freq read errors in spapr_dt_cpu()

jianchunfu (1):
  target/ppc: Add error reporting when opening file fails

 hw/ppc/e500.c  |  8 +++-
 hw/ppc/ppc440_bamboo.c | 17 ++---
 hw/ppc/sam460ex.c  |  8 +++-
 hw/ppc/spapr.c | 12 +++-
 include/hw/ppc/spapr.h |  1 +
 target/ppc/kvm.c   | 33 +
 target/ppc/kvm_ppc.h   |  2 +-
 7 files changed, 58 insertions(+), 23 deletions(-)

-- 
2.36.1

[PATCH 1/9] target/ppc/kvm.c: do not return -1 on uint64_t return

[Daniel Henrique Barboza]

kvmppc_read_int_dt() and kvmppc_read_int_cpu_dt() return an uint64_t,
while returning -1 when an error occurs. kvmppc_read_int_cpu_dt() claims
that it will return 0 if anything wrong happens, but it's returning -1
if kmvppc_find_cpu_dt() fails.

The elephant in the room is that returning -1 while claiming that the
return is uint64_t, results in 18446744073709551615 for the callers.
This reason alone is enough to not return -1 under these circunstances.

We'll still have the problem of having to deal with a '0' return that
might, or might not be, an error. We'll make this distintion clear in
the next patches.

Signed-off-by: Daniel Henrique Barboza 
---
 target/ppc/kvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 6eed466f80..109823136d 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1907,7 +1907,7 @@ static uint64_t kvmppc_read_int_dt(const char *filename)
 
 f = fopen(filename, "rb");
 if (!f) {
-return -1;
+return 0;
 }
 
 len = fread(, 1, sizeof(u), f);
@@ -1934,7 +1934,7 @@ static uint64_t kvmppc_read_int_cpu_dt(const char 
*propname)
 uint64_t val;
 
 if (kvmppc_find_cpu_dt(buf, sizeof(buf))) {
-return -1;
+return 0;
 }
 
 tmp = g_strdup_printf("%s/%s", buf, propname);
-- 
2.36.1

[PATCH 9/9] spapr.c: handle clock freq read errors in spapr_dt_cpu()

[Daniel Henrique Barboza]

Let's put the default spapr clock value in a SPAPR_CLOCK_FREQ for better
readability.

After that, make 'cpufreq' default to SPAPR_CLOCK_FREQ if
kvmppc_get_clockfreq() fails to read the clock from the DT.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c | 12 +++-
 include/hw/ppc/spapr.h |  1 +
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index f66e3cbe38..80189c78be 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -654,7 +654,7 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
offset,
0x, 0x};
 uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq()
 : SPAPR_TIMEBASE_FREQ;
-uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq(NULL) : 10;
+uint32_t cpufreq = SPAPR_CLOCK_FREQ;
 uint32_t page_sizes_prop[64];
 size_t page_sizes_prop_size;
 unsigned int smp_threads = ms->smp.threads;
@@ -699,6 +699,16 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
offset,
 }
 
 _FDT((fdt_setprop_cell(fdt, offset, "timebase-frequency", tbfreq)));
+
+if (kvm_enabled()) {
+Error *local_err = NULL;
+
+cpufreq = kvmppc_get_clockfreq(_err);
+if (local_err) {
+cpufreq = SPAPR_CLOCK_FREQ;
+}
+}
+
 _FDT((fdt_setprop_cell(fdt, offset, "clock-frequency", cpufreq)));
 _FDT((fdt_setprop_cell(fdt, offset, "slb-size", 
cpu->hash64_opts->slb_size)));
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,slb-size", 
cpu->hash64_opts->slb_size)));
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 072dda2c72..ed579635ca 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -26,6 +26,7 @@ typedef struct SpaprPendingHpt SpaprPendingHpt;
 #define SPAPR_ENTRY_POINT   0x100
 
 #define SPAPR_TIMEBASE_FREQ 51200ULL
+#define SPAPR_CLOCK_FREQ10ULL
 
 #define TYPE_SPAPR_RTC "spapr-rtc"
 
-- 
2.36.1

[PATCH 8/9] e500.c: use PLATFORM_CLK_FREQ_HZ if unable to read clock freq from DT

[Daniel Henrique Barboza]

Default 'clock_freq' to PLATFORM_CLK_FREQ_HZ if kvmppc_get_clockfreq()
fails to read the clock from the DT.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/e500.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 4b4e99ef3c..dc53d99b47 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -404,8 +404,14 @@ static int ppce500_load_device_tree(PPCE500MachineState 
*pms,
 fprintf(stderr, "couldn't set /chosen/bootargs\n");
 
 if (kvm_enabled()) {
+Error *local_err = NULL;
+
 /* Read out host's frequencies */
-clock_freq = kvmppc_get_clockfreq(NULL);
+clock_freq = kvmppc_get_clockfreq(_err);
+if (local_err) {
+clock_freq = PLATFORM_CLK_FREQ_HZ;
+}
+
 tb_freq = kvmppc_get_tbfreq();
 
 /* indicate KVM hypercall interface */
-- 
2.36.1

[PATCH 7/9] sam460ex.c: use CPU_FREQ if unable to read DT clock

[Daniel Henrique Barboza]

Fallback 'clock_freq' to CPU_FREQ if kvmppc_get_clockfreq() fails to
read the clock from the DT.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/sam460ex.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 4d25cb2c2e..0b3ce0cb17 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -178,8 +178,14 @@ static int sam460ex_load_device_tree(hwaddr addr,
  * directly access the timebase without host involvement, we must expose
  * the correct frequencies. */
 if (kvm_enabled()) {
+Error *local_err = NULL;
+
 tb_freq = kvmppc_get_tbfreq();
-clock_freq = kvmppc_get_clockfreq(NULL);
+clock_freq = kvmppc_get_clockfreq(_err);
+
+if (local_err) {
+clock_freq = CPU_FREQ;
+}
 }
 
 qemu_fdt_setprop_cell(fdt, "/cpus/cpu@0", "clock-frequency",
-- 
2.36.1

[PATCH 2/9] target/ppc: add errp to kvmppc_read_int_cpu_dt()

[Daniel Henrique Barboza]

The function can't just return 0 whether an error happened and call it a
day. We must provide a way of letting callers know if the zero return is
legitimate or due to an error.

Add an Error pointer to kvmppc_read_int_cpu_dt() that will be filled
with an appropriate error, if one occurs. Callers are then free to pass
an Error pointer and handle it.

Signed-off-by: Daniel Henrique Barboza 
---
 target/ppc/kvm.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 109823136d..bc17437097 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1925,15 +1925,17 @@ static uint64_t kvmppc_read_int_dt(const char *filename)
 
 /*
  * Read a CPU node property from the host device tree that's a single
- * integer (32-bit or 64-bit).  Returns 0 if anything goes wrong
- * (can't find or open the property, or doesn't understand the format)
+ * integer (32-bit or 64-bit).  Returns 0 and set errp if anything goes
+ * wrong (can't find or open the property, or doesn't understand the
+ * format)
  */
-static uint64_t kvmppc_read_int_cpu_dt(const char *propname)
+static uint64_t kvmppc_read_int_cpu_dt(const char *propname, Error **errp)
 {
 char buf[PATH_MAX], *tmp;
 uint64_t val;
 
 if (kvmppc_find_cpu_dt(buf, sizeof(buf))) {
+error_setg(errp, "Failed to read CPU property %s", propname);
 return 0;
 }
 
@@ -1946,12 +1948,12 @@ static uint64_t kvmppc_read_int_cpu_dt(const char 
*propname)
 
 uint64_t kvmppc_get_clockfreq(void)
 {
-return kvmppc_read_int_cpu_dt("clock-frequency");
+return kvmppc_read_int_cpu_dt("clock-frequency", NULL);
 }
 
 static int kvmppc_get_dec_bits(void)
 {
-int nr_bits = kvmppc_read_int_cpu_dt("ibm,dec-bits");
+int nr_bits = kvmppc_read_int_cpu_dt("ibm,dec-bits", NULL);
 
 if (nr_bits > 0) {
 return nr_bits;
@@ -2336,8 +2338,8 @@ static void alter_insns(uint64_t *word, uint64_t flags, 
bool on)
 static void kvmppc_host_cpu_class_init(ObjectClass *oc, void *data)
 {
 PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
-uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size");
-uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size");
+uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size", NULL);
+uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size", NULL);
 
 /* Now fix up the class with information we can query from the host */
 pcc->pvr = mfpvr();
-- 
2.36.1

[PATCH 6/9] ppc440_bamboo.c: handle clock freq read error in load_device_tree

[Daniel Henrique Barboza]

Let's put the default clock and timebase freq value in macros for better
readability.  Use PPC440EP_CLOCK_FREQ as the default value of
'clock_freq' if kvmppc_get_clockfreq() throws an error.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/ppc440_bamboo.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index d23f881d9d..6318112393 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -50,6 +50,10 @@
 
 #define PPC440EP_SDRAM_NR_BANKS 4
 
+#define PPC440EP_TB_FREQ4
+#define PPC440EP_CLOCK_FREQ 4
+
+
 static const ram_addr_t ppc440ep_sdram_bank_sizes[] = {
 256 * MiB, 128 * MiB, 64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 0
 };
@@ -67,8 +71,8 @@ static int bamboo_load_device_tree(hwaddr addr,
 char *filename;
 int fdt_size;
 void *fdt;
-uint32_t tb_freq = 4;
-uint32_t clock_freq = 4;
+uint32_t tb_freq = PPC440EP_TB_FREQ;
+uint32_t clock_freq = PPC440EP_CLOCK_FREQ;
 
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, BINARY_DEVICE_TREE_FILE);
 if (!filename) {
@@ -106,8 +110,15 @@ static int bamboo_load_device_tree(hwaddr addr,
  * directly access the timebase without host involvement, we must expose
  * the correct frequencies. */
 if (kvm_enabled()) {
+Error *local_err = NULL;
+
 tb_freq = kvmppc_get_tbfreq();
-clock_freq = kvmppc_get_clockfreq(NULL);
+clock_freq = kvmppc_get_clockfreq(_err);
+
+/* Use default clock if we're unable to read it from the DT */
+if (local_err) {
+clock_freq = PPC440EP_CLOCK_FREQ;
+}
 }
 
 qemu_fdt_setprop_cell(fdt, "/cpus/cpu@0", "clock-frequency",
-- 
2.36.1

[PATCH 3/9] target/ppc: Add error reporting when opening file fails

[Daniel Henrique Barboza]

From: jianchunfu 

Add error reporting before return when opening file fails in
kvmppc_read_int_dt().

Signed-off-by: jianchunfu 
[danielhb: use error_setg() instead of fprintf]
Signed-off-by: Daniel Henrique Barboza 
---
 target/ppc/kvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index bc17437097..7611e9ccf6 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1896,7 +1896,7 @@ static int kvmppc_find_cpu_dt(char *buf, int buf_len)
 return 0;
 }
 
-static uint64_t kvmppc_read_int_dt(const char *filename)
+static uint64_t kvmppc_read_int_dt(const char *filename, Error **errp)
 {
 union {
 uint32_t v32;
@@ -1907,6 +1907,7 @@ static uint64_t kvmppc_read_int_dt(const char *filename)
 
 f = fopen(filename, "rb");
 if (!f) {
+error_setg(errp, "Error opening %s: %s", filename, strerror(errno));
 return 0;
 }
 
@@ -1940,7 +1941,7 @@ static uint64_t kvmppc_read_int_cpu_dt(const char 
*propname, Error **errp)
 }
 
 tmp = g_strdup_printf("%s/%s", buf, propname);
-val = kvmppc_read_int_dt(tmp);
+val = kvmppc_read_int_dt(tmp, errp);
 g_free(tmp);
 
 return val;
-- 
2.36.1

[PATCH 5/5] target/arm: Correctly implement Feat_DoubleLock

[Peter Maydell]

The architecture defines the OS DoubleLock as a register which
(similarly to the OS Lock) suppresses debug events for use in CPU
powerdown sequences.  This functionality is required in Arm v7 and
v8.0; from v8.2 it becomes optional and in v9 it must not be
implemented.

Currently in QEMU we implement the OSDLR_EL1 register as a NOP.  This
is wrong both for the "feature implemented" and the "feature not
implemented" cases: if the feature is implemented then the DLK bit
should read as written and cause suppression of debug exceptions, and
if it is not implemented then the bit must be RAZ/WI.

Signed-off-by: Peter Maydell 
---
Is there a nicer way to implement the isar_any feature test ?
What I have here is correct but a bit ad-hoc.
---
 target/arm/cpu.h  | 36 
 target/arm/debug_helper.c | 17 +++--
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index c533ad0b64d..069dfe1d308 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -500,6 +500,7 @@ typedef struct CPUArchState {
 uint64_t dbgwcr[16]; /* watchpoint control registers */
 uint64_t mdscr_el1;
 uint64_t oslsr_el1; /* OS Lock Status */
+uint64_t osdlr_el1; /* OS DoubleLock status */
 uint64_t mdcr_el2;
 uint64_t mdcr_el3;
 /* Stores the architectural value of the counter *the last time it was
@@ -2253,6 +2254,15 @@ FIELD(DBGDIDR, CTX_CMPS, 20, 4)
 FIELD(DBGDIDR, BRPS, 24, 4)
 FIELD(DBGDIDR, WRPS, 28, 4)
 
+FIELD(DBGDEVID, PCSAMPLE, 0, 4)
+FIELD(DBGDEVID, WPADDRMASK, 4, 4)
+FIELD(DBGDEVID, BPADDRMASK, 8, 4)
+FIELD(DBGDEVID, VECTORCATCH, 12, 4)
+FIELD(DBGDEVID, VIRTEXTNS, 16, 4)
+FIELD(DBGDEVID, DOUBLELOCK, 20, 4)
+FIELD(DBGDEVID, AUXREGS, 24, 4)
+FIELD(DBGDEVID, CIDMASK, 28, 4)
+
 FIELD(MVFR0, SIMDREG, 0, 4)
 FIELD(MVFR0, FPSP, 4, 4)
 FIELD(MVFR0, FPDP, 8, 4)
@@ -3731,6 +3741,11 @@ static inline bool isar_feature_aa32_debugv8p2(const 
ARMISARegisters *id)
 return FIELD_EX32(id->id_dfr0, ID_DFR0, COPDBG) >= 8;
 }
 
+static inline bool isar_feature_aa32_doublelock(const ARMISARegisters *id)
+{
+return FIELD_EX32(id->dbgdevid, DBGDEVID, DOUBLELOCK) > 0;
+}
+
 /*
  * 64-bit feature tests via id registers.
  */
@@ -4155,6 +4170,11 @@ static inline bool isar_feature_aa64_sme_fa64(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64smfr0, ID_AA64SMFR0, FA64);
 }
 
+static inline bool isar_feature_aa64_doublelock(const ARMISARegisters *id)
+{
+return FIELD_SEX64(id->id_aa64dfr0, ID_AA64DFR0, DOUBLELOCK) >= 0;
+}
+
 /*
  * Feature tests for "does this exist in either 32-bit or 64-bit?"
  */
@@ -4198,6 +4218,22 @@ static inline bool isar_feature_any_ras(const 
ARMISARegisters *id)
 return isar_feature_aa64_ras(id) || isar_feature_aa32_ras(id);
 }
 
+static inline bool isar_feature_any_doublelock(const ARMISARegisters *id)
+{
+/*
+ * We can't just OR together the aa32 and aa64 checks, because
+ * if there is no AArch64 support the aa64 function will default
+ * to returning true for a zero id_aa64dfr0.
+ * We use "is id_aa64pfr0 non-zero" as a proxy for "do we have
+ * the AArch64 ID register values in id", because it's always the
+ * case that ID_AA64PFR0_EL1.EL0 at least will be non-zero.
+ */
+if (id->id_aa64pfr0) {
+return isar_feature_aa64_doublelock(id);
+}
+return isar_feature_aa32_doublelock(id);
+}
+
 /*
  * Forward to the above feature tests given an ARMCPU pointer.
  */
diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index e96a4ffd28d..62bd8f85383 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -142,7 +142,7 @@ static bool aa32_generate_debug_exceptions(CPUARMState *env)
  */
 bool arm_generate_debug_exceptions(CPUARMState *env)
 {
-if (env->cp15.oslsr_el1 & 1) {
+if ((env->cp15.oslsr_el1 & 1) || (env->cp15.osdlr_el1 & 1)) {
 return false;
 }
 if (is_a64(env)) {
@@ -614,6 +614,18 @@ static void oslar_write(CPUARMState *env, const 
ARMCPRegInfo *ri,
 env->cp15.oslsr_el1 = deposit32(env->cp15.oslsr_el1, 1, 1, oslock);
 }
 
+static void osdlr_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+/*
+ * Only defined bit is bit 0 (DLK); if Feat_DoubleLock is not
+ * implemented this is RAZ/WI.
+ */
+if (cpu_isar_feature(any_doublelock, env_archcpu(env))) {
+env->cp15.osdlr_el1 = value & 1;
+}
+}
+
 static const ARMCPRegInfo debug_cp_reginfo[] = {
 /*
  * DBGDRAR, DBGDSAR: always RAZ since we don't implement memory mapped
@@ -670,7 +682,8 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
 { .name = "OSDLR_EL1", .state = ARM_CP_STATE_BOTH,
   .cp = 14, .opc0 = 2, .opc1 = 0, .crn = 1, .crm = 3, .opc2 = 4,
   .access = PL1_RW, .accessfn = access_tdosa,
-  .type = ARM_CP_NOP },
+  .writefn = osdlr_write,
+  .fieldoffset = offsetof(CPUARMState, 

[PATCH 4/9] target/ppc: use g_autofree in kvmppc_read_int_cpu_dt()

[Daniel Henrique Barboza]

This spares us a g_free() call. Let's also not use 'val' and return the
value of kvmppc_read_int_dt() directly.

Signed-off-by: Daniel Henrique Barboza 
---
 target/ppc/kvm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 7611e9ccf6..c218380eb7 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1932,8 +1932,8 @@ static uint64_t kvmppc_read_int_dt(const char *filename, 
Error **errp)
  */
 static uint64_t kvmppc_read_int_cpu_dt(const char *propname, Error **errp)
 {
-char buf[PATH_MAX], *tmp;
-uint64_t val;
+g_autofree char *tmp = NULL;
+char buf[PATH_MAX];
 
 if (kvmppc_find_cpu_dt(buf, sizeof(buf))) {
 error_setg(errp, "Failed to read CPU property %s", propname);
@@ -1941,10 +1941,8 @@ static uint64_t kvmppc_read_int_cpu_dt(const char 
*propname, Error **errp)
 }
 
 tmp = g_strdup_printf("%s/%s", buf, propname);
-val = kvmppc_read_int_dt(tmp, errp);
-g_free(tmp);
 
-return val;
+return kvmppc_read_int_dt(tmp, errp);
 }
 
 uint64_t kvmppc_get_clockfreq(void)
-- 
2.36.1

[PATCH 2/5] target/arm: Move define_debug_regs() to debug_helper.c

[Peter Maydell]

The target/arm/helper.c file is very long and is a grabbag of all
kinds of functionality.  We have already a debug_helper.c which has
code for implementing architectural debug.  Move the code which
defines the debug-related system registers out to this file also.
This affects the define_debug_regs() function and the various
functions and arrays which are used only by it.

The functions raw_write() and arm_mdcr_el2_eff() and
define_debug_regs() now need to be global rather than local to
helper.c; everything else is pure code movement.

Signed-off-by: Peter Maydell 
---
 target/arm/cpregs.h   |   3 +
 target/arm/internals.h|   9 +
 target/arm/debug_helper.c | 525 +
 target/arm/helper.c   | 531 +-
 4 files changed, 538 insertions(+), 530 deletions(-)

diff --git a/target/arm/cpregs.h b/target/arm/cpregs.h
index d30758ee713..7e78c2c05c6 100644
--- a/target/arm/cpregs.h
+++ b/target/arm/cpregs.h
@@ -442,6 +442,9 @@ void arm_cp_write_ignore(CPUARMState *env, const 
ARMCPRegInfo *ri,
 /* CPReadFn that can be used for read-as-zero behaviour */
 uint64_t arm_cp_read_zero(CPUARMState *env, const ARMCPRegInfo *ri);
 
+/* CPWriteFn that just writes the value to ri->fieldoffset */
+void raw_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value);
+
 /*
  * CPResetFn that does nothing, for use if no reset is required even
  * if fieldoffset is non zero.
diff --git a/target/arm/internals.h b/target/arm/internals.h
index c66f74a0db1..00e2e710f6c 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1307,6 +1307,15 @@ int exception_target_el(CPUARMState *env);
 bool arm_singlestep_active(CPUARMState *env);
 bool arm_generate_debug_exceptions(CPUARMState *env);
 
+/* Add the cpreg definitions for debug related system registers */
+void define_debug_regs(ARMCPU *cpu);
+
+/* Effective value of MDCR_EL2 */
+static inline uint64_t arm_mdcr_el2_eff(CPUARMState *env)
+{
+return arm_is_el2_enabled(env) ? env->cp15.mdcr_el2 : 0;
+}
+
 /* Powers of 2 for sve_vq_map et al. */
 #define SVE_VQ_POW2_MAP \
 ((1 << (1 - 1)) | (1 << (2 - 1)) |  \
diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index b18a6bd3a23..9a78c1db966 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -6,8 +6,10 @@
  * SPDX-License-Identifier: GPL-2.0-or-later
  */
 #include "qemu/osdep.h"
+#include "qemu/log.h"
 #include "cpu.h"
 #include "internals.h"
+#include "cpregs.h"
 #include "exec/exec-all.h"
 #include "exec/helper-proto.h"
 
@@ -528,6 +530,529 @@ void HELPER(exception_swstep)(CPUARMState *env, uint32_t 
syndrome)
 raise_exception_debug(env, EXCP_UDEF, syndrome);
 }
 
+/*
+ * Check for traps to "powerdown debug" registers, which are controlled
+ * by MDCR.TDOSA
+ */
+static CPAccessResult access_tdosa(CPUARMState *env, const ARMCPRegInfo *ri,
+   bool isread)
+{
+int el = arm_current_el(env);
+uint64_t mdcr_el2 = arm_mdcr_el2_eff(env);
+bool mdcr_el2_tdosa = (mdcr_el2 & MDCR_TDOSA) || (mdcr_el2 & MDCR_TDE) ||
+(arm_hcr_el2_eff(env) & HCR_TGE);
+
+if (el < 2 && mdcr_el2_tdosa) {
+return CP_ACCESS_TRAP_EL2;
+}
+if (el < 3 && (env->cp15.mdcr_el3 & MDCR_TDOSA)) {
+return CP_ACCESS_TRAP_EL3;
+}
+return CP_ACCESS_OK;
+}
+
+/*
+ * Check for traps to "debug ROM" registers, which are controlled
+ * by MDCR_EL2.TDRA for EL2 but by the more general MDCR_EL3.TDA for EL3.
+ */
+static CPAccessResult access_tdra(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+int el = arm_current_el(env);
+uint64_t mdcr_el2 = arm_mdcr_el2_eff(env);
+bool mdcr_el2_tdra = (mdcr_el2 & MDCR_TDRA) || (mdcr_el2 & MDCR_TDE) ||
+(arm_hcr_el2_eff(env) & HCR_TGE);
+
+if (el < 2 && mdcr_el2_tdra) {
+return CP_ACCESS_TRAP_EL2;
+}
+if (el < 3 && (env->cp15.mdcr_el3 & MDCR_TDA)) {
+return CP_ACCESS_TRAP_EL3;
+}
+return CP_ACCESS_OK;
+}
+
+/*
+ * Check for traps to general debug registers, which are controlled
+ * by MDCR_EL2.TDA for EL2 and MDCR_EL3.TDA for EL3.
+ */
+static CPAccessResult access_tda(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+int el = arm_current_el(env);
+uint64_t mdcr_el2 = arm_mdcr_el2_eff(env);
+bool mdcr_el2_tda = (mdcr_el2 & MDCR_TDA) || (mdcr_el2 & MDCR_TDE) ||
+(arm_hcr_el2_eff(env) & HCR_TGE);
+
+if (el < 2 && mdcr_el2_tda) {
+return CP_ACCESS_TRAP_EL2;
+}
+if (el < 3 && (env->cp15.mdcr_el3 & MDCR_TDA)) {
+return CP_ACCESS_TRAP_EL3;
+}
+return CP_ACCESS_OK;
+}
+
+static void oslar_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+/*
+ * Writes to OSLAR_EL1 may update the OS lock status, which can be
+ * read via a bit in 

[PATCH 4/5] target/arm: Implement AArch32 DBGDEVID, DBGDEVID1, DBGDEVID2

[Peter Maydell]

Starting with v7 of the debug architecture, there are three extra
ID registers that add information on top of that provided in
DBGDIDR. These are DBGDEVID, DBGDEVID1 and DBGDEVID2. In the
v7 debug architecture, DBGDEVID is optional, present only of
DBGDIDR.DEVID_imp is set. In v7.1 all three must be present.

Implement the missing registers.  Note that we only need to set the
values in the ARMISARegisters struct for the CPUs Cortex-A7, A15,
A53, A57 and A72 (plus the 32-bit 'max' which uses the Cortex-A53
values): earlier CPUs didn't implement v7 of the architecture, and
our other 64-bit CPUs (Cortex-A76, Neoverse-N1 and A64fx) don't have
AArch32 support at EL1.

Signed-off-by: Peter Maydell 
---
Clearly no guest code users care about is trying to read these
registers, or they'd have noticed the UNDEFs. But the AArch32
indicator that Feat_DoubleLock is present is in DBGDEVID, so
I want it in ARMISARegisters so I can test against it.
---
 target/arm/cpu.h  |  7 +++
 target/arm/cpu64.c|  6 ++
 target/arm/cpu_tcg.c  |  6 ++
 target/arm/debug_helper.c | 36 
 4 files changed, 55 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 4a4342f2622..c533ad0b64d 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -988,6 +988,8 @@ struct ArchCPU {
 uint32_t mvfr2;
 uint32_t id_dfr0;
 uint32_t dbgdidr;
+uint32_t dbgdevid;
+uint32_t dbgdevid1;
 uint64_t id_aa64isar0;
 uint64_t id_aa64isar1;
 uint64_t id_aa64pfr0;
@@ -3719,6 +3721,11 @@ static inline bool isar_feature_aa32_ssbs(const 
ARMISARegisters *id)
 return FIELD_EX32(id->id_pfr2, ID_PFR2, SSBS) != 0;
 }
 
+static inline bool isar_feature_aa32_debugv7p1(const ARMISARegisters *id)
+{
+return FIELD_EX32(id->id_dfr0, ID_DFR0, COPDBG) >= 5;
+}
+
 static inline bool isar_feature_aa32_debugv8p2(const ARMISARegisters *id)
 {
 return FIELD_EX32(id->id_dfr0, ID_DFR0, COPDBG) >= 8;
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 19188d6cc2a..b4fd4b7ec87 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -79,6 +79,8 @@ static void aarch64_a57_initfn(Object *obj)
 cpu->isar.id_aa64isar0 = 0x00011120;
 cpu->isar.id_aa64mmfr0 = 0x1124;
 cpu->isar.dbgdidr = 0x3516d000;
+cpu->isar.dbgdevid = 0x01110f13;
+cpu->isar.dbgdevid1 = 0x2;
 cpu->isar.reset_pmcr_el0 = 0x41013000;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
@@ -134,6 +136,8 @@ static void aarch64_a53_initfn(Object *obj)
 cpu->isar.id_aa64isar0 = 0x00011120;
 cpu->isar.id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */
 cpu->isar.dbgdidr = 0x3516d000;
+cpu->isar.dbgdevid = 0x00110f13;
+cpu->isar.dbgdevid1 = 0x1;
 cpu->isar.reset_pmcr_el0 = 0x41033000;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x700fe01a; /* 32KB L1 dcache */
@@ -187,6 +191,8 @@ static void aarch64_a72_initfn(Object *obj)
 cpu->isar.id_aa64isar0 = 0x00011120;
 cpu->isar.id_aa64mmfr0 = 0x1124;
 cpu->isar.dbgdidr = 0x3516d000;
+cpu->isar.dbgdevid = 0x01110f13;
+cpu->isar.dbgdevid1 = 0x2;
 cpu->isar.reset_pmcr_el0 = 0x41023000;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index b751a19c8a7..3099b38e32b 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -563,6 +563,8 @@ static void cortex_a7_initfn(Object *obj)
 cpu->isar.id_isar3 = 0x2131;
 cpu->isar.id_isar4 = 0x10011142;
 cpu->isar.dbgdidr = 0x3515f005;
+cpu->isar.dbgdevid = 0x01110f13;
+cpu->isar.dbgdevid1 = 0x1;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x701fe00a; /* 32K L1 dcache */
 cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */
@@ -606,6 +608,8 @@ static void cortex_a15_initfn(Object *obj)
 cpu->isar.id_isar3 = 0x2131;
 cpu->isar.id_isar4 = 0x10011142;
 cpu->isar.dbgdidr = 0x3515f021;
+cpu->isar.dbgdevid = 0x01110f13;
+cpu->isar.dbgdevid1 = 0x0;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x701fe00a; /* 32K L1 dcache */
 cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */
@@ -1098,6 +1102,8 @@ static void arm_max_initfn(Object *obj)
 cpu->isar.id_isar5 = 0x00011121;
 cpu->isar.id_isar6 = 0;
 cpu->isar.dbgdidr = 0x3516d000;
+cpu->isar.dbgdevid = 0x00110f13;
+cpu->isar.dbgdevid1 = 0x2;
 cpu->isar.reset_pmcr_el0 = 0x41013000;
 cpu->clidr = 0x0a200023;
 cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index 691b9b74c4a..e96a4ffd28d 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -999,6 +999,42 @@ void define_debug_regs(ARMCPU *cpu)
 define_one_arm_cp_reg(cpu, );
 }
 
+/*
+ * DBGDEVID is present in the v7 debug architecture if
+ * DBGDIDR.DEVID_imp is 1 (bit 15); from 

[PATCH 3/5] target/arm: Suppress debug exceptions when OS Lock set

[Peter Maydell]

The "OS Lock" in the Arm debug architecture is a way for software
to suppress debug exceptions while it is trying to power down
a CPU and save the state of the breakpoint and watchpoint
registers. In QEMU we implemented the support for writing
the OS Lock bit via OSLAR_EL1 and reading it via OSLSR_EL1,
but didn't implement the actual behaviour.

The required behaviour with the OS Lock set is:
 * debug exceptions (apart from BKPT insns) are suppressed
 * some MDSCR_EL1 bits allow write access to the corresponding
   EDSCR external debug status register that they shadow
   (we can ignore this because we don't implement external debug)
 * similarly with the OSECCR_EL1 which shadows the EDECCR
   (but we don't implement OSECCR_EL1 anyway)

Implement the missing behaviour of suppressing debug
exceptions.

Signed-off-by: Peter Maydell 
---
 target/arm/debug_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index 9a78c1db966..691b9b74c4a 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -142,6 +142,9 @@ static bool aa32_generate_debug_exceptions(CPUARMState *env)
  */
 bool arm_generate_debug_exceptions(CPUARMState *env)
 {
+if (env->cp15.oslsr_el1 & 1) {
+return false;
+}
 if (is_a64(env)) {
 return aa64_generate_debug_exceptions(env);
 } else {
-- 
2.25.1

[PATCH 0/5] target/arm: Implement (or don't) OS Lock and DoubleLock properly

[Peter Maydell]

Continuing in my series of filling in bits of the architecture
that probably nobody much cares about, this series fixes up
Feat_DoubleLock. DoubleLock is a part of the debug architecture
which allows a guest OS to suppress debug exceptions while
it is powering down a CPU so that they don't cause updates to
bits of debug register state that then don't get preserved
across the power-down/up sequence. The reason for looking
at QEMU's support here is that recent versions of the architecture
define that the feature becomes first optional (after v8.2 or
so) and then mustn't be implemented at all at v9.

We have only ever implemented this by NOPing the OSDLR_EL1 register,
which is not correct for either the "implement the feature"
or the "don't implement the feature" case. What is supposed
to happen is that if the feature is implemented then there is
one writable bit which is set to 1 to suppress debug exceptions,
and if the feature is not implemented then the bit is RAZ/WI.
We also don't properly implement the related OS Lock which
does something very similar. There we correctly implemented
the register reading and writing parts but didn't make the
bit do anything.

The series starts with some code movement, while I was messing
with the debug code, shifting 500 lines of debug related code
out of the massive helper.c and into debug_helper.c. Patch 2
is big but almost entirely pure code motion (best reviewed with
git's --color-moved support). I think this helps in our
ongoing quest to make helper.c less of a massive grabbag
of miscellaneous things.

Patch 3 implements the required behaviour of the OS Lock
(which turns out to be very easy).

Patch 4 adds support for some AArch32 debug ID registers we
turn out to be missing. Clearly nobody was trying to read these,
but one of them is where the field for "is FEAT_DoubleLock
present" is kept, so we need the data internally.

Finally, patch 5 fixes the implementation of OSDLR_EL1 to
either be RAZ/WI or to have a bit that has the required
suppress-debug-exceptions behaviour.

thanks
-- PMM

Peter Maydell (5):
  target/arm: Fix code style issues in debug helper functions
  target/arm: Move define_debug_regs() to debug_helper.c
  target/arm: Suppress debug exceptions when OS Lock set
  target/arm: Implement AArch32 DBGDEVID, DBGDEVID1, DBGDEVID2
  target/arm: Correctly implement Feat_DoubleLock

 target/arm/cpregs.h   |   3 +
 target/arm/cpu.h  |  43 +++
 target/arm/internals.h|   9 +
 target/arm/cpu64.c|   6 +
 target/arm/cpu_tcg.c  |   6 +
 target/arm/debug_helper.c | 577 ++
 target/arm/helper.c   | 513 +
 7 files changed, 645 insertions(+), 512 deletions(-)

-- 
2.25.1

[PATCH 1/5] target/arm: Fix code style issues in debug helper functions

[Peter Maydell]

Before moving debug system register helper functions to a
different file, fix the code style issues (mostly block
comment syntax) so checkpatch doesn't complain about the
code-motion patch.

Signed-off-by: Peter Maydell 
---
 target/arm/helper.c | 58 +
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index f6dcb1a1152..1c7ec2f8678 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -307,7 +307,8 @@ static uint64_t arm_mdcr_el2_eff(CPUARMState *env)
 return arm_is_el2_enabled(env) ? env->cp15.mdcr_el2 : 0;
 }
 
-/* Check for traps to "powerdown debug" registers, which are controlled
+/*
+ * Check for traps to "powerdown debug" registers, which are controlled
  * by MDCR.TDOSA
  */
 static CPAccessResult access_tdosa(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -327,7 +328,8 @@ static CPAccessResult access_tdosa(CPUARMState *env, const 
ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
-/* Check for traps to "debug ROM" registers, which are controlled
+/*
+ * Check for traps to "debug ROM" registers, which are controlled
  * by MDCR_EL2.TDRA for EL2 but by the more general MDCR_EL3.TDA for EL3.
  */
 static CPAccessResult access_tdra(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -347,7 +349,8 @@ static CPAccessResult access_tdra(CPUARMState *env, const 
ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
-/* Check for traps to general debug registers, which are controlled
+/*
+ * Check for traps to general debug registers, which are controlled
  * by MDCR_EL2.TDA for EL2 and MDCR_EL3.TDA for EL3.
  */
 static CPAccessResult access_tda(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -5982,7 +5985,8 @@ static CPAccessResult ctr_el0_access(CPUARMState *env, 
const ARMCPRegInfo *ri,
 static void oslar_write(CPUARMState *env, const ARMCPRegInfo *ri,
 uint64_t value)
 {
-/* Writes to OSLAR_EL1 may update the OS lock status, which can be
+/*
+ * Writes to OSLAR_EL1 may update the OS lock status, which can be
  * read via a bit in OSLSR_EL1.
  */
 int oslock;
@@ -5997,7 +6001,8 @@ static void oslar_write(CPUARMState *env, const 
ARMCPRegInfo *ri,
 }
 
 static const ARMCPRegInfo debug_cp_reginfo[] = {
-/* DBGDRAR, DBGDSAR: always RAZ since we don't implement memory mapped
+/*
+ * DBGDRAR, DBGDSAR: always RAZ since we don't implement memory mapped
  * debug components. The AArch64 version of DBGDRAR is named MDRAR_EL1;
  * unlike DBGDRAR it is never accessible from EL0.
  * DBGDSAR is deprecated and must RAZ from v8 anyway, so it has no AArch64
@@ -6052,21 +6057,24 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
   .cp = 14, .opc0 = 2, .opc1 = 0, .crn = 1, .crm = 3, .opc2 = 4,
   .access = PL1_RW, .accessfn = access_tdosa,
   .type = ARM_CP_NOP },
-/* Dummy DBGVCR: Linux wants to clear this on startup, but we don't
+/*
+ * Dummy DBGVCR: Linux wants to clear this on startup, but we don't
  * implement vector catch debug events yet.
  */
 { .name = "DBGVCR",
   .cp = 14, .opc1 = 0, .crn = 0, .crm = 7, .opc2 = 0,
   .access = PL1_RW, .accessfn = access_tda,
   .type = ARM_CP_NOP },
-/* Dummy DBGVCR32_EL2 (which is only for a 64-bit hypervisor
+/*
+ * Dummy DBGVCR32_EL2 (which is only for a 64-bit hypervisor
  * to save and restore a 32-bit guest's DBGVCR)
  */
 { .name = "DBGVCR32_EL2", .state = ARM_CP_STATE_AA64,
   .opc0 = 2, .opc1 = 4, .crn = 0, .crm = 7, .opc2 = 0,
   .access = PL2_RW, .accessfn = access_tda,
   .type = ARM_CP_NOP | ARM_CP_EL3_NO_EL2_KEEP },
-/* Dummy MDCCINT_EL1, since we don't implement the Debug Communications
+/*
+ * Dummy MDCCINT_EL1, since we don't implement the Debug Communications
  * Channel but Linux may try to access this register. The 32-bit
  * alias is DBGDCCINT.
  */
@@ -6079,9 +6087,9 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
 static const ARMCPRegInfo debug_lpae_cp_reginfo[] = {
 /* 64 bit access versions of the (dummy) debug registers */
 { .name = "DBGDRAR", .cp = 14, .crm = 1, .opc1 = 0,
-  .access = PL0_R, .type = ARM_CP_CONST|ARM_CP_64BIT, .resetvalue = 0 },
+  .access = PL0_R, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
 { .name = "DBGDSAR", .cp = 14, .crm = 2, .opc1 = 0,
-  .access = PL0_R, .type = ARM_CP_CONST|ARM_CP_64BIT, .resetvalue = 0 },
+  .access = PL0_R, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
 };
 
 /*
@@ -6496,13 +6504,15 @@ void hw_watchpoint_update(ARMCPU *cpu, int n)
 break;
 }
 
-/* Attempts to use both MASK and BAS fields simultaneously are
+/*
+ * Attempts to use both MASK and BAS fields simultaneously are
  * CONSTRAINED UNPREDICTABLE; we opt to ignore BAS in this case,
  * thus generating a watchpoint for every byte in the masked region.
  */
 mask = FIELD_EX64(wcr, 

Re: [PATCH v3 09/14] hw/sensor: Add IC_DEVICE_ID to ISL voltage regulators

[Titus Rwantare]

On Wed, 29 Jun 2022 at 21:52, Peter Delevoryas  wrote:
>
> From: Peter Delevoryas 
>
> This commit adds a passthrough for PMBUS_IC_DEVICE_ID to allow Renesas
> voltage regulators to return the integrated circuit device ID if they
> would like to.
>
> The behavior is very device specific, so it hasn't been added to the
> general PMBUS model. Additionally, if the device ID hasn't been set,
> then the voltage regulator will respond with the error byte value.  The
> guest error message will change slightly for IC_DEVICE_ID with this
> commit.
>
> Signed-off-by: Peter Delevoryas 
> ---
>  hw/sensor/isl_pmbus_vr.c | 12 
>  include/hw/sensor/isl_pmbus_vr.h |  5 +
>  2 files changed, 17 insertions(+)
>
> diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
> index e11e028884..799ea9d89e 100644
> --- a/hw/sensor/isl_pmbus_vr.c
> +++ b/hw/sensor/isl_pmbus_vr.c
> @@ -15,6 +15,18 @@
>
>  static uint8_t isl_pmbus_vr_read_byte(PMBusDevice *pmdev)
>  {
> +ISLState *s = ISL69260(pmdev);
> +
> +switch (pmdev->code) {
> +case PMBUS_IC_DEVICE_ID:
> +if (!s->ic_device_id_len) {
> +break;
> +}
> +pmbus_send(pmdev, s->ic_device_id, s->ic_device_id_len);
> +pmbus_idle(pmdev);
> +return 0;
> +}
> +
>  qemu_log_mask(LOG_GUEST_ERROR,
>"%s: reading from unsupported register: 0x%02x\n",
>__func__, pmdev->code);
> diff --git a/include/hw/sensor/isl_pmbus_vr.h 
> b/include/hw/sensor/isl_pmbus_vr.h
> index 3e47ff7e48..aa2c2767df 100644
> --- a/include/hw/sensor/isl_pmbus_vr.h
> +++ b/include/hw/sensor/isl_pmbus_vr.h
> @@ -12,12 +12,17 @@
>  #include "hw/i2c/pmbus_device.h"
>  #include "qom/object.h"
>
> +#define TYPE_ISL69259   "isl69259"
>  #define TYPE_ISL69260   "isl69260"
>  #define TYPE_RAA228000  "raa228000"
>  #define TYPE_RAA229004  "raa229004"
> +#define ISL_MAX_IC_DEVICE_ID_LEN 16
>
>  struct ISLState {
>  PMBusDevice parent;
> +
> +uint8_t ic_device_id[ISL_MAX_IC_DEVICE_ID_LEN];
> +uint8_t ic_device_id_len;
>  };
>
>  OBJECT_DECLARE_SIMPLE_TYPE(ISLState, ISL69260)
> --
> 2.37.0
>
Reviewed-by: Titus Rwantare 

Re: [PATCH v3 08/14] hw/i2c/pmbus: Add idle state to return 0xff's

[Titus Rwantare]

On Wed, 29 Jun 2022 at 21:52, Peter Delevoryas  wrote:
>
> From: Peter Delevoryas 
>
> Signed-off-by: Peter Delevoryas 
> ---
>  hw/i2c/pmbus_device.c | 9 +
>  include/hw/i2c/pmbus_device.h | 7 +++
>  2 files changed, 16 insertions(+)
>
> diff --git a/hw/i2c/pmbus_device.c b/hw/i2c/pmbus_device.c
> index 62885fa6a1..f89fea65f3 100644
> --- a/hw/i2c/pmbus_device.c
> +++ b/hw/i2c/pmbus_device.c
> @@ -261,6 +261,11 @@ void pmbus_check_limits(PMBusDevice *pmdev)
>  }
>  }
>
> +void pmbus_idle(PMBusDevice *pmdev)
> +{
> +pmdev->code = PMBUS_IDLE_STATE;
> +}
> +
>  /* assert the status_cml error upon receipt of malformed command */
>  static void pmbus_cml_error(PMBusDevice *pmdev)
>  {
> @@ -984,6 +989,10 @@ static uint8_t pmbus_receive_byte(SMBusDevice *smd)
>  }
>  break;
>
> +case PMBUS_IDLE_STATE:
> +pmbus_send8(pmdev, PMBUS_ERR_BYTE);
> +break;
> +
>  case PMBUS_CLEAR_FAULTS:  /* Send Byte */
>  case PMBUS_PAGE_PLUS_WRITE:   /* Block Write-only */
>  case PMBUS_STORE_DEFAULT_ALL: /* Send Byte */
> diff --git a/include/hw/i2c/pmbus_device.h b/include/hw/i2c/pmbus_device.h
> index 0f4d6b3fad..93f5d57c9d 100644
> --- a/include/hw/i2c/pmbus_device.h
> +++ b/include/hw/i2c/pmbus_device.h
> @@ -155,6 +155,7 @@ enum pmbus_registers {
>  PMBUS_MFR_MAX_TEMP_1= 0xC0, /* R/W word */
>  PMBUS_MFR_MAX_TEMP_2= 0xC1, /* R/W word */
>  PMBUS_MFR_MAX_TEMP_3= 0xC2, /* R/W word */
> +PMBUS_IDLE_STATE= 0xFF,
>  };
>
>  /* STATUS_WORD */
> @@ -527,6 +528,12 @@ int pmbus_page_config(PMBusDevice *pmdev, uint8_t 
> page_index, uint64_t flags);
>   */
>  void pmbus_check_limits(PMBusDevice *pmdev);
>
> +/**
> + * Enter an idle state where only the PMBUS_ERR_BYTE will be returned
> + * indefinitely until a new command is issued.
> + */
> +void pmbus_idle(PMBusDevice *pmdev);
> +
>  extern const VMStateDescription vmstate_pmbus_device;
>
>  #define VMSTATE_PMBUS_DEVICE(_field, _state) {   \
> --
> 2.37.0
>

Reviewed-by: Titus Rwantare 

Re: [PATCH v3 10/14] hw/sensor: Add Renesas ISL69259 device model

[Titus Rwantare]

On Wed, 29 Jun 2022 at 21:52, Peter Delevoryas  wrote:
>
> From: Peter Delevoryas 
>
> This adds the ISL69259, using all the same functionality as the existing
> ISL69260 but overriding the IC_DEVICE_ID.
>
> Signed-off-by: Peter Delevoryas 
> ---
>  hw/sensor/isl_pmbus_vr.c | 28 
>  1 file changed, 28 insertions(+)
>
> diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
> index 799ea9d89e..853d70536f 100644
> --- a/hw/sensor/isl_pmbus_vr.c
> +++ b/hw/sensor/isl_pmbus_vr.c
> @@ -119,6 +119,18 @@ static void raa228000_exit_reset(Object *obj)
>  pmdev->pages[0].read_temperature_3 = 0;
>  }
>
> +static void isl69259_exit_reset(Object *obj)
> +{
> +ISLState *s = ISL69260(obj);
> +static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2, 0x49, 
> 0x3c};
> +g_assert_cmphex(sizeof(ic_device_id), <=, sizeof(s->ic_device_id));
> +

This generates an error from the checkpatch script:
Checking 0010-hw-sensor-Add-Renesas-ISL69259-device-model.patch...
ERROR: Use g_assert or g_assert_not_reached
#27: FILE: hw/sensor/isl_pmbus_vr.c:126:
+g_assert_cmphex(sizeof(ic_device_id), <=, sizeof(s->ic_device_id));

otherwise, LGTM.


Titus

Re: [PATCH v3 10/14] hw/sensor: Add Renesas ISL69259 device model

[Titus Rwantare]

On Wed, 29 Jun 2022 at 23:30, Cédric Le Goater  wrote:
>
> On 6/30/22 06:51, Peter Delevoryas wrote:
> > From: Peter Delevoryas 
> >
> > This adds the ISL69259, using all the same functionality as the existing
> > ISL69260 but overriding the IC_DEVICE_ID.
> >
> > Signed-off-by: Peter Delevoryas 
> > ---
> >   hw/sensor/isl_pmbus_vr.c | 28 
> >   1 file changed, 28 insertions(+)
> >
> > diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
> > index 799ea9d89e..853d70536f 100644
> > --- a/hw/sensor/isl_pmbus_vr.c
> > +++ b/hw/sensor/isl_pmbus_vr.c
> > @@ -119,6 +119,18 @@ static void raa228000_exit_reset(Object *obj)
> >   pmdev->pages[0].read_temperature_3 = 0;
> >   }
> >
> > +static void isl69259_exit_reset(Object *obj)
> > +{
> > +ISLState *s = ISL69260(obj);
> > +static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2, 0x49, 
> > 0x3c};
>
> This looks like an ISLClass attribute to me. In which case, you wouldn't need 
> the
> reset handler nor the 'ic_device_id_len' field.
>
> Thanks,
>
> C.

I asked for this because, so far, I've been doing all the register
defaults in reset handlers, including read-only registers.
I don't mind either way, but it seemed preferable to have the devices
consistent.

Titus

Re: [PATCH v6 6/8] KVM: Handle page fault for private memory

[Vishal Annapurve]

...
> > > /*
> > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > index afe18d70ece7..e18460e0d743 100644
> > > --- a/arch/x86/kvm/mmu/mmu.c
> > > +++ b/arch/x86/kvm/mmu/mmu.c
> > > @@ -2899,6 +2899,9 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm,
> > > if (max_level == PG_LEVEL_4K)
> > > return PG_LEVEL_4K;
> > >
> > > +   if (kvm_slot_is_private(slot))
> > > +   return max_level;
> >
> > Can you explain the rationale behind the above change?
> > AFAIU, this overrides the transparent_hugepage=never setting for both
> > shared and private mappings.
>
> As Sean pointed out, this should check against fault->is_private instead
> of the slot. For private fault, the level is retrieved and stored to
> fault->max_level in kvm_faultin_pfn_private() instead of here.
>
> For shared fault, it will continue to query host_level below. For
> private fault, the host level has already been accounted in
> kvm_faultin_pfn_private().
>
> Chao
> >

With transparent_hugepages=always setting I see issues with the
current implementation.

Scenario:
1) Guest accesses a gfn range 0x800-0xa00 as private
2) Guest calls mapgpa to convert the range 0x84d-0x86e as shared
3) Guest tries to access recently converted memory as shared for the first time
Guest VM shutdown is observed after step 3 -> Guest is unable to
proceed further since somehow code section is not as expected

Corresponding KVM trace logs after step 3:
VCPU-0-61883   [078] . 72276.115679: kvm_page_fault: address
84d000 error_code 4
VCPU-0-61883   [078] . 72276.127005: kvm_mmu_spte_requested: gfn
84d pfn 100b4a4d level 2
VCPU-0-61883   [078] . 72276.127008: kvm_tdp_mmu_spte_changed: as
id 0 gfn 800 level 2 old_spte 100b1b16827 new_spte 100b4a00ea7
VCPU-0-61883   [078] . 72276.127009: kvm_mmu_prepare_zap_page: sp
gen 0 gfn 800 l1 8-byte q0 direct wux nxe ad root 0 sync
VCPU-0-61883   [078] . 72276.127009: kvm_tdp_mmu_spte_changed: as
id 0 gfn 800 level 1 old_spte 1003eb27e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 801 level 1 old_spte 10056cc8e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 802 level 1 old_spte 10056fa2e67 new_spte 5a0
VCPU-0-61883   [078] . 72276.127010: kvm_tdp_mmu_spte_changed: as
id 0 gfn 803 level 1 old_spte 0 new_spte 5a0

 VCPU-0-61883   [078] . 72276.127089: kvm_tdp_mmu_spte_changed: as
id 0 gfn 9ff level 1 old_spte 100a43f4e67 new_spte 5a0
 VCPU-0-61883   [078] . 72276.127090: kvm_mmu_set_spte: gfn 800
spte 100b4a00ea7 (rwxu) level 2 at 10052fa5020
 VCPU-0-61883   [078] . 72276.127091: kvm_fpu: unload

Looks like with transparent huge pages enabled kvm tried to handle the
shared memory fault on 0x84d gfn by coalescing nearby 4K pages
to form a contiguous 2MB page mapping at gfn 0x800, since level 2 was
requested in kvm_mmu_spte_requested.
This caused the private memory contents from regions 0x800-0x84c and
0x86e-0xa00 to get unmapped from the guest leading to guest vm
shutdown.

Does getting the mapping level as per the fault access type help
address the above issue? Any such coalescing should not cross between
private to
shared or shared to private memory regions.

> > > host_level = host_pfn_mapping_level(kvm, gfn, pfn, slot);
> > > return min(host_level, max_level);
> > >  }
> >

Regards,
Vishal

Re: [PATCH v3 14/14] hw/arm/aspeed: Add oby35-cl machine

[Peter Delevoryas]

On Thu, Jun 30, 2022 at 06:42:52PM +0200, Cédric Le Goater wrote:
> On 6/30/22 18:15, Peter Delevoryas wrote:
> > On Thu, Jun 30, 2022 at 01:02:54PM +0200, Cédric Le Goater wrote:
> > > On 6/30/22 06:51, Peter Delevoryas wrote:
> > > > From: Peter Delevoryas 
> > > > 
> > > > The fby35 machine includes 4 server boards, each of which has a "bridge
> > > > interconnect" (BIC). This chip abstracts the pinout for the server board
> > > > into a single endpoint that the baseboard management controller (BMC)
> > > > can talk to using IPMB.
> > > > 
> > > > This commit adds a machine for testing the BIC on the server board. It
> > > > runs OpenBIC (https://github.com/facebook/openbic) and the server board
> > > > is called CraterLake, so the code name is oby35-cl. There's also a
> > > > variant of the baseboard that replaces the BMC with a BIC, but that
> > > > machine is not included here.
> > > > 
> > > > A test image can be built from https://github.com/facebook/openbic using
> > > > the instructions in the README.md to build the meta-facebook/yv35-cl
> > > > recipe, or retrieved from my Github:
> > > > 
> > > >   wget 
> > > > https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.17.01/Y35BCL.elf
> > > > 
> > > > And you can run this machine with the following command:
> > > > 
> > > >   qemu-system-arm -machine oby35-cl -nographic -kernel Y35BCL.elf
> > > > 
> > > > It should produce output like the following:
> > > > 
> > > >   [00:00:00.005,000]  usb_dc_aspeed: select ep[0x81] as IN 
> > > > endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x82] as IN 
> > > > endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x1] as 
> > > > IN endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x2] as 
> > > > IN endpoint
> > > >   [00:00:00.006,000]  usb_dc_aspeed: select ep[0x3] as OUT 
> > > > endpoint
> > > >   *** Booting Zephyr OS build v00.01.05  ***
> > > >   Hello, welcome to yv35 craterlake 2022.25.1
> > > >   BIC class type(class-1), 1ou present status(0), 2ou present 
> > > > status(0), board revision(0x1)
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff 
> > > > ff ff ff ff ff]
> > > >   [init_drive_type] sensor 0x14 post sensor read failed!
> > > > 
> > > >   [init_drive_type] sensor 0x30 post sensor read failed!
> > > >   [init_drive_type] sensor 0x39 post sensor read failed!
> > > >   ipmi_init
> > > >   [set_DC_status] gpio number(15) status(0)
> > > >   [set_post_status] gpio number(1) status(1)
> > > >   uart:~$ [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, 
> > > > idr=0x2c, odr=0x38, str=0x44
> > > > 
> > > >   [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP 
> > > > magic  invalid
> > > >   [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read 
> > > > failed: -22
> > > >   [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
> 

[Bug 1838390] Re: vmx_write_mem: mmu_gva_to_gpa failed when using hvf

[Daniel Kolakowski]

It still happens to me when I try to run Haiku builds on my macos 10.14.
* QEMU emulator version 7.0.0

Command line:
qemu-system-x86_64 -machine q35,accel=hvf -cpu host -smp 4 -m 2048 -vga vmware 
-boot menu=on -drive file="haiku-minimum.mmc",if=none,format=raw,id=x0 -device 
ide-hd,drive=x0,bus=ide.0 -usb -device qemu-xhci,id=xhci -device usb-mouse 
-device usb-kbd -serial stdio -rtc clock=vm,base=localtime

Output:
[ipro1000] (em) Link is up 1000 Mbps Full Duplex
framebuffer: init_hardware()
vmx_write_mem: mmu_gva_to_gpa 853b3000 failed
[1]82284 abort  qemu-system-x86_64 -machine q35,accel=hvf -cpu host 
-smp 4 -m 2048 -vga vmwar

Haiku boots most of the way and crashes when trying to show desktop.
Same happens with -vga virtio and with -vga option completely removed.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838390

Title:
  vmx_write_mem: mmu_gva_to_gpa failed when using hvf

Status in QEMU:
  Expired

Bug description:
  Installed qemu 4.0.0 by homebrew, used below commands:

  1. qemu-img create -f raw arch-vm.img 100G
  2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d 
-cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard 
-device virtio-mouse -device virtio-tablet -drive 
file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off 
-nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda 
-vga virtio

  Displayed bootloader menu successfully, select "Boot Arch Linux" then
  crashed with message: vmx_write_mem: mmu_gva_to_gpa 91953b54
  failed.

  Use tcg accelerator has no problem but very slow.

  See attachment for full crash report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838390/+subscriptions

Re: [PATCH] Align Raspberry Pi DMA interrupts with Linux DTS

[Makarov, Andrey]

> Is there any hardware documentation that says whether QEMU or
> the DTB is correct? The device tree is at best a secondary source...


No. It should have been in the "BCM2835 ARM Peripherals" datasheet but the 
appropriate "ARM peripherals interrupt table" there is nearly empty.


> You can't connect multiple qemu_irq lines to one like this.
> If the hardware behaves this way then you need to create
> an OR gate, wire all the lines from the devices to the
> OR gate inputs, and wire the OR gate output to the destination.


Thank you for this correction, I will send another version of patch.


Andrey Makarov,

Team Lead



From: Peter Maydell 
Sent: Sunday, June 26, 2022 1:16:18 PM
To: Andrey Makarov
Cc: qemu-devel@nongnu.org; Makarov, Andrey
Subject: Re: [PATCH] Align Raspberry Pi DMA interrupts with Linux DTS

On Fri, 24 Jun 2022 at 21:54, Andrey Makarov  wrote:
>
> All Raspberry Pi models 1-3 (based on bcm2835) have
> Linux device tree (arch/arm/boot/dts/bcm2835-common.dtsi +25):
>
> /* dma channel 11-14 share one irq */
>
> which mismatched the Qemu model.
> In this patch channels 0--10 and 11--14 are handled separately.

Is there any hardware documentation that says whether QEMU or
the DTB is correct? The device tree is at best a secondary source...

> Signed-off-by: Andrey Makarov 
> ---
>  hw/arm/bcm2835_peripherals.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
> index 48538c9360..3d808b0e31 100644
> --- a/hw/arm/bcm2835_peripherals.c
> +++ b/hw/arm/bcm2835_peripherals.c
> @@ -322,13 +322,21 @@ static void bcm2835_peripherals_realize(DeviceState 
> *dev, Error **errp)
>  memory_region_add_subregion(>peri_mr, DMA15_OFFSET,
>  sysbus_mmio_get_region(SYS_BUS_DEVICE(>dma), 1));
>
> -for (n = 0; n <= 12; n++) {
> +for (n = 0; n <= 10; n++) {
>  sysbus_connect_irq(SYS_BUS_DEVICE(>dma), n,
> qdev_get_gpio_in_named(DEVICE(>ic),
>BCM2835_IC_GPU_IRQ,
>INTERRUPT_DMA0 + n));
>  }
>
> +/* According to DTS, dma channels 11-14 share one irq */
> +for (n = 11; n <= 14; n++) {
> +sysbus_connect_irq(SYS_BUS_DEVICE(>dma), n,
> +   qdev_get_gpio_in_named(DEVICE(>ic),
> +  BCM2835_IC_GPU_IRQ,
> +  INTERRUPT_DMA0 + 11));

You can't connect multiple qemu_irq lines to one like this.
If the hardware behaves this way then you need to create
an OR gate, wire all the lines from the devices to the
OR gate inputs, and wire the OR gate output to the destination.

thanks
-- PMM

Re: [PULL 00/14] (Mostly) build system changes for 2022-06-24

[Peter Maydell]

On Thu, 30 Jun 2022 at 18:14, Paolo Bonzini  wrote:
>
>
>
> Il ven 24 giu 2022, 17:57 Richard Henderson  ha 
> scritto:
>>
>> But then the i386 cross-compiler isn't used:
>
>
> Yeah, that was intentional. In theory a softmmu target is freestanding and 
> does not need anything beyond the compiler install, so configure defaults to 
> the native compiler, which is biarch. That however assumes that the compiler 
> install includes the libgcc for both architectures.
>
> Does that mean that Ubuntu installs GCC without a 32-bit libgcc.a?

I think they package it in a separate package, eg lib32gcc-9-dev
(adjust package name to suit gcc version).

-- PMM

Re: [PULL 00/14] (Mostly) build system changes for 2022-06-24

[Paolo Bonzini]

Il ven 24 giu 2022, 17:57 Richard Henderson 
ha scritto:

> But then the i386 cross-compiler isn't used:
>

Yeah, that was intentional. In theory a softmmu target is freestanding and
does not need anything beyond the compiler install, so configure defaults
to the native compiler, which is biarch. That however assumes that the
compiler install includes the libgcc for both architectures.

Does that mean that Ubuntu installs GCC without a 32-bit libgcc.a?

Paolo


> $ cat tests/tcg/config-i386-softmmu.mak
>
> # Automatically generated by configure - do not modify
>
> TARGET_NAME=i386
>
> BUILD_STATIC=
>
> EXTRA_CFLAGS=-m32
>
> CC=cc
>
> CCAS=cc
>
> AR=ar
>
> AS=as
>
> LD=ld
>
> NM=nm
>
> OBJCOPY=objcopy
>
> RANLIB=ranlib
>
> STRIP=strip
>
> QEMU=/home/rth/qemu-publish/bld/qemu-system-i386
>
>
> leading to failure:
>
> cc -nostdlib -ggdb -O0 -isystem
> /home/rth/qemu-publish/src/tests/tcg/minilib -m32
> -ffreestanding
> /home/rth/qemu-publish/src/tests/tcg/multiarch/system/hello.c -o hello
> -Wl,-T/home/rth/qemu-publish/src/tests/tcg/i386/system/kernel.ld
> -Wl,-melf_i386 -static
> -nostdlib boot.o  printf.o -lgcc
>
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/11/libgcc.a when
> searching for -lgcc
>
> /usr/bin/ld: cannot find -lgcc: No such file or directory
>
> collect2: error: ld returned 1 exit status
>
> make[1]: ***
> [/home/rth/qemu-publish/src/tests/tcg/i386/Makefile.softmmu-target:32:
> hello]
> Error 1
>
>
>
> r~
>
>

[PATCH] linux-user: Fix stracing in-memory mmap arguments

[Ilya Leoshkevich]

On some architectures mmap() arguments are passed via an in-memory
array, and qemu's strace support does not recognize that. Fix by
sharing the argument fetching logic between mmap() implementation and
tracing.

An alternative approach would be to fetch arguments only once at the
beginning of do_syscall(), however, that would change what the
qemu_plugin_register_vcpu_syscall_cb() users get.

Signed-off-by: Ilya Leoshkevich 
---
 linux-user/mmap.c  | 20 
 linux-user/strace.c| 24 
 linux-user/syscall.c   | 25 +++--
 linux-user/user-mmap.h | 12 
 4 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 4e7a6be6ee..fbb50e3e98 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -899,3 +899,23 @@ abi_long target_madvise(abi_ulong start, abi_ulong len_in, 
int advice)
 
 return ret;
 }
+
+abi_long old_mmap_get_args(abi_long *arg1, abi_long *arg2, abi_long *arg3,
+   abi_long *arg4, abi_long *arg5, abi_long *arg6)
+{
+abi_long orig_arg1 = *arg1, *v;
+
+v = lock_user(VERIFY_READ, orig_arg1, 6 * sizeof(abi_ulong), 1);
+if (!v) {
+return -TARGET_EFAULT;
+}
+*arg1 = tswapal(v[0]);
+*arg2 = tswapal(v[1]);
+*arg3 = tswapal(v[2]);
+*arg4 = tswapal(v[3]);
+*arg5 = tswapal(v[4]);
+*arg6 = tswapal(v[5]);
+unlock_user(v, orig_arg1, 0);
+
+return 0;
+}
diff --git a/linux-user/strace.c b/linux-user/strace.c
index 7d882526da..f25195ae85 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -16,6 +16,7 @@
 #include 
 #include "qemu.h"
 #include "user-internals.h"
+#include "user-mmap.h"
 #include "strace.h"
 
 struct syscallname {
@@ -3532,9 +3533,9 @@ print_utimensat(CPUArchState *cpu_env, const struct 
syscallname *name,
 
 #if defined(TARGET_NR_mmap) || defined(TARGET_NR_mmap2)
 static void
-print_mmap(CPUArchState *cpu_env, const struct syscallname *name,
-   abi_long arg0, abi_long arg1, abi_long arg2,
-   abi_long arg3, abi_long arg4, abi_long arg5)
+print_mmap2(CPUArchState *cpu_env, const struct syscallname *name,
+abi_long arg0, abi_long arg1, abi_long arg2,
+abi_long arg3, abi_long arg4, abi_long arg5)
 {
 print_syscall_prologue(name);
 print_pointer(arg0, 0);
@@ -3545,7 +3546,22 @@ print_mmap(CPUArchState *cpu_env, const struct 
syscallname *name,
 print_raw_param("%#x", arg5, 1);
 print_syscall_epilogue(name);
 }
-#define print_mmap2 print_mmap
+#endif
+
+#if defined(TARGET_NR_mmap)
+static void
+print_mmap(CPUArchState *cpu_env, const struct syscallname *name,
+   abi_long arg0, abi_long arg1, abi_long arg2,
+   abi_long arg3, abi_long arg4, abi_long arg5)
+{
+if (mmap_get_args(, , , , , )) {
+print_syscall_prologue(name);
+print_pointer(arg0, 0);
+print_syscall_epilogue(name);
+return;
+}
+print_mmap2(cpu_env, name, arg0, arg1, arg2, arg3, arg4, arg5);
+}
 #endif
 
 #ifdef TARGET_NR_mprotect
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 669add74c1..00d4be9094 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -9917,33 +9917,14 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 return ret;
 #ifdef TARGET_NR_mmap
 case TARGET_NR_mmap:
-#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || \
-(defined(TARGET_ARM) && defined(TARGET_ABI32)) || \
-defined(TARGET_M68K) || defined(TARGET_CRIS) || defined(TARGET_MICROBLAZE) 
\
-|| defined(TARGET_S390X)
-{
-abi_ulong *v;
-abi_ulong v1, v2, v3, v4, v5, v6;
-if (!(v = lock_user(VERIFY_READ, arg1, 6 * sizeof(abi_ulong), 1)))
-return -TARGET_EFAULT;
-v1 = tswapal(v[0]);
-v2 = tswapal(v[1]);
-v3 = tswapal(v[2]);
-v4 = tswapal(v[3]);
-v5 = tswapal(v[4]);
-v6 = tswapal(v[5]);
-unlock_user(v, arg1, 0);
-ret = get_errno(target_mmap(v1, v2, v3,
-target_to_host_bitmask(v4, 
mmap_flags_tbl),
-v5, v6));
+ret = mmap_get_args(, , , , , );
+if (ret) {
+return ret;
 }
-#else
-/* mmap pointers are always untagged */
 ret = get_errno(target_mmap(arg1, arg2, arg3,
 target_to_host_bitmask(arg4, 
mmap_flags_tbl),
 arg5,
 arg6));
-#endif
 return ret;
 #endif
 #ifdef TARGET_NR_mmap2
diff --git a/linux-user/user-mmap.h b/linux-user/user-mmap.h
index 480ce1c114..f48474bd1d 100644
--- a/linux-user/user-mmap.h
+++ b/linux-user/user-mmap.h
@@ -31,5 +31,17 @@ extern abi_ulong mmap_next_start;
 abi_ulong mmap_find_vma(abi_ulong, abi_ulong, abi_ulong);
 void 

Re: [PATCH v3 14/14] hw/arm/aspeed: Add oby35-cl machine

[Cédric Le Goater]

On 6/30/22 18:15, Peter Delevoryas wrote:

On Thu, Jun 30, 2022 at 01:02:54PM +0200, Cédric Le Goater wrote:

On 6/30/22 06:51, Peter Delevoryas wrote:

From: Peter Delevoryas 

The fby35 machine includes 4 server boards, each of which has a "bridge
interconnect" (BIC). This chip abstracts the pinout for the server board
into a single endpoint that the baseboard management controller (BMC)
can talk to using IPMB.

This commit adds a machine for testing the BIC on the server board. It
runs OpenBIC (https://github.com/facebook/openbic) and the server board
is called CraterLake, so the code name is oby35-cl. There's also a
variant of the baseboard that replaces the BMC with a BIC, but that
machine is not included here.

A test image can be built from https://github.com/facebook/openbic using
the instructions in the README.md to build the meta-facebook/yv35-cl
recipe, or retrieved from my Github:

  wget 
https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.17.01/Y35BCL.elf

And you can run this machine with the following command:

  qemu-system-arm -machine oby35-cl -nographic -kernel Y35BCL.elf

It should produce output like the following:

  [00:00:00.005,000]  usb_dc_aspeed: select ep[0x81] as IN endpoint
  [00:00:00.006,000]  usb_dc_aspeed: select ep[0x82] as IN endpoint
  [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x1] as IN 
endpoint
  [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x2] as IN 
endpoint
  [00:00:00.006,000]  usb_dc_aspeed: select ep[0x3] as OUT endpoint
  *** Booting Zephyr OS build v00.01.05  ***
  Hello, welcome to yv35 craterlake 2022.25.1
  BIC class type(class-1), 1ou present status(0), 2ou present status(0), 
board revision(0x1)
  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff ff 
ff ff ff]
  [init_drive_type] sensor 0x14 post sensor read failed!

  [init_drive_type] sensor 0x30 post sensor read failed!
  [init_drive_type] sensor 0x39 post sensor read failed!
  ipmi_init
  [set_DC_status] gpio number(15) status(0)
  [set_post_status] gpio number(1) status(1)
  uart:~$ [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
odr=0x38, str=0x44

  [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
 invalid
  [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
  [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
odr=0x38, str=0x44

  [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
 invalid
  [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
  uart:~$ BIC Ready

Signed-off-by: Peter Delevoryas 


LGTM.

That said I would prefer to introduce the machine first and then
populate with devices.


Ohh ok, I'll submit the machine definition separately all by itself and then
submit any extra devices like the CPLD or ME afterwards.


I have kept the "full system" in my tree for now :

  cb4481ae1812 aspeed: Add AST2600 (BMC) to fby35  (full system)
  c155bf27d3e7 aspeed: Make aspeed_board_init_flashes public (trivial)
  3f5485fa88b9 aspeed: Add fby35 skeleton  (trivial)

because the ROM vs. execute-in-place is being analyzed. Let's see if
we can make progress and simplify the initial 

Re: [PATCH v3 13/14] hw/misc/aspeed: Add intel-me

[Peter Delevoryas]

On Thu, Jun 30, 2022 at 01:09:09PM +0200, Cédric Le Goater wrote:
> On 6/30/22 06:51, Peter Delevoryas wrote:
> > From: Peter Delevoryas 
> > 
> > The Intel Management Engine is an IPMI endpoint that responds to various
> > IPMI commands.
> 
> Have you looked at the ipmi-bmc-sim device ? It is relatively easy
> to attach to a bus.

No I haven't! I didn't realize there was already some ipmi simulation code,
that's great. I'll look into turning this into an ipmi-me-sim or something.

> 
> > In this commit, I've added some very basic functionality that
> > will respond back with a respond code of zero (success), while also setting
> > an appropriate response NetFN (request NetFN + 1), a matching command ID and
> > sequence number, and the 2 standard checksums. Other data is not provided,
> > but the model here could be extended to respond to more kinds of requests.
> > 
> > Signed-off-by: Peter Delevoryas 
> > ---
> >   MAINTAINERS  |   1 +
> >   hw/misc/intel_me.c   | 162 +++
> >   hw/misc/meson.build  |   3 +-
> >   hw/misc/trace-events |   8 +++
> >   4 files changed, 173 insertions(+), 1 deletion(-)
> >   create mode 100644 hw/misc/intel_me.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3ffd473db1..3220644bb5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1068,6 +1068,7 @@ F: include/hw/net/ftgmac100.h
> >   F: docs/system/arm/aspeed.rst
> >   F: tests/qtest/*aspeed*
> >   F: hw/misc/fby35_sb_cpld.c
> > +F: hw/misc/intel_me.c
> >   NRF51
> >   M: Joel Stanley 
> > diff --git a/hw/misc/intel_me.c b/hw/misc/intel_me.c
> > new file mode 100644
> > index 00..933ae45101
> > --- /dev/null
> > +++ b/hw/misc/intel_me.c
> > @@ -0,0 +1,162 @@
> > +/*
> > + * Copyright (c) Meta Platforms, Inc. and affiliates. (http://www.meta.com)
> > + *
> > + * This code is licensed under the GPL version 2 or later. See the COPYING
> > + * file in the top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu/main-loop.h"
> > +#include "hw/i2c/i2c.h"
> > +#include "trace.h"
> > +
> > +#define TYPE_INTEL_ME "intel-me"
> > +OBJECT_DECLARE_SIMPLE_TYPE(IntelMEState, INTEL_ME);
> > +
> > +struct IntelMEState {
> > +I2CSlave parent_obj;
> > +
> > +I2CBus *bus;
> > +QEMUBH *bh;
> > +int rx_len;
> > +int tx_len;
> > +int tx_pos;
> > +uint8_t rx_buf[512];
> > +uint8_t tx_buf[512];
> > +};
> > +
> > +static void intel_me_bh(void *opaque)
> > +{
> > +IntelMEState *s = opaque;
> > +I2CSlave *i2c = I2C_SLAVE(s);
> > +uint8_t target_addr;
> > +
> > +assert(s->bus->bh == s->bh);
> > +
> > +switch (s->tx_pos) {
> > +case 0:
> > +target_addr = s->tx_buf[s->tx_pos++];
> > +trace_intel_me_tx_start(i2c->address, target_addr);
> > +if (i2c_start_send_async(s->bus, target_addr) != 0) {
> > +break;
> > +}
> > +return;
> > +default:
> > +if (s->tx_pos >= s->tx_len) {
> > +break;
> > +}
> > +trace_intel_me_tx_data(i2c->address, s->tx_buf[s->tx_pos]);
> > +if (i2c_send_async(s->bus, s->tx_buf[s->tx_pos++]) != 0) {
> > +break;
> > +}
> > +return;
> > +}
> > +
> > +trace_intel_me_tx_end(i2c->address);
> > +i2c_end_transfer(s->bus);
> > +i2c_bus_release(s->bus);
> > +s->tx_len = 0;
> > +s->tx_pos = 0;
> > +memset(s->tx_buf, 0, sizeof(s->tx_buf));
> > +}
> > +
> > +static void intel_me_realize(DeviceState *dev, Error **errp)
> > +{
> > +IntelMEState *s = INTEL_ME(dev);
> > +
> > +s->bus = I2C_BUS(qdev_get_parent_bus(dev));
> > +s->bh = qemu_bh_new(intel_me_bh, s);
> > +s->rx_len = 0;
> > +s->tx_len = 0;
> > +s->tx_pos = 0;
> > +memset(s->rx_buf, 0, sizeof(s->rx_buf));
> > +memset(s->tx_buf, 0, sizeof(s->tx_buf));
> > +}
> > +
> > +static uint8_t checksum(const uint8_t *ptr, int len)
> > +{
> > +int sum = 0;
> > +
> > +for (int i = 0; i < len; i++) {
> > +sum += ptr[i];
> > +}
> > +
> > +return 256 - sum;
> > +}
> > +
> > +static int intel_me_i2c_event(I2CSlave *i2c, enum i2c_event event)
> > +{
> > +IntelMEState *s = INTEL_ME(i2c);
> > +
> > +switch (event) {
> > +case I2C_START_RECV:
> > +break;
> > +case I2C_START_SEND:
> > +trace_intel_me_rx_start(i2c->address);
> > +s->rx_len = 0;
> > +memset(s->rx_buf, 0, sizeof(s->rx_buf));
> > +break;
> > +case I2C_START_SEND_ASYNC:
> > +break;
> > +case I2C_FINISH:
> > +trace_intel_me_rx_end(i2c->address);
> > +s->tx_len = 10;
> > +s->tx_pos = 0;
> > +s->tx_buf[0] = s->rx_buf[2];
> > +s->tx_buf[1] = ((s->rx_buf[0] >> 2) + 1) << 2;
> > +s->tx_buf[2] = checksum(s->tx_buf, 2);
> > +s->tx_buf[3] = i2c->address;
> > +s->tx_buf[4] = (s->rx_buf[3] >> 2) << 2;
> > +s->tx_buf[5] = s->rx_buf[4];
> > +

Re: [PATCH v3 14/14] hw/arm/aspeed: Add oby35-cl machine

[Peter Delevoryas]

On Thu, Jun 30, 2022 at 01:02:54PM +0200, Cédric Le Goater wrote:
> On 6/30/22 06:51, Peter Delevoryas wrote:
> > From: Peter Delevoryas 
> > 
> > The fby35 machine includes 4 server boards, each of which has a "bridge
> > interconnect" (BIC). This chip abstracts the pinout for the server board
> > into a single endpoint that the baseboard management controller (BMC)
> > can talk to using IPMB.
> > 
> > This commit adds a machine for testing the BIC on the server board. It
> > runs OpenBIC (https://github.com/facebook/openbic) and the server board
> > is called CraterLake, so the code name is oby35-cl. There's also a
> > variant of the baseboard that replaces the BMC with a BIC, but that
> > machine is not included here.
> > 
> > A test image can be built from https://github.com/facebook/openbic using
> > the instructions in the README.md to build the meta-facebook/yv35-cl
> > recipe, or retrieved from my Github:
> > 
> >  wget 
> > https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.17.01/Y35BCL.elf
> > 
> > And you can run this machine with the following command:
> > 
> >  qemu-system-arm -machine oby35-cl -nographic -kernel Y35BCL.elf
> > 
> > It should produce output like the following:
> > 
> >  [00:00:00.005,000]  usb_dc_aspeed: select ep[0x81] as IN endpoint
> >  [00:00:00.006,000]  usb_dc_aspeed: select ep[0x82] as IN endpoint
> >  [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x1] as IN 
> > endpoint
> >  [00:00:00.006,000]  usb_dc_aspeed: pre-selected ep[0x2] as IN 
> > endpoint
> >  [00:00:00.006,000]  usb_dc_aspeed: select ep[0x3] as OUT endpoint
> >  *** Booting Zephyr OS build v00.01.05  ***
> >  Hello, welcome to yv35 craterlake 2022.25.1
> >  BIC class type(class-1), 1ou present status(0), 2ou present status(0), 
> > board revision(0x1)
> >  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x62 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x76 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 0 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  check_vr_type: i2c4 0x60 page 1 [04 00 81 d2 49 3c ff ff ff ff ff ff 
> > ff ff ff ff]
> >  [init_drive_type] sensor 0x14 post sensor read failed!
> > 
> >  [init_drive_type] sensor 0x30 post sensor read failed!
> >  [init_drive_type] sensor 0x39 post sensor read failed!
> >  ipmi_init
> >  [set_DC_status] gpio number(15) status(0)
> >  [set_post_status] gpio number(1) status(1)
> >  uart:~$ [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, 
> > idr=0x2c, odr=0x38, str=0x44
> > 
> >  [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
> >  invalid
> >  [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
> >  [00:00:01.010,000]  kcs_aspeed: KCS3: addr=0xca2, idr=0x2c, 
> > odr=0x38, str=0x44
> > 
> >  [00:00:01.016,000]  spi_nor_multi_dev: [1216][spi1_cs0]SFDP magic 
> >  invalid
> >  [00:00:01.016,000]  spi_nor_multi_dev: [1456]SFDP read failed: -22
> >  uart:~$ BIC Ready
> > 
> > Signed-off-by: Peter Delevoryas 
> 
> LGTM.
> 
> That said I would prefer to introduce the machine first and then
> populate with devices.

Ohh ok, I'll submit the machine definition separately all by itself and then
submit any extra devices like the CPLD or ME afterwards.

> 
> May be it is time to introduce a new 

Re: [PATCH v2] target/i386: Add unaccepted memory configuration

[Dionna Amalie Glaze]

> > The most recent patches I recall for SEV-SNP introduced a new
> > 'sev-snp-guest' object instead of overloading the existing
> > 'sev-guest' object:
> >
> >https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg04757.html
> >
>
> Correct, the SNP support for Qemu is only RFC at this point until the KVM
> support for SNP is (near) finalized.
>

Ah okay, should I wait until that RFC patch set is merged to propose
an extension to it, or should I coordinate with y'all at AMD to
include this in your patch set?

Apologies Pankaj, I forgot the change log (still new to git
send-email). The change is that the configuration option is no longer
in MachineState, but part of SevGuestState, with accessor functions
for fw_cfg.c to know if it needs to add the fw_cfg file and what its
value should be. That was the main feedback on v1.

-- 
-Dionna Glaze, PhD (she/her)

Re: [PATCH RFC 0/2] arm: enable MTE for QEMU + kvm

[Cornelia Huck]

On Wed, Jun 29 2022, Eric Auger  wrote:

> Hi Connie,
>
> On 6/13/22 18:02, Cornelia Huck wrote:
>> On Fri, Jun 10 2022, Eric Auger  wrote:
>> 
>>> Hi Connie,
>>>
>>> On 5/12/22 15:11, Cornelia Huck wrote:
 This series enables MTE for kvm guests, if the kernel supports it.
 Lightly tested while running under the simulator (the arm64/mte/
 kselftests pass... if you wait patiently :)

 A new cpu property "mte" (defaulting to on if possible) is introduced;
 for tcg, you still need to enable mte at the machine as well.
>>> isn't the property set to off by default when kvm is enabled (because of
>>> the migration blocker).
>> 
>> Oh, I had changed that around several times, and it seems I ended up
>> being confused when I wrote this cover letter... I wonder what the best
>> state would be (assuming that I don't manage to implement it soonish,
>> but it seems we still would need kernel changes as by the discussion in
>> that other patch series.)
> Having mte=off by default along with KVM, until the migration gets
> supported, looks OK to me. Does it prevent you from having it set to
> another value by default with TCG (depending on the virt machine
> tag_memory option)?
>
>   tag_memory=on   tag_memory=off
> KVM CPU mte=off   invalid mte=off
> KVM CPU mte=oninvalid mte=on
> TCG CPU mte=off   invalid mte=off
> TCG CPU mte=onmte=on  invalid
>
> default value:
> KVM mte = off until migration gets supported
> TCG mte = machine.tag_memory

With OnOffAuto, I currently have:

valid for tcg: cpu.mte=on, tag_memory=on (result: mte on)
   cpu.mte=off, tag_memory either on or off (result: mte off)
   cpu.mte unspecified, tag_memory either on or off (result:
   mte==tag_memory)
valid for kvm: tag_memory always off
   cpu.mte=off (result: mte off)
   cpu.mte=on if mte supported in kvm (result: mte on)
   cpu.mte unspecified (result: mte on if kvm supports it;
   this I can flip)
all other combinations: error

Re: [PATCH RFC 1/2] arm/kvm: enable MTE if available

[Cornelia Huck]

On Wed, Jun 29 2022, Eric Auger  wrote:

> Hi Connie,
>
> On 6/14/22 10:40, Cornelia Huck wrote:
>> On Fri, Jun 10 2022, Eric Auger  wrote:
>> 
>>> Hi Connie,
>>> On 5/12/22 15:11, Cornelia Huck wrote:
 We need to disable migration, as we do not yet have a way to migrate
 the tags as well.
>>>
>>> This patch does much more than adding a migration blocker ;-) you may
>>> describe the new cpu option and how it works.
>> 
>> I admit this is a bit terse ;) The idea is to control mte at the cpu
>> level directly (and not indirectly via tag memory at the machine
>> level). I.e. the user gets whatever is available given the constraints
>> (host support etc.) if they don't specify anything, and they can
>> explicitly turn it off/on.
>
> Could the OnOffAuto property value be helpful?

I completely forgot that this exists; I hacked up something (still
untested), and it seems to be able to do what I want.

I'll post it after I've verified that it actually works :)

>> The big elefant in the room is how migration will end up
>> working... after reading the disscussions in
>> https://lore.kernel.org/all/cajc+z1fzxsyb_zjit4+0utr-88vqql+-01xnmsefua-dxdy...@mail.gmail.com/
>> I don't think it will be as "easy" as I thought, and we probably require
>> some further fiddling on the kernel side.
> Yes maybe the MTE migration process shall be documented and discussed
> separately on the ML? Is Haibu Xu's address bouncing?

Yes, that address is bouncing...

I've piggybacked onto a recent kvm discussion in
https://lore.kernel.org/all/875ykmcd8q@redhat.com/ -- I guess there
had not been any change for migration in the meantime, we need to find a
way to tie page data + metadata together.

Re: [PATCH v2] io_uring: fix short read slow path

[Stefano Garzarella]

On Thu, Jun 30, 2022 at 10:01:37AM +0900, Dominique Martinet wrote:

sqeq.off here is the offset to read within the disk image, so obviously
not 'nread' (the amount we just read), but as the author meant to write
its current value incremented by the amount we just read.

Normally recent versions of linux will not issue short reads,
but it can happen so we should fix this.

This lead to weird image corruptions when short read happened

Fixes: 6663a0a33764 ("block/io_uring: implements interfaces for io_uring")
Link: https://lkml.kernel.org/r/yrrfgo4a1js0g...@atmark-techno.com
Signed-off-by: Dominique Martinet 


Thanks for fixing this issue!

Reviewed-by: Stefano Garzarella 


---
v1 -> v2: also updated total_read to use += as suggested by Kevin,
thank you!

I've tested this quickly by making short reads "recursives", e.g. added
the following to luring_resubmit_short_read() after setting 'remaining':
   if (remaining > 4096) remaining -= 4096;

so when we ask for more we issue an extra short reads, making sure we go
through the two short reads path.
(Unfortunately I wasn't quite sure what to fiddle with to issue short
reads in the first place, I tried cutting one of the iovs short in
luring_do_submit() but I must not have been doing it properly as I ended
up with 0 return values which are handled by filling in with 0 (reads
after eof) and that didn't work well)


Do you remember the kernel version where you first saw these problems?

Thanks,
Stefano

Re: [PATCH v2 09/13] hw/i2c/pmbus: Add read-only IC_DEVICE_ID support

[Patrick Venture]

On Wed, Jun 29, 2022 at 11:34 AM Peter Delevoryas  wrote:

>
>
> > On Jun 29, 2022, at 11:04 AM, Titus Rwantare  wrote:
> >
> > On Tue, 28 Jun 2022 at 20:36, Peter Delevoryas
> >  wrote:
> >>
> >> Signed-off-by: Peter Delevoryas 
> >> ---
> >
> >> --- a/hw/i2c/pmbus_device.c
> >> +++ b/hw/i2c/pmbus_device.c
> >> @@ -984,6 +984,11 @@ static uint8_t pmbus_receive_byte(SMBusDevice *smd)
> >> }
> >> break;
> >>
> >> +case PMBUS_IC_DEVICE_ID:
> >> +pmbus_send(pmdev, pmdev->pages[index].ic_device_id,
> >> +   sizeof(pmdev->pages[index].ic_device_id));
> >> +break;
> >> +
> >
> > I don't think it's a good idea to add this here because this sends 16
> > bytes for all PMBus devices. I have at least one device that formats
> > IC_DEVICE_ID differently that I've not got permission to upstream.
> > The spec leaves the size and format up to the manufacturer, so this is
> > best done in isl_pmbus_vr.c in isl_pmbus_vr_read_byte().
> > Look at the adm1272_read_byte() which is more interesting than
> > isl_pmbus_vr one as an example.
>
> Argh, yes, you’re absolutely right. I didn’t read the spec in very
> much detail, I see now that the length is device-specific. For the
> ISL69259 I see that it’s 4 bytes, which makes sense now. This
> is not the exact datasheet for the ISL69259, but I think the IC_DEVICE_ID
> part is the same.
>
>
> https://www.renesas.com/us/en/document/dst/isl68229-isl68239-datasheet
>
> Putting the logic in isl_pmbus_vr_read_byte() is a good idea, I hadn’t
> seen the implementation in adm1272_read_byte(), that looks great,
> I’ll just add a switch on the command code and move the error message
> to the default case.
>
> >
> >
> >> case PMBUS_CLEAR_FAULTS:  /* Send Byte */
> >> case PMBUS_PAGE_PLUS_WRITE:   /* Block Write-only */
> >> case PMBUS_STORE_DEFAULT_ALL: /* Send Byte */
> >> diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
> >> index e11e028884..b12c46ab6d 100644
> >> --- a/hw/sensor/isl_pmbus_vr.c
> >> +++ b/hw/sensor/isl_pmbus_vr.c
> >> @@ -218,6 +218,28 @@ static void isl_pmbus_vr_class_init(ObjectClass
> *klass, void *data,
> >> k->device_num_pages = pages;
> >> }
> >>
> >> +static void isl69259_init(Object *obj)
> >> +{
> >> +static const uint8_t ic_device_id[] = {0x04, 0x00, 0x81, 0xD2,
> 0x49};
> >> +PMBusDevice *pmdev = PMBUS_DEVICE(obj);
> >> +int i;
> >> +
> >> +raa22xx_init(obj);
> >> +for (i = 0; i < pmdev->num_pages; i++) {
> >> +memcpy(pmdev->pages[i].ic_device_id, ic_device_id,
> >> +   sizeof(ic_device_id));
> >> +}
> >> +}
> >> +
> >
> > We tend to set default register values in exit_reset() calls. You can
> > do something like in raa228000_exit_reset()
>
> Oh got it. If I can move the logic to isl_pmbus_vr_read_byte perhaps
> I can avoid this whole function though.
>
> >
> >
> >> diff --git a/include/hw/i2c/pmbus_device.h
> b/include/hw/i2c/pmbus_device.h
> >> index 0f4d6b3fad..aed7809841 100644
> >> --- a/include/hw/i2c/pmbus_device.h
> >> +++ b/include/hw/i2c/pmbus_device.h
> >> @@ -407,6 +407,7 @@ typedef struct PMBusPage {
> >> uint16_t mfr_max_temp_1;   /* R/W word */
> >> uint16_t mfr_max_temp_2;   /* R/W word */
> >> uint16_t mfr_max_temp_3;   /* R/W word */
> >> +uint8_t ic_device_id[16];  /* Read-Only block-read */
> >
> > You wouldn't be able to do this here either, since the size could be
> > anything for other devices.
>
> Right, yeah I see what you mean.
>
> >
> > Thanks for the new device. It helps me see where to expand on PMBus.
>
> Thanks for adding the whole pmbus infrastructure! It’s really useful.
> And thanks for the review.
>
> Off-topic, but I’ve been meaning to reach out to you guys (Google
> engineers working on QEMU for OpenBMC) about your Nuvoton NPCM845R
> series, my team is interested in using it. I was just curious about
> the status of it and if there’s any features missing and what plans
> you have for the future, maybe we can collaborate.
>

Peter, feel free to reach out to me, or Titus, and we can sync up.  I used
to work with Patrick who's now at Fb on OpenBMC stuff.  We sent a bunch of
the Nuvoton patches up for review recently, and we're actively adding more
devices, etc.

We also have quite a few patches downstream we're looking to upstream,
including PECI, and sensors, etc, etc that we've seen on BMC servers.

Patrick


>
> Thanks!
> Peter
>
> >
> >
> > Titus
>
>

Re: [PATCH v2] io_uring: fix short read slow path

[Hanna Reitz]

On 30.06.22 03:01, Dominique Martinet wrote:

sqeq.off here is the offset to read within the disk image, so obviously
not 'nread' (the amount we just read), but as the author meant to write
its current value incremented by the amount we just read.

Normally recent versions of linux will not issue short reads,
but it can happen so we should fix this.

This lead to weird image corruptions when short read happened

Fixes: 6663a0a33764 ("block/io_uring: implements interfaces for io_uring")
Link: https://lkml.kernel.org/r/yrrfgo4a1js0g...@atmark-techno.com
Signed-off-by: Dominique Martinet 
---
v1 -> v2: also updated total_read to use += as suggested by Kevin,
thank you!

I've tested this quickly by making short reads "recursives", e.g. added
the following to luring_resubmit_short_read() after setting 'remaining':
 if (remaining > 4096) remaining -= 4096;

so when we ask for more we issue an extra short reads, making sure we go
through the two short reads path.
(Unfortunately I wasn't quite sure what to fiddle with to issue short
reads in the first place, I tried cutting one of the iovs short in
luring_do_submit() but I must not have been doing it properly as I ended
up with 0 return values which are handled by filling in with 0 (reads
after eof) and that didn't work well)

Anyway, this looks OK to me now.

Thanks,
Dominique

  block/io_uring.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Hanna Reitz 

Re: [PATCH v3 2/2] ui/gtk: a new array param monitor to specify the target displays

[Markus Armbruster]

Dongwon Kim  writes:

> New integer array parameter, 'monitor' is for specifying the target
> monitors where individual GTK windows are placed upon launching.
>
> Monitor numbers in the array are associated with virtual consoles
> in the order of [VC0, VC1, VC2 ... VCn].
>
> Every GTK window containing each VC will be placed in the region
> of corresponding monitors.
>
> Usage: -display gtk,monitor.=,..
>ex)-display gtk,monitor.0=1,monitor.1=0
>
> v3: - Revised commit message
> - Rewrote desription of the new parameter (Markus Armbruster)
> - Replaced unnecessary 'for' loop with 'if' condition
>   (Markus Armbruster)

Again, patch history ...
> Cc: Daniel P. Berrangé 
> Cc: Markus Armbruster 
> Cc: Philippe Mathieu-Daudé 
> Cc: Paolo Bonzini 
> Cc: Gerd Hoffmann 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---

... goes here.

>  qapi/ui.json|  9 -
>  qemu-options.hx |  3 ++-
>  ui/gtk.c| 31 +--
>  3 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/qapi/ui.json b/qapi/ui.json
> index 413371d5e8..7b4c098bb4 100644
> --- a/qapi/ui.json
> +++ b/qapi/ui.json
> @@ -1195,12 +1195,19 @@
>  #   assuming the guest will resize the display to match
>  #   the window size then.  Otherwise it defaults to "off".
>  #   Since 3.1
> +# @monitor: Array of numbers, each of which represents physical
> +#   monitor where GTK window containing a given VC will be
> +#   placed. Each monitor number in the array will be
> +#   associated with a virtual-console starting from VC0.

Drop the hyphen in "virtual-console".

Is the term "virtual console" obvious?  Gerd?

> +#
> +#   since 7.1
>  #
>  # Since: 2.12
>  ##
>  { 'struct'  : 'DisplayGTK',
>'data': { '*grab-on-hover' : 'bool',
> -'*zoom-to-fit'   : 'bool'  } }
> +'*zoom-to-fit'   : 'bool',
> +'*monitor'   : ['uint16']  } }
>  
>  ##
>  # @DisplayEGLHeadless:
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 377d22fbd8..aabdfb0636 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1938,7 +1938,8 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
>  #endif
>  #if defined(CONFIG_GTK)
>  "-display gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
> -"[,show-cursor=on|off][,window-close=on|off]\n"
> +"[,monitor.=][,show-cursor=on|off]"
> +"[,window-close=on|off]\n"
>  #endif
>  #if defined(CONFIG_VNC)
>  "-display vnc=[,]\n"
> diff --git a/ui/gtk.c b/ui/gtk.c
> index e6878c3209..935176e614 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -2316,6 +2316,10 @@ static void gtk_display_init(DisplayState *ds, 
> DisplayOptions *opts)
>  GtkDisplayState *s = g_malloc0(sizeof(*s));
>  GdkDisplay *window_display;
>  GtkIconTheme *theme;
> +GtkWidget *win;
> +GdkRectangle dest;
> +uint16List *mon;
> +int n_mon;
>  int i;
>  char *dir;
>  
> @@ -2393,10 +2397,33 @@ static void gtk_display_init(DisplayState *ds, 
> DisplayOptions *opts)
>  gtk_menu_item_activate(GTK_MENU_ITEM(s->untabify_item));
>  }
>  }
> -if (opts->has_full_screen &&
> -opts->full_screen) {
> +
> +if (opts->u.gtk.has_monitor) {
> +i = 0;
> +n_mon = gdk_display_get_n_monitors(window_display);
> +for (mon = opts->u.gtk.monitor; mon; mon = mon->next) {
> +if (mon->value < n_mon && i < s->nb_vcs) {
> +win = s->vc[i].window ? s->vc[i].window : s->window;
> +if (opts->has_full_screen && opts->full_screen) {
> +gtk_window_fullscreen_on_monitor(
> +GTK_WINDOW(win),
> +gdk_display_get_default_screen(window_display),
> +mon->value);
> +} else {
> +gdk_monitor_get_geometry(
> +gdk_display_get_monitor(window_display, mon->value),
> +);
> +gtk_window_move(GTK_WINDOW(win),
> +dest.x, dest.y);
> +}
> +i++;
> +}
> +}
> +} else if (opts->has_full_screen &&
> +   opts->full_screen) {

I'd join these two lines, like

   } else if (opts->has_full_screen && opts->full_screen) {

or even exploit the fact that a opts->full_screen is false when absent

   } else if (opts->full_screen) {

>  gtk_menu_item_activate(GTK_MENU_ITEM(s->full_screen_item));
>  }
> +
>  if (opts->u.gtk.has_grab_on_hover &&
>  opts->u.gtk.grab_on_hover) {
>  gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));

Re: [PATCH v5 05/12] qapi: net: add stream and dgram netdevs

[Laurent Vivier]

On 29/06/2022 13:20, Markus Armbruster wrote:

Laurent Vivier  writes:


Copied from socket netdev file and modified to use SocketAddress
to be able to introduce new features like unix socket.

"udp" and "mcast" are squashed into dgram netdev, multicast is detected
according to the IP address type.
"listen" and "connect" modes are managed by stream netdev. An optional
parameter "server" defines the mode (server by default)

Signed-off-by: Laurent Vivier 
Reviewed-by: Stefano Brivio 
---


[...]

...

+# @server: create server socket (default: true)
+#
+# Since: 7.1
+##
+{ 'struct': 'NetdevStreamOptions',
+  'data': {
+'addr':   'SocketAddress',
+'*server': 'bool' } }
+
+##
+# @NetdevDgramOptions:
+#
+# Configuration info for datagram socket netdev.
+#
+# @remote: remote address
+# @local: local address
+#
+# The code checks there is at least one of these options and reports an error
+# if not. If remote address is present and it's a multicast address, local
+# address is optional. Otherwise local address is required and remote address
+# is optional.
+#
+# Since: 7.1
+##
+{ 'struct': 'NetdevDgramOptions',
+  'data': {
+'*local':  'SocketAddress',
+'*remote': 'SocketAddress' } }


Hard to see, but the space in "} }" is funny: it's U+00A0
(NO-BREAK-SPACE) encoded in UTF-8.  Make it a plain old space, please.



I'm sorry, this happens sometime because I use a french macintosh keyboard, and to do '}' 
I have to press alt+) and if I don't release fast enough 'alt' I produce an alt+space that 
seems to generate this (invisible) character code...

(I've the same problem with '|' = alt+shift+l, but bash doesn't like it)

I'm updating the series with all your comments.

Thank you for the reviews.

Laurent

Re: [PATCH v3 1/3] ui/gtk: detach VCs for additional guest displays

[Markus Armbruster]

Dongwon Kim  writes:

> Detaching any addtional guest displays in case multiple displays are
> assigned to the guest OS (e.g. max_outputs=n) so that all of them are
> visible upon lauching.
>
> v2: - making sure type of VC is GD_VC_GFX before qemu_console_is_graphic
>   (Gerd Hoffman)
> - vc[0] is always primary guest display so we won't need n_gfx_vcs
>   (Gerd Hoffmann)
> - making sure detached window's size same as original surface size
>   (Daniel P. Berrangé)

Patch history ...

> Cc: Daniel P. Berrangé 
> Cc: Markus Armbruster 
> Cc: Philippe Mathieu-Daudé 
> Cc: Paolo Bonzini 
> Cc: Gerd Hoffmann 
> Cc: Vivek Kasireddy 
> Signed-off-by: Dongwon Kim 
> ---

... goes here, so it doesn't end up in git.  You can also keep it in the
cover letter instead.

>  ui/gtk.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

Re: [PATCH] gtk: Add show_tabs=on|off command line option.

[Markus Armbruster]

Hanna Reitz  writes:

> Hi,
>
> (Thanks for the patch!)
>
> On 27.06.22 18:44, Felix xq Queißner wrote:
>> The patch adds "show_tabs" command line option for GTK ui similar to 
>> "grab_on_hover". This option allows tabbed view mode to not have to be 
>> enabled by hand at each start of the VM.
>
> I’m not sure we have a hard rule on it, but I think generally commit messages 
> should be wrapped at 72 characters.

Yes, please.

[...]

Re: [PATCH v2] target/i386: Add unaccepted memory configuration

[Tom Lendacky]

On 6/30/22 03:14, Daniel P. Berrangé wrote:

On Wed, Jun 29, 2022 at 07:37:01PM +, Dionna Glaze wrote:

For SEV-SNP, an OS is "SEV-SNP capable" without supporting this UEFI
v2.9 memory type. In order for OVMF to be able to avoid pre-validating
potentially hundreds of gibibytes of data before booting, it needs to
know if the guest OS can support its use of the new type of memory in
the memory map.


This talks about something supported for SEV-SNP, but


  static void
  sev_guest_class_init(ObjectClass *oc, void *data)
  {
@@ -376,6 +401,14 @@ sev_guest_class_init(ObjectClass *oc, void *data)
 sev_guest_set_kernel_hashes);
  object_class_property_set_description(oc, "kernel-hashes",
  "add kernel hashes to guest firmware for measured Linux boot");
+object_class_property_add_enum(oc, "accept-all-memory",
+   "MemoryAcceptance",
+   _acceptance_lookup,
+sev_guest_get_accept_all_memory, sev_guest_set_accept_all_memory);
+object_class_property_set_description(
+oc, "accept-all-memory",
+"false: Accept all memory, true: Accept up to 4G and leave the rest 
unaccepted (UEFI"
+" v2.9 memory type), default: default firmware behavior.");
  }


..this is adding a property to the 'sev-guest' object, which only
targets SEV/SEV-ES currently AFAIK.

The most recent patches I recall for SEV-SNP introduced a new
'sev-snp-guest' object instead of overloading the existing
'sev-guest' object:

   https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg04757.html



Correct, the SNP support for Qemu is only RFC at this point until the KVM 
support for SNP is (near) finalized.


Thanks,
Tom




With regards,
Daniel

Re: [PATCH 1/5] multifd: Create property multifd-sync-each-iteration

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> We used to synchronize all channels at the end of each RAM section
> sent.  That is not needed, so preparing to only synchronize once every
> full round in latests patches.
> 
> Notice that we initialize the property as true.  We will change the
> default when we introduce the new mechanism.

I don't understand why this is a property - does it break the actual
stream format?

Dave

> Signed-off-by: Juan Quintela 
> ---
>  migration/migration.h |  6 ++
>  hw/core/machine.c |  1 +
>  migration/migration.c | 10 ++
>  3 files changed, 17 insertions(+)
> 
> diff --git a/migration/migration.h b/migration/migration.h
> index 485d58b95f..70dae24516 100644
> --- a/migration/migration.h
> +++ b/migration/migration.h
> @@ -332,6 +332,11 @@ struct MigrationState {
>   * This save hostname when out-going migration starts
>   */
>  char *hostname;
> +/*
> + * Synchronize channels after each iteration.
> + * We used to do that on the past, but it is suboptimal.
> + */
> +bool multifd_sync_each_iteration;
>  };
>  
>  void migrate_set_state(int *state, int old_state, int new_state);
> @@ -374,6 +379,7 @@ int migrate_multifd_channels(void);
>  MultiFDCompression migrate_multifd_compression(void);
>  int migrate_multifd_zlib_level(void);
>  int migrate_multifd_zstd_level(void);
> +bool migrate_multifd_sync_each_iteration(void);
>  
>  #ifdef CONFIG_LINUX
>  bool migrate_use_zero_copy_send(void);
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index a673302cce..c8a60917e0 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -43,6 +43,7 @@
>  GlobalProperty hw_compat_7_0[] = {
>  { "arm-gicv3-common", "force-8-bit-prio", "on" },
>  { "nvme-ns", "eui64-default", "on"},
> +{ "migration", "multifd-sync-each-iteration", "on"},
>  };
>  const size_t hw_compat_7_0_len = G_N_ELEMENTS(hw_compat_7_0);
>  
> diff --git a/migration/migration.c b/migration/migration.c
> index 31739b2af9..3f79df0b70 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -2540,6 +2540,13 @@ bool migrate_use_multifd(void)
>  return s->enabled_capabilities[MIGRATION_CAPABILITY_MULTIFD];
>  }
>  
> +bool migrate_multifd_sync_each_iteration(void)
> +{
> +MigrationState *s = migrate_get_current();
> +
> +return s->multifd_sync_each_iteration;
> +}
> +
>  bool migrate_pause_before_switchover(void)
>  {
>  MigrationState *s;
> @@ -4274,6 +4281,9 @@ static Property migration_properties[] = {
>  DEFINE_PROP_SIZE("announce-step", MigrationState,
>parameters.announce_step,
>DEFAULT_MIGRATE_ANNOUNCE_STEP),
> +/* We will change to false when we introduce the new mechanism */
> +DEFINE_PROP_BOOL("multifd-sync-each-iteration", MigrationState,
> +  multifd_sync_each_iteration, true),
>  
>  /* Migration capabilities */
>  DEFINE_PROP_MIG_CAP("x-xbzrle", MIGRATION_CAPABILITY_XBZRLE),
> -- 
> 2.34.1
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH] gtk: Add show_tabs=on|off command line option.

[Hanna Reitz]

On 30.06.22 16:09, Hanna Reitz wrote:

Hi,

(Thanks for the patch!)

On 27.06.22 18:44, Felix xq Queißner wrote:
The patch adds "show_tabs" command line option for GTK ui similar to 
"grab_on_hover". This option allows tabbed view mode to not have to 
be enabled by hand at each start of the VM.


I’m not sure we have a hard rule on it, but I think generally commit 
messages should be wrapped at 72 characters.



Signed-off-by: Felix "xq" Queißner 
---
  qapi/ui.json    | 5 -
  qemu-options.hx | 2 +-
  ui/gtk.c    | 4 
  3 files changed, 9 insertions(+), 2 deletions(-)


[...]


diff --git a/qemu-options.hx b/qemu-options.hx
index 377d22fbd8..2b279afff7 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1937,7 +1937,7 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
  "    [,window-close=on|off]\n"
  #endif
  #if defined(CONFIG_GTK)
-    "-display 
gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
+    "-display 
gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off][,show-tabs=on|off]\n"

  " [,show-cursor=on|off][,window-close=on|off]\n"


Oops, noticed another thing (a bit late): Considering the options are 
already spit over two lines, it looks to me like this line’s length is 
supposed to be limited.  (My guess is we’re trying to not exceed 80 
characters here in this source file.)  Therefore, this new option should 
probably go on a separate new line.


Hanna

Re: [PATCH] gtk: Add show_tabs=on|off command line option.

[Hanna Reitz]

Hi,

(Thanks for the patch!)

On 27.06.22 18:44, Felix xq Queißner wrote:

The patch adds "show_tabs" command line option for GTK ui similar to 
"grab_on_hover". This option allows tabbed view mode to not have to be enabled by hand at 
each start of the VM.


I’m not sure we have a hard rule on it, but I think generally commit 
messages should be wrapped at 72 characters.



Signed-off-by: Felix "xq" Queißner 
---
  qapi/ui.json| 5 -
  qemu-options.hx | 2 +-
  ui/gtk.c| 4 
  3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index 413371d5e8..049e7957a9 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1195,12 +1195,15 @@
  #   assuming the guest will resize the display to match
  #   the window size then.  Otherwise it defaults to "off".
  #   Since 3.1
+# @show-tabs:   Displays the tab items by default.
+#   Since 7.1


I don’t really understand what “tab items” is supposed to mean. Perhaps 
“tabs item”?


But a bit more verbosity might be nice, too.  What about “Display the 
tab bar for switching between the various graphical interfaces (e.g. VGA 
and virtual console character devices) by default”?  (Note the 
imperative on “Display”, I think we generally use the imperative to 
document options.)



  #
  # Since: 2.12
  ##
  { 'struct'  : 'DisplayGTK',
'data': { '*grab-on-hover' : 'bool',
-'*zoom-to-fit'   : 'bool'  } }
+'*zoom-to-fit'   : 'bool',
+'*show-tabs' : 'bool'  } }
  
  ##

  # @DisplayEGLHeadless:
diff --git a/qemu-options.hx b/qemu-options.hx
index 377d22fbd8..2b279afff7 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1937,7 +1937,7 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
  "[,window-close=on|off]\n"
  #endif
  #if defined(CONFIG_GTK)
-"-display gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
+"-display 
gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off][,show-tabs=on|off]\n"
  "[,show-cursor=on|off][,window-close=on|off]\n"


There is some documentation further below that explains the other 
options.  I think this new option should be explained there as well.  
(Probably reusing the documentation from qapi/ui.json.)



  #endif
  #if defined(CONFIG_VNC)
diff --git a/ui/gtk.c b/ui/gtk.c
index 2a791dd2aa..1467b8c7d7 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2390,6 +2390,10 @@ static void gtk_display_init(DisplayState *ds, 
DisplayOptions *opts)
  opts->u.gtk.grab_on_hover) {
  gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));
  }
+if (opts->u.gtk.has_show_tabs &&
+opts->u.gtk.show_tabs) {
+gtk_menu_item_activate(GTK_MENU_ITEM(s->show_tabs_item));
+}
  gd_clipboard_init(s);
  }


Not that I’d know any of this code, but FWIW, makes sense and looks good 
to me.


Thanks!

Hanna

Re: [PATCH v3 2/3] target/ppc: Improve Radix xlate level validation

[Fabiano Rosas]

Leandro Lupori  writes:

> Check if the number and size of Radix levels are valid on
> POWER9/POWER10 CPUs, according to the supported Radix Tree
> Configurations described in their User Manuals.
>
> Signed-off-by: Leandro Lupori 

Reviewed-by: Fabiano Rosas 

> ---
>  target/ppc/mmu-radix64.c | 49 +++-
>  1 file changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/target/ppc/mmu-radix64.c b/target/ppc/mmu-radix64.c
> index 9a8a2e2875..705bff76be 100644
> --- a/target/ppc/mmu-radix64.c
> +++ b/target/ppc/mmu-radix64.c
> @@ -236,17 +236,37 @@ static void ppc_radix64_set_rc(PowerPCCPU *cpu, 
> MMUAccessType access_type,
>  }
>  }
>  
> +static bool ppc_radix64_is_valid_level(int level, int psize, uint64_t nls)
> +{
> +/*
> + * Check if this is a valid level, according to POWER9 and POWER10
> + * Processor User's Manuals, sections 4.10.4.1 and 5.10.6.1, 
> respectively:
> + * Supported Radix Tree Configurations and Resulting Page Sizes.
> + *
> + * Note: these checks are specific to POWER9 and POWER10 CPUs. Any future
> + * CPUs that supports a different Radix MMU configuration will need their
> + * own implementation.
> + */
> +switch (level) {
> +case 0: /* Root Page Dir */
> +return psize == 52 && nls == 13;
> +case 1:
> +case 2:
> +return nls == 9;
> +case 3:
> +return nls == 9 || nls == 5;
> +default:
> +qemu_log_mask(LOG_GUEST_ERROR, "invalid radix level: %d\n", level);
> +return false;
> +}
> +}
> +
>  static int ppc_radix64_next_level(AddressSpace *as, vaddr eaddr,
>uint64_t *pte_addr, uint64_t *nls,
>int *psize, uint64_t *pte, int 
> *fault_cause)
>  {
>  uint64_t index, pde;
>  
> -if (*nls < 5) { /* Directory maps less than 2**5 entries */
> -*fault_cause |= DSISR_R_BADCONFIG;
> -return 1;
> -}
> -
>  /* Read page  entry from guest address space */
>  pde = ldq_phys(as, *pte_addr);
>  if (!(pde & R_PTE_VALID)) { /* Invalid Entry */
> @@ -270,12 +290,8 @@ static int ppc_radix64_walk_tree(AddressSpace *as, vaddr 
> eaddr,
>   hwaddr *raddr, int *psize, uint64_t *pte,
>   int *fault_cause, hwaddr *pte_addr)
>  {
> -uint64_t index, pde, rpn , mask;
> -
> -if (nls < 5) { /* Directory maps less than 2**5 entries */
> -*fault_cause |= DSISR_R_BADCONFIG;
> -return 1;
> -}
> +uint64_t index, pde, rpn, mask;
> +int level = 0;
>  
>  index = eaddr >> (*psize - nls);/* Shift */
>  index &= ((1UL << nls) - 1);   /* Mask */
> @@ -283,6 +299,11 @@ static int ppc_radix64_walk_tree(AddressSpace *as, vaddr 
> eaddr,
>  do {
>  int ret;
>  
> +if (!ppc_radix64_is_valid_level(level++, *psize, nls)) {
> +*fault_cause |= DSISR_R_BADCONFIG;
> +return 1;
> +}
> +
>  ret = ppc_radix64_next_level(as, eaddr, pte_addr, , psize, ,
>   fault_cause);
>  if (ret) {
> @@ -456,6 +477,7 @@ static int ppc_radix64_process_scoped_xlate(PowerPCCPU 
> *cpu,
>  }
>  } else {
>  uint64_t rpn, mask;
> +int level = 0;
>  
>  index = (eaddr & R_EADDR_MASK) >> (*g_page_size - nls); /* Shift */
>  index &= ((1UL << nls) - 1);/* Mask */
> @@ -475,6 +497,11 @@ static int ppc_radix64_process_scoped_xlate(PowerPCCPU 
> *cpu,
>  return ret;
>  }
>  
> +if (!ppc_radix64_is_valid_level(level++, *g_page_size, nls)) {
> +fault_cause |= DSISR_R_BADCONFIG;
> +return 1;
> +}
> +
>  ret = ppc_radix64_next_level(cs->as, eaddr & R_EADDR_MASK, 
> _raddr,
>   , g_page_size, , 
> _cause);
>  if (ret) {

Re: [PATCH v4 0/4] hmat acpi: Don't require initiator value in -numa

[Michael S. Tsirkin]

On Thu, Jun 30, 2022 at 02:40:13PM +0200, Brice Goglin wrote:
> 
> Le 30/06/2022 à 14:23, Igor Mammedov a écrit :
> > On Thu, 30 Jun 2022 09:36:47 +0200
> > Brice Goglin  wrote:
> > 
> > > Allow -numa without initiator value when hmat=on so that we may
> > > build more complex topologies, e.g. NUMA nodes whose best initiators
> > > are not just another single node.
> > > 
> > patches looks fine code-wise,
> > however something wrong with them, i.e. 'git am' doesn't like them
> > nor ./scripts/checkpatch (which one should use before sending patches).
> > 
> > I've checked it's not my mail server/client issue(or whatever)
> > that corrupts them (ones downloaded from patchew are broken as well)
> 
> 
> I don't know what's going on. These 4 patches are in
> https://github.com/bgoglin/qemu/commits/hmat-noinitiator (rebased on master
> 10mn ago).

It's the commit log that's corrupted.

> Do whatever you want with them. I am not allowed to spend more time on this.
> 
> Brice

Maybe someone will fix up the log and repost. One can hope ..

-- 
MST

Re: [PATCH v4 0/4] hmat acpi: Don't require initiator value in -numa

[Michael S. Tsirkin]

On Thu, Jun 30, 2022 at 02:56:16PM +0200, Igor Mammedov wrote:
> On Thu, 30 Jun 2022 14:40:13 +0200
> Brice Goglin  wrote:
> 
> > Le 30/06/2022 à 14:23, Igor Mammedov a écrit :
> > > On Thu, 30 Jun 2022 09:36:47 +0200
> > > Brice Goglin  wrote:
> > >  
> > >> Allow -numa without initiator value when hmat=on so that we may
> > >> build more complex topologies, e.g. NUMA nodes whose best initiators
> > >> are not just another single node.
> > >>  
> > > patches looks fine code-wise,
> > > however something wrong with them, i.e. 'git am' doesn't like them
> > > nor ./scripts/checkpatch (which one should use before sending patches).
> > >
> > > I've checked it's not my mail server/client issue(or whatever)
> > > that corrupts them (ones downloaded from patchew are broken as well)  
> > 
> > 
> > I don't know what's going on. These 4 patches are in 
> > https://github.com/bgoglin/qemu/commits/hmat-noinitiator (rebased on 
> > master 10mn ago).
> 
> I'm not sure if we take patches from directly from git-forges,
> I guess it's upto maintainers.
> 
> CCing Michael,
>  since these should go through his tree

I could if nothing else worked, but I would much rather get
patches that did get processed by patchew and other automated
mail based tools.


> > 
> > Do whatever you want with them. I am not allowed to spend more time on this.
> > 
> > Brice
> > 
> > 
> > 

Re: [PATCH v4 1/4] hmat acpi: Don't require initiator value in -numa

[Michael S. Tsirkin]

On Thu, Jun 30, 2022 at 09:40:19AM +0200, Brice Goglin wrote:


...


> 
> Before this patch, we had to add ",initiator=X" to "-numa 
> node,nodeid=2,memdev=ram2".
> The lstopo output difference between initiator=1 and no initiator is:
> @@ -1,10 +1,10 @@
>  Machine (2966MB total) + Package P#0
> +  NUMANode P#2 (979MB)
>Group0
>  NUMANode P#0 (980MB)
>  Core P#0 + PU P#0
>  Core P#1 + PU P#1
>Group0
>  NUMANode P#1 (1007MB)
> -NUMANode P#2 (979MB)
>  Core P#2 + PU P#2
>  Core P#3 + PU P#3
> 
> Corresponding changes in the HMAT MPDA structure:
> @@ -49,10 +49,10 @@
>  [078h 0120   2]   Structure Type :  [Memory Proximity Domain 
> Attributes]
>  [07Ah 0122   2] Reserved : 
>  [07Ch 0124   4]   Length : 0028
> -[080h 0128   2]Flags (decoded below) : 0001
> -Processor Proximity Domain Valid : 1
> +[080h 0128   2]Flags (decoded below) : 

Including diff output like this is what is confusing
mail processing tools. Just escape the diff in the output
and this will make git happy. E.g.:

The lstopo output difference between initiator=1 and no initiator is:

| @@ -1,10 +1,10 @@
|  Machine (2966MB total) + Package P#0
| +  NUMANode P#2 (979MB)
|Group0
|  NUMANode P#0 (980MB)
|  Core P#0 + PU P#0
|  Core P#1 + PU P#1
|Group0
|  NUMANode P#1 (1007MB)
| -NUMANode P#2 (979MB)
|  Core P#2 + PU P#2
|  Core P#3 + PU P#3
| 
| Corresponding changes in the HMAT MPDA structure:
| @@ -49,10 +49,10 @@
|  [078h 0120   2]   Structure Type :  [Memory Proximity Domain 
Attributes]
|  [07Ah 0122   2] Reserved : 
|  [07Ch 0124   4]   Length : 0028
| -[080h 0128   2]Flags (decoded below) : 0001
| -Processor Proximity Domain Valid : 1
| +[080h 0128   2]Flags (decoded below) : 




-- 
MST

Re: [PATCH v6 00/15] block: cleanup backing and file handling

[Hanna Reitz]

On 24.06.22 23:28, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

That's the first part of
"[PATCH v5 00/45] Transactional block-graph modifying API",
updated and almost reviewed.

On commit (15) is added to original scope of
"block: cleanup backing and file handling", as it's related.

01: add Hanna's r-b
02: - mention snapshot-access in commit msg
 - return ret in compress_open instead of EINVAL
 - add Hanna's r-b
03: add Hanna's r-b
04: - add case in commit msg
 - fix comments
05: - fix type in commit msg
 - add Hanna's r-b
06: add Hanna's r-b
07: wording improvements
08: - fix wording
 - add Hanna's r-b

09: I add the description, whey we allow a degradation. Still,
 up to maintainers: it's OK to merge 09-13 into one bit commit

13: - fix s/|/||/
 - improve comment
 - more readable logic when handle filters in bdrv_child_cb_attach()
 - don't keep **child indirection, move to just returning a child ptr
   (honestly, I didn't analyze all the callers do they need this int value. 
Do you think it's needed?)
 - handle snapshot-access.c
14: get rid of _ptr
15: update comment


Reviewed-by: Hanna Reitz 

Patch 2 needs to be rebased on 79ef0cebb5694411e7452f0cf15c4bd170c7f2d6, 
but that should be straightforward.

Re: [PATCH v20 00/13] Add LoongArch linux-user emulation support

[gaosong]

Hi, Richard

On 2022/6/24 上午11:10, Song Gao wrote:

Hi All,

This series adds support linux-user emulation.
As the LoongArch kernel had merged into 5.19-rc1,
you can see the latest kernel at https://kernel.org

Need review patch:

   0002-linux-user-Add-LoongArch-signal-support.patch

V20:
   - Update signal.c, we should't set sc_extcontext[0] on
 setup_sigcontext;

V19:
   - Update signal.c, add fpu info, fpu_context and end info to
 target_rt_sigframe.

V18:
   - Update signal.c, add set fpu_context'magic, update parse_extcontext()
 and remove some cast.

V17:
   - Split v16 patch7 to  patch7-11, and fix some bugs for system-mode;
   - Update signal.c, add parse_extcontext();
   - Add get_elf_hwcap(), and ELF_PLATFORM.

V16:
   - Update signal.c;
   - Update helper_rdtime_d();
   - Update scripts/gensyscalls.sh, fixed a warning.

v15:
   - Rebase;
   - Update README;
   - Adjust some functions and structure to support user-mode;
   - Update syscall;
   - Update target_sigcontext;

Old series:
- https://patchew.org/QEMU/20220623085526.1678168-1-gaos...@loongson.cn/

Test:
make check  && make check-tcg  &&  run LoongArch bash

Thanks.
Song Gao


Song Gao (13):
   linux-user: Add LoongArch generic header files
   linux-user: Add LoongArch signal support
   linux-user: Add LoongArch elf support
   linux-user: Add LoongArch syscall support
   linux-user: Add LoongArch cpu_loop support
   scripts: add loongarch64 binfmt config
   target/loongarch: remove badaddr from CPULoongArch
   target/loongarch: Fix missing update CSR_BADV
   target/loongarch: Fix helper_asrtle_d/asrtgt_d raise wrong exception
   target/loongarch: remove unused include hw/loader.h
   target/loongarch: Adjust functions and structure to support user-mode
   default-configs: Add loongarch linux-user support
   target/loongarch: Update README


Sorry for disturbing you,   Should we need some changes or tests with 
this series?


Thanks.
Song Gao

  configs/targets/loongarch64-linux-user.mak|   3 +
  linux-user/elfload.c  |  91 +
  linux-user/loongarch64/cpu_loop.c |  96 ++
  linux-user/loongarch64/signal.c   | 326 ++
  linux-user/loongarch64/sockbits.h |  11 +
  linux-user/loongarch64/syscall_nr.h   | 312 +
  linux-user/loongarch64/target_cpu.h   |  34 ++
  linux-user/loongarch64/target_elf.h   |  12 +
  linux-user/loongarch64/target_errno_defs.h|  12 +
  linux-user/loongarch64/target_fcntl.h |  11 +
  linux-user/loongarch64/target_prctl.h |   1 +
  linux-user/loongarch64/target_resource.h  |  11 +
  linux-user/loongarch64/target_signal.h|  13 +
  linux-user/loongarch64/target_structs.h   |  11 +
  linux-user/loongarch64/target_syscall.h   |  48 +++
  linux-user/loongarch64/termbits.h |  11 +
  linux-user/syscall_defs.h |   6 +-
  scripts/gensyscalls.sh|   2 +
  scripts/qemu-binfmt-conf.sh   |   6 +-
  target/loongarch/README   |  39 ++-
  target/loongarch/cpu.c|  34 +-
  target/loongarch/cpu.h|   8 +-
  target/loongarch/gdbstub.c|   2 +-
  target/loongarch/helper.h |   2 +
  .../insn_trans/trans_privileged.c.inc |  36 ++
  target/loongarch/internals.h  |   2 +
  target/loongarch/op_helper.c  |  10 +-
  27 files changed, 1135 insertions(+), 15 deletions(-)
  create mode 100644 configs/targets/loongarch64-linux-user.mak
  create mode 100644 linux-user/loongarch64/cpu_loop.c
  create mode 100644 linux-user/loongarch64/signal.c
  create mode 100644 linux-user/loongarch64/sockbits.h
  create mode 100644 linux-user/loongarch64/syscall_nr.h
  create mode 100644 linux-user/loongarch64/target_cpu.h
  create mode 100644 linux-user/loongarch64/target_elf.h
  create mode 100644 linux-user/loongarch64/target_errno_defs.h
  create mode 100644 linux-user/loongarch64/target_fcntl.h
  create mode 100644 linux-user/loongarch64/target_prctl.h
  create mode 100644 linux-user/loongarch64/target_resource.h
  create mode 100644 linux-user/loongarch64/target_signal.h
  create mode 100644 linux-user/loongarch64/target_structs.h
  create mode 100644 linux-user/loongarch64/target_syscall.h
  create mode 100644 linux-user/loongarch64/termbits.h

Re: [PULL 15/18] qapi: introduce x-query-ramblock QMP command

[Claudio Fontana]

On 6/30/22 12:20, Daniel P. Berrangé wrote:
> On Thu, Jun 30, 2022 at 12:14:36PM +0200, Claudio Fontana wrote:
>> On 6/9/22 14:52, Dr. David Alan Gilbert wrote:
>>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
 On Thu, Jun 09, 2022 at 12:07:31PM +0200, Claudio Fontana wrote:
> Hello all,
>
> it would be really good to be able to rely on this command or something 
> similar,
> to be able to know the approximate size of a migration before starting it.
>
> in QEMU ram_bytes_total() returns what I would like to have,
> but there is currently no QMP way to get it without starting a migration,
> which when trying to optimize it/size it is just about too late.

 Aside from the main VM RAM, what other RAM blocks are likely to have
 a size large enough to be of consequence to the live migration
 data copy, and whose size is not already known to the mgmt app from
 the guest config choices it made ? VGA RAM could be a few 100MB I
 guess, but the mgmt app knows about that. I've always assumed everything
 else is just noise in comparison to the main RAM region.

 Still I wonder how useful this is as its just a static figure, and the
 problems with migration transfer are the bulking up of data when the
 VM is repeatedly dirtying stuff at a high rate.

> Do you think x-query-ramblock could be promoted to non-experimental?

 It would have to be re-written, as this current impl is just emitting
 a huge printf formatted string. To be considered supportable, the data
 would have to be formally modelled in QAPI instead.

 IOW, it would be a case of introducing a new command that emits formal
 data, convertintg 'info ramblock' to use that, and then deprecating this 
 x-query-ramblock.

> Should another one be made available instead, like :
> query-ram-bytes-total ?

 That would be simpler if you're just wanting it to give a single
 figure.
>>>
>>> Is this what qmp_query_memory_size_summary does?
>>
>> No, I am not looking at something returning the machine->ram_size,
>> but rather how many bytes are actually used in each RAMBlock, in order to 
>> estimate the transfer size of a guest to disk.
>>
>> This would be the return value of something like 
>> migration/ram.c::ram_bytes_total().
>>
>> The main guest RAM total size is in most cases an overestimation of the 
>> actual bytes required to be transferred.
>>
>> If there was such a feature that just returns ram_bytes_total via QMP,
>> by knowing the size in bytes before the transfer, we can prealloc the space 
>> on disk, which would improve the performance of this series:
>>
>> https://patchew.org/Libvirt/20220607091936.7948-1-cfont...@suse.de/
>>
>> The interleaved format I posted there works just fine to migrate a suspended 
>> VM to disk (virsh save) from multifd channels to a single file,
>> but still incurs in a 4-5% performance penalty compared with the multiple 
>> files approach,
>> that is apparently due to multiple threads competing on acquiring locks to 
>> adjust the file size (on XFS).
>>
>> Doing a fallocate() would likely remove this performance decrease compared 
>> with multifd to multiple files,
>> but requires knowing beforehand the approximate size of the transfer, and as 
>> mentioned mnachine->ram_size is just overkill in practice and risks erroring 
>> out if not enough space is available.
>>
>> Feedback on the interleaved format I posted there is welcome as well,
> 
> I still believe that libvirt is the wrong place to be implementing any
> of this logic. It all belongs in QEMU, because QEMU is the place which
> holds all the information needed to do an optimal job, and libvirt does
> not, as this request for extra QMP features shows.
> 
> With regards,
> Daniel

Hi Daniel,

I know your position about the implementation in libvirt vs a potential 
(non-existing for now) QEMU implementation.

The implementation in QEMU seems to me to require more investment due to the 
need of a new migration target protocol to be defined carefully (possibly 
"disk://")
and the need to alter and test all migrated devices participating in the 
creating the migration stream.

I don't think this request for an QMP feature shows anything really.

Knowing the _actual_ size of a migration stream before deciding to migrate is I 
think a pretty useful feature in itself I would think,
including for libvirt and higher level components in the stack. The lack of the 
feature just shows, well, the lack of this feature.

Regarding my prototype I pointed at that happens to use libvirt, I wonder if 
you or anyone have any feedback on the actual format of the VM saved in 
parallel to disk,
regardless of which component writes it, libvirt or QEMU, and I wonder also if 
there is any feedback on the O_DIRECT -friendly I/O API, which are both things 
we can make progress on also regardless of the libvirt vs QEMU implementation 
of the 

Re: [PATCH v4 0/4] hmat acpi: Don't require initiator value in -numa

[Igor Mammedov]

On Thu, 30 Jun 2022 14:40:13 +0200
Brice Goglin  wrote:

> Le 30/06/2022 à 14:23, Igor Mammedov a écrit :
> > On Thu, 30 Jun 2022 09:36:47 +0200
> > Brice Goglin  wrote:
> >  
> >> Allow -numa without initiator value when hmat=on so that we may
> >> build more complex topologies, e.g. NUMA nodes whose best initiators
> >> are not just another single node.
> >>  
> > patches looks fine code-wise,
> > however something wrong with them, i.e. 'git am' doesn't like them
> > nor ./scripts/checkpatch (which one should use before sending patches).
> >
> > I've checked it's not my mail server/client issue(or whatever)
> > that corrupts them (ones downloaded from patchew are broken as well)  
> 
> 
> I don't know what's going on. These 4 patches are in 
> https://github.com/bgoglin/qemu/commits/hmat-noinitiator (rebased on 
> master 10mn ago).

I'm not sure if we take patches from directly from git-forges,
I guess it's upto maintainers.

CCing Michael,
 since these should go through his tree

> 
> Do whatever you want with them. I am not allowed to spend more time on this.
> 
> Brice
> 
> 
> 

Re: [PATCH v4 0/4] hmat acpi: Don't require initiator value in -numa

[Brice Goglin]

Le 30/06/2022 à 14:23, Igor Mammedov a écrit :

On Thu, 30 Jun 2022 09:36:47 +0200
Brice Goglin  wrote:


Allow -numa without initiator value when hmat=on so that we may
build more complex topologies, e.g. NUMA nodes whose best initiators
are not just another single node.


patches looks fine code-wise,
however something wrong with them, i.e. 'git am' doesn't like them
nor ./scripts/checkpatch (which one should use before sending patches).

I've checked it's not my mail server/client issue(or whatever)
that corrupts them (ones downloaded from patchew are broken as well)



I don't know what's going on. These 4 patches are in 
https://github.com/bgoglin/qemu/commits/hmat-noinitiator (rebased on 
master 10mn ago).


Do whatever you want with them. I am not allowed to spend more time on this.

Brice





OpenPGP_signature
Description: OpenPGP digital signature

[PATCH v2 2/3] python/qmp/legacy: make QEMUMonitorProtocol accept a socket

[marcandre . lureau]

From: Marc-André Lureau 

Teach QEMUMonitorProtocol to accept an exisiting socket.

Signed-off-by: Marc-André Lureau 
---
 python/qemu/qmp/legacy.py | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/python/qemu/qmp/legacy.py b/python/qemu/qmp/legacy.py
index 03b5574618fa..72e8f9af7362 100644
--- a/python/qemu/qmp/legacy.py
+++ b/python/qemu/qmp/legacy.py
@@ -22,6 +22,7 @@
 #
 
 import asyncio
+import socket
 from types import TracebackType
 from typing import (
 Any,
@@ -69,22 +70,32 @@ class QEMUMonitorProtocol:
 
 :param address:  QEMU address, can be either a unix socket path (string)
  or a tuple in the form ( address, port ) for a TCP
- connection
+ connection or None
+:param sock: a socket or None
 :param server:   Act as the socket server. (See 'accept')
 :param nickname: Optional nickname used for logging.
 """
 
-def __init__(self, address: SocketAddrT,
+def __init__(self,
+ address: Optional[SocketAddrT] = None,
+ sock: Optional[socket.socket] = None,
  server: bool = False,
  nickname: Optional[str] = None):
 
+assert address or sock
 self._qmp = QMPClient(nickname)
 self._aloop = asyncio.get_event_loop()
 self._address = address
+self._sock = sock
 self._timeout: Optional[float] = None
 
 if server:
-self._sync(self._qmp.start_server(self._address))
+if sock:
+assert self._sock is not None
+self._sync(self._qmp.open_with_socket(self._sock))
+else:
+assert self._address is not None
+self._sync(self._qmp.start_server(self._address))
 
 _T = TypeVar('_T')
 
@@ -139,6 +150,7 @@ def connect(self, negotiate: bool = True) -> 
Optional[QMPMessage]:
 :return: QMP greeting dict, or None if negotiate is false
 :raise ConnectError: on connection errors
 """
+assert self._address is not None
 self._qmp.await_greeting = negotiate
 self._qmp.negotiate = negotiate
 
-- 
2.37.0.rc0

[PATCH v2 1/3] python/qmp/protocol: add open_with_socket()

[marcandre . lureau]

From: Marc-André Lureau 

Instead of listening for incoming connections with a SocketAddr, add a
new method open_with_socket() that accepts an existing socket.

Signed-off-by: Marc-André Lureau 
---
 python/qemu/qmp/protocol.py | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/python/qemu/qmp/protocol.py b/python/qemu/qmp/protocol.py
index 6ea86650ad24..4710a57f9126 100644
--- a/python/qemu/qmp/protocol.py
+++ b/python/qemu/qmp/protocol.py
@@ -18,6 +18,7 @@
 from enum import Enum
 from functools import wraps
 import logging
+import socket
 from ssl import SSLContext
 from typing import (
 Any,
@@ -296,6 +297,19 @@ async def start_server_and_accept(
 await self.accept()
 assert self.runstate == Runstate.RUNNING
 
+@upper_half
+@require(Runstate.IDLE)
+async def open_with_socket(self, sock: socket.socket) -> None:
+"""
+Start connection with given socket.
+
+:param sock: A socket.
+
+:raise StateError: When the `Runstate` is not `IDLE`.
+"""
+self._reader, self._writer = await asyncio.open_connection(sock=sock)
+self._set_state(Runstate.CONNECTING)
+
 @upper_half
 @require(Runstate.IDLE)
 async def start_server(self, address: SocketAddrT,
@@ -343,11 +357,12 @@ async def accept(self) -> None:
 protocol-level failure occurs while establishing a new
 session, the wrapped error may also be an `QMPError`.
 """
-if self._accepted is None:
-raise QMPError("Cannot call accept() before start_server().")
-await self._session_guard(
-self._do_accept(),
-'Failed to establish connection')
+if not self._reader:
+if self._accepted is None:
+raise QMPError("Cannot call accept() before start_server().")
+await self._session_guard(
+self._do_accept(),
+'Failed to establish connection')
 await self._session_guard(
 self._establish_session(),
 'Failed to establish session')
-- 
2.37.0.rc0

[PATCH v2 0/3] python/qemu/machine: fix potential hang in QMP accept

[marcandre . lureau]

From: Marc-André Lureau 

Hi,

As reported earlier by Richard Henderson ("virgl avocado hang" thread), avocado
tests may hang when QEMU exits before the QMP connection is established.

v2:
 - use a socketpair() for QMP (instead of async concurrent code from v1) as
   suggested by Daniel Berrange.
 - should not regress (hopefully)

Marc-André Lureau (3):
  python/qmp/protocol: add open_with_socket()
  python/qmp/legacy: make QEMUMonitorProtocol accept a socket
  python/qemu/machine: use socketpair() for QMP by default

 python/qemu/machine/machine.py | 24 
 python/qemu/qmp/legacy.py  | 18 +++---
 python/qemu/qmp/protocol.py| 25 -
 3 files changed, 51 insertions(+), 16 deletions(-)

-- 
2.37.0.rc0

[PATCH v2 3/3] python/qemu/machine: use socketpair() for QMP by default

[marcandre . lureau]

From: Marc-André Lureau 

When no monitor address is given, establish the QMP communication through
a socketpair() (API is also supported on Windows since Python 3.5)

Signed-off-by: Marc-André Lureau 
---
 python/qemu/machine/machine.py | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/python/qemu/machine/machine.py b/python/qemu/machine/machine.py
index 37191f433b2d..aa1d9447352d 100644
--- a/python/qemu/machine/machine.py
+++ b/python/qemu/machine/machine.py
@@ -158,17 +158,13 @@ def __init__(self,
 self._qmp_timer = qmp_timer
 
 self._name = name or f"qemu-{os.getpid()}-{id(self):02x}"
+self._sock_pair: Optional[Tuple[socket.socket, socket.socket]] = None
 self._temp_dir: Optional[str] = None
 self._base_temp_dir = base_temp_dir
 self._sock_dir = sock_dir
 self._log_dir = log_dir
 
-if monitor_address is not None:
-self._monitor_address = monitor_address
-else:
-self._monitor_address = os.path.join(
-self.sock_dir, f"{self._name}-monitor.sock"
-)
+self._monitor_address = monitor_address
 
 self._console_log_path = console_log
 if self._console_log_path:
@@ -303,7 +299,11 @@ def _base_args(self) -> List[str]:
 args = ['-display', 'none', '-vga', 'none']
 
 if self._qmp_set:
-if isinstance(self._monitor_address, tuple):
+if self._sock_pair:
+fd = self._sock_pair[0].fileno()
+os.set_inheritable(fd, True)
+moncdev = f"socket,id=mon,fd={fd}"
+elif isinstance(self._monitor_address, tuple):
 moncdev = "socket,id=mon,host={},port={}".format(
 *self._monitor_address
 )
@@ -337,10 +337,17 @@ def _pre_launch(self) -> None:
 self._remove_files.append(self._console_address)
 
 if self._qmp_set:
+monitor_address = None
+sock = None
+if self._monitor_address is None:
+self._sock_pair = socket.socketpair()
+sock = self._sock_pair[1]
 if isinstance(self._monitor_address, str):
 self._remove_files.append(self._monitor_address)
+monitor_address = self._monitor_address
 self._qmp_connection = QEMUMonitorProtocol(
-self._monitor_address,
+address=monitor_address,
+sock=sock,
 server=True,
 nickname=self._name
 )
@@ -360,6 +367,7 @@ def _pre_launch(self) -> None:
 ))
 
 def _post_launch(self) -> None:
+self._sock_pair[0].close()
 if self._qmp_connection:
 self._qmp.accept(self._qmp_timer)
 
-- 
2.37.0.rc0

Re: [PATCH v4 0/4] hmat acpi: Don't require initiator value in -numa

[Igor Mammedov]

On Thu, 30 Jun 2022 09:36:47 +0200
Brice Goglin  wrote:

> Allow -numa without initiator value when hmat=on so that we may
> build more complex topologies, e.g. NUMA nodes whose best initiators
> are not just another single node.
>

patches looks fine code-wise,
however something wrong with them, i.e. 'git am' doesn't like them
nor ./scripts/checkpatch (which one should use before sending patches).

I've checked it's not my mail server/client issue(or whatever)
that corrupts them (ones downloaded from patchew are broken as well)

> changes v3->v4
> * use -numa cpu instead of legacy cpus=
> changes v2->v3:
> * improve messages for patches 0/4 and 3/4
> changes v1->v2:
> * add q35 acpi test
> 
> Brice Goglin (4):
>hmat acpi: Don't require initiator value in -numa
>tests: acpi: add and whitelist *.hmat-noinitiator expected blobs
>tests: acpi: q35: add test for hmat nodes without initiators
>tests: acpi: q35: update expected blobs *.hmat-noinitiators
> 
>   hw/core/machine.c |   4 +-
>   tests/data/acpi/q35/APIC.acpihmat-noinitiator | Bin 0 -> 144 bytes
>   tests/data/acpi/q35/DSDT.acpihmat-noinitiator | Bin 0 -> 8553 bytes
>   tests/data/acpi/q35/FACP.acpihmat-noinitiator | Bin 0 -> 244 bytes
>   tests/data/acpi/q35/HMAT.acpihmat-noinitiator | Bin 0 -> 288 bytes
>   tests/data/acpi/q35/SRAT.acpihmat-noinitiator | Bin 0 -> 312 bytes
>   tests/qtest/bios-tables-test.c|  49 ++
>   7 files changed, 50 insertions(+), 3 deletions(-)
>   create mode 100644 tests/data/acpi/q35/APIC.acpihmat-noinitiator
>   create mode 100644 tests/data/acpi/q35/DSDT.acpihmat-noinitiator
>   create mode 100644 tests/data/acpi/q35/FACP.acpihmat-noinitiator
>   create mode 100644 tests/data/acpi/q35/HMAT.acpihmat-noinitiator
>   create mode 100644 tests/data/acpi/q35/SRAT.acpihmat-noinitiator
> 

[PULL 23/27] hw/i2c: support multiple masters

[Cédric Le Goater]

From: Klaus Jensen 

Allow slaves to master the bus by registering a bottom halve. If the bus
is busy, the bottom half is queued up. When a slave has succesfully
mastered the bus, the bottom half is scheduled.

Signed-off-by: Klaus Jensen 
[ clg : - fixed typos in commit log ]
Message-Id: <20220601210831.67259-4-...@irrelevant.dk>
Signed-off-by: Cédric Le Goater 
Message-Id: <20220630045133.32251-5...@pjd.dev>
Signed-off-by: Cédric Le Goater 
---
 include/hw/i2c/i2c.h | 14 ++
 hw/i2c/core.c| 34 +-
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
index 5ca3b708c0be..be8bb8b78a60 100644
--- a/include/hw/i2c/i2c.h
+++ b/include/hw/i2c/i2c.h
@@ -69,13 +69,25 @@ struct I2CNode {
 QLIST_ENTRY(I2CNode) next;
 };
 
+typedef struct I2CPendingMaster I2CPendingMaster;
+
+struct I2CPendingMaster {
+QEMUBH *bh;
+QSIMPLEQ_ENTRY(I2CPendingMaster) entry;
+};
+
 typedef QLIST_HEAD(I2CNodeList, I2CNode) I2CNodeList;
+typedef QSIMPLEQ_HEAD(I2CPendingMasters, I2CPendingMaster) I2CPendingMasters;
 
 struct I2CBus {
 BusState qbus;
 I2CNodeList current_devs;
+I2CPendingMasters pending_masters;
 uint8_t saved_address;
 bool broadcast;
+
+/* Set from slave currently mastering the bus. */
+QEMUBH *bh;
 };
 
 I2CBus *i2c_init_bus(DeviceState *parent, const char *name);
@@ -117,6 +129,8 @@ int i2c_start_send(I2CBus *bus, uint8_t address);
 
 void i2c_end_transfer(I2CBus *bus);
 void i2c_nack(I2CBus *bus);
+void i2c_bus_master(I2CBus *bus, QEMUBH *bh);
+void i2c_bus_release(I2CBus *bus);
 int i2c_send(I2CBus *bus, uint8_t data);
 uint8_t i2c_recv(I2CBus *bus);
 bool i2c_scan_bus(I2CBus *bus, uint8_t address, bool broadcast,
diff --git a/hw/i2c/core.c b/hw/i2c/core.c
index d0cb2d32fa44..145dce60782a 100644
--- a/hw/i2c/core.c
+++ b/hw/i2c/core.c
@@ -13,6 +13,7 @@
 #include "migration/vmstate.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#include "qemu/main-loop.h"
 #include "trace.h"
 
 #define I2C_BROADCAST 0x00
@@ -62,6 +63,7 @@ I2CBus *i2c_init_bus(DeviceState *parent, const char *name)
 
 bus = I2C_BUS(qbus_new(TYPE_I2C_BUS, parent, name));
 QLIST_INIT(>current_devs);
+QSIMPLEQ_INIT(>pending_masters);
 vmstate_register(NULL, VMSTATE_INSTANCE_ID_ANY, _i2c_bus, bus);
 return bus;
 }
@@ -74,7 +76,7 @@ void i2c_slave_set_address(I2CSlave *dev, uint8_t address)
 /* Return nonzero if bus is busy.  */
 int i2c_bus_busy(I2CBus *bus)
 {
-return !QLIST_EMPTY(>current_devs);
+return !QLIST_EMPTY(>current_devs) || bus->bh;
 }
 
 bool i2c_scan_bus(I2CBus *bus, uint8_t address, bool broadcast,
@@ -180,6 +182,26 @@ int i2c_start_transfer(I2CBus *bus, uint8_t address, bool 
is_recv)
: I2C_START_SEND);
 }
 
+void i2c_bus_master(I2CBus *bus, QEMUBH *bh)
+{
+if (i2c_bus_busy(bus)) {
+I2CPendingMaster *node = g_new(struct I2CPendingMaster, 1);
+node->bh = bh;
+
+QSIMPLEQ_INSERT_TAIL(>pending_masters, node, entry);
+
+return;
+}
+
+bus->bh = bh;
+qemu_bh_schedule(bus->bh);
+}
+
+void i2c_bus_release(I2CBus *bus)
+{
+bus->bh = NULL;
+}
+
 int i2c_start_recv(I2CBus *bus, uint8_t address)
 {
 return i2c_do_start_transfer(bus, address, I2C_START_RECV);
@@ -206,6 +228,16 @@ void i2c_end_transfer(I2CBus *bus)
 g_free(node);
 }
 bus->broadcast = false;
+
+if (!QSIMPLEQ_EMPTY(>pending_masters)) {
+I2CPendingMaster *node = QSIMPLEQ_FIRST(>pending_masters);
+bus->bh = node->bh;
+
+QSIMPLEQ_REMOVE_HEAD(>pending_masters, entry);
+g_free(node);
+
+qemu_bh_schedule(bus->bh);
+}
 }
 
 int i2c_send(I2CBus *bus, uint8_t data)
-- 
2.35.3

[PULL 16/27] hw/sensor: add Maxim MAX31785 device

[Cédric Le Goater]

From: Maheswara Kurapati 

MAX31785 is a PMBus compliant 6-Channel fan controller. It supports 6 fan
channels, 11 temperature sensors, and 6-Channel ADC to measure the remote
voltages. Datasheet can be found here:
https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf

This initial version of the driver has skeleton and support for the
fan channels. Requests for temperature sensors, and ADC Channels the
are serviced with the default values as per the datasheet.  No additional
instrumentation is done. NV Log feature is not supported.

Signed-off-by: Maheswara Kurapati 
Signed-off-by: Jae Hyun Yoo 
Reviewed-by: Joel Stanley 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220627154703.148943-5-quic_jaeh...@quicinc.com>
Signed-off-by: Cédric Le Goater 
---
 hw/sensor/max31785.c  | 573 ++
 hw/sensor/Kconfig |   4 +
 hw/sensor/meson.build |   1 +
 3 files changed, 578 insertions(+)
 create mode 100644 hw/sensor/max31785.c

diff --git a/hw/sensor/max31785.c b/hw/sensor/max31785.c
new file mode 100644
index ..8b95e324814b
--- /dev/null
+++ b/hw/sensor/max31785.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Maxim MAX31785 PMBus 6-Channel Fan Controller
+ *
+ * Datasheet:
+ * https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+ *
+ * Copyright(c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/i2c/pmbus_device.h"
+#include "hw/irq.h"
+#include "migration/vmstate.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+
+#define TYPE_MAX31785 "max31785"
+#define MAX31785(obj) OBJECT_CHECK(MAX31785State, (obj), TYPE_MAX31785)
+
+/* MAX31785 mfr specific PMBus commands */
+#define MAX31785_MFR_MODE   0xD1
+#define MAX31785_MFR_PSEN_CONFIG0xD2
+#define MAX31785_MFR_VOUT_PEAK  0xD4
+#define MAX31785_MFR_TEMPERATURE_PEAK   0xD6
+#define MAX31785_MFR_VOUT_MIN   0xD7
+#define MAX31785_MFR_FAULT_RESPONSE 0xD9
+#define MAX31785_MFR_NV_FAULT_LOG   0xDC
+#define MAX31785_MFR_TIME_COUNT 0xDD
+#define MAX31785_MFR_TEMP_SENSOR_CONFIG 0xF0
+#define MAX31785_MFR_FAN_CONFIG 0xF1
+#define MAX31785_MFR_FAN_LUT0xF2
+#define MAX31785_MFR_READ_FAN_PWM   0xF3
+#define MAX31785_MFR_FAN_FAULT_LIMIT0xF5
+#define MAX31785_MFR_FAN_WARN_LIMIT 0xF6
+#define MAX31785_MFR_FAN_RUN_TIME   0xF7
+#define MAX31785_MFR_FAN_PWM_AVG0xF8
+#define MAX31785_MFR_FAN_PWM2RPM0xF9
+
+/* defaults as per the data sheet */
+#define MAX31785_DEFAULT_CAPABILITY0x10
+#define MAX31785_DEFAULT_VOUT_MODE 0x40
+#define MAX31785_DEFAULT_VOUT_SCALE_MONITOR0x7FFF
+#define MAX31785_DEFAULT_FAN_COMMAND_1 0x7FFF
+#define MAX31785_DEFAULT_OV_FAULT_LIMIT0x7FFF
+#define MAX31785_DEFAULT_OV_WARN_LIMIT 0x7FFF
+#define MAX31785_DEFAULT_OT_FAULT_LIMIT0x7FFF
+#define MAX31785_DEFAULT_OT_WARN_LIMIT 0x7FFF
+#define MAX31785_DEFAULT_PMBUS_REVISION0x11
+#define MAX31785_DEFAULT_MFR_ID0x4D
+#define MAX31785_DEFAULT_MFR_MODEL 0x53
+#define MAX31785_DEFAULT_MFR_REVISION  0x3030
+#define MAX31785A_DEFAULT_MFR_REVISION 0x3040
+#define MAX31785B_DEFAULT_MFR_REVISION 0x3061
+#define MAX31785B_DEFAULT_MFR_TEMPERATURE_PEAK 0x8000
+#define MAX31785B_DEFAULT_MFR_VOUT_MIN 0x7FFF
+#define MAX31785_DEFAULT_TEXT  0x3130313031303130
+
+/* MAX31785 pages */
+#define MAX31785_TOTAL_NUM_PAGES  23
+#define MAX31785_FAN_PAGES6
+#define MAX31785_MIN_FAN_PAGE 0
+#define MAX31785_MAX_FAN_PAGE 5
+#define MAX31785_MIN_TEMP_PAGE6
+#define MAX31785_MAX_TEMP_PAGE16
+#define MAX31785_MIN_ADC_VOLTAGE_PAGE 17
+#define MAX31785_MAX_ADC_VOLTAGE_PAGE 22
+
+/* FAN_CONFIG_1_2 */
+#define MAX31785_MFR_FAN_CONFIG0xF1
+#define MAX31785_FAN_CONFIG_ENABLE BIT(7)
+#define MAX31785_FAN_CONFIG_RPM_PWMBIT(6)
+#define MAX31785_FAN_CONFIG_PULSE(pulse)   (pulse << 4)
+#define MAX31785_DEFAULT_FAN_CONFIG_1_2(pulse) 
\
+(MAX31785_FAN_CONFIG_ENABLE | MAX31785_FAN_CONFIG_PULSE(pulse))
+#define MAX31785_DEFAULT_MFR_FAN_CONFIG0x
+
+/* fan speed in RPM */
+#define MAX31785_DEFAULT_FAN_SPEED   0x7fff
+#define MAX31785_DEFAULT_FAN_STATUS  0x00
+
+#define MAX31785_DEFAULT_FAN_MAX_PWM 0x2710
+
+/*
+ * MAX31785State:
+ * @code: The command code received
+ * @page: Each page corresponds to a device monitored by the Max 31785
+ * The page register determines the available commands depending on device
+ * 
_
+ * |   0   |  Fan Connected to PWM0
|
+ * 
|___|___|
+ * |   1   |  Fan 

[PULL 15/27] hw/i2c: pmbus: Page #255 is valid page for read requests.

[Cédric Le Goater]

From: Maheswara Kurapati 

Current implementation of the pmbus core driver treats the read request
for page 255 as invalid request and sets the invalid command bit (bit 7)
in the STATUS_CML register. As per the PMBus specification it is a valid
request.

Refer to the PMBus specification, revision 1.3.1, section 11.10 PAGE,
on the page 58:
  "Setting the PAGE to FFh means that all subsequent comands are to be
   applied to all outputs.

   Some commands, such as READ_TEMPERATURE, may use a common sensor but
   be available on all pages of a device. Such implementations are the
   decision of each device manufacturer or are specified in a PMBus
   Application Profile. Consult the manufacturer's documents or the
   Application Profile Specification as needed."

For e.g.,
The VOUT_MODE is a valid command for page 255 for maxim 31785 device.
refer to Table 1. PMBus Command Codes on page 14 in the datasheet.
https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf

Fixes: 38870253f1d1 ("hw/i2c: pmbus: fix error returns and guard against out of 
range accesses")

Signed-off-by: Maheswara Kurapati 
Signed-off-by: Jae Hyun Yoo 
Reviewed-by: Titus Rwantare 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220627154703.148943-4-quic_jaeh...@quicinc.com>
Signed-off-by: Cédric Le Goater 
---
 hw/i2c/pmbus_device.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/i2c/pmbus_device.c b/hw/i2c/pmbus_device.c
index 62885fa6a15e..749a33af827b 100644
--- a/hw/i2c/pmbus_device.c
+++ b/hw/i2c/pmbus_device.c
@@ -284,14 +284,10 @@ static uint8_t pmbus_receive_byte(SMBusDevice *smd)
 
 /*
  * Reading from all pages will return the value from page 0,
- * this is unspecified behaviour in general.
+ * means that all subsequent commands are to be applied to all output.
  */
 if (pmdev->page == PB_ALL_PAGES) {
 index = 0;
-qemu_log_mask(LOG_GUEST_ERROR,
-  "%s: tried to read from all pages\n",
-  __func__);
-pmbus_cml_error(pmdev);
 } else if (pmdev->page > pmdev->num_pages - 1) {
 qemu_log_mask(LOG_GUEST_ERROR,
   "%s: page %d is out of range\n",
-- 
2.35.3

[PULL 14/27] hw/arm/aspeed: add Qualcomm Firework BMC machine

[Cédric Le Goater]

From: Graeme Gregory 

Add base for Qualcomm Firework BMC machine.

Signed-off-by: Graeme Gregory 
Signed-off-by: Jae Hyun Yoo 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220627154703.148943-3-quic_jaeh...@quicinc.com>
Signed-off-by: Cédric Le Goater 
---
 hw/arm/aspeed.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 6e4b287fd31b..74cb297dd38c 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -962,6 +962,16 @@ static void qcom_dc_scm_bmc_i2c_init(AspeedMachineState 
*bmc)
 i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 15), "tmp105", 0x4d);
 }
 
+static void qcom_dc_scm_firework_i2c_init(AspeedMachineState *bmc)
+{
+AspeedSoCState *soc = >soc;
+
+/* Create the generic DC-SCM hardware */
+qcom_dc_scm_bmc_i2c_init(bmc);
+
+/* Now create the Firework specific hardware */
+}
+
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
 {
 return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1429,6 +1439,26 @@ static void 
aspeed_machine_qcom_dc_scm_v1_class_init(ObjectClass *oc,
 aspeed_soc_num_cpus(amc->soc_name);
 };
 
+static void aspeed_machine_qcom_firework_class_init(ObjectClass *oc,
+void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+mc->desc   = "Qualcomm DC-SCM V1/Firework BMC (Cortex A7)";
+amc->soc_name  = "ast2600-a3";
+amc->hw_strap1 = QCOM_DC_SCM_V1_BMC_HW_STRAP1;
+amc->hw_strap2 = QCOM_DC_SCM_V1_BMC_HW_STRAP2;
+amc->fmc_model = "n25q512a";
+amc->spi_model = "n25q512a";
+amc->num_cs= 2;
+amc->macs_mask = ASPEED_MAC2_ON | ASPEED_MAC3_ON;
+amc->i2c_init  = qcom_dc_scm_firework_i2c_init;
+mc->default_ram_size = 1 * GiB;
+mc->default_cpus = mc->min_cpus = mc->max_cpus =
+aspeed_soc_num_cpus(amc->soc_name);
+};
+
 static const TypeInfo aspeed_machine_types[] = {
 {
 .name  = MACHINE_TYPE_NAME("palmetto-bmc"),
@@ -1470,6 +1500,10 @@ static const TypeInfo aspeed_machine_types[] = {
 .name  = MACHINE_TYPE_NAME("qcom-dc-scm-v1-bmc"),
 .parent= TYPE_ASPEED_MACHINE,
 .class_init= aspeed_machine_qcom_dc_scm_v1_class_init,
+}, {
+.name  = MACHINE_TYPE_NAME("qcom-firework-bmc"),
+.parent= TYPE_ASPEED_MACHINE,
+.class_init= aspeed_machine_qcom_firework_class_init,
 }, {
 .name  = MACHINE_TYPE_NAME("fp5280g2-bmc"),
 .parent= TYPE_ASPEED_MACHINE,
-- 
2.35.3

[PULL 13/27] hw/arm/aspeed: add support for the Qualcomm DC-SCM v1 board

[Cédric Le Goater]

From: Jae Hyun Yoo 

Add qcom-dc-scm-v1 board support.

Signed-off-by: Jae Hyun Yoo 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220627154703.148943-2-quic_jaeh...@quicinc.com>
Signed-off-by: Cédric Le Goater 
---
 hw/arm/aspeed.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index b43dc0fda853..6e4b287fd31b 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -174,6 +174,10 @@ struct AspeedMachineState {
 #define BLETCHLEY_BMC_HW_STRAP1 AST2600_EVB_HW_STRAP1
 #define BLETCHLEY_BMC_HW_STRAP2 AST2600_EVB_HW_STRAP2
 
+/* Qualcomm DC-SCM hardware value */
+#define QCOM_DC_SCM_V1_BMC_HW_STRAP1  0x
+#define QCOM_DC_SCM_V1_BMC_HW_STRAP2  0x0041
+
 #define AST_SMP_MAILBOX_BASE0x1e6e2180
 #define AST_SMP_MBOX_FIELD_ENTRY(AST_SMP_MAILBOX_BASE + 0x0)
 #define AST_SMP_MBOX_FIELD_GOSIGN   (AST_SMP_MAILBOX_BASE + 0x4)
@@ -951,6 +955,13 @@ static void fby35_i2c_init(AspeedMachineState *bmc)
  */
 }
 
+static void qcom_dc_scm_bmc_i2c_init(AspeedMachineState *bmc)
+{
+AspeedSoCState *soc = >soc;
+
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 15), "tmp105", 0x4d);
+}
+
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
 {
 return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1398,6 +1409,26 @@ static void 
aspeed_minibmc_machine_ast1030_evb_class_init(ObjectClass *oc,
 amc->macs_mask = 0;
 }
 
+static void aspeed_machine_qcom_dc_scm_v1_class_init(ObjectClass *oc,
+ void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+mc->desc   = "Qualcomm DC-SCM V1 BMC (Cortex A7)";
+amc->soc_name  = "ast2600-a3";
+amc->hw_strap1 = QCOM_DC_SCM_V1_BMC_HW_STRAP1;
+amc->hw_strap2 = QCOM_DC_SCM_V1_BMC_HW_STRAP2;
+amc->fmc_model = "n25q512a";
+amc->spi_model = "n25q512a";
+amc->num_cs= 2;
+amc->macs_mask = ASPEED_MAC2_ON | ASPEED_MAC3_ON;
+amc->i2c_init  = qcom_dc_scm_bmc_i2c_init;
+mc->default_ram_size = 1 * GiB;
+mc->default_cpus = mc->min_cpus = mc->max_cpus =
+aspeed_soc_num_cpus(amc->soc_name);
+};
+
 static const TypeInfo aspeed_machine_types[] = {
 {
 .name  = MACHINE_TYPE_NAME("palmetto-bmc"),
@@ -1435,6 +1466,10 @@ static const TypeInfo aspeed_machine_types[] = {
 .name  = MACHINE_TYPE_NAME("g220a-bmc"),
 .parent= TYPE_ASPEED_MACHINE,
 .class_init= aspeed_machine_g220a_class_init,
+}, {
+.name  = MACHINE_TYPE_NAME("qcom-dc-scm-v1-bmc"),
+.parent= TYPE_ASPEED_MACHINE,
+.class_init= aspeed_machine_qcom_dc_scm_v1_class_init,
 }, {
 .name  = MACHINE_TYPE_NAME("fp5280g2-bmc"),
 .parent= TYPE_ASPEED_MACHINE,
-- 
2.35.3

[PULL 12/27] aspeed: Remove use of qemu_get_cpu

[Cédric Le Goater]

From: Peter Delevoryas 

Signed-off-by: Peter Delevoryas 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220624003701.1363500-6-p...@fb.com>
Signed-off-by: Cédric Le Goater 
---
 hw/arm/aspeed_ast2600.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index dbb4a2e838f9..29d2e2ece220 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -318,7 +318,7 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 
 for (i = 0; i < sc->num_cpus; i++) {
 SysBusDevice *sbd = SYS_BUS_DEVICE(>a7mpcore);
-DeviceState  *d   = DEVICE(qemu_get_cpu(i));
+DeviceState  *d   = DEVICE(>cpu[i]);
 
 irq = qdev_get_gpio_in(d, ARM_CPU_IRQ);
 sysbus_connect_irq(sbd, i, irq);
-- 
2.35.3

[PULL 09/27] aspeed: Add memory property to Aspeed SoC

[Cédric Le Goater]

From: Peter Delevoryas 

Multi-SoC machines can use this property to specify a memory container
for each SoC. Single SoC machines will just specify get_system_memory().

Signed-off-by: Peter Delevoryas 
Reviewed-by: Cédric Le Goater 
Message-Id: <20220624003701.1363500-3-p...@fb.com>
Signed-off-by: Cédric Le Goater 
---
 include/hw/arm/aspeed_soc.h |  1 +
 hw/arm/aspeed.c |  4 
 hw/arm/aspeed_ast10x0.c |  5 ++---
 hw/arm/aspeed_ast2600.c |  4 ++--
 hw/arm/aspeed_soc.c | 12 +++-
 5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index e8a104823d35..c8e903b821db 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -49,6 +49,7 @@ struct AspeedSoCState {
 ARMCPU cpu[ASPEED_CPUS_NUM];
 A15MPPrivState a7mpcore;
 ARMv7MStatearmv7m;
+MemoryRegion *memory;
 MemoryRegion *dram_mr;
 MemoryRegion dram_container;
 MemoryRegion sram;
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index dc09773b0ba5..b43dc0fda853 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -329,6 +329,8 @@ static void aspeed_machine_init(MachineState *machine)
 _abort);
 object_property_set_int(OBJECT(>soc), "hw-strap2", amc->hw_strap2,
 _abort);
+object_property_set_link(OBJECT(>soc), "memory",
+ OBJECT(get_system_memory()), _abort);
 object_property_set_link(OBJECT(>soc), "dram",
  OBJECT(machine->ram), _abort);
 if (machine->kernel_filename) {
@@ -1336,6 +1338,8 @@ static void aspeed_minibmc_machine_init(MachineState 
*machine)
 object_initialize_child(OBJECT(machine), "soc", >soc, amc->soc_name);
 qdev_connect_clock_in(DEVICE(>soc), "sysclk", sysclk);
 
+object_property_set_link(OBJECT(>soc), "memory",
+ OBJECT(get_system_memory()), _abort);
 qdev_prop_set_uint32(DEVICE(>soc), "uart-default",
  amc->uart_default);
 qdev_realize(DEVICE(>soc), NULL, _abort);
diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
index 5df480a21f39..e074f80cc742 100644
--- a/hw/arm/aspeed_ast10x0.c
+++ b/hw/arm/aspeed_ast10x0.c
@@ -148,7 +148,6 @@ static void aspeed_soc_ast1030_realize(DeviceState 
*dev_soc, Error **errp)
 {
 AspeedSoCState *s = ASPEED_SOC(dev_soc);
 AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
-MemoryRegion *system_memory = get_system_memory();
 DeviceState *armv7m;
 Error *err = NULL;
 int i;
@@ -172,7 +171,7 @@ static void aspeed_soc_ast1030_realize(DeviceState 
*dev_soc, Error **errp)
 qdev_prop_set_string(armv7m, "cpu-type", sc->cpu_type);
 qdev_connect_clock_in(armv7m, "cpuclk", s->sysclk);
 object_property_set_link(OBJECT(>armv7m), "memory",
- OBJECT(system_memory), _abort);
+ OBJECT(s->memory), _abort);
 sysbus_realize(SYS_BUS_DEVICE(>armv7m), _abort);
 
 /* Internal SRAM */
@@ -181,7 +180,7 @@ static void aspeed_soc_ast1030_realize(DeviceState 
*dev_soc, Error **errp)
 error_propagate(errp, err);
 return;
 }
-memory_region_add_subregion(system_memory,
+memory_region_add_subregion(s->memory,
 sc->memmap[ASPEED_DEV_SRAM],
 >sram);
 
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index a4d90daf3702..e4aa908faba6 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -291,7 +291,7 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 object_property_set_int(OBJECT(>cpu[i]), "cntfrq", 112500,
 _abort);
 object_property_set_link(OBJECT(>cpu[i]), "memory",
- OBJECT(get_system_memory()), _abort);
+ OBJECT(s->memory), _abort);
 
 if (!qdev_realize(DEVICE(>cpu[i]), NULL, errp)) {
 return;
@@ -329,7 +329,7 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 error_propagate(errp, err);
 return;
 }
-memory_region_add_subregion(get_system_memory(),
+memory_region_add_subregion(s->memory,
 sc->memmap[ASPEED_DEV_SRAM], >sram);
 
 /* DPMCU */
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index a53a0ca6d63a..502c23dd0218 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -243,7 +243,7 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 /* CPU */
 for (i = 0; i < sc->num_cpus; i++) {
 object_property_set_link(OBJECT(>cpu[i]), "memory",
- OBJECT(get_system_memory()), _abort);
+ OBJECT(s->memory), _abort);
 if (!qdev_realize(DEVICE(>cpu[i]), NULL, errp)) {
 return;
 }
@@ 

[PATCH] hw/i386: pass RNG seed to e820 setup table

[Jason A. Donenfeld]

Tiny machines optimized for fast boot time generally don't use EFI,
which means a random seed has to be supplied some other way, in this
case by the e820 setup table, which supplies a place for one. This
commit adds passing this random seed via the table. It is confirmed to
be working with the Linux patch in the link.

Link: https://lore.kernel.org/lkml/20220630113300.1892799-1-ja...@zx2c4.com/
Signed-off-by: Jason A. Donenfeld 
---
 hw/i386/x86.c| 19 ++-
 include/standard-headers/asm-x86/bootparam.h |  1 +
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 6003b4b2df..0724759eec 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -26,6 +26,7 @@
 #include "qemu/cutils.h"
 #include "qemu/units.h"
 #include "qemu/datadir.h"
+#include "qemu/guest-random.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qerror.h"
 #include "qapi/qapi-visit-common.h"
@@ -1045,6 +1046,16 @@ void x86_load_linux(X86MachineState *x86ms,
 }
 fclose(f);
 
+setup_data_offset = QEMU_ALIGN_UP(kernel_size, 16);
+kernel_size = setup_data_offset + sizeof(struct setup_data) + 32;
+kernel = g_realloc(kernel, kernel_size);
+stq_p(header + 0x250, prot_addr + setup_data_offset);
+setup_data = (struct setup_data *)(kernel + setup_data_offset);
+setup_data->next = 0;
+setup_data->type = cpu_to_le32(SETUP_RNG_SEED);
+setup_data->len = cpu_to_le32(32);
+qemu_guest_getrandom_nofail(setup_data->data, 32);
+
 /* append dtb to kernel */
 if (dtb_filename) {
 if (protocol < 0x209) {
@@ -1059,13 +1070,11 @@ void x86_load_linux(X86MachineState *x86ms,
 exit(1);
 }
 
-setup_data_offset = QEMU_ALIGN_UP(kernel_size, 16);
-kernel_size = setup_data_offset + sizeof(struct setup_data) + dtb_size;
+kernel_size += sizeof(struct setup_data) + dtb_size;
 kernel = g_realloc(kernel, kernel_size);
 
-stq_p(header + 0x250, prot_addr + setup_data_offset);
-
-setup_data = (struct setup_data *)(kernel + setup_data_offset);
+setup_data->next = prot_addr + setup_data_offset + sizeof(*setup_data) 
+ setup_data->len;
+++setup_data;
 setup_data->next = 0;
 setup_data->type = cpu_to_le32(SETUP_DTB);
 setup_data->len = cpu_to_le32(dtb_size);
diff --git a/include/standard-headers/asm-x86/bootparam.h 
b/include/standard-headers/asm-x86/bootparam.h
index 072e2ed546..b8cb1fa313 100644
--- a/include/standard-headers/asm-x86/bootparam.h
+++ b/include/standard-headers/asm-x86/bootparam.h
@@ -10,6 +10,7 @@
 #define SETUP_EFI  4
 #define SETUP_APPLE_PROPERTIES 5
 #define SETUP_JAILHOUSE6
+#define SETUP_RNG_SEED 8
 
 #define SETUP_INDIRECT (1<<31)
 
-- 
2.35.1

[PULL 08/27] aspeed: Set CPU memory property explicitly

[Cédric Le Goater]

From: Peter Delevoryas 

Signed-off-by: Peter Delevoryas 
Message-Id: <20220624003701.1363500-2-p...@fb.com>
Signed-off-by: Cédric Le Goater 
---
 hw/arm/aspeed_ast2600.c | 2 ++
 hw/arm/aspeed_soc.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index bb5927c36bbf..a4d90daf3702 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -290,6 +290,8 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 
 object_property_set_int(OBJECT(>cpu[i]), "cntfrq", 112500,
 _abort);
+object_property_set_link(OBJECT(>cpu[i]), "memory",
+ OBJECT(get_system_memory()), _abort);
 
 if (!qdev_realize(DEVICE(>cpu[i]), NULL, errp)) {
 return;
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 3e6055ac9129..a53a0ca6d63a 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -242,6 +242,8 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 
 /* CPU */
 for (i = 0; i < sc->num_cpus; i++) {
+object_property_set_link(OBJECT(>cpu[i]), "memory",
+ OBJECT(get_system_memory()), _abort);
 if (!qdev_realize(DEVICE(>cpu[i]), NULL, errp)) {
 return;
 }
-- 
2.35.3