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

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:

Re: [PATCH 3/8] target/i386: return bool from x86_cpu_filter_features

[snip] > @@ -7558,7 +7558,7 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp) > * > * Returns: 0 if all flags are supported by the host, non-zero otherwise. Comment can be updated as well. :-) Returns: true if any flag is not supported by the host, false otherwise. > */ > -static

[PATCH v2] target/riscv: Fix vcompress with rvv_ta_all_1s

vcompress packs vl or less fields into vd, so the tail starts after the last packed field. This could be more clearly expressed in the ISA, but for now this thread helps to explain it: https://github.com/riscv/riscv-v-spec/issues/796 Signed-off-by: Anton Blanchard --- target/riscv/vector_helper

Re: [CAUTION - External Sender] Re: [PATCH] target/riscv: Fix vcompress with rvv_ta_all_1s

On Wed, Oct 30, 2024 at 2:09 PM Anton Blanchard wrote: > > Hi Alistair, > > On Wed, Oct 30, 2024 at 2:39 PM Alistair Francis wrote: > > > vcompress packs vl or less fields into vd, so the tail starts after the > > > last packed field. > > > > Is that right? > > > > It's different from every other

Re: [CAUTION - External Sender] Re: [PATCH] target/riscv: Fix vcompress with rvv_ta_all_1s

Hi Alistair, On Wed, Oct 30, 2024 at 2:39 PM Alistair Francis wrote: > > vcompress packs vl or less fields into vd, so the tail starts after the > > last packed field. > > Is that right? > > It's different from every other vector command. Although the wording > in the spec is very confusing It i

Re: [PATCH v3 1/3] linux-headers: Add unistd_64.h

On Wed, Oct 30, 2024 at 11:47 AM gaosong wrote: > > 在 2024/10/28 下午5:55, maobibo 写道: > > > > > > On 2024/10/28 下午3:39, gaosong wrote: > >> 在 2024/10/28 上午10:38, Bibo Mao 写道: > >>> since 6.11, unistd.h includes header file unistd_64.h directly on > >>> some platforms, here add unistd_64.h on these

Re: [PATCH v2] hw/loongarch/boot: Use warn_report when no kernel filename

On 29/10/24 22:23, Song Gao wrote: When we run “qemu-system-loongarch64 -qmp stdio -vnc none -S”, we get an error message “Need kernel filename” and then we can't use qmp cmd to query some information. So, we just throw a warning and then the cpus starts running from address VIRT_FLASH0_BASE.

Re: [PATCH] target/riscv: Fix vcompress with rvv_ta_all_1s

On Wed, Oct 30, 2024 at 11:13 AM Anton Blanchard wrote: > > vcompress packs vl or less fields into vd, so the tail starts after the > last packed field. Is that right? It's different from every other vector command. Although the wording in the spec is very confusing Alistair

[PATCH v2] ui/sdl: Mouse event optimization

Use a convergence factor to make the VM's input global coordinates more closely approach the global coordinates of host. Change-Id: I2c3f12f1fe7dfb9306d1fc40c4fd4d299937f4c6 Signed-off-by: Lei Huang --- ui/sdl2.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletion

Re: [PATCH 2/8] target/i386: do not rely on ExtSaveArea for accelerator-supported XCR0 bits

On Tue, Oct 29, 2024 at 04:18:52PM +0100, Paolo Bonzini wrote: > Date: Tue, 29 Oct 2024 16:18:52 +0100 > From: Paolo Bonzini > Subject: [PATCH 2/8] target/i386: do not rely on ExtSaveArea for > accelerator-supported XCR0 bits > X-Mailer: git-send-email 2.47.0 > > Right now, QEMU is using the "fe

Re: [PATCH v2 0/8] Add AVX10.1 CPUID support and GraniteRapids-v2 model

On Tue, Oct 29, 2024 at 04:18:50PM +0100, Paolo Bonzini wrote: > Most of the patches here are from Tao Su's v1. The main issue in his > version were two: > > - overlooking kvm_cpu_xsave_init(), which currently looks at ExtSaveArea. > This would get a bit ugly for extended save states that are e

Re: [PATCH] ui/sdl: Mouse event optimization

>On Tue, 29 Oct 2024, Lei Huang wrote: >>> On Fri, 25 Oct 2024, Lei Huang wrote: Use a convergence factor to make the VM's input global coordinates more closely approach the global coordinates of DOM0. >>> >>> Dom0 is some Xen terminology. Do you mean "host" which is more often used

Re: [PATCH v1 2/4] accel/kvm: Keep track of the HWPoisonPage page_size

On 10/28/24 17:42, David Hildenbrand wrote: On 26.10.24 01:27, William Roche wrote: On 10/23/24 09:28, David Hildenbrand wrote: On 22.10.24 23:35, “William Roche wrote: From: William Roche Add the page size information to the hwpoison_page_list elements. As the kernel doesn't always report

Re: [PATCH 4/8] target/i386: add AVX10 feature and AVX10 version property

On Tue, Oct 29, 2024 at 04:18:54PM +0100, Paolo Bonzini wrote: > From: Tao Su [ ... ] > static void max_x86_cpu_realize(DeviceState *dev, Error **errp) > { > Object *obj = OBJECT(dev); > +X86CPU *cpu = X86_CPU(dev); > +CPUX86State *env = &cpu->env; > > if (!object_property_

Re: [PATCH v2] hw/riscv: Add Microblaze V 32bit virt board

On Thu, Oct 17, 2024 at 5:26 PM Sai Pavan Boddu wrote: > > Add a basic board with interrupt controller (intc), timer, serial > (uartlite), small memory called LMB@0 (128kB) and DDR@0x8000 > (configured via command line eg. -m 2g). > This is basic configuration which matches HW generated out of

Re: [PATCH 1/8] target/i386: cpu: set correct supported XCR0 features for TCG

On Tue, Oct 29, 2024 at 04:18:51PM +0100, Paolo Bonzini wrote: > Date: Tue, 29 Oct 2024 16:18:51 +0100 > From: Paolo Bonzini > Subject: [PATCH 1/8] target/i386: cpu: set correct supported XCR0 features > for TCG > X-Mailer: git-send-email 2.47.0 > > Signed-off-by: Paolo Bonzini > --- > target/

Re: [PATCH RFC 2/2] migration: Avoid doing RAMBlock dirty sync in the initial iteration

On Wed, Oct 30, 2024 at 12:21 AM Peter Xu wrote: > On Wed, Oct 23, 2024 at 10:09:51AM +0800, yong.hu...@smartx.com wrote: > > From: Hyman Huang > > > > KVM always returns 1 when userspace retrieves a dirty bitmap for > > the first time when KVM_DIRTY_LOG_INITIALLY_SET is enabled; in such > > sce

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

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 s

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

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

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

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 c

Re: [PATCH v2 4/4] hw/loongarch/virt: Enable cpu hotplug feature on virt machine

> > > @@ -1382,8 +1384,40 @@ static void virt_cpu_pre_plug(HotplugHandler > > > *hotplug_dev, > > >} > > > if (cpu->phy_id == UNSET_PHY_ID) { > > > -error_setg(&local_err, "CPU hotplug not supported"); > > > -goto out; > > > +if ((cpu->thread_id < 0) || (cpu->

Re: [PATCH v1 3/4] system/physmem: Largepage punch hole before reset of memory pages

On 10/28/24 18:01, David Hildenbrand wrote: On 26.10.24 01:27, William Roche wrote: On 10/23/24 09:30, David Hildenbrand wrote: On 22.10.24 23:35, “William Roche wrote: From: William Roche When the VM reboots, a memory reset is performed calling qemu_ram_remap() on all hwpoisoned pages. Whi

Re: [PATCH v2 4/4] hw/loongarch/virt: Enable cpu hotplug feature on virt machine

On 2024/10/29 下午9:48, Zhao Liu wrote: [snip] @@ -1382,8 +1384,40 @@ static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, } if (cpu->phy_id == UNSET_PHY_ID) { -error_setg(&local_err, "CPU hotplug not supported"); -goto out; +if ((cpu->thread_id

Re: [PATCH v2 2/4] hw/loongarch/virt: Implement cpu plug interface

Hi Zhao, On 2024/10/29 下午9:37, Zhao Liu wrote: (CC Igor since I want to refer his comment on hotplug design.) Hi Bibo, I have some comments about your hotplug design. [snip] +static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, + DeviceState *dev, Error

[PATCH v2] hw/loongarch/boot: Use warn_report when no kernel filename

When we run “qemu-system-loongarch64 -qmp stdio -vnc none -S”, we get an error message “Need kernel filename” and then we can't use qmp cmd to query some information. So, we just throw a warning and then the cpus starts running from address VIRT_FLASH0_BASE. Signed-off-by: Song Gao --- hw/loon

Re: [PATCH v3 1/3] linux-headers: Add unistd_64.h

在 2024/10/28 下午5:55, maobibo 写道: On 2024/10/28 下午3:39, gaosong wrote: 在 2024/10/28 上午10:38, Bibo Mao 写道: since 6.11, unistd.h includes header file unistd_64.h directly on some platforms, here add unistd_64.h on these platforms. Affected platforms are ARM64, LoongArch64 and Riscv. Otherwise th

Re: [PATCH v2 0/2] target/riscv/kvm: riscv-aia fixes

On Tue, Oct 29, 2024 at 4:21 AM Daniel Henrique Barboza wrote: > > Hi, > > In this second version we removed patches 3 and 4 from v1. The reasoning > behind is that the deprecation process is too harsh in comparison with > the user benefit from using bools instead of strings. > > We'll expose the

Re: [PATCH 0/4] target/riscv/kvm: add riscv-aia bool props

On Tue, Oct 29, 2024 at 4:01 AM Daniel Henrique Barboza wrote: > > Hi, > > I had a change of heart w.r.t this work. I still believe that the boolean > properties > are better to deal with since we don't have to deal with string parsing, and > that we > should avoid creating new string props in t

Re: [PATCH v2 1/4] hw/loongarch/virt: Add CPU topology support

Hi Zhao, Thanks for reviewing the patch. On 2024/10/29 下午9:19, Zhao Liu wrote: Hi Bibo, [snip] +In the CPU topology relationship, When we know the ``socket_id`` ``core_id`` +and ``thread_id`` of the CPU, we can calculate its ``arch_id``: + +``arch_id = (socket_id * S) + (core_id * C) + (thre

Re: [PATCH 3/4] target/riscv/kvm: add kvm-aia bools props

On Fri, Oct 11, 2024 at 9:19 PM Daniel Henrique Barboza wrote: > > > > On 10/10/24 10:57 PM, Alistair Francis wrote: > > On Tue, Sep 24, 2024 at 10:46 PM Daniel Henrique Barboza > > wrote: > >> > >> Boolean properties are preferrable in comparision to string properties > >> since they don't requi

Re: [PATCH 6/6] target/i386: Introduce GraniteRapids-v2 model

On Tue, Oct 29, 2024 at 10:58:39PM +0800, Zhao Liu wrote: > On Mon, Oct 28, 2024 at 10:45:12AM +0800, Tao Su wrote: > > Date: Mon, 28 Oct 2024 10:45:12 +0800 > > From: Tao Su > > Subject: [PATCH 6/6] target/i386: Introduce GraniteRapids-v2 model > > X-Mailer: git-send-email 2.34.1 > > > > Update

Re: [PATCH 1/1] hw/loongarch/boot: Use warn_report when no kernel filename

在 2024/10/30 上午3:48, Philippe Mathieu-Daudé 写道: On 29/10/24 06:35, Song Gao wrote: When we run “qemu-system-loongarch64 -qmp stdio -vnc none -S”, we get an error message “Need kernel filename” and then we can't use qmp cmd to query some information. So, we just throw a warning and then the cpus

Re: [PATCH v10 00/12] riscv: QEMU RISC-V IOMMU support

On Thu, Oct 17, 2024 at 6:41 AM Daniel Henrique Barboza wrote: > > Hi, > > In this new version we fixed address alignment issues in some command > queue commands, pointed out by Jason in v9. > > No other changes made. Series based on alistair/riscv-to-apply.next. > > All patches reviewed. > > Chan

[PATCH] target/riscv: Fix vcompress with rvv_ta_all_1s

vcompress packs vl or less fields into vd, so the tail starts after the last packed field. Signed-off-by: Anton Blanchard --- target/riscv/vector_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c index 072bd44

[PATCH V3] crypto: Introduce SM3 hash hmac pbkdf algorithm

Introduce the SM3 cryptographic hash algorithm (GB/T 32905-2016). SM3 (GB/T 32905-2016) is a cryptographic standard issued by the Organization of State Commercial Cryptography Administration (OSCCA) as an authorized cryptographic algorithm for use within China. Detect the SM3 cryptographic hash a

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

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

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

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 > desi

Re: [PATCH] tests/tcg: Do not use inttypes.h in multiarch/system/memory.c

On Thu, 2024-10-10 at 11:20 +0200, Paolo Bonzini wrote: > On 10/10/24 10:58, Ilya Leoshkevich wrote: > > make check-tcg fails on Fedora with the following error message: > > > > alpha-linux-gnu-gcc [...] > > qemu/tests/tcg/multiarch/system/memory.c -o memory [...] > > qemu/tests/tcg/mult

[PATCH v3 1/2] linux-user: Allow custom rt signal mappings

Some applications want to use low priority realtime signals (e.g., SIGRTMAX). Currently QEMU cannot map all target realtime signals to host realtime signals, and chooses to sacrifice the end of the target realtime signal range. Allow users to choose how to map target realtime signals to host realt

[PATCH v3 0/2] linux-user: Allow mapping low priority rt signals

v1: Unfortunately lost. v2: https://lore.kernel.org/qemu-devel/20240212205022.242968-1-...@linux.ibm.com/ v2 -> v3: Make the mapping configurable (Richard). Hi, There are apps out there that want to use SIGRTMAX, which linux-user currently does not map to a host signal. The reason is that with

[PATCH v3 2/2] tests/tcg: Add SIGRTMIN/SIGRTMAX test

Test the lowest and the highest real-time signals. This requires configuring the real-time signal mapping, and therefore some knowledge about the host. To this end, pass the emulator path in the QEMU environment variable to all tests (this should not disturb the existing ones), and assume that all

[PATCH RFC v2 2/7] qom: TYPE_SINGLETON interface

This patch introduces a new QOM interface called SINGLETON. The singleton interface declares an object class which can only create one instance globally. Backgrounds / Use Cases === There can be some existing classes that can start to benefit from it. One example is vIOMMU i

[PATCH RFC v2 5/7] x86/iommu: Make x86-iommu a singleton object

X86 IOMMUs cannot be created more than one on a system yet. Make it a singleton so it guards the system from accidentally create yet another IOMMU object when one already presents. Now if someone tries to create more than one, e.g., via: ./qemu -M q35 -device intel-iommu -device intel-iommu T

[PATCH RFC v2 7/7] migration: Reset current_migration properly

current_migration is never reset, even if the migration object is freed already. It means anyone references that can trigger UAF and it'll be hard to debug. Properly clear the pointer now. So far the only place to do is via its own finalize(), which means QEMU is releasing the last refcount and

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

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 r

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

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 dev

Re: [PATCH 0/4] Trivial patches from multifd device state transfer support patch set

On 29.10.2024 21:40, Peter Xu wrote: On Tue, Oct 29, 2024 at 03:58:12PM +0100, Maciej S. Szmigiero wrote: From: "Maciej S. Szmigiero" A new version of the multifd device state transfer support with VFIO consumer patch set is being prepared, the previous version and the associated discussion is

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

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 dur

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

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 RFC v2 6/7] migration: Make migration object a singleton object

This makes the migration object a singleton unit. After this, we can do something slightly tricky later on with the guarantee that nobody will be able to create the object twice. Signed-off-by: Peter Xu --- migration/migration.c | 13 + 1 file changed, 13 insertions(+) diff --git a

[PATCH RFC v2 4/7] qdev: Make qdev_get_machine() safe before machine creates

qdev_get_machine() is the helper that QEMU heavily uses in most places to fetch the current machine object after it's created. It can only be called after the machine is created as of now, otherwise a container can be wrongly created at path "/machine", and that could crash QEMU later. It's not a

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

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 Mo

[PATCH RFC v2 3/7] qdev: Make device_set_realized() be fully prepared with !machine

We're going to enable qdev_get_machine() to work even before machine is created. Make device_set_realized() be prepared with it. Currently, a device can be realized even before machine is created, but only in one of QEMU's qtest, test-global-qdev-props.c. Right now, the test_static_prop_subproce

[PATCH RFC v2 0/7] QOM: Singleton interface

v1: https://lore.kernel.org/r/20241024165627.1372621-1-pet...@redhat.com This patchset introduces the singleton interface for QOM. I didn't add a changelog because there're quite a few changes here and there, plus new patches. So it might just be easier to re-read, considering the patchset isn't

[PATCH RFC v2 1/7] qom: Track dynamic initiations of random object class

Add a helper object_new_allowed(), use it to track all the places in QEMU where a new (and especially, random) object can be created. Currently, it is some form of a cleanup, just to put together all the errors where QEMU wants to avoid instantiations of abstract classes. The follow up patch will

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

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

Re: [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers

On Tue, Oct 29, 2024 at 09:46:01PM +0100, Maciej S. Szmigiero wrote: > On 29.10.2024 21:35, Peter Xu wrote: > > On Tue, Oct 29, 2024 at 03:58:16PM +0100, Maciej S. Szmigiero wrote: > > > From: "Maciej S. Szmigiero" > > > > > > Some of these SaveVMHandlers were missing the BQL behavior annotation,

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

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

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

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: * Th

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

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.

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

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 Revie

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

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 ca

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

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

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

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", "di

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

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 +++---

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

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 --- MAINTAIN

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

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 c

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

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-Jo

Re: [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers

On Tue, Oct 29, 2024 at 03:58:16PM +0100, Maciej S. Szmigiero wrote: > From: "Maciej S. Szmigiero" > > Some of these SaveVMHandlers were missing the BQL behavior annotation, > making people wonder what it exactly is. > > Signed-off-by: Maciej S. Szmigiero > --- > include/migration/register.h |

Re: [PATCH 0/4] Trivial patches from multifd device state transfer support patch set

On Tue, Oct 29, 2024 at 03:58:12PM +0100, Maciej S. Szmigiero wrote: > From: "Maciej S. Szmigiero" > > A new version of the multifd device state transfer support with VFIO consumer > patch set is being prepared, the previous version and the associated > discussion is available here: > https://lor

Re: [PATCH 1/1] target/arm: Add cortex-m0+ support

Hi Peter, >On Tue, 22 Oct 2024 at 21:34, Matthieu Castet wrote: >> >> Signed-off-by: Matthieu Castet > >Hi; thanks for this patch. I have some initial code review comments, >but the change looks broadly correct to me and I don't think >there's anything obvious missing. > >The commit message body

Re: [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers

On 29.10.2024 21:35, Peter Xu wrote: On Tue, Oct 29, 2024 at 03:58:16PM +0100, Maciej S. Szmigiero wrote: From: "Maciej S. Szmigiero" Some of these SaveVMHandlers were missing the BQL behavior annotation, making people wonder what it exactly is. Signed-off-by: Maciej S. Szmigiero --- inclu

Re: [PATCH v3 0/8] Migration: Make misc.h helpers available for whole VM lifecycle

On Thu, Oct 24, 2024 at 05:30:48PM -0400, Peter Xu wrote: > Based-on: <20241024165627.1372621-1-pet...@redhat.com> > CI: https://gitlab.com/peterx/qemu/-/pipelines/1511349805 > > This is a follow up of below patch from Avihai as a replacement: > > https://lore.kernel.org/qemu-devel/20241020

Re: [PATCH] target/hppa: Add CPU reset method

On 10/29/24 13:44, Peter Maydell wrote: On Fri, 25 Oct 2024 at 19:25, Helge Deller wrote: Add the missing CPU reset method, which resets all CPU registers and the TLB to zero. Then the CPU will switch to 32-bit mode (PSW_W bit is not set) and start execution at address 0xf004. Signed-off-

[RFC v4 0/2] target/riscv: add wrapper for target specific macros in atomicity check.

The version 4 of the patch wraps the host specific macros used to check the support for atomic 128 bit memory operations into generic macros. The patch also adjusts the indentation of the if/else clauses and the comment about the above mentioned check for atomic 128b load/store to reflect better th

Re: [PATCH v4 2/9] hw/core: Make CPU topology enumeration arch-agnostic

On 22/10/24 10:51, Zhao Liu wrote: Cache topology needs to be defined based on CPU topology levels. Thus, define CPU topology enumeration in qapi/machine.json to make it generic for all architectures. To match the general topology naming style, rename CPU_TOPO_LEVEL_* to CPU_TOPOLOGY_LEVEL_*, an

Re: [PATCH 7/8] target/i386: Add AVX512 state when AVX10 is supported

On Tue, Oct 29, 2024 at 4:19 PM Paolo Bonzini wrote: > > From: Tao Su > > AVX10 state enumeration in CPUID leaf D and enabling in XCR0 register > are identical to AVX512 state regardless of the supported vector lengths. > > Given that some E-cores will support AVX10 but not support AVX512, add >

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

Hi Paolo, On Wed, Oct 30, 2024 at 1:32 AM 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,

Re: [PATCH v2 1/1] virtio-pci: fix memory_region_find for VirtIOPCIRegion's MR

On Wed, Oct 09, 2024 at 05:58:27PM +0800, Gao Shiyuan wrote: > As shown below, if a virtio PCI device is attached under a pci-bridge, the MR > of VirtIOPCIRegion does not belong to any address space. So memory_region_find > cannot be used to search for this MR. > > Introduce the virtio-pci and pci

Re: [PATCH 2/5] qom: use object_new_with_class when possible

On 29/10/24 09:26, Paolo Bonzini wrote: A small optimization/code simplification, that also makes it clear that we won't look for a type in a not-loaded-yet module---the module will have been loaded by a call to module_object_class_by_name(), if present. Signed-off-by: Paolo Bonzini --- hw/co

Re: [PATCH 1/1] hw/loongarch/boot: Use warn_report when no kernel filename

On 29/10/24 06:35, Song Gao wrote: When we run “qemu-system-loongarch64 -qmp stdio -vnc none -S”, we get an error message “Need kernel filename” and then we can't use qmp cmd to query some information. So, we just throw a warning and then the cpus starts running from address VIRT_FLASH0_BASE.

Re: [PATCH v6 6/7] target/riscv: rvv: Provide group continuous ld/st flow for unit-stride ld/st instructions

On 9/18/24 2:14 PM, Max Chou wrote: The vector unmasked unit-stride and whole register load/store instructions will load/store continuous memory. If the endian of both the host and guest architecture are the same, then we can group the element load/store to load/store more data at a time. Sig

[RFC v4 2/2] target/riscv: rvv: improve performance of RISC-V vector loads and stores on large amounts of data.

This patch optimizes the emulation of unit-stride load/store RVV instructions when the data being loaded/stored per iteration amounts to 16 bytes or more. The optimization consists of calling __builtin_memcpy on chunks of data of 16 bytes between the memory address of the simulated vector register

[RFC v4 1/2] target/riscv: rvv: reduce the overhead for simple RISC-V vector unit-stride loads and stores

This patch improves the performance of the emulation of the RVV unit-stride loads and stores in the following cases: - when the data being loaded/stored per iteration amounts to 8 bytes or less. - when the vector length is 16 bytes (VLEN=128) and there's no grouping of the vector registers (LMUL

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

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. Thanks! Gentle ping. This patch series has been revi

Re: [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers

"Maciej S. Szmigiero" writes: > From: "Maciej S. Szmigiero" > > Some of these SaveVMHandlers were missing the BQL behavior annotation, > making people wonder what it exactly is. > > Signed-off-by: Maciej S. Szmigiero Reviewed-by: Fabiano Rosas

Re: [PATCH 2/4] migration/ram: Add load start trace event

"Maciej S. Szmigiero" writes: > From: "Maciej S. Szmigiero" > > There's a RAM load complete trace event but there wasn't its start equivalent. > > Signed-off-by: Maciej S. Szmigiero Reviewed-by: Fabiano Rosas

Re: [PATCH v3 5/8] migration: Drop migration_is_idle()

Peter Xu writes: > Now with the current migration_is_running(), it will report exactly the > opposite of what will be reported by migration_is_idle(). > > Drop migration_is_idle(), instead use "!migration_is_running()" which > should be identical on functionality. > > In reality, most of the idle

Re: [PATCH v3 4/8] migration: Drop migration_is_setup_or_active()

Peter Xu writes: > This helper is mostly the same as migration_is_running(), except that one > has COLO reported as true, the other has CANCELLING reported as true. > > Per my past years experience on the state changes, none of them should > matter. > > To make it slightly safer, report both COLO

Re: [PATCH v6 1/7] target/riscv: Set vdata.vm field for vector load/store whole register instructions

On 9/18/24 2:14 PM, Max Chou wrote: The vm field of the vector load/store whole register instruction's encoding is 1. The helper function of the vector load/store whole register instructions may need the vdata.vm field to do some optimizations. Signed-off-by: Max Chou --- I wonder if we sh

Re: [PATCH v6 2/7] target/riscv: rvv: Replace VSTART_CHECK_EARLY_EXIT in vext_ldst_us

On 9/18/24 2:14 PM, Max Chou wrote: Because the real vl (evl) of vext_ldst_us may be different (e.g. vlm.v/vsm.v/etc.), so the VSTART_CHECK_EARLY_EXIT checking function should be replaced by checking evl in vext_ldst_us. Signed-off-by: Max Chou --- Reviewed-by: Daniel Henrique Barboza

Re: [PATCH v3 1/8] migration: Take migration object refcount earlier for threads

Peter Xu writes: > Both migration thread or background snapshot thread will take a refcount of > the migration object at the entrace of the thread function. > > That makes sense, because it protects the object from being freed by the > main thread in migration_shutdown() later, but it might still

Re: [PATCH v3 3/8] migration: Unexport ram_mig_init()

Peter Xu writes: > It's only used within migration/. > > Signed-off-by: Peter Xu > --- > include/migration/misc.h | 1 - > migration/ram.h | 1 + > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/migration/misc.h b/include/migration/misc.h > index df57be6b5e..e8

Re: [PATCH v3 2/8] migration: Unexport dirty_bitmap_mig_init()

Peter Xu writes: > It's only used within migration/, so it shouldn't be exported. > > Reviewed-by: Cédric Le Goater > Signed-off-by: Peter Xu > --- > include/migration/misc.h | 3 --- > migration/migration.h| 4 > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/inclu

Re: [PATCH 2/2] tests/functional: Add a test for sh4eb

On 29/10/2024 18.58, Rob Landley wrote: On 10/24/24 03:27, Thomas Huth wrote: Now that we are aware of binaries that are available for sh4eb, we should make sure that there are no regressions with this target and test it regularly in our CI. Any progress on restoring this? Didn't see it in "gi

Re: [PATCH 1/2] Revert "Remove the unused sh4eb target"

On 25/10/2024 18.09, Rob Landley wrote: On 10/24/24 03:27, Thomas Huth wrote: This reverts commit 73ceb12960e686b763415f0880cc5171ccce01cf. The "r2d" machine can work in big endian mode, see:   https://lore.kernel.org/qemu-devel/ d6755445-1060-48a8-82b6-2f392c21f...@landley.net/ So the reas

Re: [PATCH] scripts: remove erroneous file that breaks git clone on Windows

On 10/23/24 00:39, Pierrick Bouvier wrote: This file was created by mistake in recent ed7667188 (9p: remove 'proxy' filesystem backend driver). When cloning the repository using native git for windows, we see this: Error: error: invalid path 'scripts/meson-buildoptions.' Error: The process 'C:\P

Re: [PATCH 2/2] tests/functional: Add a test for sh4eb

On 10/24/24 03:27, Thomas Huth wrote: Now that we are aware of binaries that are available for sh4eb, we should make sure that there are no regressions with this target and test it regularly in our CI. Any progress on restoring this? Didn't see it in "git pull" just now... +class R2dEBTest(Li

Re: [PATCH 00/36] next-cube: more tidy-ups and improvements

On 29/10/2024 11:22, Peter Maydell wrote: On Wed, 23 Oct 2024 at 09:59, Mark Cave-Ayland wrote: This series contains a number of tidy-ups and improvements to the NeXTCube machine which include: - Bringing the code up-to-date with our latest coding standards/APIs, in particular rela

  1   2   3   >