Re: [PATCH v2 07/18] aspeed: Fix hardcode attach flash model of spi controllers
Hello Jamin,
Sorry for the later answer. I think I missed the question below.
On 10/23/24 04:46, Jamin Lin wrote:
Hi Cedric,
Subject: Re: [PATCH v2 07/18] aspeed: Fix hardcode attach flash model of spi
controllers
oops. R-b sent on the wrong patch.
On 10/22/24 12:48, Cédric Le Goater wrote:
On 10/22/24 11:40, Jamin Lin wrote:
It only attached flash model of fmc and spi[0] in aspeed_machine_init
function.
However, AST2500 and AST2600 have one fmc and two spi(spi1 and spi2)
controllers; AST2700 have one fmc and 3 spi(spi0, spi1 and spi2) controllers.
Besides, it used hardcode to attach flash model of fmc, spi[0] and
spi[1] in aspeed_minibmc_machine_init for AST1030.
To make both functions more flexible and support all ASPEED SOCs spi
controllers, adds a for loop with sc->spis_num to attach flash model
of all supported spi controllers. The sc->spis_num is from AspeedSoCClass.
To be honest, I am not a big fan of the aspeed_board_init_flashes() routine.
See commit 27a2c66c92ec for the reason.
I prefer the more flexible approach :
$ qemu-system-arm -M ast2600-evb \
-blockdev node-name=fmc0,driver=file,filename=/path/to/fmc0.img \
-device mx66u51235f,bus=ssi.0,cs=0x0,drive=fmc0 \
-blockdev node-name=fmc1,driver=file,filename=/path/to/fmc1.img \
-device mx66u51235f,bus=ssi.0,cs=0x1,drive=fmc1 \
-blockdev node-name=spi1,driver=file,filename=/path/to/spi1.img \
-device mx66u51235f,cs=0x0,bus=ssi.1,drive=spi1 \
-nographic -nodefaults
Thanks for notify me this solution.
I can successfully attach the default image to supported SPI controllers with
different flash model.
It seems we need to add "defaults_enabled()" if-statement in
aspeed_minibmc_machine_init
to support this solution for AST1030. Otherwise, I will get this error.
qemu-system-arm: -device w25q80bl,bus=ssi.0,cs=0x0,drive=fmc0: CS index '0x0'
in use by a w25q80bl device
https://github.com/qemu/qemu/blob/master/hw/arm/aspeed.c
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[1],
bmc->spi_model ? bmc->spi_model : amc->spi_model,
amc->num_cs, (amc->num_cs * 2));
}
Do I need to send this patch in v3 patch series?
Or individually send this patch in the new patch series?
defaults_enabled() should be used to avoid creating the devices indeed.
Please send a patch for it. Or did you already ?
Thanks,
C.
AST1030:
-blockdev node-name=fmc0,driver=file,filename=./fmc_cs0_img \
-device w25q80bl,bus=ssi.0,cs=0x0,drive=fmc0 \
-blockdev node-name=fmc1,driver=file,filename=./fmc_cs1_img \
-device w25q80bl,bus=ssi.0,cs=0x1,drive=fmc1 \
-blockdev node-name=spi1c0,driver=file,filename=./spi1_cs0_img \
-device w25q256,bus=ssi.1,cs=0x0,drive=spi1c0 \
-blockdev node-name=spi1c1,driver=file,filename=./spi1_cs1_img \
-device w25q256,bus=ssi.1,cs=0x1,drive=spi1c1 \
-blockdev node-name=spi2c0,driver=file,filename=./spi2_cs0_img \
-device w25q256,bus=ssi.2,cs=0x0,drive=spi2c0 \
-blockdev node-name=spi2c1,driver=file,filename=./spi2_cs1_img \
-device w25q256,bus=ssi.2,cs=0x1,drive=spi2c1 \
-nodefaults
AST2600:
-blockdev node-name=fmc0,driver=file,filename=$1 \
-device mx66u51235f,cs=0x0,bus=ssi.0,drive=fmc0 \
-blockdev node-name=fmc1,driver=file,filename=./fmc_cs1_img \
-device mx66u51235f,cs=0x1,bus=ssi.0,drive=fmc1 \
-blockdev node-name=spi1,driver=file,filename=./spi1_cs0_img \
-device mx66u51235f,cs=0x0,bus=ssi.1,drive=spi1 \
-blockdev node-name=spi2,driver=file,filename=./spi2_cs0_img \
-device mx66u51235f,cs=0x0,bus=ssi.2,drive=spi2 \
-nodefaults
which doesn't use the drive_get() interface and so, doesn't make assumption
on the order of the drives defined on the QEMU command line.
Also, the number of availabe flash devices is a machine definition, not a SoC
definition. Not all CS are wired.
I will drop that patch for now.
Understand and thanks for suggestion.
Jamin
Thanks,
C.
---
hw/arm/aspeed.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index
b4b1ce9efb..7ac01a3562 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -419,9 +419,11 @@ static void aspeed_machine_init(MachineState
*machine)
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,
-
Re: [PATCH ssh v2] ssh: Do not switch session to non-blocking mode
13.11.2024 15:55, Richard W.M. Jones wrote:
From: Jakub Jelen
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoid infinite looping in case of network errors:
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/498
Since then, the ssh driver in qemu fails to read files over SFTP
as the first SFTP messages exchanged after switching the session
to non-blocking mode return SSH_AGAIN, but that message is lost
int the SFTP internals and interpretted as SSH_ERROR, which is
returned to the caller:
https://gitlab.com/libssh/libssh-mirror/-/issues/280
This is indeed an issue in libssh that we should address in the
long term, but it will require more work on the internals. For
now, the SFTP is not supported in non-blocking mode.
Fixes: https://gitlab.com/libssh/libssh-mirror/-/issues/280
Signed-off-by: Jakub Jelen
Signed-off-by: Richard W.M. Jones
---
block/ssh.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/block/ssh.c b/block/ssh.c
index 9f8140bcb6..b9f33ec739 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -866,9 +866,6 @@ static int ssh_open(BlockDriverState *bs, QDict *options,
int bdrv_flags,
goto err;
}
-/* Go non-blocking. */
-ssh_set_blocking(s->session, 0);
-
if (s->attrs->type == SSH_FILEXFER_TYPE_REGULAR) {
bs->supported_truncate_flags = BDRV_REQ_ZERO_WRITE;
}
I'm picking this up for the next stable series, since new libssh
is being released and used. Hopefully the resulting code wont
break with old libssh.
Thanks,
/mjt
Re: [PATCH v10 10/15] hw/vmapple/aes: Introduce aes engine
On 2024/11/13 23:23, Phil Dennis-Jordan wrote: 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 Reviewed-by: Akihiko Odaki
Re: [PATCH v10 15/15] hw/vmapple/vmapple: Add vmapple machine type
On 2024/11/13 23:23, Phil Dennis-Jordan wrote: 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. v7: * Tiny error handling fix, un-inlined function. v8: * Use object_property_add_uint64_ptr rather than defining custom UUID property get/set functions. v9: * Documentation improvements * Fixed variable name and struct field used during pvpanic device creation. v10: * Documentation fixup for changed virtio-blk device type. * Small improvements to shell commands in documentation. * Improved propagation of errors during cfg device instantiation. MAINTAINERS | 1 + contrib/vmapple/uuid.sh | 9 + docs/system/arm/vmapple.rst | 63 docs/system/target-arm.rst | 1 + hw/vmapple/Kconfig | 20 ++ hw/vmapple/meson.build | 1 + hw/vmapple/vmapple.c| 646 7 files changed, 741 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 c6b41b983bf..031754b1e13 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2768,6 +2768,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..5d59890c291 --- /dev/null +++ b/docs/system/arm/vmapple.rst @@ -0,0 +1,63 @@ +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
Re: [PATCH v10 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
On 2024/11/13 23:23, Phil Dennis-Jordan wrote: 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. Implementation wise, most of the complexity lies in the differing threading models of ParavirtualizedGraphics.framework, which uses libdispatch and internal locks, versus QEMU, which heavily uses the BQL, especially during memory-mapped device I/O. Great care has therefore been taken to prevent deadlocks by never calling into PVG methods while holding the BQL, and similarly never acquiring the BQL in a callback from PVG. Different strategies have been used (libdispatch, blocking and non-blocking BHs, RCU, etc.) depending on the specific requirements at each framework entry and exit point. 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. v6: * Switched PGTask_s's' mapped_regions from GPtrArray to GArray * Allow DisplaySurface to manage its own vram now that texture -> vram copy occurs under BQL. * Memory mapping operations now use RCU_READ_LOCK_GUARD() where possible instead of a heavy-weight BH job to acquire the BQL. * Changed PVG cursor and mode setting callbacks to kick off BHs instead of libdispatch tasks
RE: [PATCH v2 07/18] aspeed: Fix hardcode attach flash model of spi controllers
Hi Cedric,
> Subject: Re: [PATCH v2 07/18] aspeed: Fix hardcode attach flash model of spi
> controllers
>
> Hello Jamin,
>
> Sorry for the later answer. I think I missed the question below.
>
> On 10/23/24 04:46, Jamin Lin wrote:
> > Hi Cedric,
> >
> >> Subject: Re: [PATCH v2 07/18] aspeed: Fix hardcode attach flash model
> >> of spi controllers
> >>
> >> oops. R-b sent on the wrong patch.
> >>
> >> On 10/22/24 12:48, Cédric Le Goater wrote:
> >>> On 10/22/24 11:40, Jamin Lin wrote:
> It only attached flash model of fmc and spi[0] in
> aspeed_machine_init
> >> function.
> However, AST2500 and AST2600 have one fmc and two spi(spi1 and
> spi2) controllers; AST2700 have one fmc and 3 spi(spi0, spi1 and spi2)
> controllers.
>
> Besides, it used hardcode to attach flash model of fmc, spi[0] and
> spi[1] in aspeed_minibmc_machine_init for AST1030.
>
> To make both functions more flexible and support all ASPEED SOCs
> spi controllers, adds a for loop with sc->spis_num to attach flash
> model of all supported spi controllers. The sc->spis_num is from
> AspeedSoCClass.
> >>
> >> To be honest, I am not a big fan of the aspeed_board_init_flashes()
> >> routine.
> >> See commit 27a2c66c92ec for the reason.
> >>
> >> I prefer the more flexible approach :
> >>
> >> $ qemu-system-arm -M ast2600-evb \
> >> -blockdev
> node-name=fmc0,driver=file,filename=/path/to/fmc0.img \
> >> -device mx66u51235f,bus=ssi.0,cs=0x0,drive=fmc0 \
> >> -blockdev
> node-name=fmc1,driver=file,filename=/path/to/fmc1.img \
> >> -device mx66u51235f,bus=ssi.0,cs=0x1,drive=fmc1 \
> >> -blockdev
> node-name=spi1,driver=file,filename=/path/to/spi1.img \
> >> -device mx66u51235f,cs=0x0,bus=ssi.1,drive=spi1 \
> >> -nographic -nodefaults
> >>
> > Thanks for notify me this solution.
> > I can successfully attach the default image to supported SPI controllers
> > with
> different flash model.
> > It seems we need to add "defaults_enabled()" if-statement in
> > aspeed_minibmc_machine_init to support this solution for AST1030.
> Otherwise, I will get this error.
> >
> > qemu-system-arm: -device w25q80bl,bus=ssi.0,cs=0x0,drive=fmc0: CS
> > index '0x0' in use by a w25q80bl device
> >
> > https://github.com/qemu/qemu/blob/master/hw/arm/aspeed.c
> > 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[1],
> >bmc->spi_model ? bmc->spi_model :
> amc->spi_model,
> >amc->num_cs, (amc->num_cs * 2));
> >}
> >
> > Do I need to send this patch in v3 patch series?
> > Or individually send this patch in the new patch series?
>
>
> defaults_enabled() should be used to avoid creating the devices indeed.
> Please send a patch for it. Or did you already ?
>
This patch had been applied,
https://github.com/qemu/qemu/commit/22b3c557ffd4fb9c6c034a839b3e5b82d131123a
Thanks-Jamin
> Thanks,
>
> C.
>
>
>
> >
> > AST1030:
> > -blockdev node-name=fmc0,driver=file,filename=./fmc_cs0_img \ -device
> > w25q80bl,bus=ssi.0,cs=0x0,drive=fmc0 \ -blockdev
> > node-name=fmc1,driver=file,filename=./fmc_cs1_img \ -device
> > w25q80bl,bus=ssi.0,cs=0x1,drive=fmc1 \ -blockdev
> > node-name=spi1c0,driver=file,filename=./spi1_cs0_img \ -device
> > w25q256,bus=ssi.1,cs=0x0,drive=spi1c0 \ -blockdev
> > node-name=spi1c1,driver=file,filename=./spi1_cs1_img \ -device
> > w25q256,bus=ssi.1,cs=0x1,drive=spi1c1 \ -blockdev
> > node-name=spi2c0,driver=file,filename=./spi2_cs0_img \ -device
> > w25q256,bus=ssi.2,cs=0x0,drive=spi2c0 \ -blockdev
> > node-name=spi2c1,driver=file,filename=./spi2_cs1_img \ -device
> > w25q256,bus=ssi.2,cs=0x1,drive=spi2c1 \ -nodefaults
> >
> > AST2600:
> > -blockdev node-name=fmc0,driver=file,filename=$1 \ -device
> > mx66u51235f,cs=0x0,bus=ssi.0,drive=fmc0 \ -blockdev
> > node-name=fmc1,driver=file,filename=./fmc_cs1_img \ -device
> > mx66u51235f,cs=0x1,bus=ssi.0,drive=fmc1 \ -blockdev
> > node-name=spi1,driver=file,filename=./spi1_cs0_img \ -device
> > mx66u51235f,cs=0x0,bus=ssi.1,drive=spi1 \ -blockdev
> > node-name=spi2,driver=file,filename=./spi2_cs0_img \ -device
> > mx66u51235f,cs=0x0,bus=ssi.2,drive=spi2 \ -nodefaults
> >
> >> which doesn't use the drive_get() interface and so, doesn't make
> >> assumption on the order of the drives defined on the QEMU command line.
> >>
> >> Also, the number of availabe flash devices is a machine definition,
> >> not a SoC definition. Not all CS are wired.
> >>
> >> I will drop that patch for now.
>
Re: [RFC PATCH 0/5] support unaligned access to xHCI Capability
I would be happy to receive your comments. ping. On 2024/11/08 12:29, Tomoyuki HIROSE wrote: This patch set aims to support unaligned access to xHCI Capability Registers. To achieve this, we introduce the emulation of an unaligned access through multiple aligned accesses. This patch set also adds a test device and several tests using this device to verify that the emulation functions correctly. Using these changes, unaligned access to xHCI Capability Registers is now supported. During development, I required a lot of 'MemoryRegionOps' structs with its own read/write functions for tests. In the QEMU project, a large number of similar functions or structs are often written in '.inc' files. I followed this approach for the test functions but would appreciate feedback on whether this is appropriate. Tomoyuki HIROSE (5): hw/nvme/ctrl: specify the 'valid' field in MemoryRegionOps system/memory: support unaligned access hw/misc: add test device for memory access tests/qtest: add test for memory region access hw/usb/hcd-xhci: allow unaligned access to Capability Registers hw/misc/Kconfig |4 + hw/misc/memaccess-testdev.c | 197 +++ hw/misc/meson.build |1 + hw/nvme/ctrl.c |5 + hw/usb/hcd-xhci.c |4 +- include/hw/misc/memaccess-testdev.h | 42 + include/hw/misc/memaccess-testdev.h.inc | 1864 +++ system/memory.c | 147 +- system/physmem.c|8 - tests/qtest/memaccess-test.c| 598 tests/qtest/meson.build |9 + 11 files changed, 2842 insertions(+), 37 deletions(-) create mode 100644 hw/misc/memaccess-testdev.c create mode 100644 include/hw/misc/memaccess-testdev.h create mode 100644 include/hw/misc/memaccess-testdev.h.inc create mode 100644 tests/qtest/memaccess-test.c
Re: [PATCH v10 03/15] hw/display/apple-gfx: Adds PCI implementation
On 2024/11/13 23:23, Phil Dennis-Jordan wrote:
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.
* Smaller code review issues addressed.
v5:
* Minor error handling improvement.
v6:
* Removed an unused function parameter.
v9:
* Fixup of changed common call.
* Whitespace and comment formatting tweaks.
hw/display/Kconfig | 4 +
hw/display/apple-gfx-pci.m | 150 +
hw/display/meson.build | 1 +
3 files changed, 155 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..5a27b95ac79
--- /dev/null
+++ b/hw/display/apple-gfx-pci.m
@@ -0,0 +1,150 @@
+/*
+ * 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, 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, vector);
+};
+
+apple_gfx_common_realize(&s->common, DEVICE(dev), 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);
Re: [PATCH v10 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
On 2024/11/13 23:23, Phil Dennis-Jordan wrote: 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. Implementation wise, most of the complexity lies in the differing threading models of ParavirtualizedGraphics.framework, which uses libdispatch and internal locks, versus QEMU, which heavily uses the BQL, especially during memory-mapped device I/O. Great care has therefore been taken to prevent deadlocks by never calling into PVG methods while holding the BQL, and similarly never acquiring the BQL in a callback from PVG. Different strategies have been used (libdispatch, blocking and non-blocking BHs, RCU, etc.) depending on the specific requirements at each framework entry and exit point. 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. v6: * Switched PGTask_s's' mapped_regions from GPtrArray to GArray * Allow DisplaySurface to manage its own vram now that texture -> vram copy occurs under BQL. * Memory mapping operations now use RCU_READ_LOCK_GUARD() where possible instead of a heavy-weight BH job to acquire the BQL. * Changed PVG cursor and mode setting callbacks to kick off BHs instead of libdispatch tasks
Re: [PATCH v10 12/15] hw/vmapple/cfg: Introduce vmapple cfg region
On 2024/11/13 23:23, Phil Dennis-Jordan wrote: 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 Reviewed-by: Akihiko Odaki
Re: [PULL v4 00/10] Block layer patches
On Mon, 25 Nov 2024 at 10:06, Kevin Wolf wrote: > > The following changes since commit 6b99bb046dd36a6dd5525b8f88c2dcddae49222a: > > Merge tag 'pull-lu-20241122' of https://gitlab.com/rth7680/qemu into > staging (2024-11-24 13:39:06 +) > > are available in the Git repository at: > > https://repo.or.cz/qemu/kevin.git tags/for-upstream > > for you to fetch changes up to fbdea3d6c13d5a75895c287a004c6f1a6bf6c164: > > ssh: Do not switch session to non-blocking mode (2024-11-25 11:03:42 +0100) > > > Block layer patches > > - Fix qmp_device_add() to not throw non-scalar options away (fixes > iothread-vq-mapping being silently ignored in device_add) > - Fix qdev property crash with integer PCI addresses and JSON -device > - iotests: Fix mypy failure > - parallels: Avoid potential integer overflow > - ssh: libssh broke with non-blocking sessions, use a blocking one for now > - Fix crash in migration_is_running() > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.2 for any user-visible changes. -- PMM
