Re: [PATCH] hw/nvme: fix handling of over-committed queues

[Klaus Jensen]

On Oct 28 09:15, Keith Busch wrote:
> On Mon, Oct 28, 2024 at 10:01:50AM +0100, Klaus Jensen wrote:
> > On Oct 25 10:45, Keith Busch wrote:
> > > On Fri, Oct 25, 2024 at 12:50:45PM +0200, Klaus Jensen wrote:
> > > > @@ -1520,9 +1520,16 @@ static void nvme_post_cqes(void *opaque)
> > > >  nvme_inc_cq_tail(cq);
> > > >  nvme_sg_unmap(&req->sg);
> > > > +
> > > > +if (QTAILQ_EMPTY(&sq->req_list) && !nvme_sq_empty(sq)) {
> > > > +qemu_bh_schedule(sq->bh);
> > > > +}
> > > > +
> > > >  QTAILQ_INSERT_TAIL(&sq->req_list, req, entry);
> > > >  }
> > > 
> > > Shouldn't we schedule the bottom half after the req has been added to
> > > the list? I think everything the callback needs to be written prior to
> > > calling qemu_bh_schedule().
> > > 
> > 
> > Not as far as I know. It is only queued up; it won't be executed
> > immediately. It might run next (ASAP) if we are already in a bottom
> > half, but not before whatever context we are in returns.
> 
> Okay. I was trying to come up with an explanation for why Waldek was
> still able to reproduce the problem, and that was all I have so far.
> 

I was too eager in removing the start_sqs stuff. I removed kicking the
cq when transitioning from full to non-full. The core fix is the right
one, but I introduced a bug...

v2 just posted should be good. Verified it with OSv master.


signature.asc
Description: PGP signature

[PATCH v2] hw/nvme: fix handling of over-committed queues

[Klaus Jensen]

From: Klaus Jensen 

If a host chooses to use the SQHD "hint" in the CQE to know if there is
room in the submission queue for additional commands, it may result in a
situation where there are not enough internal resources (struct
NvmeRequest) available to process the command. For a lack of a better
term, the host may "over-commit" the device (i.e., it may have more
inflight commands than the queue size).

For example, assume a queue with N entries. The host submits N commands
and all are picked up for processing, advancing the head and emptying
the queue. Regardless of which of these N commands complete first, the
SQHD field of that CQE will indicate to the host that the queue is
empty, which allows the host to issue N commands again. However, if the
device has not posted CQEs for all the previous commands yet, the device
will have less than N resources available to process the commands, so
queue processing is suspended.

And here lies an 11 year latent bug. In the absense of any additional
tail updates on the submission queue, we never schedule the processing
bottom-half again unless we observe a head update on an associated full
completion queue. This has been sufficient to handle N-to-1 SQ/CQ setups
(in the absense of over-commit of course). Incidentially, that "kick all
associated SQs" mechanism can now be killed since we now just schedule
queue processing when we return a processing resource to a non-empty
submission queue, which happens to cover both edge cases. However, we
must retain kicking the CQ if it was previously full.

So, apparently, no previous driver tested with hw/nvme has ever used
SQHD (e.g., neither the Linux NVMe driver or SPDK uses it). But then OSv
shows up with the driver that actually does. I salute you.

Fixes: f3c507adcd7b ("NVMe: Initial commit for new storage interface")
Cc: qemu-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2388
Reported-by: Waldemar Kozaczuk 
Signed-off-by: Klaus Jensen 
---
Changes in v2:
- Retain cq kick on previously full queue
- Link to v1: 
https://lore.kernel.org/r/20241025-issue-2388-v1-1-16707e0d3...@samsung.com
---
 hw/nvme/ctrl.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 
f4e89203c1a6e3b051fd7185cbf01ec9bae9684a..1185455a94c4af43a39708b1b97dba9624fc7ad3
 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -1520,9 +1520,16 @@ static void nvme_post_cqes(void *opaque)
 stl_le_p(&n->bar.csts, NVME_CSTS_FAILED);
 break;
 }
+
 QTAILQ_REMOVE(&cq->req_list, req, entry);
+
 nvme_inc_cq_tail(cq);
 nvme_sg_unmap(&req->sg);
+
+if (QTAILQ_EMPTY(&sq->req_list) && !nvme_sq_empty(sq)) {
+qemu_bh_schedule(sq->bh);
+}
+
 QTAILQ_INSERT_TAIL(&sq->req_list, req, entry);
 }
 if (cq->tail != cq->head) {
@@ -7950,7 +7957,6 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int 
val)
 /* Completion queue doorbell write */
 
 uint16_t new_head = val & 0x;
-int start_sqs;
 NvmeCQueue *cq;
 
 qid = (addr - (0x1000 + (1 << 2))) >> 3;
@@ -8001,19 +8007,16 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, 
int val)
 
 trace_pci_nvme_mmio_doorbell_cq(cq->cqid, new_head);
 
-start_sqs = nvme_cq_full(cq) ? 1 : 0;
-cq->head = new_head;
-if (!qid && n->dbbuf_enabled) {
-stl_le_pci_dma(pci, cq->db_addr, cq->head, MEMTXATTRS_UNSPECIFIED);
-}
-if (start_sqs) {
-NvmeSQueue *sq;
-QTAILQ_FOREACH(sq, &cq->sq_list, entry) {
-qemu_bh_schedule(sq->bh);
-}
+/* scheduled deferred cqe posting if queue was previously full */
+if (nvme_cq_full(cq)) {
 qemu_bh_schedule(cq->bh);
 }
 
+cq->head = new_head;
+if (!qid && n->dbbuf_enabled) {
+stl_le_pci_dma(pci, cq->db_addr, cq->head, MEMTXATTRS_UNSPECIFIED);
+}
+
 if (cq->tail == cq->head) {
 if (cq->irq_enabled) {
 n->cq_pending--;

---
base-commit: fdf250e5a37830615e324017cb3a503e84b3712c
change-id: 20241025-issue-2388-bd047487f74c

Best regards,
-- 
Klaus Jensen 

Re: [PATCH] hw/sd/sdcard: Fix calculation of size when using eMMC boot partitions

[Cédric Le Goater]

On 10/28/24 17:23, Jan Luebbe wrote:

The sd_bootpart_offset() function calculates the *runtime* offset which
changes as the guest switches between accessing the main user data area
and the boot partitions by writing to the EXT_CSD_PART_CONFIG_ACC_MASK
bits, so it shouldn't be used to calculate the main user data area size.

Instead, subtract the boot_part_size directly (twice, as there are two
identical boot partitions defined by the eMMC spec).


Fixes: c8cb19876d3e ("hw/sd/sdcard: Support boot area in emmc image")


Suggested-by: Cédric Le Goater 
Signed-off-by: Jan Luebbe 


Tested-by: Guenter Roeck 

Reviewed-by: Cédric Le Goater 

Thanks,

C.




---
  hw/sd/sd.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 2d3467c3d956..8430d5ae361c 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -826,7 +826,9 @@ static void sd_reset(DeviceState *dev)
  sect = 0;
  }
  size = sect << HWBLOCK_SHIFT;
-size -= sd_bootpart_offset(sd);
+if (sd_is_emmc(sd)) {
+size -= sd->boot_part_size * 2;
+}
  
  sect = sd_addr_to_wpnum(size) + 1;
  

Re: [PATCH v3 3/7] qapi: block-job-change: make copy-mode parameter optional

[Vladimir Sementsov-Ogievskiy]

On 22.10.24 15:35, Kevin Wolf wrote:

Am 02.10.2024 um 16:06 hat Vladimir Sementsov-Ogievskiy geschrieben:

We are going to add more parameters to change. We want to make possible
to change only one or any subset of available options. So all the
options should be optional.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Acked-by: Markus Armbruster 


This is different from blockdev-reopen, which requires repeating all
options (and can therefore reuse the type from blockdev-add). One of the
reasons why we made it like that is that we had some options for which
"option absent" was a meaningful value in itself, so it would have
become ambiguous if an absent option in blockdev-reopen should mean
"leave the existing value unchanged" or "unset the option".



Right.. Thanks for noting this. I'll try to apply blockdev-reopen approach here.


Are we confident that this will never happen with job options? In case
of doubt, I would go for consistency with blockdev-reopen.

Either way, it would be good to document the reasoning for whatever
option we choose in the commit message.

Kevin



--
Best regards,
Vladimir

[PATCH v5 09/15] gpex: Allow more than 4 legacy IRQs

[Phil Dennis-Jordan]

From: Alexander Graf 

Some boards such as vmapple don't do real legacy PCI IRQ swizzling.
Instead, they just keep allocating more board IRQ lines for each new
legacy IRQ. Let's support that mode by giving instantiators a new
"nr_irqs" property they can use to support more than 4 legacy IRQ lines.
In this mode, GPEX will export more IRQ lines, one for each device.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Akihiko Odaki 
---

v4:

 * Turned pair of IRQ arrays into array of structs.
 * Simplified swizzling logic selection.

 hw/arm/sbsa-ref.c  |  2 +-
 hw/arm/virt.c  |  2 +-
 hw/i386/microvm.c  |  2 +-
 hw/loongarch/virt.c|  2 +-
 hw/mips/loongson3_virt.c   |  2 +-
 hw/openrisc/virt.c | 12 +--
 hw/pci-host/gpex.c | 43 ++
 hw/riscv/virt.c| 12 +--
 hw/xtensa/virt.c   |  2 +-
 include/hw/pci-host/gpex.h |  7 +++
 10 files changed, 55 insertions(+), 31 deletions(-)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index e3195d54497..7e7322486c2 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -673,7 +673,7 @@ static void create_pcie(SBSAMachineState *sms)
 /* Map IO port space */
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);
 
-for (i = 0; i < GPEX_NUM_IRQS; i++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
 sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
qdev_get_gpio_in(sms->gic, irq + i));
 gpex_set_irq_num(GPEX_HOST(dev), i, irq + i);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 8b2b991d978..bd3b17be2ea 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1547,7 +1547,7 @@ static void create_pcie(VirtMachineState *vms)
 /* Map IO port space */
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);
 
-for (i = 0; i < GPEX_NUM_IRQS; i++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
 sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
qdev_get_gpio_in(vms->gic, irq + i));
 gpex_set_irq_num(GPEX_HOST(dev), i, irq + i);
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 693099f2256..b3a348bee09 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -139,7 +139,7 @@ static void create_gpex(MicrovmMachineState *mms)
 mms->gpex.mmio64.base, mmio64_alias);
 }
 
-for (i = 0; i < GPEX_NUM_IRQS; i++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
 sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
x86ms->gsi[mms->gpex.irq + i]);
 }
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 9a635d1d3d3..50056384994 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -741,7 +741,7 @@ static void virt_devices_init(DeviceState *pch_pic,
 memory_region_add_subregion(get_system_memory(), VIRT_PCI_IO_BASE,
 pio_alias);
 
-for (i = 0; i < GPEX_NUM_IRQS; i++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
 sysbus_connect_irq(d, i,
qdev_get_gpio_in(pch_pic, 16 + i));
 gpex_set_irq_num(GPEX_HOST(gpex_dev), i, 16 + i);
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index f3b6326cc59..884b5f23a99 100644
--- a/hw/mips/loongson3_virt.c
+++ b/hw/mips/loongson3_virt.c
@@ -458,7 +458,7 @@ static inline void loongson3_virt_devices_init(MachineState 
*machine,
 virt_memmap[VIRT_PCIE_PIO].base, s->pio_alias);
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, virt_memmap[VIRT_PCIE_PIO].base);
 
-for (i = 0; i < GPEX_NUM_IRQS; i++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
 irq = qdev_get_gpio_in(pic, PCIE_IRQ_BASE + i);
 sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, irq);
 gpex_set_irq_num(GPEX_HOST(dev), i, PCIE_IRQ_BASE + i);
diff --git a/hw/openrisc/virt.c b/hw/openrisc/virt.c
index 47d2c9bd3c7..6f053bf48e0 100644
--- a/hw/openrisc/virt.c
+++ b/hw/openrisc/virt.c
@@ -318,7 +318,7 @@ static void create_pcie_irq_map(void *fdt, char *nodename, 
int irq_base,
 {
 int pin, dev;
 uint32_t irq_map_stride = 0;
-uint32_t full_irq_map[GPEX_NUM_IRQS * GPEX_NUM_IRQS * 6] = {};
+uint32_t full_irq_map[PCI_NUM_PINS * PCI_NUM_PINS * 6] = {};
 uint32_t *irq_map = full_irq_map;
 
 /*
@@ -330,11 +330,11 @@ static void create_pcie_irq_map(void *fdt, char 
*nodename, int irq_base,
  * possible slot) seeing the interrupt-map-mask will allow the table
  * to wrap to any number of devices.
  */
-for (dev = 0; dev < GPEX_NUM_IRQS; dev++) {
+for (dev = 0; dev < PCI_NUM_PINS; dev++) {
 int devfn = dev << 3;
 
-for (pin = 0; pin < GPEX_NUM_IRQS; pin++) {
-int irq_nr = irq_base + ((pin + PCI_SLOT(devfn)) % GPEX_NUM_IRQS);
+for (pin = 0; pin < PCI_NUM_PINS; pin++) {
+int irq_nr = irq_base + ((pin + PCI_SLOT(devfn)) % PCI_NUM_PINS);
 int i = 0;
 
 

[PATCH v5 00/15] macOS PV Graphics and new vmapple machine type

[Phil Dennis-Jordan]

This patch set introduces a new ARM and macOS HVF specific machine type
called "vmapple", as well as a family of display devices based on the
ParavirtualizedGraphics.framework in macOS. One of the display adapter
variants, apple-gfx-mmio, is required for the new machine type, while
apple-gfx-pci can be used to enable 3D graphics acceleration with x86-64
macOS guest OSes.

Previous versions of this patch set were submitted semi-separately:
the original vmapple patch set by Alexander Graf included a monolithic
implementation of apple-gfx-mmio. I subsequently reviewed and reworked
the latter to support the PCI variant of the device as well and submitted
the result in isolation. As requested in subsequent review, I have now
recombined this with the original vmapple patch set, which I have updated
and improved in a few ways as well.

The vmapple machine type approximates the configuration in macOS's own
Virtualization.framework when running arm64 macOS guests. In addition to
generic components such as a GICv3 and an XHCI USB controller, it
includes nonstandard extensions to the virtio block device, a special
"hardware" aes engine, a configuration device, a pvpanic variant, a
"backdoor" interface, and of course the apple-gfx paravirtualised display
adapter.

There are currently a few limitations to this which aren't intrinsic,
just imperfect emulation of the VZF, but it's good enough to be just
about usable for some purposes:

 * macOS 12 guests only. Versions 13+ currently fail during early boot.
 * macOS 11+ arm64 hosts only, with hvf accel. (Perhaps some differences
   between Apple M series CPUs and TCG's aarch64 implementation? macOS
   hosts only because ParavirtualizedGraphics.framework is a black box
   implementing most of the logic behind the apple-gfx device.)
 * PCI devices use legacy IRQs, not MSI/MSI-X. As far as I can tell,
   we'd need to include the GICv3 ITS, but it's unclear to me what
   exactly needs wiring up.
 * Due to lack of MSI(-X), event delivery from USB devices to the guest
   macOS isn't working correctly. My current conclusion is that the
   OS's XHCI driver simply was never designed to work with legacy IRQs.
   The upshot is that keyboard and mouse/tablet input is very laggy.
   The solution would be to implement MSI(-X) support or figure out how
   to make hcd-xhci-sysbus work with the macOS guest, if at all possible.
   (EHCI and UHCI/OHCI controllers are not an option as the VMAPPLE
   guest kernel does not include drivers for these.)
 * The guest OS must first be provisioned using Virtualization.framework;
   the disk images can subsequently be used in Qemu. (See docs.)

The apple-gfx device can be used independently from the vmapple machine
type, at least in the PCI variant. It mainly targets x86-64 macOS guests
from version 11 on, but also includes a UEFI bootrom for basic
framebuffer mode. macOS 11 is also required on the host side, as well
as a GPU that supports the Metal API. On the guest side, this provides
3D acceleration/GPGPU support with a baseline Metal feature set,
irrespective of the host GPU's feature set. A few limitations in the
current integration:

 * Although it works fine with TCG, it does not work correctly
   cross-architecture: x86-64 guests on arm64 hosts appear to make
   some boot progress, but rendering is corrupted. I suspect
   incompatible texture memory layouts; I have no idea if this is
   fixable.
 * ParavirtualizedGraphics.framework and the guest driver support
   multi-headed configurations. The current Qemu integration always
   connects precisely 1 display.
 * State serialisation and deserialisation is currently not
   implemented, though supported in principle by the framework.
   Both apple-gfx variants thus set up a migration blocker.
 * Rendering efficiency could be better. The GPU-rendered guest
   framebuffer is copied to system memory and uses Qemu's usual
   CPU-based drawing. For maximum efficiency, the Metal texture
   containing the guest framebuffer could be drawn directly to
   a Metal view in the host window, staying on the GPU. (Similar
   to the OpenGL/virgl render path on other platforms.)

My part of this work has been sponsored by Sauce Labs Inc.

---

v2 -> v3:

 * Merged the apple-gfx and vmapple patchsets.
 * Squashed a bunch of later apple-gfx patches into the main one.
   (dGPU support, queried MMIO area size, host GPU picking logic.)
 * Rebased on latest upstream, fixing any breakages due to internal
   Qemu API changes.
 * apple-gfx: Switched to re-entrant MMIO. This is supported by the
   underlying framework and simplifies the MMIO forwarding code which
   was previously different on x86-64 vs aarch64.
 * vmapple: Fixes for minor bugs and comments from the last round of
   review.
 * vmapple aes, conf, apple-gfx: Switched reset methods to implement
   the ResettableClass base's interface.
 * vmapple: switched from virtio-hid to an XHCI USB controller and
   USB mouse and tablet devices. macOS does not provide dri

[PATCH v5 03/15] hw/display/apple-gfx: Adds PCI implementation

[Phil Dennis-Jordan]

This change wires up the PCI variant of the paravirtualised
graphics device, mainly useful for x86-64 macOS guests, implemented
by macOS's ParavirtualizedGraphics.framework. It builds on code
shared with the vmapple/mmio variant of the PVG device.

Signed-off-by: Phil Dennis-Jordan 
---

v4:

 * Threading improvements analogous to those in common apple-gfx code
   and mmio device variant.
 * Addressed some smaller issues raised in code review.

v5:

 * Minor error handling improvement.

 hw/display/Kconfig |   4 +
 hw/display/apple-gfx-pci.m | 149 +
 hw/display/meson.build |   1 +
 3 files changed, 154 insertions(+)
 create mode 100644 hw/display/apple-gfx-pci.m

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index 6a9b7b19ada..2b53dfd7d26 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -149,3 +149,7 @@ config MAC_PVG_MMIO
 bool
 depends on MAC_PVG && AARCH64
 
+config MAC_PVG_PCI
+bool
+depends on MAC_PVG && PCI
+default y if PCI_DEVICES
diff --git a/hw/display/apple-gfx-pci.m b/hw/display/apple-gfx-pci.m
new file mode 100644
index 000..870d0c41e66
--- /dev/null
+++ b/hw/display/apple-gfx-pci.m
@@ -0,0 +1,149 @@
+/*
+ * QEMU Apple ParavirtualizedGraphics.framework device, PCI variant
+ *
+ * Copyright © 2023-2024 Phil Dennis-Jordan
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * ParavirtualizedGraphics.framework is a set of libraries that macOS provides
+ * which implements 3d graphics passthrough to the host as well as a
+ * proprietary guest communication channel to drive it. This device model
+ * implements support to drive that library from within QEMU as a PCI device
+ * aimed primarily at x86-64 macOS VMs.
+ */
+
+#include "apple-gfx.h"
+#include "hw/pci/pci_device.h"
+#include "hw/pci/msi.h"
+#include "qapi/error.h"
+#include "trace.h"
+#import 
+
+OBJECT_DECLARE_SIMPLE_TYPE(AppleGFXPCIState, APPLE_GFX_PCI)
+
+struct AppleGFXPCIState {
+PCIDevice parent_obj;
+
+AppleGFXState common;
+};
+
+static const char* apple_gfx_pci_option_rom_path = NULL;
+
+static void apple_gfx_init_option_rom_path(void)
+{
+NSURL *option_rom_url = PGCopyOptionROMURL();
+const char *option_rom_path = option_rom_url.fileSystemRepresentation;
+apple_gfx_pci_option_rom_path = g_strdup(option_rom_path);
+[option_rom_url release];
+}
+
+static void apple_gfx_pci_init(Object *obj)
+{
+AppleGFXPCIState *s = APPLE_GFX_PCI(obj);
+
+if (!apple_gfx_pci_option_rom_path) {
+/* The following is done on device not class init to avoid running
+ * ObjC code before fork() in -daemonize mode. */
+PCIDeviceClass *pci = PCI_DEVICE_CLASS(object_get_class(obj));
+apple_gfx_init_option_rom_path();
+pci->romfile = apple_gfx_pci_option_rom_path;
+}
+
+apple_gfx_common_init(obj, &s->common, TYPE_APPLE_GFX_PCI);
+}
+
+typedef struct AppleGFXPCIInterruptJob {
+PCIDevice *device;
+uint32_t vector;
+} AppleGFXPCIInterruptJob;
+
+static void apple_gfx_pci_raise_interrupt(void *opaque)
+{
+AppleGFXPCIInterruptJob *job = opaque;
+
+if (msi_enabled(job->device)) {
+msi_notify(job->device, job->vector);
+}
+g_free(job);
+}
+
+static void apple_gfx_pci_interrupt(PCIDevice *dev, AppleGFXPCIState *s,
+uint32_t vector)
+{
+AppleGFXPCIInterruptJob *job;
+
+trace_apple_gfx_raise_irq(vector);
+job = g_malloc0(sizeof(*job));
+job->device = dev;
+job->vector = vector;
+aio_bh_schedule_oneshot(qemu_get_aio_context(),
+apple_gfx_pci_raise_interrupt, job);
+}
+
+static void apple_gfx_pci_realize(PCIDevice *dev, Error **errp)
+{
+AppleGFXPCIState *s = APPLE_GFX_PCI(dev);
+int ret;
+
+pci_register_bar(dev, PG_PCI_BAR_MMIO,
+ PCI_BASE_ADDRESS_SPACE_MEMORY, &s->common.iomem_gfx);
+
+ret = msi_init(dev, 0x0 /* config offset; 0 = find space */,
+   PG_PCI_MAX_MSI_VECTORS, true /* msi64bit */,
+   false /*msi_per_vector_mask*/, errp);
+if (ret != 0) {
+return;
+}
+
+@autoreleasepool {
+PGDeviceDescriptor *desc = [PGDeviceDescriptor new];
+desc.raiseInterrupt = ^(uint32_t vector) {
+apple_gfx_pci_interrupt(dev, s, vector);
+};
+
+apple_gfx_common_realize(&s->common, desc, errp);
+[desc release];
+desc = nil;
+}
+}
+
+static void apple_gfx_pci_reset(Object *obj, ResetType type)
+{
+AppleGFXPCIState *s = APPLE_GFX_PCI(obj);
+[s->common.pgdev reset];
+}
+
+static void apple_gfx_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+PCIDeviceClass *pci = PCI_DEVICE_CLASS(klass);
+ResettableClass *rc = RESETTABLE_CLASS(klass);
+
+rc->phases.hold = apple_gfx_pci_reset;
+dc->desc = "macOS Paravirtualized Graphics PCI Display Controller";
+dc->hotpluggable = false;
+s

[PATCH v5 12/15] hw/vmapple/cfg: Introduce vmapple cfg region

[Phil Dennis-Jordan]

From: Alexander Graf 

Instead of device tree or other more standardized means, VMApple passes
platform configuration to the first stage boot loader in a binary encoded
format that resides at a dedicated RAM region in physical address space.

This patch models this configuration space as a qdev device which we can
then map at the fixed location in the address space. That way, we can
influence and annotate all configuration fields easily.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
---
v3:

 * Replaced legacy device reset method with Resettable method

v4:

 * Fixed initialisation of default values for properties
 * Dropped superfluous endianness conversions
 * Moved most header code to .c, device name #define goes in vmapple.h

v5:

 * Improved error reporting in case of string property buffer overflow.

 hw/vmapple/Kconfig   |   3 +
 hw/vmapple/cfg.c | 203 +++
 hw/vmapple/meson.build   |   1 +
 include/hw/vmapple/vmapple.h |   2 +
 4 files changed, 209 insertions(+)
 create mode 100644 hw/vmapple/cfg.c

diff --git a/hw/vmapple/Kconfig b/hw/vmapple/Kconfig
index 68f88876eb9..8bbeb9a9237 100644
--- a/hw/vmapple/Kconfig
+++ b/hw/vmapple/Kconfig
@@ -4,3 +4,6 @@ config VMAPPLE_AES
 config VMAPPLE_BDIF
 bool
 
+config VMAPPLE_CFG
+bool
+
diff --git a/hw/vmapple/cfg.c b/hw/vmapple/cfg.c
new file mode 100644
index 000..91c57239f86
--- /dev/null
+++ b/hw/vmapple/cfg.c
@@ -0,0 +1,203 @@
+/*
+ * VMApple Configuration Region
+ *
+ * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/vmapple/vmapple.h"
+#include "hw/sysbus.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+#include "net/net.h"
+
+OBJECT_DECLARE_SIMPLE_TYPE(VMAppleCfgState, VMAPPLE_CFG)
+
+#define VMAPPLE_CFG_SIZE 0x0001
+
+typedef struct VMAppleCfg {
+uint32_t version; /* 0x000 */
+uint32_t nr_cpus; /* 0x004 */
+uint32_t unk1;/* 0x008 */
+uint32_t unk2;/* 0x00c */
+uint32_t unk3;/* 0x010 */
+uint32_t unk4;/* 0x014 */
+uint64_t ecid;/* 0x018 */
+uint64_t ram_size;/* 0x020 */
+uint32_t run_installer1;  /* 0x028 */
+uint32_t unk5;/* 0x02c */
+uint32_t unk6;/* 0x030 */
+uint32_t run_installer2;  /* 0x034 */
+uint32_t rnd; /* 0x038 */
+uint32_t unk7;/* 0x03c */
+MACAddr mac_en0;  /* 0x040 */
+uint8_t pad1[2];
+MACAddr mac_en1;  /* 0x048 */
+uint8_t pad2[2];
+MACAddr mac_wifi0;/* 0x050 */
+uint8_t pad3[2];
+MACAddr mac_bt0;  /* 0x058 */
+uint8_t pad4[2];
+uint8_t reserved[0xa0];   /* 0x060 */
+uint32_t cpu_ids[0x80];   /* 0x100 */
+uint8_t scratch[0x200];   /* 0x180 */
+char serial[32];  /* 0x380 */
+char unk8[32];/* 0x3a0 */
+char model[32];   /* 0x3c0 */
+uint8_t unk9[32]; /* 0x3e0 */
+uint32_t unk10;   /* 0x400 */
+char soc_name[32];/* 0x404 */
+} VMAppleCfg;
+
+struct VMAppleCfgState {
+SysBusDevice parent_obj;
+VMAppleCfg cfg;
+
+MemoryRegion mem;
+char *serial;
+char *model;
+char *soc_name;
+};
+
+static void vmapple_cfg_reset(Object *obj, ResetType type)
+{
+VMAppleCfgState *s = VMAPPLE_CFG(obj);
+VMAppleCfg *cfg;
+
+cfg = memory_region_get_ram_ptr(&s->mem);
+memset(cfg, 0, VMAPPLE_CFG_SIZE);
+*cfg = s->cfg;
+}
+
+static bool strlcpy_set_error(char *restrict dst, const char *restrict src,
+  size_t dst_size, Error **errp,
+  const char *parent_func, const char *location,
+  const char *buffer_name, const char *extra_info)
+{
+size_t len;
+
+len = g_strlcpy(dst, src, dst_size);
+if (len < dst_size) { /* len does not count nul terminator */
+return true;
+}
+
+error_setg(errp,
+   "%s (%s) strlcpy error: Destination buffer %s too small "
+   "(need %zu, have %zu) %s",
+   parent_func, location, buffer_name, len + 1, dst_size, 
extra_info);
+return false;
+}
+
+/*
+ * String copying wrapper that returns and reports a runtime error in
+ * case of truncation due to insufficient destination buffer space.
+ */
+#define strlcpy_array_return_error(dst_array, src, errp, extra_info) \
+do { \
+if (!strlcpy_set_error((dst_array), (src), ARRAY_SIZE(dst_array), \
+   (errp), __func__, stringify(__LINE__), \
+   # dst_array, extra_info)) { \
+return; \
+} \
+} while (0)
+
+st

[PATCH v5 10/15] hw/vmapple/aes: Introduce aes engine

[Phil Dennis-Jordan]

From: Alexander Graf 

VMApple contains an "aes" engine device that it uses to encrypt and
decrypt its nvram. It has trivial hard coded keys it uses for that
purpose.

Add device emulation for this device model.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
---
v3:

 * Rebased on latest upstream and fixed minor breakages.
 * Replaced legacy device reset method with Resettable method

v4:

 * Improved logging of unimplemented functions and guest errors.
 * Better adherence to naming and coding conventions.
 * Cleaner error handling and recovery, including using g_autoptr

v5:

 * More logging improvements
 * Use xxx64_overflow() functions for hexdump buffer size calculations.

 hw/vmapple/Kconfig   |   2 +
 hw/vmapple/aes.c | 578 +++
 hw/vmapple/meson.build   |   1 +
 hw/vmapple/trace-events  |  14 +
 include/hw/vmapple/vmapple.h |  17 ++
 include/qemu/cutils.h|  15 +
 util/hexdump.c   |  18 ++
 7 files changed, 645 insertions(+)
 create mode 100644 hw/vmapple/aes.c
 create mode 100644 include/hw/vmapple/vmapple.h

diff --git a/hw/vmapple/Kconfig b/hw/vmapple/Kconfig
index 8b137891791..a73504d5999 100644
--- a/hw/vmapple/Kconfig
+++ b/hw/vmapple/Kconfig
@@ -1 +1,3 @@
+config VMAPPLE_AES
+bool
 
diff --git a/hw/vmapple/aes.c b/hw/vmapple/aes.c
new file mode 100644
index 000..2b4567b6a57
--- /dev/null
+++ b/hw/vmapple/aes.c
@@ -0,0 +1,578 @@
+/*
+ * QEMU Apple AES device emulation
+ *
+ * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "trace.h"
+#include "crypto/hash.h"
+#include "crypto/aes.h"
+#include "crypto/cipher.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "hw/vmapple/vmapple.h"
+#include "migration/vmstate.h"
+#include "qemu/cutils.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "sysemu/dma.h"
+
+OBJECT_DECLARE_SIMPLE_TYPE(AESState, APPLE_AES)
+
+#define MAX_FIFO_SIZE 9
+
+#define CMD_KEY   0x1
+#define CMD_KEY_CONTEXT_SHIFT27
+#define CMD_KEY_CONTEXT_MASK (0x1 << CMD_KEY_CONTEXT_SHIFT)
+#define CMD_KEY_SELECT_MAX_IDX   0x7
+#define CMD_KEY_SELECT_SHIFT 24
+#define CMD_KEY_SELECT_MASK  (CMD_KEY_SELECT_MAX_IDX << 
CMD_KEY_SELECT_SHIFT)
+#define CMD_KEY_KEY_LEN_NUM  4u
+#define CMD_KEY_KEY_LEN_SHIFT22
+#define CMD_KEY_KEY_LEN_MASK ((CMD_KEY_KEY_LEN_NUM - 1u) << 
CMD_KEY_KEY_LEN_SHIFT)
+#define CMD_KEY_ENCRYPT_SHIFT20
+#define CMD_KEY_ENCRYPT_MASK (0x1 << CMD_KEY_ENCRYPT_SHIFT)
+#define CMD_KEY_BLOCK_MODE_SHIFT 16
+#define CMD_KEY_BLOCK_MODE_MASK  (0x3 << CMD_KEY_BLOCK_MODE_SHIFT)
+#define CMD_IV0x2
+#define CMD_IV_CONTEXT_SHIFT 26
+#define CMD_IV_CONTEXT_MASK  (0x3 << CMD_KEY_CONTEXT_SHIFT)
+#define CMD_DSB   0x3
+#define CMD_SKG   0x4
+#define CMD_DATA  0x5
+#define CMD_DATA_KEY_CTX_SHIFT   27
+#define CMD_DATA_KEY_CTX_MASK(0x1 << CMD_DATA_KEY_CTX_SHIFT)
+#define CMD_DATA_IV_CTX_SHIFT25
+#define CMD_DATA_IV_CTX_MASK (0x3 << CMD_DATA_IV_CTX_SHIFT)
+#define CMD_DATA_LEN_MASK0xff
+#define CMD_STORE_IV  0x6
+#define CMD_STORE_IV_ADDR_MASK   0xff
+#define CMD_WRITE_REG 0x7
+#define CMD_FLAG  0x8
+#define CMD_FLAG_STOP_MASK   BIT(26)
+#define CMD_FLAG_RAISE_IRQ_MASK  BIT(27)
+#define CMD_FLAG_INFO_MASK   0xff
+#define CMD_MAX   0x10
+
+#define CMD_SHIFT 28
+
+#define REG_STATUS0xc
+#define REG_STATUS_DMA_READ_RUNNING BIT(0)
+#define REG_STATUS_DMA_READ_PENDING BIT(1)
+#define REG_STATUS_DMA_WRITE_RUNNINGBIT(2)
+#define REG_STATUS_DMA_WRITE_PENDINGBIT(3)
+#define REG_STATUS_BUSY BIT(4)
+#define REG_STATUS_EXECUTINGBIT(5)
+#define REG_STATUS_READYBIT(6)
+#define REG_STATUS_TEXT_DPA_SEEDED  BIT(7)
+#define REG_STATUS_UNWRAP_DPA_SEEDEDBIT(8)
+
+#define REG_IRQ_STATUS0x18
+#define REG_IRQ_STATUS_INVALID_CMD  BIT(2)
+#define REG_IRQ_STATUS_FLAG BIT(5)
+#define REG_IRQ_ENABLE0x1c
+#define REG_WATERMARK 0x20
+#define REG_Q_STATUS  0x24
+#define REG_FLAG_INFO 0x30
+#define REG_FIFO  0x200
+
+static const uint32_t key_lens[CMD_KEY_KEY_LEN_NUM] = {
+[0] = 16,
+[1] = 24,
+[2] = 32,
+[3] = 64,
+};
+
+typedef struct Key {
+uint32_t key_len;
+uint8_t key[32];
+} Key;
+
+typedef struct IV {
+uint32_t iv[4];
+} IV;
+
+static Key builtin_keys[CMD_KEY_SELECT_MAX_IDX + 1] = {
+[1] = {
+.key_len = 32,
+.key = { 0x1 },
+},
+[2] = {
+.key_len = 32,
+.key = { 0x2 },
+},
+[3] = {
+.key_len = 32,
+.key = { 0x3 },
+}
+};
+
+struct AESState {
+S

[PATCH v5 11/15] hw/vmapple/bdif: Introduce vmapple backdoor interface

[Phil Dennis-Jordan]

From: Alexander Graf 

The VMApple machine exposes AUX and ROOT block devices (as well as USB OTG
emulation) via virtio-pci as well as a special, simple backdoor platform
device.

This patch implements this backdoor platform device to the best of my
understanding. I left out any USB OTG parts; they're only needed for
guest recovery and I don't understand the protocol yet.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
---

v4:

 * Moved most header code to .c, rest to vmapple.h
 * Better compliance with coding, naming, and formatting conventions.

 hw/vmapple/Kconfig   |   3 +
 hw/vmapple/bdif.c| 261 +++
 hw/vmapple/meson.build   |   1 +
 hw/vmapple/trace-events  |   5 +
 include/hw/vmapple/vmapple.h |   2 +
 5 files changed, 272 insertions(+)
 create mode 100644 hw/vmapple/bdif.c

diff --git a/hw/vmapple/Kconfig b/hw/vmapple/Kconfig
index a73504d5999..68f88876eb9 100644
--- a/hw/vmapple/Kconfig
+++ b/hw/vmapple/Kconfig
@@ -1,3 +1,6 @@
 config VMAPPLE_AES
 bool
 
+config VMAPPLE_BDIF
+bool
+
diff --git a/hw/vmapple/bdif.c b/hw/vmapple/bdif.c
new file mode 100644
index 000..7c7a277665a
--- /dev/null
+++ b/hw/vmapple/bdif.c
@@ -0,0 +1,261 @@
+/*
+ * VMApple Backdoor Interface
+ *
+ * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "trace.h"
+#include "hw/vmapple/vmapple.h"
+#include "hw/sysbus.h"
+#include "hw/block/block.h"
+#include "qapi/error.h"
+#include "sysemu/block-backend.h"
+
+OBJECT_DECLARE_SIMPLE_TYPE(VMAppleBdifState, VMAPPLE_BDIF)
+
+struct VMAppleBdifState {
+SysBusDevice parent_obj;
+
+BlockBackend *aux;
+BlockBackend *root;
+MemoryRegion mmio;
+};
+
+#define VMAPPLE_BDIF_SIZE   0x0020
+
+#define REG_DEVID_MASK  0x
+#define DEVID_ROOT  0x
+#define DEVID_AUX   0x0001
+#define DEVID_USB   0x0010
+
+#define REG_STATUS  0x0
+#define REG_STATUS_ACTIVE BIT(0)
+#define REG_CFG 0x4
+#define REG_CFG_ACTIVEBIT(1)
+#define REG_UNK10x8
+#define REG_BUSY0x10
+#define REG_BUSY_READYBIT(0)
+#define REG_UNK20x400
+#define REG_CMD 0x408
+#define REG_NEXT_DEVICE 0x420
+#define REG_UNK30x434
+
+typedef struct VblkSector {
+uint32_t pad;
+uint32_t pad2;
+uint32_t sector;
+uint32_t pad3;
+} VblkSector;
+
+typedef struct VblkReqCmd {
+uint64_t addr;
+uint32_t len;
+uint32_t flags;
+} VblkReqCmd;
+
+typedef struct VblkReq {
+VblkReqCmd sector;
+VblkReqCmd data;
+VblkReqCmd retval;
+} VblkReq;
+
+#define VBLK_DATA_FLAGS_READ  0x00030001
+#define VBLK_DATA_FLAGS_WRITE 0x00010001
+
+#define VBLK_RET_SUCCESS  0
+#define VBLK_RET_FAILED   1
+
+static uint64_t bdif_read(void *opaque, hwaddr offset, unsigned size)
+{
+uint64_t ret = -1;
+uint64_t devid = offset & REG_DEVID_MASK;
+
+switch (offset & ~REG_DEVID_MASK) {
+case REG_STATUS:
+ret = REG_STATUS_ACTIVE;
+break;
+case REG_CFG:
+ret = REG_CFG_ACTIVE;
+break;
+case REG_UNK1:
+ret = 0x420;
+break;
+case REG_BUSY:
+ret = REG_BUSY_READY;
+break;
+case REG_UNK2:
+ret = 0x1;
+break;
+case REG_UNK3:
+ret = 0x0;
+break;
+case REG_NEXT_DEVICE:
+switch (devid) {
+case DEVID_ROOT:
+ret = 0x800;
+break;
+case DEVID_AUX:
+ret = 0x1;
+break;
+}
+break;
+}
+
+trace_bdif_read(offset, size, ret);
+return ret;
+}
+
+static void le2cpu_sector(VblkSector *sector)
+{
+sector->sector = le32_to_cpu(sector->sector);
+}
+
+static void le2cpu_reqcmd(VblkReqCmd *cmd)
+{
+cmd->addr = le64_to_cpu(cmd->addr);
+cmd->len = le32_to_cpu(cmd->len);
+cmd->flags = le32_to_cpu(cmd->flags);
+}
+
+static void le2cpu_req(VblkReq *req)
+{
+le2cpu_reqcmd(&req->sector);
+le2cpu_reqcmd(&req->data);
+le2cpu_reqcmd(&req->retval);
+}
+
+static void vblk_cmd(uint64_t devid, BlockBackend *blk, uint64_t value,
+ uint64_t static_off)
+{
+VblkReq req;
+VblkSector sector;
+uint64_t off = 0;
+char *buf = NULL;
+uint8_t ret = VBLK_RET_FAILED;
+int r;
+
+cpu_physical_memory_read(value, &req, sizeof(req));
+le2cpu_req(&req);
+
+if (req.sector.len != sizeof(sector)) {
+ret = VBLK_RET_FAILED;
+goto out;
+}
+
+/* Read the vblk command */
+cpu_physical_memory_read(req.sector.addr, §or, sizeof(sector));
+le2cpu_sector(§or);
+
+off = sector.secto

[PATCH v5 01/15] ui & main loop: Redesign of system-specific main thread event handling

[Phil Dennis-Jordan]

macOS's Cocoa event handling must be done on the initial (main) thread
of the process. Furthermore, if library or application code uses
libdispatch, the main dispatch queue must be handling events on the main
thread as well.

So far, this has affected Qemu in both the Cocoa and SDL UIs, although
in different ways: the Cocoa UI replaces the default qemu_main function
with one that spins Qemu's internal main event loop off onto a
background thread. SDL (which uses Cocoa internally) on the other hand
uses a polling approach within Qemu's main event loop. Events are
polled during the SDL UI's dpy_refresh callback, which happens to run
on the main thread by default.

As UIs are mutually exclusive, this works OK as long as nothing else
needs platform-native event handling. In the next patch, a new device is
introduced based on the ParavirtualizedGraphics.framework in macOS.
This uses libdispatch internally, and only works when events are being
handled on the main runloop. With the current system, it works when
using either the Cocoa or the SDL UI. However, it does not when running
headless. Moreover, any attempt to install a similar scheme to the
Cocoa UI's main thread replacement fails when combined with the SDL
UI.

This change tidies up main thread management to be more flexible.

 * The qemu_main global function pointer is a custom function for the
   main thread, and it may now be NULL. When it is, the main thread
   runs the main Qemu loop. This represents the traditional setup.
 * When non-null, spawning the main Qemu event loop on a separate
   thread is now done centrally rather than inside the Cocoa UI code.
 * For most platforms, qemu_main is indeed NULL by default, but on
   Darwin, it defaults to a function that runs the CFRunLoop.
 * The Cocoa UI sets qemu_main to a function which runs the
   NSApplication event handling runloop, as is usual for a Cocoa app.
 * The SDL UI overrides the qemu_main function to NULL, thus
   specifying that Qemu's main loop must run on the main
   thread.
 * For other UIs, or in the absence of UIs, the platform's default
   behaviour is followed.

This means that on macOS, the platform's runloop events are always
handled, regardless of chosen UI. The new PV graphics device will
thus work in all configurations. There is no functional change on other
operating systems.

Signed-off-by: Phil Dennis-Jordan 
---

v5:

 * Simplified the way of setting/clearing the main loop by going back
   to setting qemu_main directly, but narrowing the scope of what it
   needs to do, and it can now be NULL.

 include/qemu-main.h |  3 +--
 include/qemu/typedefs.h |  1 +
 system/main.c   | 56 +++
 ui/cocoa.m  | 58 +++--
 ui/sdl2.c   |  4 +++
 5 files changed, 72 insertions(+), 50 deletions(-)

diff --git a/include/qemu-main.h b/include/qemu-main.h
index 940960a7dbc..4bd0d667edc 100644
--- a/include/qemu-main.h
+++ b/include/qemu-main.h
@@ -5,7 +5,6 @@
 #ifndef QEMU_MAIN_H
 #define QEMU_MAIN_H
 
-int qemu_default_main(void);
-extern int (*qemu_main)(void);
+extern qemu_main_fn qemu_main;
 
 #endif /* QEMU_MAIN_H */
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 3d84efcac47..b02cfe1f328 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -131,5 +131,6 @@ typedef struct IRQState *qemu_irq;
  * Function types
  */
 typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
+typedef int (*qemu_main_fn)(void);
 
 #endif /* QEMU_TYPEDEFS_H */
diff --git a/system/main.c b/system/main.c
index 9b91d21ea8c..8c90b8d2ddf 100644
--- a/system/main.c
+++ b/system/main.c
@@ -24,13 +24,14 @@
 
 #include "qemu/osdep.h"
 #include "qemu-main.h"
+#include "qemu/main-loop.h"
 #include "sysemu/sysemu.h"
 
-#ifdef CONFIG_SDL
-#include 
+#ifdef CONFIG_DARWIN
+#include 
 #endif
 
-int qemu_default_main(void)
+static int qemu_default_main(void)
 {
 int status;
 
@@ -40,10 +41,55 @@ int qemu_default_main(void)
 return status;
 }
 
-int (*qemu_main)(void) = qemu_default_main;
+/*
+ * Various macOS system libraries, including the Cocoa UI and anything using
+ * libdispatch, such as ParavirtualizedGraphics.framework, requires that the
+ * main runloop, on the main (initial) thread be running or at least regularly
+ * polled for events. A special mode is therefore supported, where the QEMU
+ * main loop runs on a separate thread and the main thread handles the
+ * CF/Cocoa runloop.
+ */
+
+static void *call_qemu_default_main(void *opaque)
+{
+int status;
+
+bql_lock();
+status = qemu_default_main();
+bql_unlock();
+
+exit(status);
+}
+
+static void qemu_run_default_main_on_new_thread(void)
+{
+QemuThread thread;
+
+qemu_thread_create(&thread, "qemu_main", call_qemu_default_main,
+   NULL, QEMU_THREAD_DETACHED);
+}
+
+
+#ifdef CONFIG_DARWIN
+static int os_darwin_cfrunloop_main(void)
+{
+CFRunLoopRun();
+abort

[PATCH v5 06/15] hw: Add vmapple subdir

[Phil Dennis-Jordan]

From: Alexander Graf 

We will introduce a number of devices that are specific to the vmapple
target machine. To keep them all tidily together, let's put them into
a single target directory.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Akihiko Odaki 
---
 MAINTAINERS | 7 +++
 hw/Kconfig  | 1 +
 hw/meson.build  | 1 +
 hw/vmapple/Kconfig  | 1 +
 hw/vmapple/meson.build  | 0
 hw/vmapple/trace-events | 2 ++
 hw/vmapple/trace.h  | 1 +
 meson.build | 1 +
 8 files changed, 14 insertions(+)
 create mode 100644 hw/vmapple/Kconfig
 create mode 100644 hw/vmapple/meson.build
 create mode 100644 hw/vmapple/trace-events
 create mode 100644 hw/vmapple/trace.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d95b9c9e53d..0437568973a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2734,6 +2734,13 @@ F: hw/hyperv/hv-balloon*.h
 F: include/hw/hyperv/dynmem-proto.h
 F: include/hw/hyperv/hv-balloon.h
 
+VMapple
+M: Alexander Graf 
+R: Phil Dennis-Jordan 
+S: Maintained
+F: hw/vmapple/*
+F: include/hw/vmapple/*
+
 Subsystems
 --
 Overall Audio backends
diff --git a/hw/Kconfig b/hw/Kconfig
index 1b4e9bb07f7..2871784cfdc 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -41,6 +41,7 @@ source ufs/Kconfig
 source usb/Kconfig
 source virtio/Kconfig
 source vfio/Kconfig
+source vmapple/Kconfig
 source xen/Kconfig
 source watchdog/Kconfig
 
diff --git a/hw/meson.build b/hw/meson.build
index b827c82c5d7..9c4f6d0d636 100644
--- a/hw/meson.build
+++ b/hw/meson.build
@@ -39,6 +39,7 @@ subdir('ufs')
 subdir('usb')
 subdir('vfio')
 subdir('virtio')
+subdir('vmapple')
 subdir('watchdog')
 subdir('xen')
 subdir('xenpv')
diff --git a/hw/vmapple/Kconfig b/hw/vmapple/Kconfig
new file mode 100644
index 000..8b137891791
--- /dev/null
+++ b/hw/vmapple/Kconfig
@@ -0,0 +1 @@
+
diff --git a/hw/vmapple/meson.build b/hw/vmapple/meson.build
new file mode 100644
index 000..e69de29bb2d
diff --git a/hw/vmapple/trace-events b/hw/vmapple/trace-events
new file mode 100644
index 000..9ccc5790487
--- /dev/null
+++ b/hw/vmapple/trace-events
@@ -0,0 +1,2 @@
+# See docs/devel/tracing.rst for syntax documentation.
+
diff --git a/hw/vmapple/trace.h b/hw/vmapple/trace.h
new file mode 100644
index 000..572adbefe04
--- /dev/null
+++ b/hw/vmapple/trace.h
@@ -0,0 +1 @@
+#include "trace/trace-hw_vmapple.h"
diff --git a/meson.build b/meson.build
index 5eab46f704f..3b9a0188d4c 100644
--- a/meson.build
+++ b/meson.build
@@ -3492,6 +3492,7 @@ if have_system
 'hw/usb',
 'hw/vfio',
 'hw/virtio',
+'hw/vmapple',
 'hw/watchdog',
 'hw/xen',
 'hw/gpio',
-- 
2.39.3 (Apple Git-145)

[PATCH v5 14/15] hw/block/virtio-blk: Replaces request free function with g_free

[Phil Dennis-Jordan]

The virtio_blk_free_request() function has been a 1-liner forwarding
to g_free() for a while now. We may as well call g_free on the request
pointer directly.

Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Akihiko Odaki 
---
 hw/block/virtio-blk.c  | 43 +++---
 hw/vmapple/virtio-blk.c|  2 +-
 include/hw/virtio/virtio-blk.h |  1 -
 3 files changed, 20 insertions(+), 26 deletions(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9e8337bb639..40d2c9bc591 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -50,11 +50,6 @@ static void virtio_blk_init_request(VirtIOBlock *s, 
VirtQueue *vq,
 req->mr_next = NULL;
 }
 
-void virtio_blk_free_request(VirtIOBlockReq *req)
-{
-g_free(req);
-}
-
 void virtio_blk_req_complete(VirtIOBlockReq *req, unsigned char status)
 {
 VirtIOBlock *s = req->dev;
@@ -93,7 +88,7 @@ static int virtio_blk_handle_rw_error(VirtIOBlockReq *req, 
int error,
 if (acct_failed) {
 block_acct_failed(blk_get_stats(s->blk), &req->acct);
 }
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 blk_error_action(s->blk, action, is_read, error);
@@ -136,7 +131,7 @@ static void virtio_blk_rw_complete(void *opaque, int ret)
 
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 block_acct_done(blk_get_stats(s->blk), &req->acct);
-virtio_blk_free_request(req);
+g_free(req);
 }
 }
 
@@ -151,7 +146,7 @@ static void virtio_blk_flush_complete(void *opaque, int ret)
 
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 block_acct_done(blk_get_stats(s->blk), &req->acct);
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 static void virtio_blk_discard_write_zeroes_complete(void *opaque, int ret)
@@ -169,7 +164,7 @@ static void virtio_blk_discard_write_zeroes_complete(void 
*opaque, int ret)
 if (is_write_zeroes) {
 block_acct_done(blk_get_stats(s->blk), &req->acct);
 }
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock *s, VirtQueue *vq)
@@ -214,7 +209,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
 
 fail:
 virtio_blk_req_complete(req, status);
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 static inline void submit_requests(VirtIOBlock *s, MultiReqBuffer *mrb,
@@ -612,7 +607,7 @@ static void virtio_blk_zone_report_complete(void *opaque, 
int ret)
 
 out:
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 g_free(data->zone_report_data.zones);
 g_free(data);
 }
@@ -661,7 +656,7 @@ static void virtio_blk_handle_zone_report(VirtIOBlockReq 
*req,
 return;
 out:
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 static void virtio_blk_zone_mgmt_complete(void *opaque, int ret)
@@ -677,7 +672,7 @@ static void virtio_blk_zone_mgmt_complete(void *opaque, int 
ret)
 }
 
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 }
 
 static int virtio_blk_handle_zone_mgmt(VirtIOBlockReq *req, BlockZoneOp op)
@@ -719,7 +714,7 @@ static int virtio_blk_handle_zone_mgmt(VirtIOBlockReq *req, 
BlockZoneOp op)
 return 0;
 out:
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 return err_status;
 }
 
@@ -750,7 +745,7 @@ static void virtio_blk_zone_append_complete(void *opaque, 
int ret)
 
 out:
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 g_free(data);
 }
 
@@ -788,7 +783,7 @@ static int virtio_blk_handle_zone_append(VirtIOBlockReq 
*req,
 
 out:
 virtio_blk_req_complete(req, err_status);
-virtio_blk_free_request(req);
+g_free(req);
 return err_status;
 }
 
@@ -855,7 +850,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 virtio_blk_req_complete(req, VIRTIO_BLK_S_IOERR);
 block_acct_invalid(blk_get_stats(s->blk),
is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ);
-virtio_blk_free_request(req);
+g_free(req);
 return 0;
 }
 
@@ -911,7 +906,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
   VIRTIO_BLK_ID_BYTES));
 iov_from_buf(in_iov, in_num, 0, serial, size);
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
-virtio_blk_free_request(req);
+g_free(req);
 break;
 }
 case VIRTIO_BLK_T_ZONE_APPEND & ~VIRTIO_BLK_T_OUT:
@@ -943,7 +938,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 if (unlikely(!(type & VIRTIO_BLK_T_OUT) ||
  out_len > sizeof(dwz_hdr))) {
 virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
-virtio_blk_free_req

Re: [PATCH v1 3/8] hw/timer/aspeed: Fix interrupt status does not be cleared for AST2600

[Andrew Jeffery]

On Tue, 2024-10-29 at 17:17 +0800, Jamin Lin wrote:
> According to the datasheet of AST2600 description, interrupt status
> set by HW
> and clear to "0" by software writing "1" on the specific bit.
> 
> Therefore, if firmware set the specific bit "1" in the interrupt
> status
> register(0x34), the specific bit of "s->irq_sts" should be cleared 0.
> 
> Signed-off-by: Jamin Lin 

Hah, the datasheet table for the register uses `RW` to describe the
bits and not `W1C`, but there's a foot-note in the table that says
they're W1C bits.

Fixes: fadefada4d07 ("aspeed/timer: Add support for IRQ status register on the 
AST2600")
Reviewed-by: Andrew Jeffery 

Thanks,

Andrew

Re: [PATCH v1 5/8] hw/sd/sdhci: Introduce a new Write Protected pin inverted property

[Andrew Jeffery]

On Tue, 2024-10-29 at 17:17 +0800, Jamin Lin wrote:
> The Write Protect pin of SDHCI model is default active low to match
> the SDHCI
> spec. So, write enable the bit 19 should be 1 and write protected the
> bit 19
> should be 0 at the Present State Register (0x24). However, some board
> are
> design Write Protected pin active high. In other words, write enable
> the bit 19
> should be 0 and write protected the bit 19 should be 1 at the
> Present State Register (0x24). To support it, introduces a new
> "wp_invert"
> property and set it false by default.
> 
> Signed-off-by: Jamin Lin 
> ---
>  hw/sd/sdhci.c | 6 ++
>  include/hw/sd/sdhci.h | 5 +
>  2 files changed, 11 insertions(+)
> 
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index db7d547156..bdf5cbfb80 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -275,6 +275,10 @@ static void sdhci_set_readonly(DeviceState *dev,
> bool level)
>  {
>  SDHCIState *s = (SDHCIState *)dev;
>  
> +    if (s->wp_invert) {
> +    level = !level;
> +    }
> +
>  if (level) {
>  s->prnsts &= ~SDHC_WRITE_PROTECT;
>  } else {
> @@ -1551,6 +1555,8 @@ static Property sdhci_sysbus_properties[] = {
>   false),
>  DEFINE_PROP_LINK("dma", SDHCIState,
>   dma_mr, TYPE_MEMORY_REGION, MemoryRegion *),
> +    DEFINE_PROP_BOOL("wp-invert", SDHCIState,

Can we line the name up with the mmc-controller devicetree binding
("wp-inverted")?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-controller.yaml#n71

Andrew

> + wp_invert, false),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/include/hw/sd/sdhci.h b/include/hw/sd/sdhci.h
> index 6cd2822f1d..d68f4788e7 100644
> --- a/include/hw/sd/sdhci.h
> +++ b/include/hw/sd/sdhci.h
> @@ -100,6 +100,11 @@ struct SDHCIState {
>  uint8_t sd_spec_version;
>  uint8_t uhs_mode;
>  uint8_t vendor;    /* For vendor specific functionality */
> +    /*
> + * Write Protect pin default active low for detecting SD card
> + * to be protected. Set wp_invert to true inverted the signal.
> + */
> +    bool wp_invert;
>  };
>  typedef struct SDHCIState SDHCIState;
>  

[PATCH v5 08/15] hvf: arm: Ignore writes to CNTP_CTL_EL0

[Phil Dennis-Jordan]

From: Alexander Graf 

MacOS unconditionally disables interrupts of the physical timer on boot
and then continues to use the virtual one. We don't really want to support
a full physical timer emulation, so let's just ignore those writes.

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Akihiko Odaki 
---
 target/arm/hvf/hvf.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 6cea483d422..b45b764dfd0 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -11,6 +11,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/error-report.h"
+#include "qemu/log.h"
 
 #include "sysemu/runstate.h"
 #include "sysemu/hvf.h"
@@ -184,6 +185,7 @@ void hvf_arm_init_debug(void)
 #define SYSREG_OSLSR_EL1  SYSREG(2, 0, 1, 1, 4)
 #define SYSREG_OSDLR_EL1  SYSREG(2, 0, 1, 3, 4)
 #define SYSREG_CNTPCT_EL0 SYSREG(3, 3, 14, 0, 1)
+#define SYSREG_CNTP_CTL_EL0   SYSREG(3, 3, 14, 2, 1)
 #define SYSREG_PMCR_EL0   SYSREG(3, 3, 9, 12, 0)
 #define SYSREG_PMUSERENR_EL0  SYSREG(3, 3, 9, 14, 0)
 #define SYSREG_PMCNTENSET_EL0 SYSREG(3, 3, 9, 12, 1)
@@ -1620,6 +1622,13 @@ static int hvf_sysreg_write(CPUState *cpu, uint32_t reg, 
uint64_t val)
 case SYSREG_OSLAR_EL1:
 env->cp15.oslsr_el1 = val & 1;
 return 0;
+case SYSREG_CNTP_CTL_EL0:
+/*
+ * Guests should not rely on the physical counter, but macOS emits
+ * disable writes to it. Let it do so, but ignore the requests.
+ */
+qemu_log_mask(LOG_UNIMP, "Unsupported write to CNTP_CTL_EL0\n");
+return 0;
 case SYSREG_OSDLR_EL1:
 /* Dummy register */
 return 0;
-- 
2.39.3 (Apple Git-145)

Re: [PATCH v4 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

[Phil Dennis-Jordan]

On Tue, 29 Oct 2024 at 08:42, Akihiko Odaki 
wrote:

> On 2024/10/29 6:06, Phil Dennis-Jordan wrote:
> >
> >
> > On Mon, 28 Oct 2024 at 17:06, Akihiko Odaki  > > wrote:
> >
> > On 2024/10/28 23:13, Phil Dennis-Jordan wrote:
> >  >
> >  >
> >  > On Mon, 28 Oct 2024 at 15:02, Akihiko Odaki
> > mailto:akihiko.od...@daynix.com>
> >  >  > >> wrote:
> >  >
> >  > On 2024/10/28 22:31, Phil Dennis-Jordan wrote:
> >  >  >
> >  >  >
> >  >  > On Mon, 28 Oct 2024 at 10:00, Phil Dennis-Jordan
> >  > mailto:p...@philjordan.eu>
> > >
> >  >  > 
> >  >  >  >
> >  >  >
> >  >  >  >  >
> >  >  >  >  > Hmm. I think if we were to use that, we
> > would
> >  > need to
> >  >  > create a new
> >  >  >  >  > QemuEvent for every job and destroy it
> > afterward,
> >  >  > which seems
> >  >  >  > expensive.
> >  >  >  >  > We can't rule out multiple concurrent
> > jobs being
> >  >  > submitted, and the
> >  >  >  >  > QemuEvent system only supports a single
> > producer as
> >  >  > far as I can
> >  >  >  > tell.
> >  >  >  >  >
> >  >  >  >  > You can probably sort of hack around it
> with
> >  > just one
> >  >  > QemuEvent by
> >  >  >  >  > putting the qemu_event_wait into a loop
> > and turning
> >  >  > the job.done
> >  >  >  > flag
> >  >  >  >  > into an atomic (because it would now
> > need to be
> >  >  > checked outside the
> >  >  >  >  > lock) but this all seems unnecessarily
> > complicated
> >  >  > considering the
> >  >  >  >  > QemuEvent uses the same mechanism
> QemuCond/
> >  > QemuMutex
> >  >  > internally
> >  >  >  > on macOS
> >  >  >  >  > (the only platform relevant here),
> except we
> >  > can use it as
> >  >  >  > intended with
> >  >  >  >  > QemuCond/QemuMutex rather than having to
> > work
> >  > against the
> >  >  >  > abstraction.
> >  >  >  >
> >  >  >  > I don't think it's going to be used
> > concurrently. It
> >  >  > would be difficult
> >  >  >  > to reason even for the framework if it
> > performs memory
> >  >  >  > unmapping/mapping/reading operations
> > concurrently.
> >  >  >  >
> >  >  >  >
> >  >  >  > I've just performed a very quick test by
> > wrapping the job
> >  >  > submission/
> >  >  >  > wait in the 2 mapMemory callbacks and the 1
> > readMemory
> >  >  > callback with
> >  >  >  > atomic counters and logging whenever a counter
> went
> >  > above 1.
> >  >  >  >
> >  >  >  >   * Overall, concurrent callbacks across all
> > types were
> >  >  > common (many per
> >  >  >  > second when the VM is busy). It's not exactly a
> >  > "thundering
> >  >  > herd" (I
> >  >  >  > never saw >2) but it's probably not a bad idea
> > to use
> >  > a separate
> >  >  >  > condition variable for each job type. (task map,
> >  > surface map,
> >  >  > memory read)
> >  >  >  >   * While I did not observe any concurrent
> > memory mapping
> >  >  > operations
> >  >  >  > *within* a type of memory map (2 task mappings
> or 2
> >  > surface
> >  >  > mappings) I
> >  >  >  > did see very occasional concurrent memory *read*
> >  > callbacks.
> >  >  > These would,
> >  >  >  > as far as I can tell, not be safe with
> QemuEvents,
> >  > unless we
> >  >  > placed the
> >  >  >  > event inside the job struct and init/destroyed
> > it on every
> >  >  > callback
> >  >  >  > (which seems like excessive overhead).
> >  >  >
> >  >  > I think we can tolerate that overhead. init/destroy
> >  > essentially
> >  >

[PATCH v5 05/15] MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF

[Phil Dennis-Jordan]

I'm happy to take responsibility for the macOS PV graphics code. As
HVF patches don't seem to get much attention at the moment, I'm also
adding myself as designated reviewer for HVF and x86 HVF to try and
improve that.

I anticipate that the resulting workload should be covered by the
funding I'm receiving for improving Qemu in combination with macOS. As
of right now this runs out at the end of 2024; I expect the workload on
apple-gfx should be relatively minor and manageable in my spare time
beyond that. I may have to remove myself from more general HVF duties
once the contract runs out if it's more than I can manage.

Signed-off-by: Phil Dennis-Jordan 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f48d9142b8a..d95b9c9e53d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -505,6 +505,7 @@ F: target/arm/hvf/
 X86 HVF CPUs
 M: Cameron Esfahani 
 M: Roman Bolshakov 
+R: Phil Dennis-Jordan 
 W: https://wiki.qemu.org/Features/HVF
 S: Maintained
 F: target/i386/hvf/
@@ -512,6 +513,7 @@ F: target/i386/hvf/
 HVF
 M: Cameron Esfahani 
 M: Roman Bolshakov 
+R: Phil Dennis-Jordan 
 W: https://wiki.qemu.org/Features/HVF
 S: Maintained
 F: accel/hvf/
@@ -2581,6 +2583,11 @@ F: hw/display/edid*
 F: include/hw/display/edid.h
 F: qemu-edid.c
 
+macOS PV Graphics (apple-gfx)
+M: Phil Dennis-Jordan 
+S: Maintained
+F: hw/display/apple-gfx*
+
 PIIX4 South Bridge (i82371AB)
 M: Hervé Poussineau 
 M: Philippe Mathieu-Daudé 
-- 
2.39.3 (Apple Git-145)

[PATCH v5 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

[Phil Dennis-Jordan]

MacOS provides a framework (library) that allows any vmm to implement a
paravirtualized 3d graphics passthrough to the host metal stack called
ParavirtualizedGraphics.Framework (PVG). The library abstracts away
almost every aspect of the paravirtualized device model and only provides
and receives callbacks on MMIO access as well as to share memory address
space between the VM and PVG.

This patch implements a QEMU device that drives PVG for the VMApple
variant of it.

Signed-off-by: Alexander Graf 
Co-authored-by: Alexander Graf 

Subsequent changes:

 * Cherry-pick/rebase conflict fixes, API use updates.
 * Moved from hw/vmapple/ (useful outside that machine type)
 * Overhaul of threading model, many thread safety improvements.
 * Asynchronous rendering.
 * Memory and object lifetime fixes.
 * Refactoring to split generic and (vmapple) MMIO variant specific
   code.

Signed-off-by: Phil Dennis-Jordan 
---
v2:

 * Cherry-pick/rebase conflict fixes
 * BQL function renaming
 * Moved from hw/vmapple/ (useful outside that machine type)
 * Code review comments: Switched to DEFINE_TYPES macro & little endian
   MMIO.
 * Removed some dead/superfluous code
 * Mad set_mode thread & memory safe
 * Added migration blocker due to lack of (de-)serialisation.
 * Fixes to ObjC refcounting and autorelease pool usage.
 * Fixed ObjC new/init misuse
 * Switched to ObjC category extension for private property.
 * Simplified task memory mapping and made it thread safe.
 * Refactoring to split generic and vmapple MMIO variant specific
   code.
 * Switched to asynchronous MMIO writes on x86-64
 * Rendering and graphics update are now done asynchronously
 * Fixed cursor handling
 * Coding convention fixes
 * Removed software cursor compositing

v3:

 * Rebased on latest upstream, fixed breakages including switching to 
Resettable methods.
 * Squashed patches dealing with dGPUs, MMIO area size, and GPU picking.
 * Allow re-entrant MMIO; this simplifies the code and solves the divergence
   between x86-64 and arm64 variants.

v4:

 * Renamed '-vmapple' device variant to '-mmio'
 * MMIO device type now requires aarch64 host and guest
 * Complete overhaul of the glue code for making Qemu's and
   ParavirtualizedGraphics.framework's threading and synchronisation models
   work together. Calls into PVG are from dispatch queues while the
   BQL-holding initiating thread processes AIO context events; callbacks from
   PVG are scheduled as BHs on the BQL/main AIO context, awaiting completion
   where necessary.
 * Guest frame rendering state is covered by the BQL, with only the PVG calls
   outside the lock, and serialised on the named render_queue.
 * Simplified logic for dropping frames in-flight during mode changes, fixed
   bug in pending frames logic.
 * Addressed smaller code review notes such as: function naming, object type
   declarations, type names/declarations/casts, code formatting, #include
   order, over-cautious ObjC retain/release, what goes in init vs realize,
   etc.

v5:

 * Smaller non-functional fixes in response to review comments, such as using
   NULL for the AIO_WAIT_WHILE context argument, type name formatting,
   deleting leftover debug code, logging improvements, state struct field
   order and documentation improvements, etc.
 * Instead of a single condition variable for all synchronous BH job types,
   there is now one for each callback block. This reduces the number
   of threads being awoken unnecessarily to near zero.
 * MMIO device variant: Unified the BH job for raising interrupts.
 * Use DMA APIs for PVG framework's guest memory read requests.
 * Thread safety improvements: ensure mutable AppleGFXState fields are not
   accessed outside the appropriate lock. Added dedicated mutex for the task
   list.
 * Retain references to MemoryRegions for which there exist mappings in each
   PGTask, and for IOSurface mappings.

 hw/display/Kconfig  |   9 +
 hw/display/apple-gfx-mmio.m | 387 ++
 hw/display/apple-gfx.h  |  79 
 hw/display/apple-gfx.m  | 773 
 hw/display/meson.build  |   4 +
 hw/display/trace-events |  28 ++
 meson.build |   4 +
 7 files changed, 1284 insertions(+)
 create mode 100644 hw/display/apple-gfx-mmio.m
 create mode 100644 hw/display/apple-gfx.h
 create mode 100644 hw/display/apple-gfx.m

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index 2250c740078..6a9b7b19ada 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -140,3 +140,12 @@ config XLNX_DISPLAYPORT
 
 config DM163
 bool
+
+config MAC_PVG
+bool
+default y
+
+config MAC_PVG_MMIO
+bool
+depends on MAC_PVG && AARCH64
+
diff --git a/hw/display/apple-gfx-mmio.m b/hw/display/apple-gfx-mmio.m
new file mode 100644
index 000..b0c5669a344
--- /dev/null
+++ b/hw/display/apple-gfx-mmio.m
@@ -0,0 +1,387 @@
+/*
+ * QEMU Apple ParavirtualizedGraphics.framework device, MMIO (arm64) variant
+ *
+ * Copyright © 2023

[PATCH v5 15/15] hw/vmapple/vmapple: Add vmapple machine type

[Phil Dennis-Jordan]

From: Alexander Graf 

Apple defines a new "vmapple" machine type as part of its proprietary
macOS Virtualization.Framework vmm. This machine type is similar to the
virt one, but with subtle differences in base devices, a few special
vmapple device additions and a vastly different boot chain.

This patch reimplements this machine type in QEMU. To use it, you
have to have a readily installed version of macOS for VMApple,
run on macOS with -accel hvf, pass the Virtualization.Framework
boot rom (AVPBooter) in via -bios, pass the aux and root volume as pflash
and pass aux and root volume as virtio drives. In addition, you also
need to find the machine UUID and pass that as -M vmapple,uuid= parameter:

$ qemu-system-aarch64 -accel hvf -M vmapple,uuid=0x1234 -m 4G \
-bios 
/System/Library/Frameworks/Virtualization.framework/Versions/A/Resources/AVPBooter.vmapple2.bin
-drive file=aux,if=pflash,format=raw \
-drive file=root,if=pflash,format=raw \
-drive file=aux,if=none,id=aux,format=raw \
-device vmapple-virtio-aux,drive=aux \
-drive file=root,if=none,id=root,format=raw \
-device vmapple-virtio-root,drive=root

With all these in place, you should be able to see macOS booting
successfully.

Known issues:
 - Keyboard and mouse/tablet input is laggy. The reason for this is
   either that macOS's XHCI driver is broken when the device/platform
   does not support MSI/MSI-X, or there's some unfortunate interplay
   with Qemu's XHCI implementation in this scenario.
 - Currently only macOS 12 guests are supported. The boot process for
   13+ will need further investigation and adjustment.

Signed-off-by: Alexander Graf 
Co-authored-by: Phil Dennis-Jordan 
Signed-off-by: Phil Dennis-Jordan 
---

v3:
 * Rebased on latest upstream, updated affinity and NIC creation
API usage
 * Included Apple-variant virtio-blk in build dependency
 * Updated API usage for setting 'redist-region-count' array-typed property on 
GIC.
 * Switched from virtio HID devices (for which macOS 12 does not contain 
drivers) to an XHCI USB controller and USB HID devices.

v4:
 * Fixups for v4 changes to the other patches in the set.
 * Corrected the assert macro to use
 * Removed superfluous endian conversions corresponding to cfg's.
 * Init error handling improvement.
 * No need to select CPU type on TCG, as only HVF is supported.
 * Machine type version bumped to 9.2
 * #include order improved

v5:
 * Fixed memory reservation for ecam alias region.
 * Better error handling setting properties on devices.
 * Simplified the machine ECID/UUID extraction script and actually created a
   file for it rather than quoting its code in documentation.

 MAINTAINERS |   1 +
 contrib/vmapple/uuid.sh |   9 +
 docs/system/arm/vmapple.rst |  60 
 docs/system/target-arm.rst  |   1 +
 hw/vmapple/Kconfig  |  20 ++
 hw/vmapple/meson.build  |   1 +
 hw/vmapple/vmapple.c| 659 
 7 files changed, 751 insertions(+)
 create mode 100755 contrib/vmapple/uuid.sh
 create mode 100644 docs/system/arm/vmapple.rst
 create mode 100644 hw/vmapple/vmapple.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0437568973a..c46d186bb05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2740,6 +2740,7 @@ R: Phil Dennis-Jordan 
 S: Maintained
 F: hw/vmapple/*
 F: include/hw/vmapple/*
+F: docs/system/arm/vmapple.rst
 
 Subsystems
 --
diff --git a/contrib/vmapple/uuid.sh b/contrib/vmapple/uuid.sh
new file mode 100755
index 000..956e8c3afed
--- /dev/null
+++ b/contrib/vmapple/uuid.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+# Used for converting a guest provisioned using Virtualization.framework
+# for use with the QEMU 'vmapple' aarch64 machine type.
+#
+# Extracts the Machine UUID from Virtualization.framework VM JSON file.
+# (as produced by 'macosvm', passed as command line argument)
+
+plutil -extract machineId raw "$1" | base64 -d | plutil -extract ECID raw -
+
diff --git a/docs/system/arm/vmapple.rst b/docs/system/arm/vmapple.rst
new file mode 100644
index 000..6a634fa4572
--- /dev/null
+++ b/docs/system/arm/vmapple.rst
@@ -0,0 +1,60 @@
+VMApple machine emulation
+
+
+VMApple is the device model that the macOS built-in hypervisor called 
"Virtualization.framework"
+exposes to Apple Silicon macOS guests. The "vmapple" machine model in QEMU 
implements the same
+device model, but does not use any code from Virtualization.Framework.
+
+Prerequisites
+-
+
+To run the vmapple machine model, you need to
+
+ * Run on Apple Silicon
+ * Run on macOS 12.0 or above
+ * Have an already installed copy of a Virtualization.Framework macOS 12 
virtual machine. I will
+   assume that you installed it using the macosvm CLI.
+
+First, we need to extract the UUID from the virtual machine that you 
installed. You can do this
+by running the shell script in contrib/vmapple/uuid.sh on the macosvm.json 
file

RE: [PATCH v1 5/8] hw/sd/sdhci: Introduce a new Write Protected pin inverted property

[Jamin Lin]

Hi Andrew, 

> Subject: Re: [PATCH v1 5/8] hw/sd/sdhci: Introduce a new Write Protected pin
> inverted property
> 
> On Tue, 2024-10-29 at 17:17 +0800, Jamin Lin wrote:
> > The Write Protect pin of SDHCI model is default active low to match
> > the SDHCI spec. So, write enable the bit 19 should be 1 and write
> > protected the bit 19 should be 0 at the Present State Register (0x24).
> > However, some board are design Write Protected pin active high. In
> > other words, write enable the bit 19 should be 0 and write protected
> > the bit 19 should be 1 at the Present State Register (0x24). To
> > support it, introduces a new "wp_invert"
> > property and set it false by default.
> >
> > Signed-off-by: Jamin Lin 
> > ---
> >  hw/sd/sdhci.c | 6 ++
> >  include/hw/sd/sdhci.h | 5 +
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c index
> > db7d547156..bdf5cbfb80 100644
> > --- a/hw/sd/sdhci.c
> > +++ b/hw/sd/sdhci.c
> > @@ -275,6 +275,10 @@ static void sdhci_set_readonly(DeviceState *dev,
> > bool level)
> >  {
> >  SDHCIState *s = (SDHCIState *)dev;
> >
> > +    if (s->wp_invert) {
> > +    level = !level;
> > +    }
> > +
> >  if (level) {
> >  s->prnsts &= ~SDHC_WRITE_PROTECT;
> >  } else {
> > @@ -1551,6 +1555,8 @@ static Property sdhci_sysbus_properties[] = {
> >   false),
> >  DEFINE_PROP_LINK("dma", SDHCIState,
> >   dma_mr, TYPE_MEMORY_REGION,
> MemoryRegion *),
> > +    DEFINE_PROP_BOOL("wp-invert", SDHCIState,
> 
> Can we line the name up with the mmc-controller devicetree binding
> ("wp-inverted")?
> 
Thanks for suggestion and review.
Will update it.

Jamin
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docume
> ntation/devicetree/bindings/mmc/mmc-controller.yaml#n71
> 
> Andrew
> 
> > + wp_invert, false),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >
> > diff --git a/include/hw/sd/sdhci.h b/include/hw/sd/sdhci.h index
> > 6cd2822f1d..d68f4788e7 100644
> > --- a/include/hw/sd/sdhci.h
> > +++ b/include/hw/sd/sdhci.h
> > @@ -100,6 +100,11 @@ struct SDHCIState {
> >  uint8_t sd_spec_version;
> >  uint8_t uhs_mode;
> >  uint8_t vendor;    /* For vendor specific functionality */
> > +    /*
> > + * Write Protect pin default active low for detecting SD card
> > + * to be protected. Set wp_invert to true inverted the signal.
> > + */
> > +    bool wp_invert;
> >  };
> >  typedef struct SDHCIState SDHCIState;
> >

Re: [PATCH v1 7/8] hw/arm/aspeed: Invert sdhci write protected pin for AST2600 and AST2500 EVBs

[Andrew Jeffery]

On Tue, 2024-10-29 at 17:17 +0800, Jamin Lin wrote:
> The Write Protect pin of SDHCI model is default active low to match
> the SDHCI
> spec. So, write enable the bit 19 should be 1 and write protected the
> bit 19
> should be 0 at the Present State Register (0x24).
> 
> According to the design of AST2500 and AST2600 EVBs, the Write
> Protected pin
> is active high by default. To support it, introduces a new
> sdhci_wp_invert
> property in ASPEED MACHINE state and set it true for AST2500 and
> AST2600 EVBs
> and set "wp_invert" property true of sdhci-generic model.
> 
> Signed-off-by: Jamin Lin 
> ---
>  hw/arm/aspeed.c | 8 
>  include/hw/arm/aspeed.h | 1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index b4b1ce9efb..0468602d95 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -403,6 +403,12 @@ static void aspeed_machine_init(MachineState
> *machine)
>   OBJECT(get_system_memory()),
> &error_abort);
>  object_property_set_link(OBJECT(bmc->soc), "dram",
>   OBJECT(machine->ram), &error_abort);
> +    if (amc->sdhci_wp_invert) {
> +    for (i = 0; i < bmc->soc->sdhci.num_slots; i++) {
> +    object_property_set_bool(OBJECT(&bmc->soc-
> >sdhci.slots[i]),
> + "wp-invert", true,
> &error_abort);
> +    }
> +    }
>  if (machine->kernel_filename) {
>  /*
>   * When booting with a -kernel command line there is no u-
> boot
> @@ -1308,6 +1314,7 @@ static void
> aspeed_machine_ast2500_evb_class_init(ObjectClass *oc, void *data)
>  amc->fmc_model = "mx25l25635e";
>  amc->spi_model = "mx25l25635f";
>  amc->num_cs    = 1;
> +    amc->sdhci_wp_invert = true;
>  amc->i2c_init  = ast2500_evb_i2c_init;
>  mc->default_ram_size   = 512 * MiB;
>  aspeed_machine_class_init_cpus_defaults(mc);
> @@ -1409,6 +1416,7 @@ static void
> aspeed_machine_ast2600_evb_class_init(ObjectClass *oc, void *data)
>  amc->num_cs    = 1;
>  amc->macs_mask = ASPEED_MAC0_ON | ASPEED_MAC1_ON |
> ASPEED_MAC2_ON |
>   ASPEED_MAC3_ON;
> +    amc->sdhci_wp_invert = true;
>  amc->i2c_init  = ast2600_evb_i2c_init;
>  mc->default_ram_size = 1 * GiB;
>  aspeed_machine_class_init_cpus_defaults(mc);
> diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h
> index cbeacb214c..879bdb96ee 100644
> --- a/include/hw/arm/aspeed.h
> +++ b/include/hw/arm/aspeed.h
> @@ -39,6 +39,7 @@ struct AspeedMachineClass {
>  uint32_t macs_mask;
>  void (*i2c_init)(AspeedMachineState *bmc);
>  uint32_t uart_default;
> +    bool sdhci_wp_invert;

Other than also calling this `sdhci_wp_inverted` to match my comment on
the earlier patch about the model property and devicetree bindings,

Reviewed-by: Andrew Jeffery 

Re: [PATCH v3 00/14] macOS PV Graphics and new vmapple machine type

[Phil Dennis-Jordan]

On Thu, 3 Oct 2024 at 10:06, Alex Bennée  wrote:

>
> > There are currently a few limitations to this which aren't intrinsic,
> > just imperfect emulation of the VZF, but it's good enough to be just
> > about usable for some purposes:
> >
> >  * macOS 12 guests only. Versions 13+ currently fail during early boot.
> >  * macOS 11+ arm64 hosts only, with hvf accel. (Perhaps some differences
> >between Apple M series CPUs and TCG's aarch64 implementation? macOS
> >hosts only because ParavirtualizedGraphics.framework is a black box
> >implementing most of the logic behind the apple-gfx device.)
>
> We don't currently have TCG CPU models for the Apple Silicon processors.
> They are not too hard to add (basically setting the correct ID register
> bits, c.f. aarch64_neoverse_n1_initfn for an example). However that
> would only cover Aarch64 architectural features. We do no modelling of
> the extra instructions that Apple added (although in theory that should
> only be run in Apples own ML libraries).
>

This really isn't my area of expertise, and I don't see myself attempting
to make it work with TCG. Given that the OS only boots with the PV graphics
device, you can only really use this machine type on a macOS host, so there
aren't many reasons to use TCG over HVF. I suppose it might make debugging
the myriad other rough edges easier!

[PATCH v5 04/15] hw/display/apple-gfx: Adds configurable mode list

[Phil Dennis-Jordan]

This change adds a property 'display_modes' on the graphics device
which permits specifying a list of display modes. (screen resolution
and refresh rate)

The property is an array of a custom type to make the syntax slightly
less awkward to use, for example:

-device '{"driver":"apple-gfx-pci", "display-modes":["1920x1080@60", 
"3840x2160@60"]}'

Signed-off-by: Phil Dennis-Jordan 
---

v4:

 * Switched to the native array property type, which recently gained
 command line support.
 * The property has also been added to the -mmio variant.
 * Tidied up the code a little.

v5:

 * Better error handling and buffer management in property parsing and
   output.

 hw/display/apple-gfx-mmio.m |   8 +++
 hw/display/apple-gfx-pci.m  |   9 ++-
 hw/display/apple-gfx.h  |  12 
 hw/display/apple-gfx.m  | 121 
 hw/display/trace-events |   2 +
 5 files changed, 139 insertions(+), 13 deletions(-)

diff --git a/hw/display/apple-gfx-mmio.m b/hw/display/apple-gfx-mmio.m
index b0c5669a344..a801c5fa722 100644
--- a/hw/display/apple-gfx-mmio.m
+++ b/hw/display/apple-gfx-mmio.m
@@ -364,6 +364,12 @@ static void apple_gfx_mmio_reset(Object *obj, ResetType 
type)
 [s->common.pgdev reset];
 }
 
+static Property apple_gfx_mmio_properties[] = {
+DEFINE_PROP_ARRAY("display-modes", AppleGFXMMIOState,
+  common.num_display_modes, common.display_modes,
+  qdev_prop_display_mode, AppleGFXDisplayMode),
+DEFINE_PROP_END_OF_LIST(),
+};
 
 static void apple_gfx_mmio_class_init(ObjectClass *klass, void *data)
 {
@@ -373,6 +379,8 @@ static void apple_gfx_mmio_class_init(ObjectClass *klass, 
void *data)
 rc->phases.hold = apple_gfx_mmio_reset;
 dc->hotpluggable = false;
 dc->realize = apple_gfx_mmio_realize;
+
+device_class_set_props(dc, apple_gfx_mmio_properties);
 }
 
 static TypeInfo apple_gfx_mmio_types[] = {
diff --git a/hw/display/apple-gfx-pci.m b/hw/display/apple-gfx-pci.m
index 870d0c41e66..e2fa2567c99 100644
--- a/hw/display/apple-gfx-pci.m
+++ b/hw/display/apple-gfx-pci.m
@@ -113,6 +113,13 @@ static void apple_gfx_pci_reset(Object *obj, ResetType 
type)
 [s->common.pgdev reset];
 }
 
+static Property apple_gfx_pci_properties[] = {
+DEFINE_PROP_ARRAY("display-modes", AppleGFXPCIState,
+  common.num_display_modes, common.display_modes,
+  qdev_prop_display_mode, AppleGFXDisplayMode),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void apple_gfx_pci_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -129,7 +136,7 @@ static void apple_gfx_pci_class_init(ObjectClass *klass, 
void *data)
 pci->class_id = PCI_CLASS_DISPLAY_OTHER;
 pci->realize = apple_gfx_pci_realize;
 
-// TODO: Property for setting mode list
+device_class_set_props(dc, apple_gfx_pci_properties);
 }
 
 static TypeInfo apple_gfx_pci_types[] = {
diff --git a/hw/display/apple-gfx.h b/hw/display/apple-gfx.h
index ef34e8160c8..e9fef09e37e 100644
--- a/hw/display/apple-gfx.h
+++ b/hw/display/apple-gfx.h
@@ -16,6 +16,7 @@
 #import 
 #include "qemu/typedefs.h"
 #include "exec/memory.h"
+#include "hw/qdev-properties.h"
 #include "ui/surface.h"
 
 @class PGDeviceDescriptor;
@@ -27,6 +28,7 @@
 
 typedef QTAILQ_HEAD(, PGTask_s) PGTaskList;
 
+struct AppleGFXDisplayMode;
 typedef struct AppleGFXState {
 /* Initialised on init/realize() */
 MemoryRegion iomem_gfx;
@@ -36,6 +38,8 @@ typedef struct AppleGFXState {
 id mtl;
 id mtl_queue;
 dispatch_queue_t render_queue;
+struct AppleGFXDisplayMode *display_modes;
+uint32_t num_display_modes;
 /*
  * QemuMutex & QemuConds for awaiting completion of PVG memory-mapping and
  * reading requests after submitting them to run in the AIO context.
@@ -66,6 +70,12 @@ typedef struct AppleGFXState {
 id texture;
 } AppleGFXState;
 
+typedef struct AppleGFXDisplayMode {
+uint16_t width_px;
+uint16_t height_px;
+uint16_t refresh_rate_hz;
+} AppleGFXDisplayMode;
+
 void apple_gfx_common_init(Object *obj, AppleGFXState *s, const char* 
obj_name);
 void apple_gfx_common_realize(AppleGFXState *s, PGDeviceDescriptor *desc,
   Error **errp);
@@ -75,5 +85,7 @@ uintptr_t apple_gfx_host_address_for_gpa_range(uint64_t 
guest_physical,
 void apple_gfx_await_bh_job(AppleGFXState *s, QemuCond *job_cond,
 bool *job_done_flag);
 
+extern const PropertyInfo qdev_prop_display_mode;
+
 #endif
 
diff --git a/hw/display/apple-gfx.m b/hw/display/apple-gfx.m
index 101b38e8a6e..2e264e5561f 100644
--- a/hw/display/apple-gfx.m
+++ b/hw/display/apple-gfx.m
@@ -31,9 +31,10 @@
 #include "sysemu/dma.h"
 #include "ui/console.h"
 
-static const PGDisplayCoord_t apple_gfx_modes[] = {
-{ .x = 1440, .y = 1080 },
-{ .x = 1280, .y = 1024 },
+static const AppleGFXDisplayMode apple_gfx_default_modes[] = {
+{ 1920, 1080, 60 },
+{ 1440, 1080

[PATCH v5 07/15] hw/misc/pvpanic: Add MMIO interface

[Phil Dennis-Jordan]

From: Alexander Graf 

In addition to the ISA and PCI variants of pvpanic, let's add an MMIO
platform device that we can use in embedded arm environments.

Signed-off-by: Alexander Graf 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Akihiko Odaki 
---

v3:
 * Rebased on upstream, updated a header path

 hw/misc/Kconfig   |  4 +++
 hw/misc/meson.build   |  1 +
 hw/misc/pvpanic-mmio.c| 61 +++
 include/hw/misc/pvpanic.h |  1 +
 4 files changed, 67 insertions(+)
 create mode 100644 hw/misc/pvpanic-mmio.c

diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 1f1baa5dde9..5a6c1603b60 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -145,6 +145,10 @@ config PVPANIC_ISA
 depends on ISA_BUS
 select PVPANIC_COMMON
 
+config PVPANIC_MMIO
+bool
+select PVPANIC_COMMON
+
 config AUX
 bool
 select I2C
diff --git a/hw/misc/meson.build b/hw/misc/meson.build
index d02d96e403b..4de4db0a600 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -122,6 +122,7 @@ system_ss.add(when: 'CONFIG_ARMSSE_MHU', if_true: 
files('armsse-mhu.c'))
 
 system_ss.add(when: 'CONFIG_PVPANIC_ISA', if_true: files('pvpanic-isa.c'))
 system_ss.add(when: 'CONFIG_PVPANIC_PCI', if_true: files('pvpanic-pci.c'))
+system_ss.add(when: 'CONFIG_PVPANIC_MMIO', if_true: files('pvpanic-mmio.c'))
 system_ss.add(when: 'CONFIG_AUX', if_true: files('auxbus.c'))
 system_ss.add(when: 'CONFIG_ASPEED_SOC', if_true: files(
   'aspeed_hace.c',
diff --git a/hw/misc/pvpanic-mmio.c b/hw/misc/pvpanic-mmio.c
new file mode 100644
index 000..56738efee53
--- /dev/null
+++ b/hw/misc/pvpanic-mmio.c
@@ -0,0 +1,61 @@
+/*
+ * QEMU simulated pvpanic device (MMIO frontend)
+ *
+ * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+
+#include "hw/qdev-properties.h"
+#include "hw/misc/pvpanic.h"
+#include "hw/sysbus.h"
+#include "standard-headers/misc/pvpanic.h"
+
+OBJECT_DECLARE_SIMPLE_TYPE(PVPanicMMIOState, PVPANIC_MMIO_DEVICE)
+
+#define PVPANIC_MMIO_SIZE 0x2
+
+struct PVPanicMMIOState {
+SysBusDevice parent_obj;
+
+PVPanicState pvpanic;
+};
+
+static void pvpanic_mmio_initfn(Object *obj)
+{
+PVPanicMMIOState *s = PVPANIC_MMIO_DEVICE(obj);
+
+pvpanic_setup_io(&s->pvpanic, DEVICE(s), PVPANIC_MMIO_SIZE);
+sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->pvpanic.mr);
+}
+
+static Property pvpanic_mmio_properties[] = {
+DEFINE_PROP_UINT8("events", PVPanicMMIOState, pvpanic.events,
+  PVPANIC_PANICKED | PVPANIC_CRASH_LOADED),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pvpanic_mmio_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+device_class_set_props(dc, pvpanic_mmio_properties);
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static const TypeInfo pvpanic_mmio_info = {
+.name  = TYPE_PVPANIC_MMIO_DEVICE,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(PVPanicMMIOState),
+.instance_init = pvpanic_mmio_initfn,
+.class_init= pvpanic_mmio_class_init,
+};
+
+static void pvpanic_register_types(void)
+{
+type_register_static(&pvpanic_mmio_info);
+}
+
+type_init(pvpanic_register_types)
diff --git a/include/hw/misc/pvpanic.h b/include/hw/misc/pvpanic.h
index 9a71a5ad0d7..049a94c1125 100644
--- a/include/hw/misc/pvpanic.h
+++ b/include/hw/misc/pvpanic.h
@@ -26,6 +26,7 @@
 
 #define TYPE_PVPANIC_ISA_DEVICE "pvpanic"
 #define TYPE_PVPANIC_PCI_DEVICE "pvpanic-pci"
+#define TYPE_PVPANIC_MMIO_DEVICE "pvpanic-mmio"
 
 #define PVPANIC_IOPORT_PROP "ioport"
 
-- 
2.39.3 (Apple Git-145)

[PATCH v5 13/15] hw/vmapple/virtio-blk: Add support for apple virtio-blk

[Phil Dennis-Jordan]

From: Alexander Graf 

Apple has its own virtio-blk PCI device ID where it deviates from the
official virtio-pci spec slightly: It puts a new "apple type"
field at a static offset in config space and introduces a new barrier
command.

This patch first creates a mechanism for virtio-blk downstream classes to
handle unknown commands. It then creates such a downstream class and a new
vmapple-virtio-blk-pci class which support the additional apple type config
identifier as well as the barrier command.

It then exposes 2 subclasses from that that we can use to expose root and
aux virtio-blk devices: "vmapple-virtio-root" and "vmapple-virtio-aux".

Signed-off-by: Alexander Graf 
Signed-off-by: Phil Dennis-Jordan 
---

v4:

 * Use recommended object type declaration pattern.
 * Correctly log unimplemented code paths.
 * Most header code moved to .c, type name #defines moved to vmapple.h

v5:

 * Corrected handling of potentially unaligned writes to virtio config area.
 * Simplified passing through device variant type to subobject.

 hw/block/virtio-blk.c  |  19 ++-
 hw/vmapple/Kconfig |   3 +
 hw/vmapple/meson.build |   1 +
 hw/vmapple/virtio-blk.c| 226 +
 include/hw/pci/pci_ids.h   |   1 +
 include/hw/virtio/virtio-blk.h |  12 +-
 include/hw/vmapple/vmapple.h   |   4 +
 7 files changed, 261 insertions(+), 5 deletions(-)
 create mode 100644 hw/vmapple/virtio-blk.c

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9166d7974d4..9e8337bb639 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -50,12 +50,12 @@ static void virtio_blk_init_request(VirtIOBlock *s, 
VirtQueue *vq,
 req->mr_next = NULL;
 }
 
-static void virtio_blk_free_request(VirtIOBlockReq *req)
+void virtio_blk_free_request(VirtIOBlockReq *req)
 {
 g_free(req);
 }
 
-static void virtio_blk_req_complete(VirtIOBlockReq *req, unsigned char status)
+void virtio_blk_req_complete(VirtIOBlockReq *req, unsigned char status)
 {
 VirtIOBlock *s = req->dev;
 VirtIODevice *vdev = VIRTIO_DEVICE(s);
@@ -966,8 +966,18 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 break;
 }
 default:
-virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
-virtio_blk_free_request(req);
+{
+/*
+ * Give subclasses a chance to handle unknown requests. This way the
+ * class lookup is not in the hot path.
+ */
+VirtIOBlkClass *vbk = VIRTIO_BLK_GET_CLASS(s);
+if (!vbk->handle_unknown_request ||
+!vbk->handle_unknown_request(req, mrb, type)) {
+virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
+virtio_blk_free_request(req);
+}
+}
 }
 return 0;
 }
@@ -2044,6 +2054,7 @@ static const TypeInfo virtio_blk_info = {
 .instance_size = sizeof(VirtIOBlock),
 .instance_init = virtio_blk_instance_init,
 .class_init = virtio_blk_class_init,
+.class_size = sizeof(VirtIOBlkClass),
 };
 
 static void virtio_register_types(void)
diff --git a/hw/vmapple/Kconfig b/hw/vmapple/Kconfig
index 8bbeb9a9237..bcd1be63e3c 100644
--- a/hw/vmapple/Kconfig
+++ b/hw/vmapple/Kconfig
@@ -7,3 +7,6 @@ config VMAPPLE_BDIF
 config VMAPPLE_CFG
 bool
 
+config VMAPPLE_VIRTIO_BLK
+bool
+
diff --git a/hw/vmapple/meson.build b/hw/vmapple/meson.build
index 64b78693a31..bf17cf906c9 100644
--- a/hw/vmapple/meson.build
+++ b/hw/vmapple/meson.build
@@ -1,3 +1,4 @@
 system_ss.add(when: 'CONFIG_VMAPPLE_AES',  if_true: files('aes.c'))
 system_ss.add(when: 'CONFIG_VMAPPLE_BDIF', if_true: files('bdif.c'))
 system_ss.add(when: 'CONFIG_VMAPPLE_CFG',  if_true: files('cfg.c'))
+system_ss.add(when: 'CONFIG_VMAPPLE_VIRTIO_BLK',  if_true: 
files('virtio-blk.c'))
diff --git a/hw/vmapple/virtio-blk.c b/hw/vmapple/virtio-blk.c
new file mode 100644
index 000..1652151ec9c
--- /dev/null
+++ b/hw/vmapple/virtio-blk.c
@@ -0,0 +1,226 @@
+/*
+ * VMApple specific VirtIO Block implementation
+ *
+ * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * VMApple uses almost standard VirtIO Block, but with a few key differences:
+ *
+ *  - Different PCI device/vendor ID
+ *  - An additional "type" identifier to differentiate AUX and Root volumes
+ *  - An additional BARRIER command
+ */
+
+#include "qemu/osdep.h"
+#include "hw/vmapple/vmapple.h"
+#include "hw/virtio/virtio-blk.h"
+#include "hw/virtio/virtio-pci.h"
+#include "qemu/bswap.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+
+OBJECT_DECLARE_TYPE(VMAppleVirtIOBlk, VMAppleVirtIOBlkClass, 
VMAPPLE_VIRTIO_BLK)
+
+typedef struct VMAppleVirtIOBlkClass {
+VirtIOBlkClass parent;
+
+void (*get_config)(VirtIODevice *vdev, uint8_t *config);
+} VMApple

RE: [PATCH v1 7/8] hw/arm/aspeed: Invert sdhci write protected pin for AST2600 and AST2500 EVBs

[Jamin Lin]

Hi Andrew,

> Subject: Re: [PATCH v1 7/8] hw/arm/aspeed: Invert sdhci write protected pin
> for AST2600 and AST2500 EVBs
> 
> On Tue, 2024-10-29 at 17:17 +0800, Jamin Lin wrote:
> > The Write Protect pin of SDHCI model is default active low to match
> > the SDHCI spec. So, write enable the bit 19 should be 1 and write
> > protected the bit 19 should be 0 at the Present State Register (0x24).
> >
> > According to the design of AST2500 and AST2600 EVBs, the Write
> > Protected pin is active high by default. To support it, introduces a
> > new sdhci_wp_invert property in ASPEED MACHINE state and set it true
> > for AST2500 and
> > AST2600 EVBs
> > and set "wp_invert" property true of sdhci-generic model.
> >
> > Signed-off-by: Jamin Lin 
> > ---
> >  hw/arm/aspeed.c | 8 
> >  include/hw/arm/aspeed.h | 1 +
> >  2 files changed, 9 insertions(+)
> >
> > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index
> > b4b1ce9efb..0468602d95 100644
> > --- a/hw/arm/aspeed.c
> > +++ b/hw/arm/aspeed.c
> > @@ -403,6 +403,12 @@ static void aspeed_machine_init(MachineState
> > *machine)
> >   OBJECT(get_system_memory(
> )),
> > &error_abort);
> >  object_property_set_link(OBJECT(bmc->soc), "dram",
> >   OBJECT(machine->ram),
> &error_abort);
> > +    if (amc->sdhci_wp_invert) {
> > +    for (i = 0; i < bmc->soc->sdhci.num_slots; i++) {
> > +    object_property_set_bool(OBJECT(&bmc->soc-
> > >sdhci.slots[i]),
> > + "wp-invert", true,
> > &error_abort);
> > +    }
> > +    }
> >  if (machine->kernel_filename) {
> >  /*
> >   * When booting with a -kernel command line there is no u-
> > boot @@ -1308,6 +1314,7 @@ static void
> > aspeed_machine_ast2500_evb_class_init(ObjectClass *oc, void *data)
> >  amc->fmc_model = "mx25l25635e";
> >  amc->spi_model = "mx25l25635f";
> >  amc->num_cs    = 1;
> > +    amc->sdhci_wp_invert = true;
> >  amc->i2c_init  = ast2500_evb_i2c_init;
> >  mc->default_ram_size   = 512 * MiB;
> >  aspeed_machine_class_init_cpus_defaults(mc);
> > @@ -1409,6 +1416,7 @@ static void
> > aspeed_machine_ast2600_evb_class_init(ObjectClass *oc, void *data)
> >  amc->num_cs    = 1;
> >  amc->macs_mask = ASPEED_MAC0_ON | ASPEED_MAC1_ON |
> ASPEED_MAC2_ON
> > |
> >   ASPEED_MAC3_ON;
> > +    amc->sdhci_wp_invert = true;
> >  amc->i2c_init  = ast2600_evb_i2c_init;
> >  mc->default_ram_size = 1 * GiB;
> >  aspeed_machine_class_init_cpus_defaults(mc);
> > diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h index
> > cbeacb214c..879bdb96ee 100644
> > --- a/include/hw/arm/aspeed.h
> > +++ b/include/hw/arm/aspeed.h
> > @@ -39,6 +39,7 @@ struct AspeedMachineClass {
> >  uint32_t macs_mask;
> >  void (*i2c_init)(AspeedMachineState *bmc);
> >  uint32_t uart_default;
> > +    bool sdhci_wp_invert;
> 
> Other than also calling this `sdhci_wp_inverted` to match my comment on the
> earlier patch about the model property and devicetree bindings,
> 
Thanks for review and suggestion.
Will update it to "sdhci_wp_inverted"

Jamin
> Reviewed-by: Andrew Jeffery 

Re: [PATCH 0/2] arm: Add collie and sx functional tests

[Guenter Roeck]

On 10/28/24 01:41, Jan Lübbe wrote:

On Sun, 2024-10-27 at 20:32 -0700, Guenter Roeck wrote:

On 10/27/24 15:26, Cédric Le Goater wrote:

On 10/27/24 23:11, Guenter Roeck wrote:

On 10/27/24 14:13, Cédric Le Goater wrote:

On 10/26/24 17:32, Guenter Roeck wrote:

On 10/26/24 03:02, Cédric Le Goater wrote:
[ ... ]




Works for me, though, and it is much better than mandating the existence
of boot partitions.


Yes. However, if the emmc device was user creatable, we could use :

    -blockdev node-name=emmc0,driver=file,filename=mmc-ast2600-evb-noboot.raw \
    -device emmc,bus=sdhci-bus.2,drive=emmc0

and with boot partitions:

    -M boot-emmc=true \
    -blockdev node-name=emmc0,driver=file,filename=mmc-ast2600-evb.raw \
    -device 
emmc,bus=sdhci-bus.2,drive=emmc0,boot-partition-size=1048576,boot-config=8

The above would be my preferred approach if acceptable. The "sd-bus"
bus identifier should be changed in other machines tough.


No real preference here, though my understanding is that emmc devices
are by definition built-in, and that is what emmc_class_init() says as well.
Also, there does not seem to be an sdhci-bus, only sd-bus, and that does
not support any index values. That may be just my lack of knowledge, though.


No, you are right. On a real ast2600-evb, the eMMC device is indeed
soldered on the board. But, for testing purposes, it is sometime
interesting to add some flexibility in the machine definition and
in the modeling too. This avoids "hard-coding" default devices in
the machines and lets the user define its own variant models using
the QEMU command line.


I would agree, but I had a number of my patches rejected because while
they would be useful for testing they would not accurately reflect the
hardware. So nowadays I gave up even trying to upstream such changes.


My patch to make eMMCs user creatable [1] was applied to target-
arm.next by Peter Maydell [2] last week.



That works for me with

drivecmd="-drive file=${ROOTFS},format=raw,if=none,id=d0"
drivecmd+=" -device emmc,drive=d0"

but unless I am missing something

drivecmd="-drive file=${ROOTFS},format=raw,if=none,id=d0"
drivecmd+=" -device sd-card,drive=d0"

also boots from the emmc controller. How do I provide the
bus and bus index ? "bus=sdhci-bus.2" doesn't work for me.
There is "sd-bus", but it does not have an index.

Thanks,
Guenter

Re: [PATCH] hw/sd/sdcard: Allow user creation of eMMCs

[Peter Maydell]

On Fri, 18 Oct 2024 at 16:42, Peter Maydell  wrote:
>
> On Tue, 15 Oct 2024 at 14:57, Jan Luebbe  wrote:
> >
> > For testing eMMC-specific functionality (such as handling boot
> > partitions), it would be very useful to attach them to generic VMs such
> > as x86_64 via the sdhci-pci device:
> >  ...
> >  -drive if=none,id=emmc-drive,file=emmc.img,format=raw \
> >  -device sdhci-pci \
> >  -device emmc,id=emmc0,drive=emmc-drive,boot-partition-size=1048576 \
> >  ...
> >
> > While most eMMCs are soldered to boards, they can also be connected to
> > SD controllers with just a passive adapter, such as:
> >  https://docs.radxa.com/en/accessories/emmc-to-usd
> >  https://github.com/voltlog/emmc-wfbga153-microsd
> >
> > The only change necessary to make the options above work is to avoid
> > disabling user_creatable, so do that. The SDHCI-PCI driver in the Linux
> > kernel already supports this just fine.
> >
> > Signed-off-by: Jan Luebbe 
>
> Applied to target-arm.next, thanks (unless anybody would
> prefer it to go via some other route).

I'm dropping this from target-arm.next since it seems like
we have a problem with the handling of boot partitions
and how the user should provide an image for an emmc card
that has boot partitions). Since that's an emmc specific
thing, sorting that out with a minimum of breaking
compatibility with previously working setups is going to
be easier if we stay temporarily in the state of "emmc
only happens for the specific board that creates them
and the user can't arbitrarily create them on the
command line".

I expect this to just be a temporary delay while we sort
out in the other thread how emmc boot partitions should work.

thanks
-- PMM

Re: [PATCH v4 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

[Akihiko Odaki]

On 2024/10/29 6:06, Phil Dennis-Jordan wrote:



On Mon, 28 Oct 2024 at 17:06, Akihiko Odaki > wrote:


On 2024/10/28 23:13, Phil Dennis-Jordan wrote:
 >
 >
 > On Mon, 28 Oct 2024 at 15:02, Akihiko Odaki
mailto:akihiko.od...@daynix.com>
 > >> wrote:
 >
 >     On 2024/10/28 22:31, Phil Dennis-Jordan wrote:
 >      >
 >      >
 >      > On Mon, 28 Oct 2024 at 10:00, Phil Dennis-Jordan
 >     mailto:p...@philjordan.eu>
>
 >      > 
      >
 >      >
 >      >          >      >
 >      >          >      > Hmm. I think if we were to use that, we
would
 >     need to
 >      >         create a new
 >      >          >      > QemuEvent for every job and destroy it
afterward,
 >      >         which seems
 >      >          >     expensive.
 >      >          >      > We can't rule out multiple concurrent
jobs being
 >      >         submitted, and the
 >      >          >      > QemuEvent system only supports a single
producer as
 >      >         far as I can
 >      >          >     tell.
 >      >          >      >
 >      >          >      > You can probably sort of hack around it with
 >     just one
 >      >         QemuEvent by
 >      >          >      > putting the qemu_event_wait into a loop
and turning
 >      >         the job.done
 >      >          >     flag
 >      >          >      > into an atomic (because it would now
need to be
 >      >         checked outside the
 >      >          >      > lock) but this all seems unnecessarily
complicated
 >      >         considering the
 >      >          >      > QemuEvent uses the same mechanism QemuCond/
 >     QemuMutex
 >      >         internally
 >      >          >     on macOS
 >      >          >      > (the only platform relevant here), except we
 >     can use it as
 >      >          >     intended with
 >      >          >      > QemuCond/QemuMutex rather than having to
work
 >     against the
 >      >          >     abstraction.
 >      >          >
 >      >          >     I don't think it's going to be used
concurrently. It
 >      >         would be difficult
 >      >          >     to reason even for the framework if it
performs memory
 >      >          >     unmapping/mapping/reading operations
concurrently.
 >      >          >
 >      >          >
 >      >          > I've just performed a very quick test by
wrapping the job
 >      >         submission/
 >      >          > wait in the 2 mapMemory callbacks and the 1
readMemory
 >      >         callback with
 >      >          > atomic counters and logging whenever a counter went
 >     above 1.
 >      >          >
 >      >          >   * Overall, concurrent callbacks across all
types were
 >      >         common (many per
 >      >          > second when the VM is busy). It's not exactly a
 >     "thundering
 >      >         herd" (I
 >      >          > never saw >2) but it's probably not a bad idea
to use
 >     a separate
 >      >          > condition variable for each job type. (task map,
 >     surface map,
 >      >         memory read)
 >      >          >   * While I did not observe any concurrent
memory mapping
 >      >         operations
 >      >          > *within* a type of memory map (2 task mappings or 2
 >     surface
 >      >         mappings) I
 >      >          > did see very occasional concurrent memory *read*
 >     callbacks.
 >      >         These would,
 >      >          > as far as I can tell, not be safe with QemuEvents,
 >     unless we
 >      >         placed the
 >      >          > event inside the job struct and init/destroyed
it on every
 >      >         callback
 >      >          > (which seems like excessive overhead).
 >      >
 >      >         I think we can tolerate that overhead. init/destroy
 >     essentially
 >      >         sets the
 >      >         fields in the data structure and I estimate its
total size is
 >      >         about 100
 >      >         bytes. It is probably better than waking an
irrelevant thread
 >      >         up. I also
 >      >         hope that keeps the code simple; it's not worthwhile
 >     adding code to
 >      >         optimize this.
 >      >
 >      >
 >      >     At least pthread_cond_{init,destroy} and
 >      >     pthread_mut

[PATCH v1 0/8] Support RTC for AST2700

[Jamin Lin via]

change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Register 2 for SD slot 0 and 1.
4. Support create flash devices via command line for AST1030.

Jamin Lin (8):
  aspeed/soc: Support RTC for AST2700
  hw/timer/aspeed: Fix coding style
  hw/timer/aspeed: Fix interrupt status does not be cleared for AST2600
  hw/sd/sdhci: Fix coding style
  hw/sd/sdhci: Introduce a new Write Protected pin inverted property
  hw/sd/aspeed_sdhci: Introduce Capabilities Register 2 for SD slot 0
and 1
  hw/arm/aspeed: Invert sdhci write protected pin for AST2600 and
AST2500 EVBs
  aspeed: Support create flash devices via command line for AST1030

 hw/arm/aspeed.c | 30 --
 hw/arm/aspeed_ast27x0.c | 11 +++
 hw/sd/aspeed_sdhci.c| 40 ---
 hw/sd/sdhci.c   | 70 -
 hw/timer/aspeed_timer.c | 15 +
 include/hw/arm/aspeed.h |  1 +
 include/hw/sd/sdhci.h   |  5 +++
 7 files changed, 123 insertions(+), 49 deletions(-)

-- 
2.34.1

[PATCH v1 5/8] hw/sd/sdhci: Introduce a new Write Protected pin inverted property

[Jamin Lin via]

The Write Protect pin of SDHCI model is default active low to match the SDHCI
spec. So, write enable the bit 19 should be 1 and write protected the bit 19
should be 0 at the Present State Register (0x24). However, some board are
design Write Protected pin active high. In other words, write enable the bit 19
should be 0 and write protected the bit 19 should be 1 at the
Present State Register (0x24). To support it, introduces a new "wp_invert"
property and set it false by default.

Signed-off-by: Jamin Lin 
---
 hw/sd/sdhci.c | 6 ++
 include/hw/sd/sdhci.h | 5 +
 2 files changed, 11 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index db7d547156..bdf5cbfb80 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -275,6 +275,10 @@ static void sdhci_set_readonly(DeviceState *dev, bool 
level)
 {
 SDHCIState *s = (SDHCIState *)dev;
 
+if (s->wp_invert) {
+level = !level;
+}
+
 if (level) {
 s->prnsts &= ~SDHC_WRITE_PROTECT;
 } else {
@@ -1551,6 +1555,8 @@ static Property sdhci_sysbus_properties[] = {
  false),
 DEFINE_PROP_LINK("dma", SDHCIState,
  dma_mr, TYPE_MEMORY_REGION, MemoryRegion *),
+DEFINE_PROP_BOOL("wp-invert", SDHCIState,
+ wp_invert, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/sd/sdhci.h b/include/hw/sd/sdhci.h
index 6cd2822f1d..d68f4788e7 100644
--- a/include/hw/sd/sdhci.h
+++ b/include/hw/sd/sdhci.h
@@ -100,6 +100,11 @@ struct SDHCIState {
 uint8_t sd_spec_version;
 uint8_t uhs_mode;
 uint8_t vendor;/* For vendor specific functionality */
+/*
+ * Write Protect pin default active low for detecting SD card
+ * to be protected. Set wp_invert to true inverted the signal.
+ */
+bool wp_invert;
 };
 typedef struct SDHCIState SDHCIState;
 
-- 
2.34.1

[PATCH v1 7/8] hw/arm/aspeed: Invert sdhci write protected pin for AST2600 and AST2500 EVBs

[Jamin Lin via]

The Write Protect pin of SDHCI model is default active low to match the SDHCI
spec. So, write enable the bit 19 should be 1 and write protected the bit 19
should be 0 at the Present State Register (0x24).

According to the design of AST2500 and AST2600 EVBs, the Write Protected pin
is active high by default. To support it, introduces a new sdhci_wp_invert
property in ASPEED MACHINE state and set it true for AST2500 and AST2600 EVBs
and set "wp_invert" property true of sdhci-generic model.

Signed-off-by: Jamin Lin 
---
 hw/arm/aspeed.c | 8 
 include/hw/arm/aspeed.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index b4b1ce9efb..0468602d95 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -403,6 +403,12 @@ static void aspeed_machine_init(MachineState *machine)
  OBJECT(get_system_memory()), &error_abort);
 object_property_set_link(OBJECT(bmc->soc), "dram",
  OBJECT(machine->ram), &error_abort);
+if (amc->sdhci_wp_invert) {
+for (i = 0; i < bmc->soc->sdhci.num_slots; i++) {
+object_property_set_bool(OBJECT(&bmc->soc->sdhci.slots[i]),
+ "wp-invert", true, &error_abort);
+}
+}
 if (machine->kernel_filename) {
 /*
  * When booting with a -kernel command line there is no u-boot
@@ -1308,6 +1314,7 @@ static void 
aspeed_machine_ast2500_evb_class_init(ObjectClass *oc, void *data)
 amc->fmc_model = "mx25l25635e";
 amc->spi_model = "mx25l25635f";
 amc->num_cs= 1;
+amc->sdhci_wp_invert = true;
 amc->i2c_init  = ast2500_evb_i2c_init;
 mc->default_ram_size   = 512 * MiB;
 aspeed_machine_class_init_cpus_defaults(mc);
@@ -1409,6 +1416,7 @@ static void 
aspeed_machine_ast2600_evb_class_init(ObjectClass *oc, void *data)
 amc->num_cs= 1;
 amc->macs_mask = ASPEED_MAC0_ON | ASPEED_MAC1_ON | ASPEED_MAC2_ON |
  ASPEED_MAC3_ON;
+amc->sdhci_wp_invert = true;
 amc->i2c_init  = ast2600_evb_i2c_init;
 mc->default_ram_size = 1 * GiB;
 aspeed_machine_class_init_cpus_defaults(mc);
diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h
index cbeacb214c..879bdb96ee 100644
--- a/include/hw/arm/aspeed.h
+++ b/include/hw/arm/aspeed.h
@@ -39,6 +39,7 @@ struct AspeedMachineClass {
 uint32_t macs_mask;
 void (*i2c_init)(AspeedMachineState *bmc);
 uint32_t uart_default;
+bool sdhci_wp_invert;
 };
 
 
-- 
2.34.1

[PATCH v1 4/8] hw/sd/sdhci: Fix coding style

[Jamin Lin via]

Fix coding style issues from checkpatch.pl

Signed-off-by: Jamin Lin 
---
 hw/sd/sdhci.c | 64 +--
 1 file changed, 42 insertions(+), 22 deletions(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index ed01499391..db7d547156 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -234,7 +234,7 @@ static void sdhci_raise_insertion_irq(void *opaque)
 
 if (s->norintsts & SDHC_NIS_REMOVE) {
 timer_mod(s->insert_timer,
-   qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 
SDHC_INSERTION_DELAY);
+qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + SDHC_INSERTION_DELAY);
 } else {
 s->prnsts = 0x1ff;
 if (s->norintstsen & SDHC_NISEN_INSERT) {
@@ -252,7 +252,7 @@ static void sdhci_set_inserted(DeviceState *dev, bool level)
 if ((s->norintsts & SDHC_NIS_REMOVE) && level) {
 /* Give target some time to notice card ejection */
 timer_mod(s->insert_timer,
-   qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 
SDHC_INSERTION_DELAY);
+qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + SDHC_INSERTION_DELAY);
 } else {
 if (level) {
 s->prnsts = 0x1ff;
@@ -290,9 +290,11 @@ static void sdhci_reset(SDHCIState *s)
 timer_del(s->insert_timer);
 timer_del(s->transfer_timer);
 
-/* Set all registers to 0. Capabilities/Version registers are not cleared
+/*
+ * Set all registers to 0. Capabilities/Version registers are not cleared
  * and assumed to always preserve their value, given to them during
- * initialization */
+ * initialization
+ */
 memset(&s->sdmasysad, 0, (uintptr_t)&s->capareg - 
(uintptr_t)&s->sdmasysad);
 
 /* Reset other state based on current card insertion/readonly status */
@@ -306,7 +308,8 @@ static void sdhci_reset(SDHCIState *s)
 
 static void sdhci_poweron_reset(DeviceState *dev)
 {
-/* QOM (ie power-on) reset. This is identical to reset
+/*
+ * QOM (ie power-on) reset. This is identical to reset
  * commanded via device register apart from handling of the
  * 'pending insert on powerup' quirk.
  */
@@ -446,8 +449,10 @@ static void sdhci_read_block_from_card(SDHCIState *s)
 s->prnsts &= ~SDHC_DAT_LINE_ACTIVE;
 }
 
-/* If stop at block gap request was set and it's not the last block of
- * data - generate Block Event interrupt */
+/*
+ * If stop at block gap request was set and it's not the last block of
+ * data - generate Block Event interrupt
+ */
 if (s->stopped_state == sdhc_gap_read && (s->trnmod & SDHC_TRNS_MULTI) &&
 s->blkcnt != 1){
 s->prnsts &= ~SDHC_DAT_LINE_ACTIVE;
@@ -549,8 +554,10 @@ static void sdhci_write_block_to_card(SDHCIState *s)
 sdhci_update_irq(s);
 }
 
-/* Write @size bytes of @value data to host controller @s Buffer Data Port
- * register */
+/*
+ * Write @size bytes of @value data to host controller @s Buffer Data Port
+ * register
+ */
 static void sdhci_write_dataport(SDHCIState *s, uint32_t value, unsigned size)
 {
 unsigned i;
@@ -595,9 +602,11 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
 return;
 }
 
-/* XXX: Some sd/mmc drivers (for example, u-boot-slp) do not account for
+/*
+ * XXX: Some sd/mmc drivers (for example, u-boot-slp) do not account for
  * possible stop at page boundary if initial address is not page aligned,
- * allow them to work properly */
+ * allow them to work properly
+ */
 if ((s->sdmasysad % boundary_chk) == 0) {
 page_aligned = true;
 }
@@ -703,7 +712,8 @@ static void get_adma_description(SDHCIState *s, ADMADescr 
*dscr)
 dma_memory_read(s->dma_as, entry_addr, &adma2, sizeof(adma2),
 MEMTXATTRS_UNSPECIFIED);
 adma2 = le64_to_cpu(adma2);
-/* The spec does not specify endianness of descriptor table.
+/*
+ * The spec does not specify endianness of descriptor table.
  * We currently assume that it is LE.
  */
 dscr->addr = (hwaddr)extract64(adma2, 32, 32) & ~0x3ull;
@@ -978,8 +988,10 @@ static bool sdhci_can_issue_command(SDHCIState *s)
 return true;
 }
 
-/* The Buffer Data Port register must be accessed in sequential and
- * continuous manner */
+/*
+ * The Buffer Data Port register must be accessed in sequential and
+ * continuous manner
+ */
 static inline bool
 sdhci_buff_access_is_sequential(SDHCIState *s, unsigned byte_num)
 {
@@ -1207,8 +1219,10 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, 
unsigned size)
 MASKED_WRITE(s->argument, mask, value);
 break;
 case SDHC_TRNMOD:
-/* DMA can be enabled only if it is supported as indicated by
- * capabilities register */
+/*
+ * DMA can be enabled only if it is supported as indicated by
+ * capabilities register
+ */
 if (!(s->capareg & R_SDHC_CAPAB_SDMA_MASK)) {
   

[PATCH v1 3/8] hw/timer/aspeed: Fix interrupt status does not be cleared for AST2600

[Jamin Lin via]

According to the datasheet of AST2600 description, interrupt status set by HW
and clear to "0" by software writing "1" on the specific bit.

Therefore, if firmware set the specific bit "1" in the interrupt status
register(0x34), the specific bit of "s->irq_sts" should be cleared 0.

Signed-off-by: Jamin Lin 
---
 hw/timer/aspeed_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/timer/aspeed_timer.c b/hw/timer/aspeed_timer.c
index 5af268ea9e..149f7cc5a6 100644
--- a/hw/timer/aspeed_timer.c
+++ b/hw/timer/aspeed_timer.c
@@ -580,7 +580,7 @@ static void aspeed_2600_timer_write(AspeedTimerCtrlState 
*s, hwaddr offset,
 
 switch (offset) {
 case 0x34:
-s->irq_sts &= tv;
+s->irq_sts &= ~tv;
 break;
 case 0x3C:
 aspeed_timer_set_ctrl(s, s->ctrl & ~tv);
-- 
2.34.1

[PATCH v1 1/8] aspeed/soc: Support RTC for AST2700

[Jamin Lin via]

The RTC controller between AST2600 and AST2700 are identical. Add RTC model for
AST2700 RTC support. The RTC controller registers base address is start at
0x12C0_F000 and its alarm interrupt is connected to GICINT13.

Signed-off-by: Jamin Lin 
---
 hw/arm/aspeed_ast27x0.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
index dca660eb6b..7ab4bec644 100644
--- a/hw/arm/aspeed_ast27x0.c
+++ b/hw/arm/aspeed_ast27x0.c
@@ -63,6 +63,7 @@ static const hwaddr aspeed_soc_ast2700_memmap[] = {
 [ASPEED_DEV_ADC]   =  0x14C0,
 [ASPEED_DEV_I2C]   =  0x14C0F000,
 [ASPEED_DEV_GPIO]  =  0x14C0B000,
+[ASPEED_DEV_RTC]   =  0x12C0F000,
 };
 
 #define AST2700_MAX_IRQ 288
@@ -376,6 +377,8 @@ static void aspeed_soc_ast2700_init(Object *obj)
 
 snprintf(typename, sizeof(typename), "aspeed.gpio-%s", socname);
 object_initialize_child(obj, "gpio", &s->gpio, typename);
+
+object_initialize_child(obj, "rtc", &s->rtc, TYPE_ASPEED_RTC);
 }
 
 /*
@@ -670,6 +673,14 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, 
Error **errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(&s->gpio), 0,
aspeed_soc_get_irq(s, ASPEED_DEV_GPIO));
 
+/* RTC */
+if (!sysbus_realize(SYS_BUS_DEVICE(&s->rtc), errp)) {
+return;
+}
+aspeed_mmio_map(s, SYS_BUS_DEVICE(&s->rtc), 0, sc->memmap[ASPEED_DEV_RTC]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->rtc), 0,
+   aspeed_soc_get_irq(s, ASPEED_DEV_RTC));
+
 create_unimplemented_device("ast2700.dpmcu", 0x1100, 0x4);
 create_unimplemented_device("ast2700.iomem0", 0x1200, 0x0100);
 create_unimplemented_device("ast2700.iomem1", 0x1400, 0x0100);
-- 
2.34.1

[PATCH v1 2/8] hw/timer/aspeed: Fix coding style

[Jamin Lin via]

Fix coding style issues from checkpatch.pl

Signed-off-by: Jamin Lin 
---
 hw/timer/aspeed_timer.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/hw/timer/aspeed_timer.c b/hw/timer/aspeed_timer.c
index b1f860ecfb..5af268ea9e 100644
--- a/hw/timer/aspeed_timer.c
+++ b/hw/timer/aspeed_timer.c
@@ -276,7 +276,8 @@ static void aspeed_timer_set_value(AspeedTimerCtrlState *s, 
int timer, int reg,
 old_reload = t->reload;
 t->reload = calculate_min_ticks(t, value);
 
-/* If the reload value was not previously set, or zero, and
+/*
+ * If the reload value was not previously set, or zero, and
  * the current value is valid, try to start the timer if it is
  * enabled.
  */
@@ -312,7 +313,8 @@ static void aspeed_timer_set_value(AspeedTimerCtrlState *s, 
int timer, int reg,
 }
 }
 
-/* Control register operations are broken out into helpers that can be
+/*
+ * Control register operations are broken out into helpers that can be
  * explicitly called on aspeed_timer_reset(), but also from
  * aspeed_timer_ctrl_op().
  */
@@ -396,7 +398,8 @@ static void aspeed_timer_set_ctrl(AspeedTimerCtrlState *s, 
uint32_t reg)
 AspeedTimer *t;
 const uint8_t enable_mask = BIT(op_enable);
 
-/* Handle a dependency between the 'enable' and remaining three
+/*
+ * Handle a dependency between the 'enable' and remaining three
  * configuration bits - i.e. if more than one bit in the control set has
  * changed, including the 'enable' bit, then we want either disable the
  * timer and perform configuration, or perform configuration and then
@@ -582,7 +585,6 @@ static void aspeed_2600_timer_write(AspeedTimerCtrlState 
*s, hwaddr offset,
 case 0x3C:
 aspeed_timer_set_ctrl(s, s->ctrl & ~tv);
 break;
-
 case 0x38:
 default:
 qemu_log_mask(LOG_GUEST_ERROR, "%s: Bad offset 0x%" HWADDR_PRIx "\n",
@@ -623,7 +625,8 @@ static void aspeed_timer_reset(DeviceState *dev)
 
 for (i = 0; i < ASPEED_TIMER_NR_TIMERS; i++) {
 AspeedTimer *t = &s->timers[i];
-/* Explicitly call helpers to avoid any conditional behaviour through
+/*
+ * Explicitly call helpers to avoid any conditional behaviour through
  * aspeed_timer_set_ctrl().
  */
 aspeed_timer_ctrl_enable(t, false);
-- 
2.34.1

[PATCH v1 6/8] hw/sd/aspeed_sdhci: Introduce Capabilities Register 2 for SD slot 0 and 1

[Jamin Lin via]

The size of SDHCI capabilities register is 64bits, so introduces new
Capabilities Register 2 for SD slot 0 (0x144) and SD slot1 (0x244).

Signed-off-by: Jamin Lin 
---
 hw/sd/aspeed_sdhci.c | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/hw/sd/aspeed_sdhci.c b/hw/sd/aspeed_sdhci.c
index 427e5336a8..b73c18fbff 100644
--- a/hw/sd/aspeed_sdhci.c
+++ b/hw/sd/aspeed_sdhci.c
@@ -24,8 +24,10 @@
 #define  ASPEED_SDHCI_DEBOUNCE_RESET 0x0005
 #define ASPEED_SDHCI_BUS 0x08
 #define ASPEED_SDHCI_SDIO_1400x10
+#define ASPEED_SDHCI_SDIO_1440x14
 #define ASPEED_SDHCI_SDIO_1480x18
 #define ASPEED_SDHCI_SDIO_2400x20
+#define ASPEED_SDHCI_SDIO_2440x24
 #define ASPEED_SDHCI_SDIO_2480x28
 #define ASPEED_SDHCI_WP_POL  0xec
 #define ASPEED_SDHCI_CARD_DET0xf0
@@ -35,21 +37,27 @@
 
 static uint64_t aspeed_sdhci_read(void *opaque, hwaddr addr, unsigned int size)
 {
-uint32_t val = 0;
+uint64_t val = 0;
 AspeedSDHCIState *sdhci = opaque;
 
 switch (addr) {
 case ASPEED_SDHCI_SDIO_140:
-val = (uint32_t)sdhci->slots[0].capareg;
+val = extract64(sdhci->slots[0].capareg, 0, 32);
+break;
+case ASPEED_SDHCI_SDIO_144:
+val = extract64(sdhci->slots[0].capareg, 32, 32);
 break;
 case ASPEED_SDHCI_SDIO_148:
-val = (uint32_t)sdhci->slots[0].maxcurr;
+val = extract64(sdhci->slots[0].maxcurr, 0, 32);
 break;
 case ASPEED_SDHCI_SDIO_240:
-val = (uint32_t)sdhci->slots[1].capareg;
+val = extract64(sdhci->slots[1].capareg, 0, 32);
+break;
+case ASPEED_SDHCI_SDIO_244:
+val = extract64(sdhci->slots[1].capareg, 32, 32);
 break;
 case ASPEED_SDHCI_SDIO_248:
-val = (uint32_t)sdhci->slots[1].maxcurr;
+ val = extract64(sdhci->slots[1].maxcurr, 0, 32);
 break;
 default:
 if (addr < ASPEED_SDHCI_REG_SIZE) {
@@ -61,9 +69,9 @@ static uint64_t aspeed_sdhci_read(void *opaque, hwaddr addr, 
unsigned int size)
 }
 }
 
-trace_aspeed_sdhci_read(addr, size, (uint64_t) val);
+trace_aspeed_sdhci_read(addr, size, val);
 
-return (uint64_t)val;
+return val;
 }
 
 static void aspeed_sdhci_write(void *opaque, hwaddr addr, uint64_t val,
@@ -79,16 +87,26 @@ static void aspeed_sdhci_write(void *opaque, hwaddr addr, 
uint64_t val,
 sdhci->regs[TO_REG(addr)] = (uint32_t)val & ~ASPEED_SDHCI_INFO_RESET;
 break;
 case ASPEED_SDHCI_SDIO_140:
-sdhci->slots[0].capareg = (uint64_t)(uint32_t)val;
+sdhci->slots[0].capareg = deposit64(sdhci->slots[0].capareg, 0, 32, val);
+break;
+case ASPEED_SDHCI_SDIO_144:
+sdhci->slots[0].capareg = deposit64(sdhci->slots[0].capareg, 32, 32, val);
 break;
 case ASPEED_SDHCI_SDIO_148:
-sdhci->slots[0].maxcurr = (uint64_t)(uint32_t)val;
+sdhci->slots[0].maxcurr = deposit64(sdhci->slots[0].maxcurr,
+0, 32, val);
 break;
 case ASPEED_SDHCI_SDIO_240:
-sdhci->slots[1].capareg = (uint64_t)(uint32_t)val;
+sdhci->slots[1].capareg = deposit64(sdhci->slots[1].capareg,
+0, 32, val);
+break;
+case ASPEED_SDHCI_SDIO_244:
+sdhci->slots[1].capareg = deposit64(sdhci->slots[1].capareg,
+32, 32, val);
 break;
 case ASPEED_SDHCI_SDIO_248:
-sdhci->slots[1].maxcurr = (uint64_t)(uint32_t)val;
+sdhci->slots[1].maxcurr = deposit64(sdhci->slots[0].maxcurr,
+0, 32, val);
 break;
 default:
 if (addr < ASPEED_SDHCI_REG_SIZE) {
-- 
2.34.1

[PATCH v1 8/8] aspeed: Support create flash devices via command line for AST1030

[Jamin Lin via]

Add a "if-statement" in aspeed_minibmc_machine_init function. If users add
"-nodefaults" in command line, the flash devices should be created by users
setting. Otherwise, the flash devices are created at machine init.

Signed-off-by: Jamin Lin 
---
 hw/arm/aspeed.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 0468602d95..e161e6b1c5 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -1602,18 +1602,20 @@ static void aspeed_minibmc_machine_init(MachineState 
*machine)
 connect_serial_hds_to_uarts(bmc);
 qdev_realize(DEVICE(bmc->soc), NULL, &error_abort);
 
-aspeed_board_init_flashes(&bmc->soc->fmc,
-  bmc->fmc_model ? bmc->fmc_model : amc->fmc_model,
-  amc->num_cs,
-  0);
+if (defaults_enabled()) {
+aspeed_board_init_flashes(&bmc->soc->fmc,
+bmc->fmc_model ? bmc->fmc_model : amc->fmc_model,
+amc->num_cs,
+0);
 
-aspeed_board_init_flashes(&bmc->soc->spi[0],
-  bmc->spi_model ? bmc->spi_model : amc->spi_model,
-  amc->num_cs, amc->num_cs);
+aspeed_board_init_flashes(&bmc->soc->spi[0],
+bmc->spi_model ? bmc->spi_model : amc->spi_model,
+amc->num_cs, amc->num_cs);
 
-aspeed_board_init_flashes(&bmc->soc->spi[1],
-  bmc->spi_model ? bmc->spi_model : amc->spi_model,
-  amc->num_cs, (amc->num_cs * 2));
+aspeed_board_init_flashes(&bmc->soc->spi[1],
+bmc->spi_model ? bmc->spi_model : amc->spi_model,
+amc->num_cs, (amc->num_cs * 2));
+}
 
 if (amc->i2c_init) {
 amc->i2c_init(bmc);
-- 
2.34.1

Re: [PATCH v6 0/3] hw/{i2c,nvme}: mctp endpoint, nvme management interface model

[Klaus Jensen]

On Oct 14 10:36, Jonathan Cameron via wrote:
> On Wed, 20 Sep 2023 09:36:34 -0500
> Corey Minyard  wrote:
> 
> > On Wed, Sep 20, 2023 at 06:31:25AM -0700, Klaus Jensen wrote:
> > > On Sep 20 07:54, Corey Minyard wrote:  
> > > > On Wed, Sep 20, 2023 at 12:48:03PM +0100, Jonathan Cameron via wrote:  
> > > > > On Thu, 14 Sep 2023 11:53:40 +0200
> > > > > Klaus Jensen  wrote:
> > > > >   
> > > > > > This adds a generic MCTP endpoint model that other devices may 
> > > > > > derive
> > > > > > from.
> > > > > > 
> > > > > > Also included is a very basic implementation of an NVMe-MI device,
> > > > > > supporting only a small subset of the required commands.
> > > > > > 
> > > > > > Since this all relies on i2c target mode, this can currently only be
> > > > > > used with an SoC that includes the Aspeed I2C controller.
> > > > > > 
> > > > > > The easiest way to get up and running with this, is to grab my 
> > > > > > buildroot
> > > > > > overlay[1] (aspeed_ast2600evb_nmi_defconfig). It includes modified a
> > > > > > modified dts as well as a couple of required packages.
> > > > > > 
> > > > > > QEMU can then be launched along these lines:
> > > > > > 
> > > > > >   qemu-system-arm \
> > > > > > -nographic \
> > > > > > -M ast2600-evb \
> > > > > > -kernel output/images/zImage \
> > > > > > -initrd output/images/rootfs.cpio \
> > > > > > -dtb output/images/aspeed-ast2600-evb-nmi.dtb \
> > > > > > -nic user,hostfwd=tcp::-:22 \
> > > > > > -device nmi-i2c,address=0x3a \
> > > > > > -serial mon:stdio
> > > > > > 
> > > > > > From within the booted system,
> > > > > > 
> > > > > >   mctp addr add 8 dev mctpi2c15
> > > > > >   mctp link set mctpi2c15 up
> > > > > >   mctp route add 9 via mctpi2c15
> > > > > >   mctp neigh add 9 dev mctpi2c15 lladdr 0x3a
> > > > > >   mi-mctp 1 9 info
> > > > > > 
> > > > > > Comments are very welcome!
> > > > > > 
> > > > > >   [1]: https://github.com/birkelund/hwtests/tree/main/br2-external
> > > > > > 
> > > > > > Signed-off-by: Klaus Jensen   
> > > > > 
> > > > > Hi Klaus,
> > > > > 
> > > > > Silly question, but who is likely to pick this up? + likely to be 
> > > > > soon?
> > > > > 
> > > > > I'm going to post the CXL stuff that makes use of the core support 
> > > > > shortly
> > > > > and whilst I can point at this patch set on list, I'd keen to see it 
> > > > > upstream
> > > > > to reduce the dependencies (it's got 2 sets ahead of it of CXL stuff
> > > > > anyway but that will all hopefully go through Michael Tsirkin's tree
> > > > > for PCI stuff in one go).  
> > > > 
> > > > I can pick it up, but he can just request a merge, too.
> > > > 
> > > > I did have a question I asked earlier about tests.  It would be unusual
> > > > at this point to add something like this without having some tests,
> > > > especially injecting invalid data.
> > > >   
> > > 
> > > Hi all,
> > > 
> > > Sorry for the late reply. I'm currently at SDC, but I will write up some
> > > tests when I get back to in the office on Monday.
> > > 
> > > Corey, what kinds of tests would be best here? Avocado "acceptance"
> > > tests or would you like to see something lower level?  
> > 
> > My main concern is testing what happens when bad data gets injected, to
> > avoid people coming up with clever names for exploits in qemu.  It's not
> > so much for this code, it's for the changes that comes in the future.
> > 
> > And, of course, normal functional tests to make sure it works.  What a
> > friend of mine calls "dead chicken" tests.  You wave a dead chicken at
> > it, and if the chicken is still dead everything is ok :).
> > 
> > I'm fine with either type of tests, but I'm not sure you can do this
> > with avocado.  It's probably about the same amount of work either path
> > you choose.
> > 
> > -corey
> 
> Hi Klaus, All,
> 
> I was looking at what dependencies I'm carrying on my CXL tree and this
> series is one of the bigger bits :(
> 
> Any plans to take it forwards?
> I have some other stuff to solve to have a fully upstream QEMU
> solution for the CXL fm-api over mctp (direct from host anyway), but
> if this is blocked indefinitely tackling how to get a controller onto
> a typical server system isn't going to be productive :(
> 
> As Davidlohr called out at in the CXL LPC Uconf [1] this is really handy
> for testing his work on libcxlmi. A number of people are looking
> at more sophisticated CXL fabric emulation and that will also need
> us to close this gap!
> 
> No promises but maybe we can find someone to help with adding tests
> if that's the only remaining blocker.
> 

Yes, I believe the lack of tests are the blocker currently. I've mostly
been testing this through a buildroot. That allows me to at least kick
it with invalid fields and so on, but it all depends on the linux mctp
driver doing the bulk of the work (and it's not really supposed to do
"bad stuff"), so it's limited how low we can go.

While I have the infrastructure to do that, I'm really not