date:20220304

Re: [PATCH 2/2] hw/arm/aspeed: add Bletchley machine type

2022-03-04 Thread Cédric Le Goater


On 3/5/22 01:06, Patrick Williams wrote:

Add the 'bletchley-bmc' machine type based on the kernel DTS[1] and
hardware schematics available to me.  The i2c model is as complete as
the current QEMU models support, but in some cases I substituted devices
that are close enough for present functionality.  Strap registers are
kept the same as the AST2600-EVB until I'm able to confirm correct
values with physical hardware.

This has been tested with an openbmc image built from [2] plus a kernel
patch[3] for the SPI flash module.

1. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts?id=a8c729e966c4e9d033242d948b0e53c2a62d32e2
2. 
https://github.com/openbmc/openbmc/commit/b9432b980d7f63f7512ffbcc7124386ba896dfc6
3. 
https://github.com/openbmc/linux/commit/25b566b9a9d7f5d4f10c1b7304007bdb286eefd7

Signed-off-by: Patrick Williams 
---
  hw/arm/aspeed.c | 77 +
  1 file changed, 77 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 617a1ecbdc..3dc2ede823 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -167,6 +167,11 @@ struct AspeedMachineState {
  #define FUJI_BMC_HW_STRAP10x
  #define FUJI_BMC_HW_STRAP20x
  
+/* Bletchley hardware value */

+/* TODO: Leave same as EVB for now. */
+#define BLETCHLEY_BMC_HW_STRAP1 AST2600_EVB_HW_STRAP1
+#define BLETCHLEY_BMC_HW_STRAP2 AST2600_EVB_HW_STRAP2
+
  /*
   * The max ram region is for firmwares that scan the address space
   * with load/store to guess how much RAM the SoC has.
@@ -901,6 +906,54 @@ static void fuji_bmc_i2c_init(AspeedMachineState *bmc)
  }
  }
  
+#define TYPE_TMP421 "tmp421"

+
+static void bletchley_bmc_i2c_init(AspeedMachineState *bmc)
+{
+AspeedSoCState *soc = >soc;
+I2CBus *i2c[13] = {};
+for (int i = 0; i < 13; i++) {
+if ((i == 8) || (i == 11)) {
+continue;
+}
+i2c[i] = aspeed_i2c_get_bus(>i2c, i);
+}
+
+/* Bus 0 - 5 all have the same config. */
+for (int i = 0; i < 6; i++) {
+/* Missing model: ti,ina230 @ 0x45 */
+/* Missing model: mps,mp5023 @ 0x40 */
+i2c_slave_create_simple(i2c[i], TYPE_TMP421, 0x4f);
+/* Missing model: nxp,pca9539 @ 0x76, but PCA9552 works enough */
+i2c_slave_create_simple(i2c[i], TYPE_PCA9552, 0x76);
+i2c_slave_create_simple(i2c[i], TYPE_PCA9552, 0x67);
+/* Missing model: fsc,fusb302 @ 0x22 */
+}
+
+/* Bus 6 */
+at24c_eeprom_init(i2c[6], 0x56, 65536);
+/* Missing model: nxp,pcf85263 @ 0x51 , but ds1338 works enough */
+i2c_slave_create_simple(i2c[6], "ds1338", 0x51);
+
+
+/* Bus 7 */
+at24c_eeprom_init(i2c[7], 0x54, 65536);
+
+/* Bus 9 */
+i2c_slave_create_simple(i2c[9], TYPE_TMP421, 0x4f);
+
+/* Bus 10 */
+i2c_slave_create_simple(i2c[10], TYPE_TMP421, 0x4f);
+/* Missing model: ti,hdc1080 @ 0x40 */
+i2c_slave_create_simple(i2c[10], TYPE_PCA9552, 0x67);
+
+/* Bus 12 */
+/* Missing model: adi,adm1278 @ 0x11 */
+i2c_slave_create_simple(i2c[12], TYPE_TMP421, 0x4c);
+i2c_slave_create_simple(i2c[12], TYPE_TMP421, 0x4d);
+i2c_slave_create_simple(i2c[12], TYPE_PCA9552, 0x67);
+}
+
  static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
  {
  return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1224,6 +1277,26 @@ static void aspeed_machine_fuji_class_init(ObjectClass 
*oc, void *data)
  aspeed_soc_num_cpus(amc->soc_name);
  };
  
+

+static void aspeed_machine_bletchley_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+mc->desc   = "Facebook Bletchley BMC (Cortex-A7)";
+amc->soc_name  = "ast2600-a3";
+amc->hw_strap1 = BLETCHLEY_BMC_HW_STRAP1;
+amc->hw_strap2 = BLETCHLEY_BMC_HW_STRAP2;
+amc->fmc_model = "w25q01jvq";


So we need this patch :

http://patchwork.ozlabs.org/project/qemu-devel/patch/20220304180920.1780992-1-patr...@stwcx.xyz/

May be I can take it through my queue.


+amc->spi_model = NULL;
+amc->num_cs= 1;


There are two flash devices on the FMC. I can fix it inline since
it is the only change I would request.

Reviewed-by: Cédric Le Goater 

Thanks,

C.


+amc->macs_mask = ASPEED_MAC2_ON;
+amc->i2c_init  = bletchley_bmc_i2c_init;
+mc->default_ram_size = 512 * MiB;
+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"),
@@ -1277,6 +1350,10 @@ static const TypeInfo aspeed_machine_types[] = {
  .name  = MACHINE_TYPE_NAME("fuji-bmc"),
  .parent= TYPE_ASPEED_MACHINE,
  .class_init= aspeed_machine_fuji_class_init,
+}, {
+.name  = MACHINE_TYPE_NAME("bletchley-bmc"),
+.parent=

Re: [PATCH 1/2] hw/arm/aspeed: allow missing spi_model

2022-03-04 Thread Cédric Le Goater


On 3/5/22 01:06, Patrick Williams wrote:

Generally all BMCs will use the fmc_model to hold their own flash
and most will have a spi_model to hold the managed system's flash,
but not all systems do.  Add a simple NULL check to allow a system
to set the spi_model as NULL to indicate it should not be instantiated.



OK. Let's do it that way for now but we need to rework 'num_cs' in the
Aspeed SMC model and the Aspeed machines. We started with a simple
requirement (1 FMC and 1 SPI) but since, things have become more complex.

1. we should get rid of AspeedSMCState::num_cs and simply use
   AspeedSMCState::max_peripherals in the SMC model. There is no need to
   restrict the number devices of the controller to match the board layout.

2. aspeed_board_init_flashes() needs a better interface. May be, something
   like :

   static void aspeed_board_init_flashes(AspeedSMCState *s,
 const char **flashtype, int count,
 int unit0)

and change ->fmc_model and ->spi_model to be arrays. Ideas welcome.

Anyhow,

Reviewed-by: Cédric Le Goater 

Thanks,

C.


Signed-off-by: Patrick Williams 
---
  hw/arm/aspeed.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 11558b327b..617a1ecbdc 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -276,7 +276,11 @@ static void aspeed_board_init_flashes(AspeedSMCState *s,
const char *flashtype,
int unit0)
  {
-int i ;
+int i;
+
+if (!flashtype) {
+return;
+}
  
  for (i = 0; i < s->num_cs; ++i) {

  DriveInfo *dinfo = drive_get(IF_MTD, 0, unit0 + i);

RE: [PATCH v2 06/10] vdpa-dev: implement the unrealize interface

2022-03-04 Thread longpeng2--- via




> -Original Message-
> From: Stefano Garzarella [mailto:sgarz...@redhat.com]
> Sent: Wednesday, January 19, 2022 7:36 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> 
> Cc: stefa...@redhat.com; m...@redhat.com; coh...@redhat.com;
> pbonz...@redhat.com; Gonglei (Arei) ; Yechuan
> ; Huangzhichao ;
> qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 06/10] vdpa-dev: implement the unrealize interface
> 
> On Mon, Jan 17, 2022 at 08:43:27PM +0800, Longpeng(Mike) via wrote:
> >From: Longpeng 
> >
> >Implements the .unrealize interface.
> >
> >Signed-off-by: Longpeng 
> >---
> > hw/virtio/vdpa-dev.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> >diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
> >index bd28cf7a15..e5691d02bb 100644
> >--- a/hw/virtio/vdpa-dev.c
> >+++ b/hw/virtio/vdpa-dev.c
> >@@ -132,9 +132,31 @@ out:
> > s->vdpa_dev_fd = -1;
> > }
> >
> >+static void vhost_vdpa_vdev_unrealize(VhostVdpaDevice *s)
> >+{
> >+VirtIODevice *vdev = VIRTIO_DEVICE(s);
> >+int i;
> >+
> >+for (i = 0; i < s->num_queues; i++) {
> >+virtio_delete_queue(s->virtqs[i]);
> >+}
> >+g_free(s->virtqs);
> >+virtio_cleanup(vdev);
> >+
> >+g_free(s->config);
> 
> Is there a particular reason for these steps in a separate function?
> 
> >+}
> >+
> > static void vhost_vdpa_device_unrealize(DeviceState *dev)
> > {
> >-return;
> >+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >+VhostVdpaDevice *s = VHOST_VDPA_DEVICE(vdev);
> >+
> >+virtio_set_status(vdev, 0);
> >+vhost_vdpa_vdev_unrealize(s);
> >+g_free(s->dev.vqs);
> >+vhost_dev_cleanup(>dev);
> >+qemu_close(s->vdpa_dev_fd);
> >+s->vdpa_dev_fd = -1;
> > }
> 
> Maybe we can have all steps (in the reverse order of
> vhost_vdpa_device_realize) in vhost_vdpa_device_unrealize().
> 

Make sense. Will do.

> Stefano

RE: [PATCH v2 05/10] vdpa-dev: implement the realize interface

2022-03-04 Thread longpeng2--- via




> -Original Message-
> From: Stefano Garzarella [mailto:sgarz...@redhat.com]
> Sent: Wednesday, January 19, 2022 7:31 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> 
> Cc: stefa...@redhat.com; m...@redhat.com; coh...@redhat.com;
> pbonz...@redhat.com; Gonglei (Arei) ; Yechuan
> ; Huangzhichao ;
> qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 05/10] vdpa-dev: implement the realize interface
> 
> On Mon, Jan 17, 2022 at 08:43:26PM +0800, Longpeng(Mike) via wrote:
> >From: Longpeng 
> >
> >Implements the .realize interface.
> >
> >Signed-off-by: Longpeng 
> >---
> > hw/virtio/vdpa-dev.c | 101 +++
> > include/hw/virtio/vdpa-dev.h |   8 +++
> > 2 files changed, 109 insertions(+)
> >
> >diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
> >index b103768f33..bd28cf7a15 100644
> >--- a/hw/virtio/vdpa-dev.c
> >+++ b/hw/virtio/vdpa-dev.c
> >@@ -27,9 +27,109 @@ uint32_t vhost_vdpa_device_get_u32(int fd, unsigned long
> int cmd, Error **errp)
> > return val;
> > }
> >
> >+static void
> >+vhost_vdpa_device_dummy_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> >+{
> >+/* Nothing to do */
> >+}
> >+
> > static void vhost_vdpa_device_realize(DeviceState *dev, Error **errp)
> > {
> >+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >+VhostVdpaDevice *s = VHOST_VDPA_DEVICE(vdev);
> >+uint32_t vdev_id, max_queue_size;
> >+struct vhost_virtqueue *vqs;
> >+int i, ret;
> >+
> >+if (s->vdpa_dev_fd == -1) {
> >+s->vdpa_dev_fd = qemu_open(s->vdpa_dev, O_RDWR, errp);
> 
> So, here we are re-opening the `vdpa_dev` again (without checking if it
> is NULL).
> 
> And we re-do the same ioctls already done in
> vhost_vdpa_device_pci_realize(), so I think we should do them in a
> single place, and that place should be here.
> 
> So, what about doing all the ioctls here, setting appropriate fields in
> VhostVdpaDevice, then using that fields in
> vhost_vdpa_device_pci_realize() after qdev_realize() to set
> `class_code`, `trans_devid`, and `nvectors`?
> 

vhost_vdpa_device_pci_realize()
  qdev_realize()
virtio_device_realize()
  vhost_vdpa_device_realize()
  virtio_bus_device_plugged()
virtio_pci_device_plugged()

These three fields would be used in virtio_pci_device_plugged(), so it's too 
late to set them after qdev_realize().  And they belong to VirtIOPCIProxy, so 
we cannot set them in vhost_vdpa_device_realize() which is transport layer 
independent.

> >+if (*errp) {
> >+return;
> >+}
> >+}
> >+s->vdpa.device_fd = s->vdpa_dev_fd;
> >+
> >+max_queue_size = vhost_vdpa_device_get_u32(s->vdpa_dev_fd,
> >+   VHOST_VDPA_GET_VRING_NUM, 
> >errp);
> >+if (*errp) {
> >+goto out;
> >+}
> >+
> >+if (s->queue_size > max_queue_size) {
> >+error_setg(errp, "vhost-vdpa-device: invalid queue_size: %d
> (max:%d)",
> >+   s->queue_size, max_queue_size);
> >+goto out;
> >+} else if (!s->queue_size) {
> >+s->queue_size = max_queue_size;
> >+}
> >+
> >+s->num_queues = vhost_vdpa_device_get_u32(s->vdpa_dev_fd,
> >+  VHOST_VDPA_GET_VQS_NUM, errp);
>  ^
> VHOST_VDPA_GET_VQS_COUNT
> 

OK, thanks :)

> >+if (*errp) {
> >+goto out;
> >+}
> >+
> >+if (!s->num_queues || s->num_queues > VIRTIO_QUEUE_MAX) {
> >+error_setg(errp, "invalid number of virtqueues: %u (max:%u)",
> >+   s->num_queues, VIRTIO_QUEUE_MAX);
> >+goto out;
> >+}
> >+
> >+s->dev.nvqs = s->num_queues;
> >+vqs = g_new0(struct vhost_virtqueue, s->dev.nvqs);
> >+s->dev.vqs = vqs;
> >+s->dev.vq_index = 0;
> >+s->dev.vq_index_end = s->dev.nvqs;
> >+s->dev.backend_features = 0;
> >+s->started = false;
> >+
> >+ret = vhost_dev_init(>dev, >vdpa, VHOST_BACKEND_TYPE_VDPA, 0,
> NULL);
> >+if (ret < 0) {
> >+error_setg(errp, "vhost-vdpa-device: vhost initialization
> failed: %s",
> >+   strerror(-ret));
> >+goto free_vqs;
> >+}
> >+
> >+vdev_id = vhost_vdpa_device_get_u32(s->vdpa_dev_fd,
> >+VHOST_VDPA_GET_DEVICE_ID, errp);
> >+if (ret < 0) {
> >+error_setg(errp, "vhost-vdpa-device: vhost get device id failed: 
> >%s",
> >+   strerror(-ret));
> >+goto vhost_cleanup;
> >+}
> >+
> >+s->config_size = vhost_vdpa_device_get_u32(s->vdpa_dev_fd,
> >+   VHOST_VDPA_GET_CONFIG_SIZE,
> errp);
> >+if (*errp) {
> >+goto vhost_cleanup;
> >+}
> >+s->config = g_malloc0(s->config_size);
> >+
> >+ret = vhost_dev_get_config(>dev, s->config, s->config_size, NULL);
> >+if (ret < 0) {
> >+error_setg(errp, "vhost-vdpa-device: get config failed");
> >+

Re: [PATCH 1/7] target/ppc: Fix vmul[eo]* instructions marked 2.07

2022-03-04 Thread Cédric Le Goater


On 3/4/22 18:51, matheus.fe...@eldorado.org.br wrote:

From: "Lucas Mateus Castro (alqotel)" 

Some ISA v2.03 Vector Multiply instructions marked to be ISA v2.07 only.
This patch fixes it.


and MacOSX 10 is also fixed.

There are of lot invalid writes when openbios is loaded :

  ...
  Invalid write at addr 0xB70A8, size 4, region 'ppc_core99.bios', reason: 
rejected
  Invalid write at addr 0xB70AC, size 4, region 'ppc_core99.bios', reason: 
rejected
  Invalid write at addr 0xB70B0, size 4, region 'ppc_core99.bios', reason: 
rejected
  Invalid write at addr 0xB70B4, size 4, region 'ppc_core99.bios', reason: 
rejected
  ...

Mark,

shouldn't we model the FW region with RAM instead ?

@@ -162,7 +162,7 @@ static void ppc_core99_init(MachineState
 memory_region_add_subregion(get_system_memory(), 0, machine->ram);
 
 /* allocate and load firmware ROM */

-memory_region_init_rom(bios, NULL, "ppc_core99.bios", PROM_SIZE,
+memory_region_init_ram(bios, NULL, "ppc_core99.bios", PROM_SIZE,
_fatal);
 memory_region_add_subregion(get_system_memory(), PROM_BASE, bios);
 


Thanks,

C.




Fixes: 80eca687c851 ("target/ppc: moved vector even and odd multiplication to 
decodetree")
Reported-by: Howard Spoelstra 
Suggested-by: Fabiano Rosas 
Signed-off-by: Lucas Mateus Castro (alqotel) 
Signed-off-by: Matheus Ferst 
---
  target/ppc/translate/vmx-impl.c.inc | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/target/ppc/translate/vmx-impl.c.inc 
b/target/ppc/translate/vmx-impl.c.inc
index f91bee839d..c5d02d13fe 100644
--- a/target/ppc/translate/vmx-impl.c.inc
+++ b/target/ppc/translate/vmx-impl.c.inc
@@ -3141,14 +3141,14 @@ static bool trans_VMULLD(DisasContext *ctx, arg_VX *a)
  return true;
  }
  
-TRANS_FLAGS2(ALTIVEC_207, VMULESB, do_vx_helper, gen_helper_VMULESB)

-TRANS_FLAGS2(ALTIVEC_207, VMULOSB, do_vx_helper, gen_helper_VMULOSB)
-TRANS_FLAGS2(ALTIVEC_207, VMULEUB, do_vx_helper, gen_helper_VMULEUB)
-TRANS_FLAGS2(ALTIVEC_207, VMULOUB, do_vx_helper, gen_helper_VMULOUB)
-TRANS_FLAGS2(ALTIVEC_207, VMULESH, do_vx_helper, gen_helper_VMULESH)
-TRANS_FLAGS2(ALTIVEC_207, VMULOSH, do_vx_helper, gen_helper_VMULOSH)
-TRANS_FLAGS2(ALTIVEC_207, VMULEUH, do_vx_helper, gen_helper_VMULEUH)
-TRANS_FLAGS2(ALTIVEC_207, VMULOUH, do_vx_helper, gen_helper_VMULOUH)
+TRANS_FLAGS(ALTIVEC, VMULESB, do_vx_helper, gen_helper_VMULESB)
+TRANS_FLAGS(ALTIVEC, VMULOSB, do_vx_helper, gen_helper_VMULOSB)
+TRANS_FLAGS(ALTIVEC, VMULEUB, do_vx_helper, gen_helper_VMULEUB)
+TRANS_FLAGS(ALTIVEC, VMULOUB, do_vx_helper, gen_helper_VMULOUB)
+TRANS_FLAGS(ALTIVEC, VMULESH, do_vx_helper, gen_helper_VMULESH)
+TRANS_FLAGS(ALTIVEC, VMULOSH, do_vx_helper, gen_helper_VMULOSH)
+TRANS_FLAGS(ALTIVEC, VMULEUH, do_vx_helper, gen_helper_VMULEUH)
+TRANS_FLAGS(ALTIVEC, VMULOUH, do_vx_helper, gen_helper_VMULOUH)
  TRANS_FLAGS2(ALTIVEC_207, VMULESW, do_vx_helper, gen_helper_VMULESW)
  TRANS_FLAGS2(ALTIVEC_207, VMULOSW, do_vx_helper, gen_helper_VMULOSW)
  TRANS_FLAGS2(ALTIVEC_207, VMULEUW, do_vx_helper, gen_helper_VMULEUW)

RE: [PATCH v2 04/10] vdpa-dev: implement the instance_init/class_init interface

2022-03-04 Thread longpeng2--- via

Hi Stefano,

> -Original Message-
> From: Stefano Garzarella [mailto:sgarz...@redhat.com]
> Sent: Wednesday, January 19, 2022 7:24 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> 
> Cc: stefa...@redhat.com; m...@redhat.com; coh...@redhat.com;
> pbonz...@redhat.com; Gonglei (Arei) ; Yechuan
> ; Huangzhichao ;
> qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 04/10] vdpa-dev: implement the instance_init/class_init
> interface
> 
> On Mon, Jan 17, 2022 at 08:43:25PM +0800, Longpeng(Mike) via wrote:
> >From: Longpeng 
> >
> >Implements the .instance_init and the .class_init interface.
> >
> >Signed-off-by: Longpeng 
> >---
> > hw/virtio/vdpa-dev-pci.c | 52 ++-
> > hw/virtio/vdpa-dev.c | 81 +++-
> > include/hw/virtio/vdpa-dev.h |  5 +++
> > 3 files changed, 134 insertions(+), 4 deletions(-)
> >
> >diff --git a/hw/virtio/vdpa-dev-pci.c b/hw/virtio/vdpa-dev-pci.c
> >index a5a7b528a9..257538dbdd 100644
> >--- a/hw/virtio/vdpa-dev-pci.c
> >+++ b/hw/virtio/vdpa-dev-pci.c
> >@@ -25,12 +25,60 @@ struct VhostVdpaDevicePCI {
> >
> > static void vhost_vdpa_device_pci_instance_init(Object *obj)
> > {
> >-return;
> >+VhostVdpaDevicePCI *dev = VHOST_VDPA_DEVICE_PCI(obj);
> >+
> >+virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> >+TYPE_VHOST_VDPA_DEVICE);
> >+object_property_add_alias(obj, "bootindex", OBJECT(>vdev),
> >+  "bootindex");
> >+}
> >+
> >+static Property vhost_vdpa_device_pci_properties[] = {
> >+DEFINE_PROP_END_OF_LIST(),
> >+};
> >+
> >+static void
> >+vhost_vdpa_device_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> >+{
> >+VhostVdpaDevicePCI *dev = VHOST_VDPA_DEVICE_PCI(vpci_dev);
> >+DeviceState *vdev = DEVICE(>vdev);
> >+uint32_t vdev_id;
> >+uint32_t num_queues;
> >+int fd;
> >+
> >+fd = qemu_open(dev->vdev.vdpa_dev, O_RDWR, errp);
> 
> We should use `vdpa_dev_fd` if the user set it, and I think we should
> also check that `vdpa_dev` is not null.
> 

The user can set both 'vdpa_dev_fd' and 'vdpa_dev' now, but how
to make sure the 'vdpa_dev_fd' is really a FD of the 'vdpa_dev' ?
Maybe we should remove 'vdpa_dev_fd' from 'vhost_vdpa_device_properties',
so the user can only set 'vdpa_dev'.

> >+if (*errp) {
> >+return;
> >+}
> >+
> >+vdev_id = vhost_vdpa_device_get_u32(fd, VHOST_VDPA_GET_DEVICE_ID, errp);
> >+if (*errp) {
> >+qemu_close(fd);
> >+return;
> >+}
> >+
> >+num_queues = vhost_vdpa_device_get_u32(fd, VHOST_VDPA_GET_VQS_NUM,
> errp);
>   ^
> The build fails here, I think this should be VHOST_VDPA_GET_VQS_COUNT
> 

Yes, I sent a wrong version, I'll send v3 later.

> >+if (*errp) {
> >+qemu_close(fd);
> >+return;
> >+}
> >+
> >+dev->vdev.vdpa_dev_fd = fd;
> >+vpci_dev->class_code = virtio_pci_get_class_id(vdev_id);
> >+vpci_dev->trans_devid = virtio_pci_get_trans_devid(vdev_id);
> >+/* one for config interrupt, one per vq */
> >+vpci_dev->nvectors = num_queues + 1;
> >+qdev_realize(vdev, BUS(_dev->bus), errp);
> > }
> >
> > static void vhost_vdpa_device_pci_class_init(ObjectClass *klass, void
> > *data)
> > {
> >-return;
> >+DeviceClass *dc = DEVICE_CLASS(klass);
> >+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> >+
> >+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> >+device_class_set_props(dc, vhost_vdpa_device_pci_properties);
> >+k->realize = vhost_vdpa_device_pci_realize;
> > }
> >
> > static const VirtioPCIDeviceTypeInfo vhost_vdpa_device_pci_info = {
> >diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
> >index f4f92b90b0..b103768f33 100644
> >--- a/hw/virtio/vdpa-dev.c
> >+++ b/hw/virtio/vdpa-dev.c
> >@@ -15,16 +15,93 @@
> > #include "sysemu/sysemu.h"
> > #include "sysemu/runstate.h"
> >
> >-static void vhost_vdpa_device_class_init(ObjectClass *klass, void *data)
> >+uint32_t vhost_vdpa_device_get_u32(int fd, unsigned long int cmd, Error
> **errp)
> >+{
> >+uint32_t val = (uint32_t)-1;
> >+
> >+if (ioctl(fd, cmd, ) < 0) {
> >+error_setg(errp, "vhost-vdpa-device: cmd 0x%lx failed: %s",
> >+   cmd, strerror(errno));
> >+}
> >+
> >+return val;
> >+}
> >+
> >+static void vhost_vdpa_device_realize(DeviceState *dev, Error **errp)
> > {
> > return;
> > }
> >
> >-static void vhost_vdpa_device_instance_init(Object *obj)
> >+static void vhost_vdpa_device_unrealize(DeviceState *dev)
> >+{
> >+return;
> >+}
> >+
> >+static void
> >+vhost_vdpa_device_get_config(VirtIODevice *vdev, uint8_t *config)
> >+{
> >+return;
> >+}
> >+
> >+static void
> >+vhost_vdpa_device_set_config(VirtIODevice *vdev, const uint8_t *config)
> >+{
> >+return;
> >+}
> >+
> >+static uint64_t vhost_vdpa_device_get_features(VirtIODevice *vdev,
> >+

Re: [PATCH v2 3/5] iotests: Remove explicit checks for qemu_img() == 0

2022-03-04 Thread John Snow

On Fri, Mar 4, 2022 at 3:23 PM Eric Blake  wrote:
>
> On Fri, Mar 04, 2022 at 02:47:44PM -0500, John Snow wrote:
> > qemu_img() returning zero ought to be the rule, not the
> > exception. Remove all explicit checks against the condition in
> > preparation for making non-zero returns an Exception.
> >
> > Signed-off-by: John Snow 
> > ---
>
> > +++ b/tests/qemu-iotests/310
>
> > @@ -105,8 +105,8 @@ with iotests.FilePath('base.img') as base_img_path, \
> >  log('')
> >
> >  # Detach backing to check that we can read the data from the top level 
> > now
> > -assert qemu_img('rebase', '-u', '-b', '', '-f', iotests.imgfmt,
> > -top_img_path) == 0
> > +qemu_img('rebase', '-u', '-b', '', '-f', iotests.imgfmt,
> > + top_img_path)
>
> You collapsed other wrapped lines into one where they fit, why not
> this one?  But it's not essential.
>

jsnow is non-deterministic.

(I can smoosh this in, or kwolf/hreitz can smoosh it in. Probably not
worth a respin, tho.)

> Reviewed-by: Eric Blake 

--js

Re: [PATCH v2 5/9] meson.build: Don't misdetect posix_memalign() on Windows

2022-03-04 Thread Philippe Mathieu-Daudé


On 4/3/22 12:21, Peter Maydell wrote:

Currently we incorrectly think that posix_memalign() exists on
Windows.  This is because of a combination of:

  * the msys2/mingw toolchain/libc claim to have a
__builtin_posix_memalign when there isn't a builtin of that name
  * meson will assume that if you have a __builtin_foo that
counts for has_function('foo')

Specifying a specific include file via prefix: causes meson to not
treat builtins as sufficient and actually look for the function
itself; see this meson pull request which added that as the official
way to get the right answer:
   https://github.com/mesonbuild/meson/pull/1150


Interesting, TIL.

Reviewed-by: Philippe Mathieu-Daudé 


Currently this misdectection doesn't cause problems because we only
use CONFIG_POSIX_MEMALIGN in oslib-posix.c; however that will change
in a following commit.

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20220226180723.1706285-6-peter.mayd...@linaro.org
---
  meson.build | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH v3 1/9] hw/i2c: pmbus: add registers

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

- add the VOUT_MIN and STATUS_MFR registers

Signed-off-by: Titus Rwantare 
---
  hw/i2c/pmbus_device.c | 24 
  include/hw/i2c/pmbus_device.h |  3 +++
  2 files changed, 27 insertions(+)


Reviewed-by: Philippe Mathieu-Daudé

Re: MacOS cocoa/OpenGL

2022-03-04 Thread Akihiko Odaki

On 2022/03/05 0:34, R Kim wrote:

Hello Guys,

Looks like we haven't yet official support for OpenGL on MacOS? I need
to apply third-party patches to make it work. It would be great if these
parts are imported to qemu and be official. Nowaways, it's really needed
Acceleration on VMs for who uses Graphical interfaces browsing, eg, chrome.

I have found it:
https://mail.gnu.org/archive/html/qemu-devel/2021-02/msg04235.html

It uses Angle from Google and the developer seems to be creating you own
branch, with a lot of patches in
https://github.com/akihikodaki/qemu/tree/macos

Another it this one, did small changes, but uses SDL instead of cocoa:
Based on initial work "Virgil 3D on macOS" by 小田喜陽彦 akihikodaki.
https://mail.gnu.org/archive/html/qem... >
With

improvements: - Get rid of ANGLE as EGL libraries. Virgil 3D solely uses
OpenGL Core backend through SDL2 which wraps to NSOpenGL. - No patch to
"cocoa" display of QEMU. Minimal modification to SDL2 display to support
Virgil 3D on macOS. QEMU cannot have both "cocoa" and "sdl2" display in
the same build. - Minimal change to libepoxy and virglrenderer,
basically only have to make sure they built without libdrm and libEGL. -
Fix known issues with OpenGL Core - Performance comparable to ANGLE
OpenGL ES backend. WebGL Aquarium at 60 FPS. Chromium web rendering is
accelerated. The accelerated ArchLinux ARM is very snappy & usable with
Apple HVF virtualization. It matches or even exceeds the performance of
typical ARM Linux flavors running on RK3399 or RPi4 bare-metal. It
probably makes M1 MacBooks the world fastest (... most expensive) Linux
ARM laptops. Nested VM is possible, and there is a demo of qemu-3dfx
Glide passthrough from nested QEMU i386 instance running Blood 1.2 3Dfx
DOS game.

https://www.youtube.com/watch?v=FVv8UjGhYPU

What should we do to have this changes in?

Sent with ProtonMail Secure Email.

Hi,

I'm adding KJ Liew, the author of the implementation with Apple's OpenGL
and sdl2, to Cc. I found the email address at:

https://github.com/kjliew/qemu-3dfx/commit/e01af020580afe172237dfeb471643aa0b6ea60b

https://github.com/akihikodaki/qemu/tree/macos is my tree. My aim is to
have a decent Linux desktop experience, and it has changes irrelevant
with graphics acceleration. The patches I thought ready for submission
are submitted to the mailing list, but the patch to support Virgil 3D is
not because the dependent change for libepoxy is somewhat stuck:

https://github.com/anholt/libepoxy/pull/239

It also contains patches posted on the mailing list I am reviewing and
testing.

I choose cocoa instead of sdl2 to implement Cocoa-specific code like
HiDPI support and cursor composition.

I decided to use ANGLE because the OpenGL implementation by Apple is
deprecated and possible bugs in the implementation would not be
(promptly) fixed. Such bugs may require workarounds in virglrenderer,
but they are not really great for submitting to the upstream.

Those does not mean, however, it is not appropriate to the other
implementation you mentioned, which uses Apple's OpenGL with sdl2. It is
reasonable to choose sdl2 if you don't need features provided by (my
modified) cocoa. The deprecation of Apple's OpenGL may not matter much
since there are many other programs which still rely on it. ANGLE is
also one of them although it is switching to Metal with Apple's help:

https://bugs.chromium.org/p/angleproject/issues/detail?id=5505

The best option to get the patches for Apple OpenGL/sdl2 in is to ask
the author for that. However, the author may not be willing to spend or
cannot afford necessary efforts. In that case, you still need to ask the
author if it is fine to add Signed-off-by line for the patches. The
implication of the line is described at:

https://www.qemu.org/docs/master/devel/submitting-a-patch.html#patch-emails-must-include-a-signed-off-by-line

If you are going to submit patches, please add me to Cc. I'll review and
propose necessary changes.

Regards,
Akihiko Odaki

Re: [PATCH v2] qemu-binfmt-conf.sh: allow elf EI_ABIVERSION=1 for mips

2022-03-04 Thread Philippe Mathieu-Daudé


Cc'ing Laurent:

$ ./scripts/get_maintainer.pl -f scripts/qemu-binfmt-conf.sh
Laurent Vivier  (maintainer:Linux user)
qemu-devel@nongnu.org (open list:All patches CC here)

On 5/3/22 01:06, Andreas K. Hüttel wrote:

With the command line flag -mplt and a recent toolchain, ELF binaries
generated by gcc can obtain EI_ABIVERSION=1, see below, which makes, e.g.,
gcc three-stage bootstrap in a mips-unknown-linux-gnu qemu-user chroot
fail since the binfmt-misc magic does not match anymore.

qemu executes these binaries just fine, so relax the mask slightly.

CHOST=mips-unknown-linux-gnu (and also mipsel-unknown-linux-gnu)
CFLAGS="-O2 -march=mips32 -mabi=32 -mplt -pipe"
gcc-11.2, binutils-2.37, glibc-2.34

|  /*
| - * ELF dump of './prev-gcc/build/gengenrtl'
| - * 29608 (0x73A8) bytes
| + * ELF dump of './gcc/build/gengenrtl'
| + * 54532 (0xD504) bytes
|   */
|
|  Elf32_Dyn dumpedelf_dyn_0[];
|  struct {
| Elf32_Ehdr ehdr;
| Elf32_Phdr phdrs[12];
| -   Elf32_Shdr shdrs[33];
| +   Elf32_Shdr shdrs[44];
| Elf32_Dyn *dyns;
|  } dumpedelf_0 = {
|
|  .ehdr = {
| .e_ident = { /* (EI_NIDENT bytes) */
| /* [0] EI_MAG:*/ 0x7F,'E','L','F',
| /* [4] EI_CLASS:  */ 1 , /* (ELFCLASS32) */
| /* [5] EI_DATA:   */ 2 , /* (ELFDATA2MSB) */
| /* [6] EI_VERSION:*/ 1 , /* (EV_CURRENT) */
| /* [7] EI_OSABI:  */ 0 , /* (ELFOSABI_NONE) */
| -   /* [8] EI_ABIVERSION: */ 0 ,
| +   /* [8] EI_ABIVERSION: */ 1 ,
| /* [9-15] EI_PAD: */ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
| },
| .e_type  = 2  , /* (ET_EXEC) */
| .e_machine   = 8  , /* (EM_MIPS) */
| .e_version   = 1  , /* (EV_CURRENT) */
| (...)

Signed-off-by: Andreas K. Hüttel 
---

v2: Add the same fix for little endian as for big endian

  scripts/qemu-binfmt-conf.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index e9bfeb94d3..fc2f856800 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -61,11 +61,11 @@ m68k_family=m68k
  # FIXME: We could use the other endianness on a MIPS host.
  
  mips_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08'

-mips_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
+mips_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
  mips_family=mips
  
  mipsel_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00'

-mipsel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+mipsel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
  mipsel_family=mips
  
  mipsn32_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08'

Re: [PATCH v3 7/9] hw/sensor: add Intersil ISL69260 device model

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

Signed-off-by: Titus Rwantare 
Reviewed-by: Hao Wu 
---
  MAINTAINERS  |   3 +
  hw/arm/Kconfig   |   1 +
  hw/sensor/Kconfig|   5 +
  hw/sensor/isl_pmbus_vr.c | 211 +
  hw/sensor/meson.build|   1 +
  include/hw/sensor/isl_pmbus_vr.h |  50 
  tests/qtest/isl_pmbus_vr-test.c  | 394 +++
  tests/qtest/meson.build  |   1 +
  8 files changed, 666 insertions(+)
  create mode 100644 hw/sensor/isl_pmbus_vr.c
  create mode 100644 include/hw/sensor/isl_pmbus_vr.h
  create mode 100644 tests/qtest/isl_pmbus_vr-test.c



diff --git a/hw/sensor/Kconfig b/hw/sensor/Kconfig
index 215944decc..a834d2f814 100644
--- a/hw/sensor/Kconfig
+++ b/hw/sensor/Kconfig
@@ -30,3 +30,8 @@ config LSM303DLHC_MAG
  bool
  depends on I2C
  default y if I2C_DEVICES
+
+config ISL_PMBUS_VR
+bool
+depends on I2C


There is a PMBUS kconfig selector (which selects SMBUS -> I2C).


+
diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
new file mode 100644
index 00..b3d24e40ab
--- /dev/null
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -0,0 +1,211 @@
+/*
+ * PMBus device for Renesas Digital Multiphase Voltage Regulators
+ *
+ * Copyright 2021 Google LLC
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sensor/isl_pmbus_vr.h"
+#include "hw/qdev-properties.h"
+#include "qapi/visitor.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+
+static uint8_t isl_pmbus_vr_read_byte(PMBusDevice *pmdev)
+{
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: reading from unsupported register: 0x%02x\n",
+  __func__, pmdev->code);
+return 0xFF;


Eventually PMBUS_ERROR_BYTE.


+}
+
+static int isl_pmbus_vr_write_data(PMBusDevice *pmdev, const uint8_t *buf,
+  uint8_t len)


Mis-aligned.


+{
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: write to unsupported register: 0x%02x\n",
+  __func__, pmdev->code);
+return 0xFF;
+}



+static void raa22xx_init(Object *obj)
+{
+PMBusDevice *pmdev = PMBUS_DEVICE(obj);
+uint64_t flags[2];
+
+flags[0] = PB_HAS_VIN | PB_HAS_VOUT | PB_HAS_VOUT_MODE |
+   PB_HAS_VOUT_RATING | PB_HAS_VOUT_MARGIN | PB_HAS_IIN |
+   PB_HAS_IOUT | PB_HAS_PIN | PB_HAS_POUT | PB_HAS_TEMPERATURE |
+   PB_HAS_TEMP2 | PB_HAS_TEMP3 | PB_HAS_STATUS_MFR_SPECIFIC;
+flags[1] = PB_HAS_IIN | PB_HAS_PIN | PB_HAS_TEMPERATURE | PB_HAS_TEMP3 |
+   PB_HAS_VOUT | PB_HAS_VOUT_MODE | PB_HAS_VOUT_MARGIN |
+   PB_HAS_VOUT_RATING | PB_HAS_IOUT | PB_HAS_POUT |
+   PB_HAS_STATUS_MFR_SPECIFIC;
+
+pmbus_page_config(pmdev, 0, flags[0]);
+pmbus_page_config(pmdev, 1, flags[1]);
+isl_pmbus_vr_add_props(obj, flags, 2);


Eventually 2 -> ARRAY_SIZE(flags).


+++ b/include/hw/sensor/isl_pmbus_vr.h
@@ -0,0 +1,50 @@
+/*
+ * PMBus device for Renesas Digital Multiphase Voltage Regulators
+ *
+ * Copyright 2022 Google LLC
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef HW_MISC_ISL_PMBUS_VR_H
+#define HW_MISC_ISL_PMBUS_VR_H
+
+#include "hw/i2c/pmbus_device.h"
+#include "qom/object.h"
+
+#define TYPE_ISL69260   "isl69260"
+
+struct ISLState {
+PMBusDevice parent;
+};
+
+OBJECT_DECLARE_SIMPLE_TYPE(ISLState, ISL69260)
+
+#define ISL_CAPABILITY_DEFAULT 0x40
+#define ISL_OPERATION_DEFAULT  0x80
+#define ISL_ON_OFF_CONFIG_DEFAULT  0x16
+#define ISL_VOUT_MODE_DEFAULT  0x40
+#define ISL_VOUT_COMMAND_DEFAULT   0x0384
+#define ISL_VOUT_MAX_DEFAULT   0x08FC
+#define ISL_VOUT_MARGIN_HIGH_DEFAULT   0x0640
+#define ISL_VOUT_MARGIN_LOW_DEFAULT0xFA
+#define ISL_VOUT_TRANSITION_RATE_DEFAULT   0x64
+#define ISL_VOUT_OV_FAULT_LIMIT_DEFAULT0x076C
+#define ISL_OT_FAULT_LIMIT_DEFAULT 0x7D
+#define ISL_OT_WARN_LIMIT_DEFAULT  0x07D0
+#define ISL_VIN_OV_WARN_LIMIT_DEFAULT  0x36B0
+#define ISL_VIN_UV_WARN_LIMIT_DEFAULT  0x1F40
+#define ISL_IIN_OC_FAULT_LIMIT_DEFAULT 0x32
+#define ISL_TON_DELAY_DEFAULT  0x14
+#define ISL_TON_RISE_DEFAULT   0x01F4
+#define ISL_TOFF_FALL_DEFAULT  0x01F4
+#define ISL_REVISION_DEFAULT   0x33
+#define ISL_READ_VOUT_DEFAULT  1000
+#define ISL_READ_IOUT_DEFAULT  40
+#define ISL_READ_POUT_DEFAULT  4
+#define ISL_READ_TEMP_DEFAULT  25
+#define ISL_READ_VIN_DEFAULT   1100
+#define ISL_READ_IIN_DEFAULT   40
+#define ISL_READ_PIN_DEFAULT   4


Hmmm we need to expose the DEFAULT definitions for the tests. OK.

Changing Kconfig:
Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 2/9] hw/i2c: pmbus: guard against out of range accesses

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

Signed-off-by: Titus Rwantare 
---
  hw/i2c/pmbus_device.c | 41 -
  1 file changed, 40 insertions(+), 1 deletion(-)



  static uint8_t pmbus_receive_byte(SMBusDevice *smd)
  {
  PMBusDevice *pmdev = PMBUS_DEVICE(smd);
  PMBusDeviceClass *pmdc = PMBUS_DEVICE_GET_CLASS(pmdev);
  uint8_t ret = 0xFF;
-uint8_t index = pmdev->page;
+uint8_t index;
  
  if (pmdev->out_buf_len != 0) {

  ret = pmbus_out_buf_pop(pmdev);
  return ret;
  }
  
+/*

+ * Reading from all pages will return the value from page 0,
+ * this is unspecified behaviour in general.
+ */
+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",
+  __func__, pmdev->page);
+pmbus_cml_error(pmdev);
+return -1;


This file returns a mix of 0xFF/-1 for error. It would be nice
to pick one. Adding a definition (PMBUS_ERR_BYTE?) could help.

Preferably with error unified:
Reviewed-by: Philippe Mathieu-Daudé

[PATCH 2/2] hw/arm/aspeed: add Bletchley machine type

2022-03-04 Thread Patrick Williams

Add the 'bletchley-bmc' machine type based on the kernel DTS[1] and
hardware schematics available to me.  The i2c model is as complete as
the current QEMU models support, but in some cases I substituted devices
that are close enough for present functionality.  Strap registers are
kept the same as the AST2600-EVB until I'm able to confirm correct
values with physical hardware.

This has been tested with an openbmc image built from [2] plus a kernel
patch[3] for the SPI flash module.

1. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts?id=a8c729e966c4e9d033242d948b0e53c2a62d32e2
2. 
https://github.com/openbmc/openbmc/commit/b9432b980d7f63f7512ffbcc7124386ba896dfc6
3. 
https://github.com/openbmc/linux/commit/25b566b9a9d7f5d4f10c1b7304007bdb286eefd7

Signed-off-by: Patrick Williams 
---
 hw/arm/aspeed.c | 77 +
 1 file changed, 77 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 617a1ecbdc..3dc2ede823 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -167,6 +167,11 @@ struct AspeedMachineState {
 #define FUJI_BMC_HW_STRAP10x
 #define FUJI_BMC_HW_STRAP20x
 
+/* Bletchley hardware value */
+/* TODO: Leave same as EVB for now. */
+#define BLETCHLEY_BMC_HW_STRAP1 AST2600_EVB_HW_STRAP1
+#define BLETCHLEY_BMC_HW_STRAP2 AST2600_EVB_HW_STRAP2
+
 /*
  * The max ram region is for firmwares that scan the address space
  * with load/store to guess how much RAM the SoC has.
@@ -901,6 +906,54 @@ static void fuji_bmc_i2c_init(AspeedMachineState *bmc)
 }
 }
 
+#define TYPE_TMP421 "tmp421"
+
+static void bletchley_bmc_i2c_init(AspeedMachineState *bmc)
+{
+AspeedSoCState *soc = >soc;
+I2CBus *i2c[13] = {};
+for (int i = 0; i < 13; i++) {
+if ((i == 8) || (i == 11)) {
+continue;
+}
+i2c[i] = aspeed_i2c_get_bus(>i2c, i);
+}
+
+/* Bus 0 - 5 all have the same config. */
+for (int i = 0; i < 6; i++) {
+/* Missing model: ti,ina230 @ 0x45 */
+/* Missing model: mps,mp5023 @ 0x40 */
+i2c_slave_create_simple(i2c[i], TYPE_TMP421, 0x4f);
+/* Missing model: nxp,pca9539 @ 0x76, but PCA9552 works enough */
+i2c_slave_create_simple(i2c[i], TYPE_PCA9552, 0x76);
+i2c_slave_create_simple(i2c[i], TYPE_PCA9552, 0x67);
+/* Missing model: fsc,fusb302 @ 0x22 */
+}
+
+/* Bus 6 */
+at24c_eeprom_init(i2c[6], 0x56, 65536);
+/* Missing model: nxp,pcf85263 @ 0x51 , but ds1338 works enough */
+i2c_slave_create_simple(i2c[6], "ds1338", 0x51);
+
+
+/* Bus 7 */
+at24c_eeprom_init(i2c[7], 0x54, 65536);
+
+/* Bus 9 */
+i2c_slave_create_simple(i2c[9], TYPE_TMP421, 0x4f);
+
+/* Bus 10 */
+i2c_slave_create_simple(i2c[10], TYPE_TMP421, 0x4f);
+/* Missing model: ti,hdc1080 @ 0x40 */
+i2c_slave_create_simple(i2c[10], TYPE_PCA9552, 0x67);
+
+/* Bus 12 */
+/* Missing model: adi,adm1278 @ 0x11 */
+i2c_slave_create_simple(i2c[12], TYPE_TMP421, 0x4c);
+i2c_slave_create_simple(i2c[12], TYPE_TMP421, 0x4d);
+i2c_slave_create_simple(i2c[12], TYPE_PCA9552, 0x67);
+}
+
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
 {
 return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1224,6 +1277,26 @@ static void aspeed_machine_fuji_class_init(ObjectClass 
*oc, void *data)
 aspeed_soc_num_cpus(amc->soc_name);
 };
 
+
+static void aspeed_machine_bletchley_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+mc->desc   = "Facebook Bletchley BMC (Cortex-A7)";
+amc->soc_name  = "ast2600-a3";
+amc->hw_strap1 = BLETCHLEY_BMC_HW_STRAP1;
+amc->hw_strap2 = BLETCHLEY_BMC_HW_STRAP2;
+amc->fmc_model = "w25q01jvq";
+amc->spi_model = NULL;
+amc->num_cs= 1;
+amc->macs_mask = ASPEED_MAC2_ON;
+amc->i2c_init  = bletchley_bmc_i2c_init;
+mc->default_ram_size = 512 * MiB;
+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"),
@@ -1277,6 +1350,10 @@ static const TypeInfo aspeed_machine_types[] = {
 .name  = MACHINE_TYPE_NAME("fuji-bmc"),
 .parent= TYPE_ASPEED_MACHINE,
 .class_init= aspeed_machine_fuji_class_init,
+}, {
+.name  = MACHINE_TYPE_NAME("bletchley-bmc"),
+.parent= TYPE_ASPEED_MACHINE,
+.class_init= aspeed_machine_bletchley_class_init,
 }, {
 .name  = TYPE_ASPEED_MACHINE,
 .parent= TYPE_MACHINE,
-- 
2.34.1

[PATCH 1/2] hw/arm/aspeed: allow missing spi_model

2022-03-04 Thread Patrick Williams

Generally all BMCs will use the fmc_model to hold their own flash
and most will have a spi_model to hold the managed system's flash,
but not all systems do.  Add a simple NULL check to allow a system
to set the spi_model as NULL to indicate it should not be instantiated.

Signed-off-by: Patrick Williams 
---
 hw/arm/aspeed.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 11558b327b..617a1ecbdc 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -276,7 +276,11 @@ static void aspeed_board_init_flashes(AspeedSMCState *s,
   const char *flashtype,
   int unit0)
 {
-int i ;
+int i;
+
+if (!flashtype) {
+return;
+}
 
 for (i = 0; i < s->num_cs; ++i) {
 DriveInfo *dinfo = drive_get(IF_MTD, 0, unit0 + i);
-- 
2.34.1

[PATCH v2] qemu-binfmt-conf.sh: allow elf EI_ABIVERSION=1 for mips

2022-03-04 Thread Andreas K . Hüttel

With the command line flag -mplt and a recent toolchain, ELF binaries
generated by gcc can obtain EI_ABIVERSION=1, see below, which makes, e.g.,
gcc three-stage bootstrap in a mips-unknown-linux-gnu qemu-user chroot
fail since the binfmt-misc magic does not match anymore.

qemu executes these binaries just fine, so relax the mask slightly.

CHOST=mips-unknown-linux-gnu (and also mipsel-unknown-linux-gnu)
CFLAGS="-O2 -march=mips32 -mabi=32 -mplt -pipe"
gcc-11.2, binutils-2.37, glibc-2.34

|  /*
| - * ELF dump of './prev-gcc/build/gengenrtl'
| - * 29608 (0x73A8) bytes
| + * ELF dump of './gcc/build/gengenrtl'
| + * 54532 (0xD504) bytes
|   */
|
|  Elf32_Dyn dumpedelf_dyn_0[];
|  struct {
| Elf32_Ehdr ehdr;
| Elf32_Phdr phdrs[12];
| -   Elf32_Shdr shdrs[33];
| +   Elf32_Shdr shdrs[44];
| Elf32_Dyn *dyns;
|  } dumpedelf_0 = {
|
|  .ehdr = {
| .e_ident = { /* (EI_NIDENT bytes) */
| /* [0] EI_MAG:*/ 0x7F,'E','L','F',
| /* [4] EI_CLASS:  */ 1 , /* (ELFCLASS32) */
| /* [5] EI_DATA:   */ 2 , /* (ELFDATA2MSB) */
| /* [6] EI_VERSION:*/ 1 , /* (EV_CURRENT) */
| /* [7] EI_OSABI:  */ 0 , /* (ELFOSABI_NONE) */
| -   /* [8] EI_ABIVERSION: */ 0 ,
| +   /* [8] EI_ABIVERSION: */ 1 ,
| /* [9-15] EI_PAD: */ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
| },
| .e_type  = 2  , /* (ET_EXEC) */
| .e_machine   = 8  , /* (EM_MIPS) */
| .e_version   = 1  , /* (EV_CURRENT) */
| (...)

Signed-off-by: Andreas K. Hüttel 
---

v2: Add the same fix for little endian as for big endian

 scripts/qemu-binfmt-conf.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index e9bfeb94d3..fc2f856800 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -61,11 +61,11 @@ m68k_family=m68k
 # FIXME: We could use the other endianness on a MIPS host.
 
 
mips_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08'
-mips_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
+mips_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
 mips_family=mips
 
 
mipsel_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00'
-mipsel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+mipsel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
 mipsel_family=mips
 
 
mipsn32_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08'
-- 
2.34.1

Re: [PATCH v3 3/9] hw/i2c: pmbus: add PEC unsupported warning

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

Signed-off-by: Titus Rwantare 
---
  hw/i2c/pmbus_device.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/hw/i2c/pmbus_device.c b/hw/i2c/pmbus_device.c
index 93c746bab3..6eeb0731d7 100644
--- a/hw/i2c/pmbus_device.c
+++ b/hw/i2c/pmbus_device.c
@@ -307,6 +307,11 @@ static uint8_t pmbus_receive_byte(SMBusDevice *smd)
  
  case PMBUS_CAPABILITY:

  pmbus_send8(pmdev, pmdev->capability);
+if (pmdev->capability & BIT(7)) {
+qemu_log_mask(LOG_GUEST_ERROR,


That would be LOG_UNIMP?


+  "%s: PEC is enabled but not yet supported.\n",
+  __func__);
+}
  break;
  
  case PMBUS_VOUT_MODE: /* R/W byte */

Re: [PATCH v3 4/9] hw/i2c: pmbus: refactor uint handling

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

This change cleans up the inputs to pmbus_receive uint, the length of
received data is contained in PMBusDevice state and doesn't need to be
passed around.

Signed-off-by: Titus Rwantare 
---
  hw/i2c/pmbus_device.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 9/9] hw/sensor: add Renesas raa228000 device

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

Signed-off-by: Titus Rwantare 
Reviewed-by: Hao Wu 
---
  hw/sensor/isl_pmbus_vr.c | 50 
  include/hw/sensor/isl_pmbus_vr.h |  1 +
  tests/qtest/isl_pmbus_vr-test.c  | 78 ++--
  3 files changed, 126 insertions(+), 3 deletions(-)

diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
index e260faeac3..df7c003ea6 100644
--- a/hw/sensor/isl_pmbus_vr.c
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -89,6 +89,24 @@ static void isl_pmbus_vr_exit_reset(Object *obj)
  }
  }
  
+/* The raa228000 uses different direct mode coefficents from most isl devices */

+static void raa228000_exit_reset(Object *obj)
+{
+isl_pmbus_vr_exit_reset(obj);
+
+PMBusDevice *pmdev = PMBUS_DEVICE(obj);


Per QEMU CodingStyle, variables are declared first.


+pmdev->pages[0].read_vout = 0;
+pmdev->pages[0].read_iout = 0;
+pmdev->pages[0].read_pout = 0;
+pmdev->pages[0].read_vin = 0;
+pmdev->pages[0].read_iin = 0;
+pmdev->pages[0].read_pin = 0;
+pmdev->pages[0].read_temperature_1 = 0;
+pmdev->pages[0].read_temperature_2 = 0;
+pmdev->pages[0].read_temperature_3 = 0;
+}



  /* test qmp access */
  static void test_tx_rx(void *obj, void *data, QGuestAllocator *alloc)
  {
@@ -384,9 +448,6 @@ static void isl_pmbus_vr_register_nodes(void)
  qos_node_create_driver("isl69260", i2c_device_create);
  qos_node_consumes("isl69260", "i2c-bus", );
  
-qos_node_create_driver("raa229004", i2c_device_create);

-qos_node_consumes("raa229004", "i2c-bus", );
-
  qos_add_test("test_defaults", "isl69260", test_defaults, NULL);
  qos_add_test("test_tx_rx", "isl69260", test_tx_rx, NULL);
  qos_add_test("test_rw_regs", "isl69260", test_rw_regs, NULL);
@@ -394,9 +455,20 @@ static void isl_pmbus_vr_register_nodes(void)
  qos_add_test("test_ro_regs", "isl69260", test_ro_regs, NULL);
  qos_add_test("test_ov_faults", "isl69260", test_voltage_faults, NULL);
  
+qos_node_create_driver("raa229004", i2c_device_create);

+qos_node_consumes("raa229004", "i2c-bus", );
+


Squash in previous commit?


  qos_add_test("test_tx_rx", "raa229004", test_tx_rx, NULL);
  qos_add_test("test_rw_regs", "raa229004", test_rw_regs, NULL);
  qos_add_test("test_pages_rw", "raa229004", test_pages_rw, NULL);
  qos_add_test("test_ov_faults", "raa229004", test_voltage_faults, NULL);


Otherwise,
Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 8/9] hw/sensor: add Renesas raa229004 PMBus device

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

The Renesas RAA229004 is a PMBus Multiphase Voltage Regulator

Signed-off-by: Titus Rwantare 
Reviewed-by: Hao Wu 
---
  hw/sensor/isl_pmbus_vr.c | 18 ++
  include/hw/sensor/isl_pmbus_vr.h |  1 +
  tests/qtest/isl_pmbus_vr-test.c  |  8 
  3 files changed, 27 insertions(+)


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 6/9] hw/i2c: Added linear mode translation for pmbus devices

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

From: Shengtan Mao 

Signed-off-by: Shengtan Mao 
Reviewed-by: Titus Rwantare 
---
  hw/i2c/pmbus_device.c | 18 ++
  include/hw/i2c/pmbus_device.h | 20 +++-
  2 files changed, 37 insertions(+), 1 deletion(-)


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 5/9] hw/i2c: pmbus: update MAINTAINERS

2022-03-04 Thread Philippe Mathieu-Daudé


On 2/3/22 02:50, Titus Rwantare wrote:

add self to MAINTAINERS for the PMBus subsystem and related sensors,
and set PMBus as maintained.

Signed-off-by: Titus Rwantare 
---
  MAINTAINERS | 10 ++
  1 file changed, 10 insertions(+)


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v3 0/9] This patch series contains updates to PMBus in QEMU along with some PMBus device models for Renesas regulators. I have also added myself to MAINTAINERS as this code is in use daily,

2022-03-04 Thread Titus Rwantare

On Fri, 4 Mar 2022 at 13:43, Corey Minyard  wrote:
>
> On Tue, Mar 01, 2022 at 05:50:44PM -0800, Titus Rwantare wrote:
> > v2:
> >   - split PMBus commit with updates into individual fixes
> >   - renamed isl_pmbus[.ch] adding _vr for voltage regulators
> >
> > v3:
> >   - split uint refactor commit and removed commit renaming files
> >   - rename rolled into preceding commits
> >   - update commit description for uint refactoring change
>
> This all looks good to me:
>
> Acked-by: Corey Minyard 
>
> Do you have a plan for getting this in to qemu?  Like through the ARM
> tree?  I could take it into an I2C tree, but there's really not much
> activity or work there.
>
> -corey

In general PMBus is more specific to i2c than ARM, but I'm not sure of
the QEMU implications.

Titus

1 2 3 4 5 >

1 - 100 of 461 matches

Mail list logo