Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 26.03.25 13:27, Gerd Hoffman wrote: Hi, The problem is that add-ons are 1) Separate binaries. So you need to match multiple files. 2) In this case, get generated out of the vendor (RH)'s control in a one-off fashion. I don't think "signing" is the correct way to address the latt

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

Hey Gerd, On 18.03.25 12:11, Gerd Hoffman wrote: Hi, Maybe not from the user's point of view, but surely for the vmfwupdate interface design and for the launch measurement calculations. When using igvm parameters for the kernel hashes we need to pass on (at least) two items via vmfwupdate

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 24.03.25 18:53, Gerd Hoffman wrote: On Mon, Mar 24, 2025 at 05:31:30PM +0100, Alexander Graf wrote: What does all this mean for the hypervisor interface ? That means we'll go scratch the region list idea and depend on igvm instead. Which means we are back to the single firmware image

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 24.03.25 16:48, Gerd Hoffman wrote: On Mon, Mar 24, 2025 at 04:42:28PM +0530, Ani Sinha wrote: On Mon, Mar 24, 2025 at 1:13 PM Gerd Hoffman wrote: Hi, Going ship the distro kernel as igvm image would work too. Will simplify the measurement pre-calculation. Also there is no need to

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 21.03.25 04:36, Ani Sinha wrote: On Thu, Mar 20, 2025 at 7:24 PM Alexander Graf wrote: Hey Gerd, On 18.03.25 12:11, Gerd Hoffman wrote: Hi, Maybe not from the user's point of view, but surely for the vmfwupdate interface design and for the launch measurement calculations.

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 17.03.25 10:56, Gerd Hoffman wrote: On Fri, Mar 14, 2025 at 03:50:19PM +0100, Alexander Graf wrote: On 14.03.25 15:08, Gerd Hoffman wrote: Hi, Ok, assuming we allow the guest submit a IGVM image (which makes sense indeed, otherwise we'll probably end up re-inventing IGVM). How

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 14.03.25 15:08, Gerd Hoffman wrote: Hi, Ok, assuming we allow the guest submit a IGVM image (which makes sense indeed, otherwise we'll probably end up re-inventing IGVM). How will the kernel hashes be handled then? I assume they will not be part of the igvm image, but they must be par

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 14.03.25 12:27, Gerd Hoffman wrote: Hi, Open question is what we do about IGVM. One option would be the guest vmfwupdate tool loading and parsing igvm, preparing the region list, then invoke the update. Problem is that some igvm feaures such as initial register state can not be easily

Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

Hi Jörg, On 13.03.25 16:39, Jörg Rödel wrote: On Thu, Mar 13, 2025 at 08:23:44PM +0530, Ani Sinha wrote: Note that even with this approach where the hypervisor *thinks* it's dealing with a real firmware, you can imagine a small rust based firmware image that is loaded by the guest in the firmwa

Re: [PATCH v5] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 14.02.25 16:35, Ani Sinha wrote: On Mon, Feb 3, 2025 at 3:50 AM Alexander Graf wrote: Hey Ani! On 28.01.25 22:31, Ani Sinha wrote: [...] diff --git a/hw/core/machine.c b/hw/core/machine.c index c23b399496..0eaf8aa3ba 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -34,6

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 14.02.25 12:16, Gerd Hoffmann wrote: On Fri, Feb 14, 2025 at 10:51:17AM +0100, Alexander Graf wrote: I also like to have dedicated register spaces per component. So even if you choose to make it a hard split, I think we're better off with 4k at 0xfef1 for control and 64k at 0xfef

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 14.02.25 08:55, Gerd Hoffmann wrote: Hi, How do your patches pick the transfer mode? Is that dictated by the host? Or is the guest free to choose? In case of the latter: How does the guest decide what to do? In our version, the guest gets to pick. It defaults to the DMA interface u

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 13.02.25 15:54, Gerd Hoffmann wrote: On Thu, Feb 13, 2025 at 11:14:03AM +0100, Alexander Graf wrote: I don't think so. The firmware driver knows this actually is normal ram and can setup mappings and memory attributes accordingly. The situation is a bit different from vga memory

[PATCH] hw/virtio/virtio-nsm: Respond with correct length

instead. Fixes: bb154e3e0cc715 ("device/virtio-nsm: Support for Nitro Secure Module device") Reported-by: Vikrant Garg Signed-off-by: Alexander Graf --- hw/virtio/virtio-nsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/virtio/virtio-nsm.c b/hw/virtio/virtio-n

Re: [Qemu Nitro Enclave] NSM virtio attestation response is always of size 0x3000

Hi Vikrant, On 13.02.25 11:01, Vikrant Garg wrote: Hello All, I am using the QEMU for emulating nitro enclave images. In my enclave image, I have an attestation service implemented in Rust. This application fetches attestations using IOCTL command. I have noticed that response from the nsm

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 13.02.25 10:28, Ard Biesheuvel wrote: On Wed, 12 Feb 2025 at 22:26, Alexander Graf wrote: On 12.02.25 16:18, Gerd Hoffmann wrote: Hi, Yes. Knowing both physical and virtual address works only for memory you allocated yourself before ExitBootServices. So you can't pass on poi

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 13.02.25 10:52, Gerd Hoffmann wrote: Hi, That will bring back all issues with cached vs non-cached memory accesses, no? So edk2 will always access that memory as device memory which means it bypasses the cache, while QEMU will access it through the cache. So that buffer would need to ac

Re: [PATCH v3 00/23] hw/uefi: add uefi variable service

On 13.02.25 10:41, Ard Biesheuvel wrote: On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann wrote: This patch adds a virtual device to qemu which the uefi firmware can use to store variables. This moves the UEFI variable management from privileged guest code (managing vars in pflash) to the host.

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 12.02.25 16:18, Gerd Hoffmann wrote: Hi, Yes. Knowing both physical and virtual address works only for memory you allocated yourself before ExitBootServices. So you can't pass on pointers from the OS, you have to copy the data to a buffer where you know the physical address instead.

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 12.02.25 13:28, Gerd Hoffmann wrote: On Wed, Feb 12, 2025 at 12:30:20PM +0100, Alexander Graf wrote: On 12.02.25 11:24, Gerd Hoffmann wrote: Why do you use confidential computing in the first place if you trust the host with your EFI variables? I'd rather see something simliar ru

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 12.02.25 11:24, Gerd Hoffmann wrote: Hi, +/* read header */ +dma_memory_read(&address_space_memory, dma, +uv->buffer, sizeof(*mhdr), +MEMTXATTRS_UNSPECIFIED); Depending on DMA sounds appealing at first, but can fall apart in corner cases.

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

On 11.02.25 10:23, Gerd Hoffmann wrote: This is the core code for guest <-> host communication. This accepts request messages from the guest, dispatches them to the service called, and sends back the response message. Signed-off-by: Gerd Hoffmann --- hw/uefi/var-service-core.c | 237 ++

Re: [PATCH v5] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

Hey Ani! On 28.01.25 22:31, Ani Sinha wrote: VM firmware update is a mechanism where the virtual machines can use their preferred and trusted firmware image in their execution environment without having to depend on a untrusted party to provide the firmware bundle. This is particularly useful fo

Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE

eviewed-by: Alexander Graf Alex

Re: [PATCH v2] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 20.12.24 14:31, Ani Sinha wrote: On Fri, Dec 20, 2024 at 5:03 PM Alexander Graf wrote: On 20.12.24 11:00, Ani Sinha wrote: Either add the I386 dependency or don't use PC_MACHINE, because on non-x86 targets PC_MACHINE(qdev_get_machine()) will crash. Ah this is where we have a disco

Re: [PATCH v2] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

On 20.12.24 11:00, Ani Sinha wrote: Either add the I386 dependency or don't use PC_MACHINE, because on non-x86 targets PC_MACHINE(qdev_get_machine()) will crash. Ah this is where we have a disconnect. I assumed that pcms = PC_MACHINE(m_obj) would return NULL on non-x86. Seems a better way to

[PATCH 1/1] docs/nitro-enclave: Clarify Enclave and Firecracker relationship

The documentation says that Nitro Enclaves are based on Firecracker. AWS has never made that statement. This patch nudges the wording to instead say it "looks like a Firecracker microvm". Signed-off-by: Alexander Graf --- docs/system/i386/nitro-enclave.rst | 2 +- 1 file changed, 1

Re: [PATCH 02/11] arm/hvf: Initialise GICv3 state just before first vCPU run

for the first time, the GIC will definitely be fully initialised at that point. Signed-off-by: Phil Dennis-Jordan Reviewed-by: Alexander Graf Alex

Re: [PATCH 01/11] hvf: Add facility for initialisation code prior to first vCPU run

such architecture-specific initialisation. Signed-off-by: Phil Dennis-Jordan Reviewed-by: Alexander Graf Alex

Re: [PATCH] docs/nitro-enclave: Fix terminal commands formatting

On 09.11.24 13:28, Dorjoy Chowdhury wrote: Signed-off-by: Dorjoy Chowdhury (nit: Please make sure to always have a patch description in the body of the patch, even if it feels like the subject says it all) Reviewed-by: Alexander Graf Alex Amazon Web Services Development Center

Re: [PATCH] eif: Use stateful qcrypto apis

update the hashes inline in the read_eif_* functions which makes the code much simpler. Signed-off-by: Dorjoy Chowdhury Reviewed-by: Alexander Graf Alex Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss

Re: [PATCH] device/virtio-nsm: Support string data for extendPCR

On 09.11.24 13:32, Dorjoy Chowdhury wrote: NSM device in AWS Nitro Enclaves supports extending with both bytestring and string data. Signed-off-by: Dorjoy Chowdhury Reviewed-by: Alexander Graf Alex --- hw/virtio/virtio-nsm.c | 21 ++--- 1 file changed, 14 insertions

Re: [PATCH] docs: Document that hvf on Arm is supported

> Am 27.11.2024 um 07:15 schrieb Akihiko Odaki : > > hvf on Arm is supported since commit a1477da3ddeb ("hvf: Add Apple > Silicon support"). > > Signed-off-by: Akihiko Odaki Reviewed-by: Alexander Graf Alex > --- > docs/about/build-platforms.rst |

Re: [PATCH] device/virtio-nsm: Support string data for extendPCR

Hey Dorjoy, On 12.11.24 13:32, Dorjoy Chowdhury wrote: Hey Alex, On Tue, Nov 12, 2024, 6:14 PM Alexander Graf wrote: Hey Dorjoy, Thanks a lot for the patch! Would you mind to send to the ML so it can go through the normal review + apply cycle? :) Same comment for the

Re: [Stable-7.2.15 17/33] target/i386: Walk NPT in guest real mode

Hey Michael, Does this queue also include the fix for the fix ("target/i386: Fix legacy page table walk")? https://lore.kernel.org/qemu-devel/20241106154329.67218-1-g...@amazon.com/ Alex On 09.11.24 07:38, Michael Tokarev wrote: From: Alexander Graf When translating virtual t

Re: [PATCH] device/virtio-nsm: Support string data for extendPCR

Hey Dorjoy, Thanks a lot for the patch! Would you mind to send to the ML so it can go through the normal review + apply cycle? :) Same comment for the other patches. Alex On 09.11.24 13:32, Dorjoy Chowdhury wrote: NSM device in AWS Nitro Enclaves supports extending with both bytestring and

[PATCH] target/i386: Fix legacy page table walk

es whether paging is active at all and uses that to determine whether we are in real mode or not. Cc: qemu-sta...@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2654 Fixes: b56617bbcb4 ("target/i386: Walk NPT in guest real mode") Signed-off-by: Alexander Graf Reported-

Re: [PATCH v3] target-i386: Walk NPT in guest real mode

Hey Mark, On 05.11.24 23:54, Mark Cave-Ayland wrote: Hi Alex, This commit appears to break my WinXP boot test: with this patch applied, attempting to boot WinXP from CDROM fails with SeaBIOS getting stuck early in a boot loop. It is possible to reproduce the issue easily with:   ./build/qe

Re: QEMU Nitro Enclave Emulation on macOS

Hi Payton, On 05.11.24 18:31, Payton Garland wrote: Hello all, I have been watching the Nitro Enclave Emulation patch . This would be a huge win for developer experience in Nitro Enclave de

Re: [PULL 23/49] hw/core: Add Enclave Image Format (EIF) related helpers

Hi Dorjoy, On 05.11.24 14:56, Dorjoy Chowdhury wrote: On Tue, Nov 5, 2024 at 6:51 PM Paolo Bonzini wrote: On Tue, Nov 5, 2024 at 12:44 PM Peter Maydell wrote: Hi; Coverity raises a couple of potential issues with the read_eif_file() function in this commit, which are both "Coverity assumes

Re: [PATCH v8 0/6] AWS Nitro Enclave emulation support

Hey Paolo, On 29.10.24 20:32, Paolo Bonzini wrote: On 10/23/24 16:27, Dorjoy Chowdhury wrote: On Wed, Oct 16, 2024 at 7:58 PM Dorjoy Chowdhury wrote: Ping This patch series has been reviewed by Alex. I am not sure if it needs more review. If not, maybe this can be picked up for merging. Th

Re: [PATCH v8 0/6] AWS Nitro Enclave emulation support

well. This is a patch series adding AWS Nitro Enclave[1] emulation support in QEMU. Alexander Graf is mentoring me on this work. I have a gitlab branch where you can view the patches in the gitlab web UI for each commit: https://gitlab.com/dorjoy03/qemu/-/tree/nitro-enclave-emulation AWS nitro enclav

[PATCH v3] target-i386: Walk NPT in guest real mode

stays and we successfully walk the NPT in real mode. Fixes: fe441054bb3f0 ("target-i386: Add NPT support") Signed-off-by: Alexander Graf Reported-by: Eduard Vlad Reviewed-by: Richard Henderson --- v1 -> v2: - Remove hack where we fake a PTE and instead just set the corresponding re

[PATCH v2] target-i386: Walk NPT in guest real mode

stays and we successfully walk the NPT in real mode. Fixes: fe441054bb3f0 ("target-i386: Add NPT support") Signed-off-by: Alexander Graf Reported-by: Eduard Vlad --- v1 -> v2: - Remove hack where we fake a PTE and instead just set the corresponding resolved variables and jump straig

Re: vm events, userspace, the vmgenid driver, and the future [was: the uevent revert thread]

On 19.09.24 00:27, Jason A. Donenfeld wrote: [broadened subject line and added relevant parties to cc list] On Tue, Sep 17, 2024 at 10:55:20PM +0200, Alexander Graf wrote: What is still open are user space applications that require event based notification on VM clone events - and *only* VM

[PATCH] target-i386: Walk NPT in guest real mode

stays and we successfully walk the NPT in real mode. Fixes: fe441054bb3f0 ("target-i386: Add NPT support") Signed-off-by: Alexander Graf Reported-by: Eduard Vlad --- target/i386/tcg/sysemu/excp_helper.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/

Re: [PATCH v4 4/6] machine/nitro-enclave: Add built-in Nitro Secure Module device

On 19.08.24 17:28, Dorjoy Chowdhury wrote: Hey Alex, On Mon, Aug 19, 2024 at 4:13 PM Alexander Graf wrote: Hey Dorjoy, On 18.08.24 13:42, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like

Re: [PATCH v4 4/6] machine/nitro-enclave: Add built-in Nitro Secure Module device

Hey Dorjoy, On 18.08.24 13:42, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like attestation. This commit adds the built-in NSM device in the nitro-enclave machine type. In Nitro Enclaves, all the PCR

Re: [PATCH v4 3/6] device/virtio-nsm: Support for Nitro Secure Module device

On 18.08.24 13:42, Dorjoy Chowdhury wrote: Nitro Secure Module (NSM)[1] device is used in AWS Nitro Enclaves for stripped down TPM functionality like cryptographic attestation. The requests to and responses from NSM device are CBOR[2] encoded. This commit adds support for NSM device in QEMU. Al

Re: [PATCH v3 2/5] machine/nitro-enclave: Add vhost-user-vsock device

On 13.08.24 20:02, Dorjoy Chowdhury wrote: On Mon, Aug 12, 2024 at 8:24 PM Daniel P. Berrangé wrote: On Sat, Aug 10, 2024 at 10:44:59PM +0600, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in vhost-vsock device support which enables applications in enclave VMs to communicate with the

Re: [PATCH v3 4/5] machine/nitro-enclave: Add built-in Nitro Secure Module device

On 10.08.24 18:45, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like attestation. This commit adds the built-in NSM device in the nitro-enclave machine type. In Nitro Enclaves, all the PCRs start in a

Re: [PATCH v3 3/5] device/virtio-nsm: Support for Nitro Secure Module device

On 10.08.24 18:45, Dorjoy Chowdhury wrote: Nitro Secure Module (NSM)[1] device is used in AWS Nitro Enclaves for stripped down TPM functionality like cryptographic attestation. The requests to and responses from NSM device are CBOR[2] encoded. This commit adds support for NSM device in QEMU. Al

Re: [PATCH v3 1/5] machine/nitro-enclave: New machine type for AWS Nitro Enclaves

On 10.08.24 18:44, Dorjoy Chowdhury wrote: AWS nitro enclaves[1] is an Amazon EC2[2] feature that allows creating isolated execution environments, called enclaves, from Amazon EC2 instances which are used for processing highly sensitive data. Enclaves have no persistent storage and no external n

Re: [PATCH v3 4/5] machine/nitro-enclave: Add built-in Nitro Secure Module device

On 10.08.24 18:45, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like attestation. This commit adds the built-in NSM device in the nitro-enclave machine type. In Nitro Enclaves, all the PCRs start in a

Re: [PATCH v3 4/5] machine/nitro-enclave: Add built-in Nitro Secure Module device

On 10.08.24 18:45, Dorjoy Chowdhury wrote: AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like attestation. This commit adds the built-in NSM device in the nitro-enclave machine type. In Nitro Enclaves, all the PCRs start in a

Re: [PATCH v2 0/2] AWS Nitro Enclave emulation

am working on adding AWS Nitro Enclave[1] emulation support in QEMU. Alexander Graf is mentoring me on this work. This is a patch series adding, not yet complete, but useful emulation support of nitro enclaves. I have a gitlab branch where you can view the patches in the gitlab web UI for each

Re: [PATCH v1 1/2] machine/microvm: support for loading EIF image

On 22.05.24 19:23, Dorjoy Chowdhury wrote: Hi Daniel, Thanks for reviewing. On Wed, May 22, 2024 at 9:32 PM Daniel P. Berrangé wrote: On Sat, May 18, 2024 at 02:07:52PM +0600, Dorjoy Chowdhury wrote: An EIF (Enclave Image Format)[1] image is used to boot an AWS nitro enclave[2] virtual machi

Re: [PATCH v1 1/2] machine/microvm: support for loading EIF image

On 27.05.24 16:52, Dorjoy Chowdhury wrote: Hi Philippe, Thank you for reviewing. On Mon, May 27, 2024 at 4:47 PM Philippe Mathieu-Daudé wrote: Hi Dorjoy, On 18/5/24 10:07, Dorjoy Chowdhury wrote: An EIF (Enclave Image Format)[1] image is used to boot an AWS nitro enclave[2] virtual machine.

Re: [PATCH] hvf: arm: Fix encodings for ID_AA64PFR1_EL1 and debug System registers

le Silicon support") Signed-off-by: Zenghui Yu Nice catch! Did you find them only because of functional issues or have you taken an automated pass somehow to validate the sysreg definitions are correct? Reviewed-by: Alexander Graf Alex

Re: Call for GSoC/Outreachy internship project ideas

/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/misc/nsm.c '''Details:''' * Skill level: intermediate - advanced (some understanding of QEMU machine modeling would be good) * Language: C * Mentor: agraf * Suggested by: Alexander Graf (OFTC: agraf, Email: g...@amazon.com) Alex

Re: [PATCH v12 04/10] hvf: Add Apple Silicon support

On 30.11.23 15:17, Philippe Mathieu-Daudé wrote: Hi, On 16/9/21 17:53, Alexander Graf wrote: With Apple Silicon available to the masses, it's a good time to add support for driving its virtualization extensions from QEMU. This patch adds all necessary architecture specific code t

Re: [PATCH 00/16] hw/uefi: add uefi variable service

Hey Gerd! On 15.11.23 16:12, Gerd Hoffmann wrote: This patch adds a virtual device to qemu which the uefi firmware can use to store variables. This moves the UEFI variable management from privileged guest code (managing vars in pflash) to the host. Main advantage is that the need to have privi

Re: [PATCH] hvf: Enable 1G page support

On 21.04.23 00:52, Alexander Graf wrote: Hvf on x86 only supported 2MiB large pages, but never bothered to strip out the 1GiB page size capability from -cpu host. With QEMU 8.0.0 this became a problem because OVMF started to use 1GiB pages by default. Let's just unconditionally add 1GiB

Re: [PATCH v2 05/11] tpm_crb: use the ISA bus

Hi Joelle, On 01.08.23 03:46, Joelle van Dyne wrote: On Tue, Jul 18, 2023 at 7:16 AM Stefan Berger wrote: On 7/17/23 09:46, Igor Mammedov wrote: On Fri, 14 Jul 2023 00:09:21 -0700 Joelle van Dyne wrote: Since this device is gated to only build for targets with the PC configuration, we sh

Re: [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc

On 31.08.23 10:53, Akihiko Odaki wrote: On 2023/08/31 17:12, Philippe Mathieu-Daudé wrote: On 30/8/23 18:14, Alexander Graf wrote: Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when bui

[PATCH v2 07/12] hw/vmapple/aes: Introduce aes engine

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 --- hw/vmapple/aes.c

[PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc

Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander

[PATCH v2 12/12] hw/vmapple/vmapple: Add vmapple machine type

OS booting successfully. Signed-off-by: Alexander Graf --- v1 -> v2: - Adapt to system_ss meson.build target - Add documentation --- MAINTAINERS | 1 + docs/system/arm/vmapple.rst | 63 docs/system/target-arm.rst | 1 + hw/vmapple/vmapple.c

[PATCH v2 00/12] Introduce new vmapple machine type

mework incompatibilities. --- v1 -> v2: - Adapt to system_ss meson.build target - Add documentation - Rework virtio-blk patch to make all vmapple virtio-blk logic subclasses - Add log message on write - Move max slot number to define - Use SPDX header - Remove useless includes

[PATCH v2 09/12] hw/vmapple/cfg: Introduce vmapple cfg region

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 --- v1 -> v2: - Adapt to system_ss meson.build target --- include/hw/vmapple/cfg.h | 68 + hw/vmapple/cf

[PATCH v2 08/12] hw/vmapple/bdif: Introduce vmapple backdoor interface

d for guest recovery and I don't understand the protocol yet. Signed-off-by: Alexander Graf --- v1 -> v2: - Adapt to system_ss meson.build target --- include/hw/vmapple/bdif.h | 31 + hw/vmapple/bdif.c | 245 ++ hw/vmapple/Kconfig

[PATCH v2 10/12] hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

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 --- v1 -> v2: - Adapt to system_ss meson.build target --- meson.build |

[PATCH v2 02/12] hw/misc/pvpanic: Add MMIO interface

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é --- v1 -> v2: - Use SPDX header - Remove

[PATCH v2 03/12] hvf: Increase number of possible memory slots

For PVG we will need more than the current 32 possible memory slots. Bump the limit to 512 instead. Signed-off-by: Alexander Graf --- v1 -> v2: - Move max slot number to define --- include/sysemu/hvf_int.h | 4 +++- accel/hvf/hvf-accel-ops.c | 2 +- 2 files changed, 4 insertions(+)

[PATCH v2 05/12] hw: Add vmapple subdir

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 --- MAINTAINERS | 6 ++ meson.build | 1 + hw/vmapple/tr

[PATCH v2 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0

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 --- v1 -> v2: - Add log mes

[PATCH v2 11/12] hw/vmapple/virtio-blk: Add support for apple virtio-blk

;vmapple-virtio-root" and "vmapple-virtio-aux". Signed-off-by: Alexander Graf --- v1 -> v2: - Rework to make all vmapple virtio-blk logic a subclass --- include/hw/pci/pci_ids.h| 1 + include/hw/virtio/virtio-blk.h | 12 +- include/hw/vmapple/virtio-blk.h |

[PATCH v2 06/12] gpex: Allow more than 4 legacy IRQs

. In this mode, GPEX will export more IRQ lines, one for each device. Signed-off-by: Alexander Graf --- include/hw/pci-host/gpex.h | 7 +++ hw/arm/sbsa-ref.c | 2 +- hw/arm/virt.c | 2 +- hw/i386/microvm.c | 2 +- hw/loongarch/virt.c| 2 +- hw/mips/loo

Re: [PATCH 12/12] hw/vmapple/vmapple: Add vmapple machine type

On 20.06.23 19:35, Bernhard Beschow wrote: Am 14. Juni 2023 22:57:34 UTC schrieb 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 differenc

Re: [PATCH 05/12] hw/virtio: Add support for apple virtio-blk

On 16.06.23 13:48, Kevin Wolf wrote: Am 15.06.2023 um 00:56 hat Alexander Graf geschrieben: 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 n

Re: [PATCH 10/12] hw/vmapple/cfg: Introduce vmapple cfg region

On 16.06.23 12:47, Philippe Mathieu-Daudé wrote: On 15/6/23 00:57, Alexander Graf wrote: 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

Re: [PATCH 09/12] hw/vmapple/bdif: Introduce vmapple backdoor interface

On 16.06.23 12:39, Philippe Mathieu-Daudé wrote: On 15/6/23 00:56, Alexander Graf wrote: 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

Re: hvf: Invalid ISV on data abort

Hi Antonio, On 02.08.23 11:43, Antonio Caggiano wrote: Hi there, I am trying to bring up a guest on HVF, which at a certain point is trying to write to an area of mmio space and it triggers a data abort where ISV=0 (translation fault level 2). I wonder what could cause it and how to recover.

Re: [PATCH 00/12] Introduce new vmapple machine type

Hi Mads, On 20.06.23 13:17, Mads Ynddal wrote: On 15 Jun 2023, at 00.40, Alexander Graf wrote: This patch set introduces a new ARM and HVF specific machine type called "vmapple". It mimicks the device model that Apple's proprietary Virtualization.Framework exposes, but i

Re: [PATCH 03/12] hvf: Increase number of possible memory slots

Hi Philippe, On 16.06.23 12:28, Philippe Mathieu-Daudé wrote: On 15/6/23 00:40, Alexander Graf wrote: For PVG we will need more than the current 32 possible memory slots. Bump the limit to 512 instead. Signed-off-by: Alexander Graf ---   accel/hvf/hvf-accel-ops.c | 2 +-   include/sysemu

[PATCH 11/12] hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

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 --- hw/vmapple/Kconfig | 3 + hw/vmapple/apple-gfx.m | 578

[PATCH 12/12] hw/vmapple/vmapple: Add vmapple machine type

ble to see macOS booting successfully. Signed-off-by: Alexander Graf --- hw/vmapple/Kconfig | 19 ++ hw/vmapple/meson.build | 1 + hw/vmapple/vmapple.c | 661 + 3 files changed, 681 insertions(+) create mode 100644 hw/vmapple/vmapple.c diff

[PATCH 08/12] hw/vmapple/aes: Introduce aes engine

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 --- hw/vmapple/Kconfig | 2 + hw/vmapple/aes.c

[PATCH 10/12] hw/vmapple/cfg: Introduce vmapple cfg region

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 --- hw/vmapple/Kconfig | 3 ++ hw/vmapple/cfg.c | 105 +++ hw/vmapple/meson.build | 1

[PATCH 07/12] gpex: Allow more than 4 legacy IRQs

. In this mode, GPEX will export more IRQ lines, one for each device. Signed-off-by: Alexander Graf --- 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

[PATCH 09/12] hw/vmapple/bdif: Introduce vmapple backdoor interface

d for guest recovery and I don't understand the protocol yet. Signed-off-by: Alexander Graf --- hw/vmapple/Kconfig| 2 + hw/vmapple/bdif.c | 245 ++ hw/vmapple/meson.build| 1 + hw/vmapple/trace-events | 5 + include/hw/vmapple/bd

[PATCH 06/12] hw: Add vmapple subdir

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 --- MAINTAINERS | 6 ++ hw/Kconfig | 1 + hw/meson.

[PATCH 05/12] hw/virtio: Add support for apple virtio-blk

o-blk-pci. When that property is set, we assume the virtio-blk device is an Apple one of the specific type and act accordingly. Signed-off-by: Alexander Graf --- hw/block/virtio-blk.c | 23 + hw/virtio/virtio-blk-pci.c | 7 +++ incl

[PATCH 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0

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 --- target/arm/hvf/hvf.c | 7 +

[PATCH 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc

Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander

[PATCH 03/12] hvf: Increase number of possible memory slots

For PVG we will need more than the current 32 possible memory slots. Bump the limit to 512 instead. Signed-off-by: Alexander Graf --- accel/hvf/hvf-accel-ops.c | 2 +- include/sysemu/hvf_int.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/accel/hvf/hvf-accel-ops.c b

[PATCH 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0

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 --- target/arm/hvf/hvf.c | 7 +

[PATCH 02/12] hw/misc/pvpanic: Add MMIO interface

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 --- hw/misc/Kconfig | 4 +++ hw/misc/meson.build | 1 + hw/misc/pvpanic-mmio.c

[PATCH 00/12] Introduce new vmapple machine type

entitlement to enable TSO Over time, I hope that some of the limitations above could cease to exist. This device model would enable very nice use cases with KVM on an Asahi Linux device. Alexander Graf (12): build: Only define OS_OBJECT_USE_OBJC with gcc hw/misc/pvpanic: Add MMIO interface

Re: [PATCH 2/3] hw/ppc/e500plat: Fix modifying QOM class internal state from instance

Hi Philippe, On 23.05.23 08:44, Philippe Mathieu-Daudé wrote: QOM object instance should not modify its class state (because all other objects instanciated from this class get affected). Instead of modifying the PPCE500MachineClass 'mpic_version' field in the instance machine_init() handler, se

  1   2   3   4   5   6   7   8   9   10   >