On 20/02/2025 22:13, Michael S. Tsirkin wrote:
> Caution: External email. Do not open attachments or click links, unless this
> email comes from a known sender and you know the content is safe.
>
>
> On Mon, Jan 20, 2025 at 05:41:32PM +, CLEMENT MATHIEU--DRIF wrote:
>> From: Clement Mathieu
Let me share my performance report after applying the patches for the
information:
1. live mlx VF migration
outgoing migration:
+--+---+---++
| VF(s) number | 1 | 2 | 4 |
+--+-
Hi Cedric,
>
> Hi Cedric,
>
> > Subject: Re: [PATCH v3 21/28] hw/misc/aspeed_hace: Fix boot issue in
> > the Crypto Manager Self Test
> >
> > On 2/13/25 04:35, Jamin Lin wrote:
> > > Currently, it does not support the CRYPT command. Instead, it only
> > > sends an interrupt to notify the firmwa
- It fix the RDMA migration broken issue
- disable RDMA + postcopy
- some cleanups
- Add a qtest for RDMA at last
Changs since V1[0]:
Add some saparate patches to refactor and cleanup based on V1
[0]
https://lore.kernel.org/qemu-devel/20250218074345.638203-1-lizhij...@fujitsu.com/
Li Zhijian (8
>-Original Message-
>From: Alex Williamson
>Subject: [PATCH 4/5] pcie, virtio: Remove redundant pm_cap
>
>The pm_cap on the PCIExpressDevice object can be distilled down
>to the new instance on the PCIDevice object.
>
>Cc: Michael S. Tsirkin
>Cc: Marcel Apfelbaum
>Signed-off-by: Alex
John Snow writes:
> On Wed, Feb 19, 2025 at 8:22 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > "The text handler you add looks just like the existing latex handler. Does
>> > LaTeX output lack "little headings", too?"
>> >
>> > Yes, almost certainly. Can you let me know which outpu
Reviewed-by: Clément Mathieu--Drif
On 19/02/2025 09:22, Zhenzhong Duan wrote:
> Caution: External email. Do not open attachments or click links, unless this
> email comes from a known sender and you know the content is safe.
>
>
> In early days vtd_ce_get_rid2pasid_entry() is used to get pasid
Em Mon, 3 Feb 2025 16:22:36 +0100
Igor Mammedov escreveu:
> On Mon, 3 Feb 2025 11:09:34 +
> Jonathan Cameron wrote:
>
> > On Fri, 31 Jan 2025 18:42:41 +0100
> > Mauro Carvalho Chehab wrote:
> >
> > > Now that the ghes preparation patches were merged, let's add support
> > > for error in
Address an error in RDMA-based migration by ensuring RDMA is prioritized
when saving pages in `ram_save_target_page()`.
Previously, the RDMA protocol's page-saving step was placed after other
protocols due to a refactoring in commit bc38dc2f5f3. This led to migration
failures characterized by unkn
Similar to migration_channels_and_transport_compatible(), introduce a
new helper migration_capabilities_and_transport_compatible() to check if
the capabilites is compatible with the transport.
Currently, only move the capabilities vs RDMA transport to this
function.
Signed-off-by: Li Zhijian
---
qemu_rdma_save_page() no longer returns RAM_SAVE_CONTROL_NOT_SUPP
since commit a4832d299dd ("migration/rdma: Check sooner if we are in postcopy
for save_page()")
Signed-off-by: Li Zhijian
---
migration/rdma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/migration/rdma.c
This qtest requires there is a RDMA(RoCE) link in the host.
In order to make the test work smoothly, introduce a
scripts/rdma-migration-helper.sh to
- setup a new Soft-RoCE(aka RXE) if it's root
- detect existing RoCE link
Test will be skipped if there is no available RoCE link.
# Start of rdma t
Refactor the page saving logic by integrating the control_save_page()
function directly into ram_save_target_page(). This change consolidates the
RDMA migration decision-making process into a single function, enhancing
clarity and maintainability.
Signed-off-by: Li Zhijian
---
migration/ram.c |
Refactor the migration control logic by eliminating the
`RAM_SAVE_CONTROL_NOT_SUPP` return value within the migration codebase.
This involves moving the checks for RDMA migration status and postcopy
state from rdma_control_save_page() to control_save_page()
With this change, control_save_page() n
Since we have disabled RDMA + postcopy, it's safe to remove
the migration_in_postcopy() that follows the migration_rdma().
Signed-off-by: Li Zhijian
---
migration/ram.c | 2 +-
migration/rdma.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/migration/ram.c b/migratio
It's believed that RDMA + postcopy-ram has been broken for a while.
Rather than spending time re-enabling it, let's simply disable it as a
trade-off.
Signed-off-by: Li Zhijian
---
migration/migration.c | 4
1 file changed, 4 insertions(+)
diff --git a/migration/migration.c b/migration/migr
Hi Eric,
>-Original Message-
>From: Eric Auger
>Subject: Re: [PATCH rfcv2 00/20] intel_iommu: Enable stage-1 translation for
>passthrough device
>
>
>Hi Zhenzhong
>
>On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
>> Hi,
>>
>> Per Jason Wang's suggestion, iommufd nesting series[1] is split into
Em Mon, 3 Feb 2025 15:34:23 +0100
Igor Mammedov escreveu:
> On Fri, 31 Jan 2025 18:42:44 +0100
> Mauro Carvalho Chehab wrote:
>
> > There are two pointers that are needed during error injection:
> >
> > 1. The start address of the CPER block to be stored;
> > 2. The address of the ack.
> >
>
Mauro Carvalho Chehab writes:
> Em Wed, 05 Feb 2025 09:16:53 +0100
> Markus Armbruster escreveu:
[...]
>> Sorry if this has been answered already... why not GPL-2.0-or-later?
>>
>> More of the same below.
>
> No particular reason. It is just that GPL-2.0 is my preferred license.
>
> I'll cha
Hi Cedric,
> Subject: Re: [PATCH v3 21/28] hw/misc/aspeed_hace: Fix boot issue in the
> Crypto Manager Self Test
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > Currently, it does not support the CRYPT command. Instead, it only
> > sends an interrupt to notify the firmware that the crypt command has
>
On 2/20/25 3:55 AM, Igor Mammedov wrote:
On Fri, 14 Feb 2025 14:16:35 +1000
Gavin Shan wrote:
The error -1 is returned if the previously reported CPER error
hasn't been claimed. The virtual machine is terminated due to
abort(). It's conflicting to the ideal behaviour that the affected
vCPU ret
Em Wed, 05 Feb 2025 09:16:53 +0100
Markus Armbruster escreveu:
> Mauro Carvalho Chehab writes:
>
> > Using the QMP GHESv2 API requires preparing a raw data array
> > containing a CPER record.
> >
> > Add a helper script with subcommands to prepare such data.
> >
> > Currently, only ARM Processo
On 2/20/2025 09:57, Michael S. Tsirkin wrote:
On Tue, Feb 11, 2025 at 10:19:23AM -0600, Konstantin Shkolnyy wrote:
Add .set_vnet_le() function that always returns success, assuming that
vDPA h/w always implements LE data format. Otherwise, QEMU disables vDPA and
outputs the message:
"backend doe
Queued in loongarch-next with title and changelog changed as follows:
target/loongarch/gdbstub: Fix gdbstub incorrectly handling some registers
Write operation with R32 (orig_a0) and R34 (CSR_BADV) is discarded on
Regards
Bibo Mao
On 2025/2/18 上午11:20, Bibo Mao wrote:
Write operation with R3
Normally, there is no need to perform firmware reconfiguration once the
virtal machine has started. Hence, currently ovmf firmware parsing happens only
once. However, if the firmware changes betweeen boots then reconfiguration needs
to happen again. Firmware can change if for example the guest brin
Uniform the removal judgement of g_hash_table_foreach_remove(), previous
name seems to perform the actual action while it just returns a Boolean.
Signed-off-by: JianChunfu
---
v2: - move smmuv3_invalidate_ste() to smmu_hash_remove_by_sid_range()
- add function smmu_configs_inv_sid_range()
v1:
SMMUTransCfg->ttb is never used in QEMU, TT base address
can be accessed by SMMUTransCfg->tt[i]->ttb.
Signed-off-by: JianChunfu
---
include/hw/arm/smmu-common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
index d1a4a6455..e5ad55b
>
> Looks good. I've queued it up on my gitlab staging tree, but
> Michael if you want to pick this one directly that's fine as well.
>
> I should be pushing out my gitlab tree shortly (bit of networking
> fun to deal with).
>
Hi, Jonathan
About qemu side, I have another question: Could the qe
On 2/21/2025 3:39 AM, David Hildenbrand wrote:
> On 20.02.25 17:13, Jean-Philippe Brucker wrote:
>> For Arm CCA we'd like the guest_memfd discard notifier to call the IOMMU
>> notifiers and create e.g. VFIO mappings. The default VFIO discard
>> notifier isn't sufficient for CCA because the DMA a
Hi Cedric,
> Cc: Troy Lee
> Subject: Re: [PATCH v3 04/28] hw/arm/aspeed: Rename IRQ table and machine
> name for AST2700 A0
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > Currently, AST2700 SoC only supports A0. To support AST2700 A1, rename
> > its IRQ table and machine name.
> >
> > Signed-off-by:
Hi Cedric,
> Subject: Re: [PATCH v3 18/28] hw/arm/aspeed: Add SoC and Machine Support
> for AST2700 A1
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > The memory map for AST2700 A1 remains compatible with AST2700 A0.
> > However, the IRQ mapping has been updated for AST2700 A1, with GIC
> > interrupt
Hi Cedric,
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > This method simplifies the process of fetching and extracting assets
> > from the Aspeed GitHub repository.
> >
> > Signed-off-by: Jamin Lin
> > ---
> > tests/functional/test_aarch64_aspeed.py | 9 +
> > 1 file changed, 5 insertion
On 20/02/2025 23:55, Peter Xu wrote:
> On Thu, Feb 20, 2025 at 05:40:38PM +0800, Li Zhijian wrote:
>> On 19/02/2025 22:11, Peter Xu wrote:
>>> then
>>> in the test it tries to detect rdma link and fetch the ip only
>> It should work without root permission if we just*detect* and*fetc
Hi Cedric,
> Subject: Re: [PATCH v3 08/28] hw/intc/aspeed: Add support for multiple output
> pins in INTC
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > Added support for multiple output pins in the INTC controller to
> > accommodate the AST2700 A1.
> >
> > Introduced "num_outpins" to represent the
On Fri, Feb 21, 2025 at 4:46 AM Michael S. Tsirkin wrote:
>
> On Thu, Feb 20, 2025 at 09:00:04PM +0100, Stefano Brivio wrote:
> > On Thu, 20 Feb 2025 13:21:33 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Feb 20, 2025 at 05:59:10PM +0100, Stefano Brivio wrote:
> > > > On Thu, 20 Feb 202
Hi Zhao,
On 2/20/2025 6:11 AM, Zhao Liu wrote:
+static const CPUCaches epyc_turin_cache_info = {
+.l1d_cache = &(CPUCacheInfo) {
+.type = DATA_CACHE,
+.level = 1,
+.size = 48 * KiB,
+.line_size = 64,
+.associativity = 12,
+.partitions = 1,
+
Hi Zhao,
On 2/20/2025 5:18 AM, Zhao Liu wrote:
On Thu, Feb 06, 2025 at 01:28:35PM -0600, Babu Moger wrote:
Date: Thu, 6 Feb 2025 13:28:35 -0600
From: Babu Moger
Subject: [PATCH v5 2/6] target/i386: Update EPYC-Rome CPU model for Cache
property, RAS, SVM feature bits
X-Mailer: git-send-email
Hi Zhao,
On 2/20/2025 6:05 AM, Zhao Liu wrote:
+static const CPUCaches epyc_genoa_v2_cache_info = {
+.l1d_cache = &(CPUCacheInfo) {
+.type = DATA_CACHE,
+.level = 1,
+.size = 32 * KiB,
+.line_size = 64,
+.associativity = 8,
+.partitions = 1,
+
Hi Zhao,
On 2/20/2025 6:00 AM, Zhao Liu wrote:
On Thu, Feb 06, 2025 at 01:28:37PM -0600, Babu Moger wrote:
Date: Thu, 6 Feb 2025 13:28:37 -0600
From: Babu Moger
Subject: [PATCH v5 4/6] target/i386: Add feature that indicates WRMSR to
BASE reg is non-serializing
X-Mailer: git-send-email 2.34.
Hi Zhao,
On 2/20/2025 5:26 AM, Zhao Liu wrote:
+static const CPUCaches epyc_milan_v3_cache_info = {
+.l1d_cache = &(CPUCacheInfo) {
+.type = DATA_CACHE,
+.level = 1,
+.size = 32 * KiB,
+.line_size = 64,
+.associativity = 8,
+.partitions = 1,
+
On Wed, Feb 12, 2025 at 05:44:49AM +, Suravee Suthikulpanit wrote:
> Current amd-iommu model internally creates an AMDVI-PCI device. Here is
> a snippet from info qtree:
>
> bus: main-system-bus
> type System
> dev: amd-iommu, id ""
> xtsup = false
> pci-id = ""
> i
- Am 20. Feb 2025 um 23:29 schrieb Philippe Mathieu-Daudé phi...@linaro.org:
> Hi Conor,
>
> On 20/2/25 19:30, Conor Dooley wrote:
>> +cc qemu-riscv, Alistar.
>>
>> On Fri, Feb 14, 2025 at 07:24:37AM +0100, Sebastian Huber wrote:
>>> Booting the microchip-icicle-kit machine using the latest
Further customize the -bios and -kernel options behaviour for the
microchip-icicle-kit machine. If "-bios none -kernel filename" is
specified, then do not load a firmware and instead only load and start
the kernel image.
Signed-off-by: Sebastian Huber
---
v2: Use riscv_find_firmware() to locate
On Thu, Feb 20, 2025 at 04:57:51PM +0100, Eric Auger wrote:
> Hi Michael,
>
>
> On 2/20/25 4:25 PM, Michael S. Tsirkin wrote:
> > On Fri, Jan 31, 2025 at 10:55:26AM +0100, Eric Auger wrote:
> >> I tested [PATCH] virtio: Remove virtio devices on device_shutdown()
> >> https://lore.kernel.org/all/2
The pm_cap on the PCIExpressDevice object can be distilled down
to the new instance on the PCIDevice object.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Alex Williamson
---
hw/pci-bridge/pcie_pci_bridge.c | 1 -
hw/virtio/virtio-pci.c | 8 +++-
include/hw/pci/pcie.h
On 5/5/23 23:24, Richard Henderson wrote:
The port currently does not support "oversize" guests, which
means riscv32 can only target 32-bit guests. We will soon be
building TCG once for all guests. This implies that we can
only support riscv64.
Since all Linux distributions target riscv64 not
On Tue, Jan 28, 2025 at 07:57:03PM +0100, David Hildenbrand wrote:
> This is based-on [1], which adds MSI-X support to virtio-balloon-pci,
> but can be applied independently.
>
> Turns out it is fairly easy to get virtio-mem-pci running on s390x. We
> only have to add MSI-X support to virtio-mem-p
On Wed, Feb 12, 2025 at 05:44:48AM +, Suravee Suthikulpanit wrote:
> Currently, amd-iommu device does not support migration. This series addresses
> an issue due hidden AMDVI-PCI device enumeration. Then introduces migratable
> VMStateDescription, which saves necessary parameters for the device
On Wed, Feb 19, 2025 at 09:52:35AM +0800, oen...@gmail.com wrote:
> From: Huaitong Han
>
> The vring call fd is set even when the guest does not use MSIX (e.g., virtio
> PMD). This results in unnecessary CPU overhead for handling virtio interrupts.
> The previous patch only optimized the conditio
Hi Richard,
On 17/2/25 00:07, Richard Henderson wrote:
Create a special subclass for sub, because two backends can
support "subtract from immediate". Drop all backend support
for an immediate as the second operand, as we transform sub
to add during optimize.
Signed-off-by: Richard Henderson
-
On Thu, Feb 20, 2025 at 03:48:53PM -0700, Alex Williamson wrote:
> Eric recently identified an issue[1] where during graceful shutdown
> of a VM in a vIOMMU configuration, the guest driver places the device
> into the D3 power state, the vIOMMU is then disabled, triggering an
> AddressSpace update.
This is now redundant to PCIDevice.pm_cap.
Cc: Cédric Le Goater
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 9 -
hw/vfio/pci.h | 1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 6903f831e45f..ba4ef65b16fa 100644
--- a/hw/vfio
The memory and IO BARs for devices are only accessible in the D0
power state. In other power states the PCI spec defines that the
device should respond to TLPs and messages with an Unsupported
Request response. The closest we can come to emulating this
behavior is to consider the BARs as unmapped
Eric recently identified an issue[1] where during graceful shutdown
of a VM in a vIOMMU configuration, the guest driver places the device
into the D3 power state, the vIOMMU is then disabled, triggering an
AddressSpace update. The device BARs are still mapped into the AS,
but the vfio host driver
Switch callers directly initializing the PCI PM capability with
pci_add_capability() to use pci_pm_init().
Cc: Dmitry Fleytman
Cc: Akihiko Odaki
Cc: Jason Wang
Cc: Stefan Weil
Cc: Sriram Yagnaraman
Cc: Keith Busch
Cc: Klaus Jensen
Cc: Jesper Devantier
Cc: Michael S. Tsirkin
Cc: Marcel Apf
We want the device in the D0 power state going into reset, but the
config write can enable the BARs in the address space, which are
then removed from the address space once we clear the memory enable
bit in the command register. Re-order to clear the command bit
first, so the power state change do
Hi Conor,
On 20/2/25 19:30, Conor Dooley wrote:
+cc qemu-riscv, Alistar.
On Fri, Feb 14, 2025 at 07:24:37AM +0100, Sebastian Huber wrote:
Booting the microchip-icicle-kit machine using the latest PolarFire SoC
Hart Software Services (HSS) no longer works since Qemu lacks support
for several re
On 9/2/25 11:36, Bernhard Beschow wrote:
TYPE_CHIPIDEA models an IP block which is also used in TYPE_ZYNQ_MACHINE which
itself is not an IMX device. CONFIG_ZYNQ selects CONFIG_USB_EHCI_SYSBUS while
TYPE_CHIPIDEA is a separate compilation unit, so only works by accident if
CONFIG_IMX is given. Fix
On 17/2/25 00:07, Richard Henderson wrote:
Use the fully general extract opcodes instead.
Signed-off-by: Richard Henderson
---
include/tcg/tcg-opc.h| 10 -
tcg/aarch64/tcg-target-has.h | 10 -
tcg/arm/tcg-target-has.h | 4 -
tcg/i386/tcg-target-has.h| 1
This is more like a cosmetics fix since the f_cd_fetch and f_ste_fetch are
basically the same field since they are in the exact same union with exact
same type.
Signed-off-by: Nicolin Chen
---
hw/arm/smmuv3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/smmuv3.c b/h
On 17/2/25 00:07, Richard Henderson wrote:
Use the fully general extract opcodes instead.
Signed-off-by: Richard Henderson
---
include/tcg/tcg-opc.h| 10 -
tcg/aarch64/tcg-target-has.h | 10 -
tcg/arm/tcg-target-has.h | 4 -
tcg/i386/tcg-target-has.h| 1
On Mon, Jan 20, 2025 at 05:41:32PM +, CLEMENT MATHIEU--DRIF wrote:
> From: Clement Mathieu--Drif
>
> This patch set belongs to a list of series that add SVM support for VT-d.
>
> Here we focus on implementing ATS support in the IOMMU and adding a
> PCI-level API to be used by virtual devices
On Thu, Feb 20, 2025 at 09:00:04PM +0100, Stefano Brivio wrote:
> On Thu, 20 Feb 2025 13:21:33 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Feb 20, 2025 at 05:59:10PM +0100, Stefano Brivio wrote:
> > > On Thu, 20 Feb 2025 10:28:20 -0500
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On
On Thu, Feb 20, 2025 at 03:48:17PM +0100, Juraj Marcin wrote:
> Maybe it could be also useful to add assertions to places where locked
> BQL is assumed and the assumption is not clear enough. Then, when
> something changes, it will fail with a clear reason instead of debugging
> race conditions tha
On Wed, Feb 19, 2025 at 8:22 AM Markus Armbruster wrote:
> John Snow writes:
>
> > "The text handler you add looks just like the existing latex handler.
> Does
> > LaTeX output lack "little headings", too?"
> >
> > Yes, almost certainly. Can you let me know which output formats we
> actually
> >
On Thu, 20 Feb 2025 13:21:33 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2025 at 05:59:10PM +0100, Stefano Brivio wrote:
> > On Thu, 20 Feb 2025 10:28:20 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Fri, Jan 24, 2025 at 05:03:27PM +0100, Stefano Brivio wrote:
> > > > But I don
Am 13. Februar 2025 00:13:24 UTC schrieb BALATON Zoltan :
>On Wed, 12 Feb 2025, Bernhard Beschow wrote:
>> Am 7. Februar 2025 01:12:38 UTC schrieb BALATON Zoltan :
>>> On Thu, 6 Feb 2025, Bernhard Beschow wrote:
Am 2. Februar 2025 01:25:22 UTC schrieb BALATON Zoltan
:
I had
On 20.02.25 17:13, Jean-Philippe Brucker wrote:
For Arm CCA we'd like the guest_memfd discard notifier to call the IOMMU
notifiers and create e.g. VFIO mappings. The default VFIO discard
notifier isn't sufficient for CCA because the DMA addresses need a
translation (even without vIOMMU).
At the
Hi Zhenzhong
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Hi,
>
> Per Jason Wang's suggestion, iommufd nesting series[1] is split into
> "Enable stage-1 translation for emulated device" series and
> "Enable stage-1 translation for passthrough device" series.
>
> This series is 2nd part focusing o
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Implement query of HOST_IOMMU_DEVICE_CAP_[NESTING|FS1GP] for IOMMUFD
> backed host IOMMU device.
>
> Query on these two capabilities is not supported for legacy backend
> because there is no plan to support nesting with leacy backend backed
> host dev
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Implement query of HOST_IOMMU_DEVICE_CAP_ERRATA for IOMMUFD
> backed host IOMMU device.
>
> Query on this capability is not supported for legacy backend
> because there is no plan to support nesting with leacy backend
legacy
> backed host device.
>
>
On Thu, 20 Feb 2025 at 18:39, Richard Henderson
wrote:
>
> On 2/20/25 09:12, Peter Maydell wrote:
> > That suggests that we are correctly implementing the x87
> > required behaviour in QEMU, and so that the TODO comment
> > I add in this patch isn't right. But then I'm a bit confused
> > about wha
+cc qemu-riscv, Alistar.
On Fri, Feb 14, 2025 at 07:24:37AM +0100, Sebastian Huber wrote:
> Booting the microchip-icicle-kit machine using the latest PolarFire SoC
> Hart Software Services (HSS) no longer works since Qemu lacks support
> for several registers (clocks, DRAM controller). Also readin
I'm trying to debug some functional tests that fail for me
with 'make check-functional' on a debug build. Consistently
(well, same set of tests in two runs) when I run
'make -j8 check-functional' these fail:
7/44 qemu:func-thorough+func-arm-thorough+thorough / func-arm-arm_sx1
On 2/20/25 7:41 PM, Eric Auger wrote:
> Hi Zhenzhong,
>
>
> On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
>> Signed-off-by: Zhenzhong Duan
>> ---
>> include/system/host_iommu_device.h | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/include/system/host_iommu_device.h
>> b/inc
Hi Zhenzhong,
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Signed-off-by: Zhenzhong Duan
> ---
> include/system/host_iommu_device.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/system/host_iommu_device.h
> b/include/system/host_iommu_device.h
> index df782598f2..18f8
On 2/20/25 09:12, Peter Maydell wrote:
That suggests that we are correctly implementing the x87
required behaviour in QEMU, and so that the TODO comment
I add in this patch isn't right. But then I'm a bit confused
about what the code is actually doing. Why do we need to look
at fmt->m68k_denormal
On Thu, Feb 20, 2025 at 05:59:10PM +0100, Stefano Brivio wrote:
> On Thu, 20 Feb 2025 10:28:20 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Fri, Jan 24, 2025 at 05:03:27PM +0100, Stefano Brivio wrote:
> > > But I don't understand why we're leaving this as it is.
> >
> > So that people notice i
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Implement [at|de]tach_hwpt handlers in VFIO subsystem. vIOMMU
> utilizes them to attach to or detach from hwpt on host side.
>
> Signed-off-by: Yi Liu
> Signed-off-by: Zhenzhong Duan
> ---
> hw/vfio/iommufd.c | 22 ++
> 1 file c
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> There are three iommufd related elements iommufd handle, devid and
There are three iommufd specific members in HostIOMMUDevice
IOMMUFD that need to be initialized after attach on realize_late() ...
> hwpt_id. hwpt_id is ready only after VFIO device
Hi Zhenzhong,
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> New added properties include IOMMUFD handle, devid and hwpt_id.
a property generally has an other meaning in qemu (PROP*).
I would rather say you enhance HostIOMMUDeviceIOMMUFD object with 3 new
members, specific to the iommufd BE + 2 new
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Currently we have realize() callback which is called before attachment.
> But there are still some elements e.g., hwpt_id is not ready before
> attachment. So we need a realize_late() callback to further initialize
> them.
from the description it is n
On Thu, 20 Feb 2025 11:45:35 +0100
Eric Auger wrote:
> Hi Alex,
>
> On 2/20/25 11:31 AM, Eric Auger wrote:
> >
> > Hi Alex,
> >
> > On 2/19/25 10:19 PM, Alex Williamson wrote:
> >> On Wed, 19 Feb 2025 11:58:44 -0700
> >> Alex Williamson wrote:
> >>
> >>> On Wed, 19 Feb 2025 18:58:58 +0100
On Mon, 17 Feb 2025 at 19:14, Richard Henderson
wrote:
>
> On 2/17/25 04:50, Peter Maydell wrote:
> > Currently we compile-time set an 'm68k_denormal' flag in the FloatFmt
> > for floatx80 for m68k. This controls our handling of what the Intel
> > documentation calls a "pseudo-denormal": a value
If GNU Binutils is configured with --enable-error-rwx-segments=yes, one
gets the following for optionrom:
```
.../bin/ld: error: pvh.img has a LOAD segment with RWX permissions
.../bin/ld: final link faile
```
Pass -Wl,--no-error-rwx-segments to suppress that.
Signed-off-by: Sam James
---
pc-bi
On Thu, Feb 13, 2025 at 13:00:31 -0500, Stefan Hajnoczi wrote:
> Implement --device virtio-scsi-pci,iothread-vq-mapping= support so that
> virtqueues can be assigned to different IOThreads. This improves SMP guest
> scalability where I/O-intensive applications can become bottlenecked on a
> single
On Thu, 20 Feb 2025 10:28:20 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Jan 24, 2025 at 05:03:27PM +0100, Stefano Brivio wrote:
> > But I don't understand why we're leaving this as it is.
>
> So that people notice if there's some backend problem and
> announcements are not going out. should h
Thank you very much!
On Thu, Feb 20, 2025 at 8:18 AM Peter Maydell
wrote:
> On Wed, 19 Feb 2025 at 18:46, Hao Wu wrote:
> >
> > Changes since v4:
> >
> > 1. Bump vmstate versions on NPCM CLK and GCR modules.
> > 2. Remove "hw/boards.h" include in npcm8xx.h and add it in npcm8xx*.c
> > 3. Use cp
In system register access pseudocode the common pattern for
AArch32 registers with access traps to EL3 is:
at EL1 and EL2:
if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then
AArch64.AArch32SystemAccessTrap(EL3, 0x03);
elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR =
Hi Zhenzhong,
On 2/19/25 9:22 AM, Zhenzhong Duan wrote:
> Signed-off-by: Nicolin Chen
> Signed-off-by: Zhenzhong Duan
in the title, there is only a single helper here. a small commit msg may
help the reader
> ---
> include/system/iommufd.h | 3 +++
> backends/iommufd.c | 30
On Fri, Jan 24, 2025 at 05:03:27PM +0100, Stefano Brivio wrote:
> But I don't understand why we're leaving this as it is.
So that people notice if there's some backend problem and
announcements are not going out. should help debug migration
issues. which we had, so we added this :)
From: Philippe Mathieu-Daudé
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs, (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"), and Cortex-15MP to 128 (see commit 528622421eb
"hw/cpu/a15mpcore: Correct default value for num-irq").
The Caldexa
From: Philippe Mathieu-Daudé
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs, (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"), and Cortex-15MP to 128 (see commit 528622421eb
"hw/cpu/a15mpcore: Correct default value for num-irq").
The Versati
On 20/2/25 14:33, Paolo Bonzini wrote:
PVG is not cross-architecture; the PVG guest drivers with x86-64 macOS do not
give
useful results with the aarch64 macOS host PVG framework, and vice versa.
To express this repurpose CONFIG_MAC_PVG, making it true only if the target has
the same architectur
The pseudocode for AT S1E2R and AT S1E2W says that they should be
UNDEFINED if executed at EL3 when EL2 is not enabled. We were
incorrectly using CP_ACCESS_TRAP and reporting the wrong exception
syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: qemu-sta...@nongnu.org
Fixes: 2a47df953202e
From: Hao Wu
NPCM8XX boot block stores the DRAM size in SCRPAD_B register in GCR
module. Since we don't simulate a detailed memory controller, we
need to store this information directly similar to the NPCM7XX's
INCTR3 register.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
Message-id: 20250
From: Hao Wu
NPCM7XX and NPCM8XX have a different set of CLK registers. This
commit changes the name of the clk files to be used by both
NPCM7XX and NPCM8XX CLK modules.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
Message-id: 20250219184609.1839281-11-wuhao...@google.com
Signed-off-by: Pe
From: Hao Wu
NPCM7XX and NPCM8XX have a different set of GCRs and the GCR module
needs to fit both. This commit changes the name of the GCR module.
Future commits will add the support for NPCM8XX GCRs.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
Message-id: 20250219184609.1839281-5-wuhao.
From: Hao Wu
The NPCM8xx GCR device can be accessed with 64-bit memory operations.
This patch supports that.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
Reviewed-by: Philippe Mathieu-Daude
Message-id: 20250219184609.1839281-10-wuhao...@google.com
Signed-off-by: Peter Maydell
---
hw/mis
From: Hao Wu
NPCM8XX SoC is the successor of the NPCM7XX. It features quad-core
Cortex-A35 (Armv8, 64-bit) CPUs and some additional peripherals.
This document describes the NPCM8XX SoC and an evaluation board
(NPCM 845 EVB).
Signed-off-by: Hao Wu
Reviewed-by: Peter Maydell
Message-id: 2025021
1 - 100 of 244 matches
Mail list logo
