Re: [PATCH 0/6] migration removals & deprecations
Doesn't apply for me. What's your base?
Re: [PATCH] target/i386/translate.c: always write 32-bits for SGDT and SIDT
On Tue, Apr 23, 2024 at 10:42 PM Mark Cave-Ayland wrote: > > Let's change "Despite claims to the contrary" with "Despite a > > confusing description". > > Thanks for sorting this, Paolo. I suspect that KVM needs a similar patch as > per > https://gitlab.com/qemu-project/qemu/-/issues/2198#note_1815726425 however > the Win32s > and OS/2 Warp 4 tests seem to work fine on KVM. Maybe it's because the SGDT > and SIDT > instructions run natively and don't need to be emulated for these cases? Yes, they are almost never emulated (only in big real mode and only on old Intel processors). Paolo
Re: [PATCH 1/6] migration: Remove 'skipped' field from MigrationStats
Fabiano Rosas writes:
> The 'skipped' field of the MigrationStats struct has been deprecated
> in 8.1. Time to remove it.
>
> Deprecation commit 7b24d32634 ("migration: skipped field is really
> obsolete.").
>
> Signed-off-by: Fabiano Rosas
> ---
> docs/about/deprecated.rst | 6 --
> docs/about/removed-features.rst | 6 ++
> migration/migration-hmp-cmds.c | 2 --
> migration/migration.c | 2 --
> qapi/migration.json | 8
> 5 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 7b548519b5..4d9d6bf2da 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -488,12 +488,6 @@ option).
> Migration
> -
>
> -``skipped`` MigrationStats field (since 8.1)
> -
> -
> -``skipped`` field in Migration stats has been deprecated. It hasn't
> -been used for more than 10 years.
> -
> ``inc`` migrate command option (since 8.2)
> ''
>
> diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
> index f9cf874f7b..9873f59bee 100644
> --- a/docs/about/removed-features.rst
> +++ b/docs/about/removed-features.rst
> @@ -614,6 +614,12 @@ was superseded by ``sections``.
> Member ``section-size`` in the return value of ``query-sgx-capabilities``
> was superseded by ``sections``.
>
> +``query-migrate`` return value member ``skipped`` (removed in 9.1)
> +''
> +
> +Member ``skipped`` of the ``MigrationStats`` struct hasn't been used
> +for more than 10 years. Removed with no replacement.
> +
> Human Monitor Protocol (HMP) commands
> -
>
> diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
> index 7e96ae6ffd..28f776d06d 100644
> --- a/migration/migration-hmp-cmds.c
> +++ b/migration/migration-hmp-cmds.c
> @@ -105,8 +105,6 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
> info->ram->total >> 10);
> monitor_printf(mon, "duplicate: %" PRIu64 " pages\n",
> info->ram->duplicate);
> -monitor_printf(mon, "skipped: %" PRIu64 " pages\n",
> - info->ram->skipped);
> monitor_printf(mon, "normal: %" PRIu64 " pages\n",
> info->ram->normal);
> monitor_printf(mon, "normal bytes: %" PRIu64 " kbytes\n",
> diff --git a/migration/migration.c b/migration/migration.c
> index 696762bc64..3b433fdb31 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1149,8 +1149,6 @@ static void populate_ram_info(MigrationInfo *info,
> MigrationState *s)
> info->ram->transferred = migration_transferred_bytes();
> info->ram->total = ram_bytes_total();
> info->ram->duplicate = stat64_get(&mig_stats.zero_pages);
> -/* legacy value. It is not used anymore */
> -info->ram->skipped = 0;
> info->ram->normal = stat64_get(&mig_stats.normal_pages);
> info->ram->normal_bytes = info->ram->normal * page_size;
> info->ram->mbps = s->mbps;
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 8c65b90328..401b8e24ac 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -23,9 +23,6 @@
> #
> # @duplicate: number of duplicate (zero) pages (since 1.2)
> #
> -# @skipped: number of skipped zero pages. Always zero, only provided
> -# for compatibility (since 1.5)
> -#
> # @normal: number of normal pages (since 1.2)
> #
> # @normal-bytes: number of normal bytes sent (since 1.2)
> @@ -63,16 +60,11 @@
> # between 0 and @dirty-sync-count * @multifd-channels. (since
> # 7.1)
> #
> -# Features:
> -#
> -# @deprecated: Member @skipped is always zero since 1.5.3
> -#
> # Since: 0.14
> ##
> { 'struct': 'MigrationStats',
>'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
> 'duplicate': 'int',
> - 'skipped': { 'type': 'int', 'features': [ 'deprecated' ] },
> 'normal': 'int',
> 'normal-bytes': 'int', 'dirty-pages-rate': 'int',
> 'mbps': 'number', 'dirty-sync-count': 'int',
Reviewed-by: Markus Armbruster
Re: [PULL v2 00/63] First batch of i386 and build system patch for QEMU 9.1
On Wed, Apr 24, 2024 at 8:49 PM Richard Henderson wrote: > > On 4/24/24 01:14, Paolo Bonzini wrote: > > The following changes since commit 62dbe54c24dbf77051bafe1039c31ddc8f37602d: > > > >Update version for v9.0.0-rc4 release (2024-04-16 18:06:15 +0100) > > > > are available in the Git repository at: > > > >https://gitlab.com/bonzini/qemu.git tags/for-upstream > > > > for you to fetch changes up to 7653b44534d3267fa63ebc9d7221eaa7b48bf5ae: > > > >target/i386/translate.c: always write 32-bits for SGDT and SIDT > > (2024-04-23 17:35:26 +0200) > > Sorry, I've already merged v1. You'll need to adjust the fix on top. It's the same tag, so you actually merged v2. Paolo
Re: [PATCH v3 4/4] qapi: introduce exit-on-error parameter for migrate-incoming
Vladimir Sementsov-Ogievskiy writes:
> Now we do set MIGRATION_FAILED state, but don't give a chance to
> orchestrator to query migration state and get the error.
>
> Let's provide a possibility for QMP-based orchestrators to get an error
> like with outgoing migration.
>
> For hmp_migrate_incoming(), let's enable the new behavior: HMP is not
> and ABI, it's mostly intended to use by developer and it makes sense
> not to stop the process.
>
> For x-exit-preconfig, let's keep the old behavior:
> - it's called from init(), so here we want to keep current behavior by
>default
> - it does exit on error by itself as well
> So, if we want to change the behavior of x-exit-preconfig, it should be
> another patch.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
[...]
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 8c65b90328..9de8b98d0b 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -1837,6 +1837,10 @@
> # @channels: list of migration stream channels with each stream in the
> # list connected to a destination interface endpoint.
> #
> +# @exit-on-error: Do exit on incoming migration failure. Default true.
Scratch "Do"?
> +# When set to false, the error is reported by MIGRATION event and
Comma before "and", please.
Suggest "the failure triggers a MIGRATION event".
> +# error could be retrieved by query-migrate command. (since 9.1)
"error details could be retrieved with query-migrate", perhaps?
> +#
> # Since: 2.3
> #
> # Notes:
> @@ -1889,7 +1893,8 @@
> ##
> { 'command': 'migrate-incoming',
> 'data': {'*uri': 'str',
> - '*channels': [ 'MigrationChannel' ] } }
> + '*channels': [ 'MigrationChannel' ],
> + '*exit-on-error': 'bool' } }
>
> ##
> # @xen-save-devices-state:
QAPI schema
Acked-by: Markus Armbruster
[...]
Re: [PATCH 0/3] Make it possible to compile the x86 binaries without FDC
On 25/04/2024 22.56, Philippe Mathieu-Daudé wrote: Hi Thomas, On 25/4/24 20:43, Thomas Huth wrote: For downstream versions of QEMU, we'd like to be able to compile QEMU without the FDC code included (since it's not required for modern VMs anymore and the FDC code has rather a bad reputation, see the VENOM CVE). IIRC you still need to keep the i440fx+piix machine DS due to migration compatibility, right? Are you able to migrate a VM booted with FDC to a non-FDC one? Migration from a machine with FDC to one without is likely not possible. But that's also not the purpose of this series. It's about having the possibility to build a QEMU binary without FDC at all in case you don't have to support old machine types with FDC anymore. The q35 machine can already be instantiated without FDC, but for being able to link a binary without the FDC code, the Kconfig file needs some tweaks and there are two spots in the pc code that directly call functions from the FDC code - those need to be disabled via #ifdefs. Is it useful to you to have q35 without FDC but i440fx+piix with? Or are you removing it from i440fx+piix due to shared code with q35? I think it might get useful. Thomas
Re: [PATCH v2] hw/mem/cxl_type3: reset dvsecs in ct3d_reset()
ping
On 11/04/2024 18:18, Jonathan Cameron wrote:
> On Tue, 9 Apr 2024 15:58:46 +0800
> Li Zhijian wrote:
>
>> After the kernel commit
>> 0cab68720598 ("cxl/pci: Fix disabling memory if DVSEC CXL Range does not
>> match a CFMWS window")
>> CXL type3 devices cannot be enabled again after the reboot because the
>> control register(see 8.1.3.2 in CXL specifiction 2.0 for more details) was
>> not reset.
>>
>> These registers could be changed by the firmware or OS, let them have
>> their initial value in reboot so that the OS can read their clean status.
>>
>> Fixes: e1706ea83da0 ("hw/cxl/device: Add a memory device (8.2.8.5)")
>> Signed-off-by: Li Zhijian
> Hi,
>
> We need to have a close look at what this is actually doing before
> considering applying it. I don't have time to get that this week, but
> hopefully will find some time later this month.
>
> I don't want a partial fix for one particular case that causes
> us potential trouble in others.
>
> Jonathan
>
>> ---
>> root_port, usp and dsp have the same issue, if this patch get approved,
>> I will send another patch to fix them later.
>>
>> V2:
>> Add fixes tag.
>> Reset all dvsecs registers instead of CTRL only
>> ---
>> hw/mem/cxl_type3.c | 11 +++
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
>> index b0a7e9f11b64..4f09d0b8fedc 100644
>> --- a/hw/mem/cxl_type3.c
>> +++ b/hw/mem/cxl_type3.c
>> @@ -30,6 +30,7 @@
>> #include "hw/pci/msix.h"
>>
>> #define DWORD_BYTE 4
>> +#define CT3D_CAP_SN_OFFSET PCI_CONFIG_SPACE_SIZE
>>
>> /* Default CDAT entries for a memory region */
>> enum {
>> @@ -284,6 +285,10 @@ static void build_dvsecs(CXLType3Dev *ct3d)
>>range2_size_hi = 0, range2_size_lo = 0,
>>range2_base_hi = 0, range2_base_lo = 0;
>>
>> +cxl_cstate->dvsec_offset = CT3D_CAP_SN_OFFSET;
>> +if (ct3d->sn != UI64_NULL) {
>> +cxl_cstate->dvsec_offset += PCI_EXT_CAP_DSN_SIZEOF;
>> +}
>> /*
>>* Volatile memory is mapped as (0x0)
>>* Persistent memory is mapped at (volatile->size)
>> @@ -664,10 +669,7 @@ static void ct3_realize(PCIDevice *pci_dev, Error
>> **errp)
>>
>> pcie_endpoint_cap_init(pci_dev, 0x80);
>> if (ct3d->sn != UI64_NULL) {
>> -pcie_dev_ser_num_init(pci_dev, 0x100, ct3d->sn);
>> -cxl_cstate->dvsec_offset = 0x100 + 0x0c;
>> -} else {
>> -cxl_cstate->dvsec_offset = 0x100;
>> +pcie_dev_ser_num_init(pci_dev, CT3D_CAP_SN_OFFSET, ct3d->sn);
>> }
>>
>> ct3d->cxl_cstate.pdev = pci_dev;
>> @@ -907,6 +909,7 @@ static void ct3d_reset(DeviceState *dev)
>>
>> cxl_component_register_init_common(reg_state, write_msk,
>> CXL2_TYPE3_DEVICE);
>> cxl_device_register_init_t3(ct3d);
>> +build_dvsecs(ct3d);
>>
>> /*
>>* Bring up an endpoint to target with MCTP over VDM.
>
RE: [PATCH v2 3/5] intel_iommu: Add a framework to do compatibility check with host IOMMU cap/ecap
>-Original Message-
>From: Cédric Le Goater
>Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
>compatibility check with host IOMMU cap/ecap
>
>On 4/25/24 10:46, Duan, Zhenzhong wrote:
>> Hi Cédric,
>>
>>> -Original Message-
>>> From: Cédric Le Goater
>>> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
>>> compatibility check with host IOMMU cap/ecap
>>>
>>> Hello Zhenzhong,
>>>
>>> On 4/18/24 10:42, Duan, Zhenzhong wrote:
Hi Cédric,
> -Original Message-
> From: Cédric Le Goater
> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
> compatibility check with host IOMMU cap/ecap
>
> Hello Zhenzhong
>
> On 4/17/24 11:24, Duan, Zhenzhong wrote:
>>
>>
>>> -Original Message-
>>> From: Cédric Le Goater
>>> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
>>> compatibility check with host IOMMU cap/ecap
>>>
>>> On 4/17/24 06:21, Duan, Zhenzhong wrote:
> -Original Message-
> From: Cédric Le Goater
> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
> compatibility check with host IOMMU cap/ecap
>
> Hello,
>
> On 4/16/24 09:09, Duan, Zhenzhong wrote:
>> Hi Cédric,
>>
>>> -Original Message-
>>> From: Cédric Le Goater
>>> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to
>do
>>> compatibility check with host IOMMU cap/ecap
>>>
>>> On 4/8/24 10:44, Zhenzhong Duan wrote:
From: Yi Liu
If check fails, the host side device(either vfio or vdpa device)
>>> should
>>> not
be passed to guest.
Implementation details for different backends will be in
>>> following
> patches.
Signed-off-by: Yi Liu
Signed-off-by: Yi Sun
Signed-off-by: Zhenzhong Duan
---
hw/i386/intel_iommu.c | 35
>>> +++
1 file changed, 35 insertions(+)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 4f84e2e801..a49b587c73 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -35,6 +35,7 @@
#include "sysemu/kvm.h"
#include "sysemu/dma.h"
#include "sysemu/sysemu.h"
+#include "sysemu/iommufd.h"
#include "hw/i386/apic_internal.h"
#include "kvm/kvm_i386.h"
#include "migration/vmstate.h"
@@ -3819,6 +3820,32 @@ VTDAddressSpace
>>> *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
return vtd_dev_as;
}
+static int vtd_check_legacy_hdev(IntelIOMMUState *s,
+ HostIOMMUDevice *hiod,
+ Error **errp)
+{
+return 0;
+}
+
+static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
+ HostIOMMUDevice *hiod,
+ Error **errp)
+{
+return 0;
+}
+
+static int vtd_check_hdev(IntelIOMMUState *s,
> VTDHostIOMMUDevice
>>> *vtd_hdev,
+ Error **errp)
+{
+HostIOMMUDevice *hiod = vtd_hdev->dev;
+
+if (object_dynamic_cast(OBJECT(hiod),
>>> TYPE_HIOD_IOMMUFD))
> {
+return vtd_check_iommufd_hdev(s, hiod, errp);
+}
+
+return vtd_check_legacy_hdev(s, hiod, errp);
+}
>>>
>>>
>>> I think we should be using the .get_host_iommu_info() class
>>> handler
>>> instead. Can we refactor the code slightly to avoid this check on
>>> the type ?
>>
>> There is some difficulty ini avoiding this check, the behavior of
> vtd_check_legacy_hdev
>> and vtd_check_iommufd_hdev are different especially after
>>> nesting
> support introduced.
>> vtd_check_iommufd_hdev() has much wider check over
>cap/ecap
>>> bits
> besides aw_bits.
>
> I think it is important to fully separate the vIOMMU model from
>the
> host IOMMU backing device.
>
> This comment is true for the structures also.
>
> Could we introduce a new HostIOMMUDeviceClass
> handler .check_hdev() handler, which would
> call .get_host_iommu_info() ?
>
> This means that HIOD_LEGACY_INFO and HIOD_IOMMUF
Re: [PULL 00/22] Misc HW patches for 2024-04-25
On 4/25/24 04:01, Philippe Mathieu-Daudé wrote: The following changes since commit 85b597413d4370cb168f711192eaef2eb70535ac: Merge tag 'housekeeping-20240424' ofhttps://github.com/philmd/qemu into staging (2024-04-24 11:49:57 -0700) are available in the Git repository at: https://github.com/philmd/qemu.git tags/hw-misc-20240425 for you to fetch changes up to 098de99aad1aa911b4950b47b55d2e2bcc4f9c0c: hw/core: Support module-id in numa configuration (2024-04-25 12:48:12 +0200) 2 checkpatch issues: - one spurious: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? - one deliberately ignored in a python script: ERROR: line over 90 characters Misc HW patch queue - Script to compare machines compat_props[] (Maksim) - Introduce 'module' CPU topology level (Zhao) - Various cleanups (Thomas, Zhao, Inès, Bernhard) Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/9.1 as appropriate. r~
Re: [PATCH for-9.1 v3 1/2] target/riscv/debug: set tval=pc in breakpoint exceptions
On 2024/4/17 7:04, Daniel Henrique Barboza wrote:
We're not setting (s/m)tval when triggering breakpoints of type 2
(mcontrol) and 6 (mcontrol6). According to the debug spec section
5.7.12, "Match Control Type 6":
"The Privileged Spec says that breakpoint exceptions that occur on
instruction fetches, loads, or stores update the tval CSR with either
zero or the faulting virtual address. The faulting virtual address for
an mcontrol6 trigger with action = 0 is the address being accessed and
which caused that trigger to fire."
A similar text is also found in the Debug spec section 5.7.11 w.r.t.
mcontrol.
Note that what we're doing ATM is not violating the spec, but it's
simple enough to set mtval/stval and it makes life easier for any
software that relies on this info.
Given that we always use action = 0, save the faulting address for the
mcontrol and mcontrol6 trigger breakpoints into env->badaddr, which is
used as as scratch area for traps with address information. 'tval' is
then set during riscv_cpu_do_interrupt().
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu_helper.c | 1 +
target/riscv/debug.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index fc090d729a..f9c6d7053b 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1717,6 +1717,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
tval = env->bins;
break;
case RISCV_EXCP_BREAKPOINT:
+tval = env->badaddr;
if (cs->watchpoint_hit) {
tval = cs->watchpoint_hit->hitaddr;
cs->watchpoint_hit = NULL;
diff --git a/target/riscv/debug.c b/target/riscv/debug.c
index e30d99cc2f..b110370ea6 100644
--- a/target/riscv/debug.c
+++ b/target/riscv/debug.c
@@ -798,6 +798,7 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
if ((ctrl & TYPE2_EXEC) && (bp->pc == pc)) {
/* check U/S/M bit against current privilege level */
if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
return true;
}
}
@@ -810,11 +811,13 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
if (env->virt_enabled) {
/* check VU/VS bit against current privilege level */
if ((ctrl >> 23) & BIT(env->priv)) {
+env->badaddr = pc;
return true;
}
} else {
/* check U/S/M bit against current privilege level */
if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
return true;
}
}
Reviewed-by: LIU Zhiwei
Zhiwei
Re: [PATCH for-9.1 v3 2/2] trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint
On 2024/4/17 7:04, Daniel Henrique Barboza wrote:
Privileged spec section 4.1.9 mentions:
"When a trap is taken into S-mode, stval is written with
exception-specific information to assist software in handling the trap.
(...)
If stval is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, or page-fault exception occurs on an
instruction fetch, load, or store, then stval will contain the faulting
virtual address."
A similar text is found for mtval in section 3.1.16.
Setting mtval/stval in this scenario is optional, but some softwares read
these regs when handling ebreaks.
Write 'badaddr' in all ebreak breakpoints to write the appropriate
'tval' during riscv_do_cpu_interrrupt().
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/insn_trans/trans_privileged.c.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/riscv/insn_trans/trans_privileged.c.inc
b/target/riscv/insn_trans/trans_privileged.c.inc
index 620ab54eb0..bc5263a4e0 100644
--- a/target/riscv/insn_trans/trans_privileged.c.inc
+++ b/target/riscv/insn_trans/trans_privileged.c.inc
@@ -62,6 +62,8 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
if (pre == 0x01f01013 && ebreak == 0x00100073 && post == 0x40705013) {
generate_exception(ctx, RISCV_EXCP_SEMIHOST);
} else {
+tcg_gen_st_tl(tcg_constant_tl(ebreak_addr), tcg_env,
+ offsetof(CPURISCVState, badaddr));
Reviewed-by: LIU Zhiwei
Zhiwei
generate_exception(ctx, RISCV_EXCP_BREAKPOINT);
}
return true;
[PATCH] ui/gtk: Draw guest frame at refresh cycle
From: Dongwon Kim
Draw routine needs to be manually invoked in the next refresh
if there is a scanout blob from the guest. This is to prevent
a situation where there is a scheduled draw event but it won't
happen bacause the window is currently in inactive state
(minimized or tabified). If draw is not done for a long time,
gl_block timeout and/or fence timeout (on the guest) will happen
eventually.
Suggested-by: Vivek Kasireddy
Cc: Gerd Hoffmann
Cc: Marc-André Lureau
Cc: Daniel P. Berrangé
Signed-off-by: Dongwon Kim
---
ui/gtk-egl.c | 1 +
ui/gtk-gl-area.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index 3af5ac5bcf..75f6b9011a 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -150,6 +150,7 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
vc, vc->window ? vc->window : vc->gfx.drawing_area);
if (vc->gfx.guest_fb.dmabuf && vc->gfx.guest_fb.dmabuf->draw_submitted) {
+gd_egl_draw(vc);
return;
}
diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
index 52dcac161e..7b4ba37b78 100644
--- a/ui/gtk-gl-area.c
+++ b/ui/gtk-gl-area.c
@@ -126,6 +126,7 @@ void gd_gl_area_refresh(DisplayChangeListener *dcl)
gd_update_monitor_refresh_rate(vc, vc->window ? vc->window :
vc->gfx.drawing_area);
if (vc->gfx.guest_fb.dmabuf && vc->gfx.guest_fb.dmabuf->draw_submitted) {
+gd_egl_draw(vc);
return;
}
--
2.34.1
Re: [PATCH] tests/avocado: update sunxi kernel from armbian to 6.6.16
Hi Peter,
I ran the avocado tests and this patch looks good to me.
The only comment I have would be that the `test_arm-Orangepi_bionic_20_08`
is not executed anymore since the image is not available, but I guess that
can be another patch.
On Thu, Apr 25, 2024 at 9:31 PM Peter Maydell
wrote:
> Whoops, forgot to cc the allwinner maintainers/reviewers on this.
> Ping for review, please?
>
> thanks
> -- PMM
>
> On Mon, 15 Apr 2024 at 16:18, Peter Maydell
> wrote:
> >
> > The Linux kernel 5.10.16 binary for sunxi has been removed from
> > apt.armbian.com. This means that the avocado tests for these machines
> > will be skipped (status CANCEL) if the old binary isn't present in
> > the avocado cache.
> >
> > Update to 6.6.16, in the same way we did in commit e384db41d8661
> > when we moved to 5.10.16 in 2021.
> >
> > Cc: qemu-sta...@nongnu.org
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2284
> > Signed-off-by: Peter Maydell
> > ---
> > At this point in the release cycle I don't think I really want
> > to put this into 9.0, though I could just about squeeze it in.
> >
> > cc'ing stable as an FYI -- since the tests fall back to the
> > CANCEL status this doesn't break CI, so it's not a requirement
> > to backport to any stable branches. But it would probably be
> > preferable to get the coverage back on the stable branches so
> > we can detect if we get something wrong on a backport of a
> > patch that affects these machines.
> > ---
> > tests/avocado/boot_linux_console.py | 70 ++---
> > tests/avocado/replay_kernel.py | 8 ++--
> > 2 files changed, 39 insertions(+), 39 deletions(-)
> >
> > diff --git a/tests/avocado/boot_linux_console.py
> b/tests/avocado/boot_linux_console.py
> > index 989b65111c0..d0ab5aaa83a 100644
> > --- a/tests/avocado/boot_linux_console.py
> > +++ b/tests/avocado/boot_linux_console.py
> > @@ -646,12 +646,12 @@ def test_arm_cubieboard_initrd(self):
> > :avocado: tags=accel:tcg
> > """
> > deb_url = ('https://apt.armbian.com/pool/main/l/'
> > -
> 'linux-5.10.16-sunxi/linux-image-current-sunxi_21.02.2_armhf.deb')
> > -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> > +
>
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> > +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> > deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> > kernel_path = self.extract_from_deb(deb_path,
> > -
> '/boot/vmlinuz-5.10.16-sunxi')
> > -dtb_path =
> '/usr/lib/linux-image-current-sunxi/sun4i-a10-cubieboard.dtb'
> > +
> '/boot/vmlinuz-6.6.16-current-sunxi')
> > +dtb_path =
> '/usr/lib/linux-image-6.6.16-current-sunxi/sun4i-a10-cubieboard.dtb'
> > dtb_path = self.extract_from_deb(deb_path, dtb_path)
> > initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
> >'2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> > @@ -690,12 +690,12 @@ def test_arm_cubieboard_sata(self):
> > :avocado: tags=accel:tcg
> > """
> > deb_url = ('https://apt.armbian.com/pool/main/l/'
> > -
> 'linux-5.10.16-sunxi/linux-image-current-sunxi_21.02.2_armhf.deb')
> > -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> > +
>
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> > +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> > deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> > kernel_path = self.extract_from_deb(deb_path,
> > -
> '/boot/vmlinuz-5.10.16-sunxi')
> > -dtb_path =
> '/usr/lib/linux-image-current-sunxi/sun4i-a10-cubieboard.dtb'
> > +
> '/boot/vmlinuz-6.6.16-current-sunxi')
> > +dtb_path =
> '/usr/lib/linux-image-6.6.16-current-sunxi/sun4i-a10-cubieboard.dtb'
> > dtb_path = self.extract_from_deb(deb_path, dtb_path)
> > rootfs_url = ('https://github.com/groeck/linux-build-test/raw/'
> >'2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> > @@ -872,13 +872,13 @@ def test_arm_bpim2u(self):
> > :avocado: tags=machine:bpim2u
> > :avocado: tags=accel:tcg
> > """
> > -deb_url = ('
> https://apt.armbian.com/pool/main/l/linux-5.10.16-sunxi/'
> > - 'linux-image-current-sunxi_21.02.2_armhf.deb')
> > -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> > +deb_url = ('https://apt.armbian.com/pool/main/l/'
> > +
>
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> > +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> > deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> > kernel_path = self.extract_from_deb(deb_path,
> > -
> '/boot/vmlinuz-5.10.16-sunxi')
> > -dtb_p
Re: [PATCH v4 04/14] util/dsa: Implement DSA task enqueue and dequeue.
Hao Xiang writes:
> * Use a safe thread queue for DSA task enqueue/dequeue.
> * Implement DSA task submission.
> * Implement DSA batch task submission.
>
> Signed-off-by: Hao Xiang
> ---
> include/qemu/dsa.h | 28 +++
> util/dsa.c | 201 +
> 2 files changed, 229 insertions(+)
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> index f15c05ee85..37cae8d9d2 100644
> --- a/include/qemu/dsa.h
> +++ b/include/qemu/dsa.h
> @@ -13,6 +13,34 @@
> #include
> #include "x86intrin.h"
>
> +typedef enum DsaTaskType {
> +DSA_TASK = 0,
> +DSA_BATCH_TASK
> +} DsaTaskType;
> +
> +typedef enum DsaTaskStatus {
> +DSA_TASK_READY = 0,
> +DSA_TASK_PROCESSING,
> +DSA_TASK_COMPLETION
> +} DsaTaskStatus;
> +
> +typedef void (*dsa_completion_fn)(void *);
> +
> +typedef struct dsa_batch_task {
> +struct dsa_hw_desc batch_descriptor;
> +struct dsa_hw_desc *descriptors;
> +struct dsa_completion_record batch_completion
> __attribute__((aligned(32)));
> +struct dsa_completion_record *completions;
> +struct dsa_device_group *group;
> +struct dsa_device *device;
> +dsa_completion_fn completion_callback;
> +QemuSemaphore sem_task_complete;
> +DsaTaskType task_type;
> +DsaTaskStatus status;
> +int batch_size;
> +QSIMPLEQ_ENTRY(dsa_batch_task) entry;
> +} dsa_batch_task;
> +
> /**
> * @brief Initializes DSA devices.
> *
> diff --git a/util/dsa.c b/util/dsa.c
> index 05bbf8e31a..75739a1af6 100644
> --- a/util/dsa.c
> +++ b/util/dsa.c
> @@ -244,6 +244,205 @@ dsa_device_group_get_next_device(struct
> dsa_device_group *group)
> return &group->dsa_devices[current];
> }
>
> +/**
> + * @brief Empties out the DSA task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + */
> +static void
> +dsa_empty_task_queue(struct dsa_device_group *group)
> +{
> +qemu_mutex_lock(&group->task_queue_lock);
> +dsa_task_queue *task_queue = &group->task_queue;
> +while (!QSIMPLEQ_EMPTY(task_queue)) {
> +QSIMPLEQ_REMOVE_HEAD(task_queue, entry);
> +}
> +qemu_mutex_unlock(&group->task_queue_lock);
> +}
> +
> +/**
> + * @brief Adds a task to the DSA task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + * @param context A pointer to the DSA task to enqueue.
> + *
> + * @return int Zero if successful, otherwise a proper error code.
> + */
> +static int
> +dsa_task_enqueue(struct dsa_device_group *group,
> + struct dsa_batch_task *task)
> +{
> +dsa_task_queue *task_queue = &group->task_queue;
> +QemuMutex *task_queue_lock = &group->task_queue_lock;
> +QemuCond *task_queue_cond = &group->task_queue_cond;
> +
> +bool notify = false;
> +
> +qemu_mutex_lock(task_queue_lock);
> +
> +if (!group->running) {
> +error_report("DSA: Tried to queue task to stopped device queue.");
> +qemu_mutex_unlock(task_queue_lock);
> +return -1;
> +}
> +
> +/* The queue is empty. This enqueue operation is a 0->1 transition. */
> +if (QSIMPLEQ_EMPTY(task_queue)) {
> +notify = true;
> +}
> +
> +QSIMPLEQ_INSERT_TAIL(task_queue, task, entry);
> +
> +/* We need to notify the waiter for 0->1 transitions. */
> +if (notify) {
> +qemu_cond_signal(task_queue_cond);
> +}
> +
> +qemu_mutex_unlock(task_queue_lock);
> +
> +return 0;
> +}
> +
> +/**
> + * @brief Takes a DSA task out of the task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + * @return dsa_batch_task* The DSA task being dequeued.
> + */
> +__attribute__((unused))
> +static struct dsa_batch_task *
> +dsa_task_dequeue(struct dsa_device_group *group)
> +{
> +struct dsa_batch_task *task = NULL;
> +dsa_task_queue *task_queue = &group->task_queue;
> +QemuMutex *task_queue_lock = &group->task_queue_lock;
> +QemuCond *task_queue_cond = &group->task_queue_cond;
> +
> +qemu_mutex_lock(task_queue_lock);
> +
> +while (true) {
> +if (!group->running) {
> +goto exit;
> +}
> +task = QSIMPLEQ_FIRST(task_queue);
> +if (task != NULL) {
> +break;
> +}
> +qemu_cond_wait(task_queue_cond, task_queue_lock);
> +}
> +
> +QSIMPLEQ_REMOVE_HEAD(task_queue, entry);
> +
> +exit:
> +qemu_mutex_unlock(task_queue_lock);
> +return task;
> +}
> +
> +/**
> + * @brief Submits a DSA work item to the device work queue.
> + *
> + * @param wq A pointer to the DSA work queue's device memory.
> + * @param descriptor A pointer to the DSA work item descriptor.
> + *
> + * @return Zero if successful, non-zero otherwise.
> + */
> +static int
> +submit_wi_int(void *wq, struct dsa_hw_desc *descriptor)
> +{
> +uint64_t retry = 0;
> +
> +_mm_sfence();
> +
> +while (true) {
> +if (_enqcmd(wq, descriptor) == 0) {
> +break;
> +}
> +retry++;
> +if (retry > max_retry_count) {
Yo
[PULL 2/2] nbd/server: Mark negotiation functions as coroutine_fn
nbd_negotiate() is already marked coroutine_fn. And given the fix in
the previous patch to have nbd_negotiate_handle_starttls not create
and wait on a g_main_loop (as that would violate coroutine
constraints), it is worth marking the rest of the related static
functions reachable only during option negotiation as also being
coroutine_fn.
Suggested-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Eric Blake
Message-ID: <20240408160214.1200629-6-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
[eblake: drop one spurious coroutine_fn marking]
Signed-off-by: Eric Blake
---
nbd/server.c | 102 +--
1 file changed, 59 insertions(+), 43 deletions(-)
diff --git a/nbd/server.c b/nbd/server.c
index 98ae0e16326..892797bb111 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -195,8 +195,9 @@ static inline void set_be_option_rep(NBDOptionReply *rep,
uint32_t option,
/* Send a reply header, including length, but no payload.
* Return -errno on error, 0 on success. */
-static int nbd_negotiate_send_rep_len(NBDClient *client, uint32_t type,
- uint32_t len, Error **errp)
+static coroutine_fn int
+nbd_negotiate_send_rep_len(NBDClient *client, uint32_t type,
+ uint32_t len, Error **errp)
{
NBDOptionReply rep;
@@ -211,15 +212,15 @@ static int nbd_negotiate_send_rep_len(NBDClient *client,
uint32_t type,
/* Send a reply header with default 0 length.
* Return -errno on error, 0 on success. */
-static int nbd_negotiate_send_rep(NBDClient *client, uint32_t type,
- Error **errp)
+static coroutine_fn int
+nbd_negotiate_send_rep(NBDClient *client, uint32_t type, Error **errp)
{
return nbd_negotiate_send_rep_len(client, type, 0, errp);
}
/* Send an error reply.
* Return -errno on error, 0 on success. */
-static int G_GNUC_PRINTF(4, 0)
+static coroutine_fn int G_GNUC_PRINTF(4, 0)
nbd_negotiate_send_rep_verr(NBDClient *client, uint32_t type,
Error **errp, const char *fmt, va_list va)
{
@@ -259,7 +260,7 @@ nbd_sanitize_name(const char *name)
/* Send an error reply.
* Return -errno on error, 0 on success. */
-static int G_GNUC_PRINTF(4, 5)
+static coroutine_fn int G_GNUC_PRINTF(4, 5)
nbd_negotiate_send_rep_err(NBDClient *client, uint32_t type,
Error **errp, const char *fmt, ...)
{
@@ -275,7 +276,7 @@ nbd_negotiate_send_rep_err(NBDClient *client, uint32_t type,
/* Drop remainder of the current option, and send a reply with the
* given error type and message. Return -errno on read or write
* failure; or 0 if connection is still live. */
-static int G_GNUC_PRINTF(4, 0)
+static coroutine_fn int G_GNUC_PRINTF(4, 0)
nbd_opt_vdrop(NBDClient *client, uint32_t type, Error **errp,
const char *fmt, va_list va)
{
@@ -288,7 +289,7 @@ nbd_opt_vdrop(NBDClient *client, uint32_t type, Error
**errp,
return ret;
}
-static int G_GNUC_PRINTF(4, 5)
+static coroutine_fn int G_GNUC_PRINTF(4, 5)
nbd_opt_drop(NBDClient *client, uint32_t type, Error **errp,
const char *fmt, ...)
{
@@ -302,7 +303,7 @@ nbd_opt_drop(NBDClient *client, uint32_t type, Error **errp,
return ret;
}
-static int G_GNUC_PRINTF(3, 4)
+static coroutine_fn int G_GNUC_PRINTF(3, 4)
nbd_opt_invalid(NBDClient *client, Error **errp, const char *fmt, ...)
{
int ret;
@@ -319,8 +320,9 @@ nbd_opt_invalid(NBDClient *client, Error **errp, const char
*fmt, ...)
* If @check_nul, require that no NUL bytes appear in buffer.
* Return -errno on I/O error, 0 if option was completely handled by
* sending a reply about inconsistent lengths, or 1 on success. */
-static int nbd_opt_read(NBDClient *client, void *buffer, size_t size,
-bool check_nul, Error **errp)
+static coroutine_fn int
+nbd_opt_read(NBDClient *client, void *buffer, size_t size,
+ bool check_nul, Error **errp)
{
if (size > client->optlen) {
return nbd_opt_invalid(client, errp,
@@ -343,7 +345,8 @@ static int nbd_opt_read(NBDClient *client, void *buffer,
size_t size,
/* Drop size bytes from the unparsed payload of the current option.
* Return -errno on I/O error, 0 if option was completely handled by
* sending a reply about inconsistent lengths, or 1 on success. */
-static int nbd_opt_skip(NBDClient *client, size_t size, Error **errp)
+static coroutine_fn int
+nbd_opt_skip(NBDClient *client, size_t size, Error **errp)
{
if (size > client->optlen) {
return nbd_opt_invalid(client, errp,
@@ -366,8 +369,9 @@ static int nbd_opt_skip(NBDClient *client, size_t size,
Error **errp)
* Return -errno on I/O error, 0 if option was completely handled by
* sending a reply about inconsistent lengths, or 1 on success.
*/
-static int nbd_opt_read_name(NBDClient *client, char **name, uint32_t *length,
- Error **errp)
+static coroutine_fn int
+nbd_opt_rea
[PULL 1/2] nbd/server: do not poll within a coroutine context
From: Zhu Yangyang
Coroutines are not supposed to block. Instead, they should yield.
The client performs TLS upgrade outside of an AIOContext, during
synchronous handshake; this still requires g_main_loop. But the
server responds to TLS upgrade inside a coroutine, so a nested
g_main_loop is wrong. Since the two callbacks no longer share more
than the setting of data.complete and data.error, it's just as easy to
use static helpers instead of trying to share a common code path. It
is also possible to add assertions that no other code is interfering
with the eventual path to qio reaching the callback, whether or not it
required a yield or main loop.
Fixes: f95910f ("nbd: implement TLS support in the protocol negotiation")
Signed-off-by: Zhu Yangyang
[eblake: move callbacks to their use point, add assertions]
Signed-off-by: Eric Blake
Message-ID: <20240408160214.1200629-5-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
nbd/nbd-internal.h | 10 --
nbd/client.c | 28
nbd/common.c | 11 ---
nbd/server.c | 28 +++-
4 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/nbd/nbd-internal.h b/nbd/nbd-internal.h
index dfa02f77ee4..91895106a95 100644
--- a/nbd/nbd-internal.h
+++ b/nbd/nbd-internal.h
@@ -72,16 +72,6 @@ static inline int nbd_write(QIOChannel *ioc, const void
*buffer, size_t size,
return qio_channel_write_all(ioc, buffer, size, errp) < 0 ? -EIO : 0;
}
-struct NBDTLSHandshakeData {
-GMainLoop *loop;
-bool complete;
-Error *error;
-};
-
-
-void nbd_tls_handshake(QIOTask *task,
- void *opaque);
-
int nbd_drop(QIOChannel *ioc, size_t size, Error **errp);
#endif
diff --git a/nbd/client.c b/nbd/client.c
index 29ffc609a4b..c89c7504673 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -596,13 +596,31 @@ static int nbd_request_simple_option(QIOChannel *ioc, int
opt, bool strict,
return 1;
}
+/* Callback to learn when QIO TLS upgrade is complete */
+struct NBDTLSClientHandshakeData {
+bool complete;
+Error *error;
+GMainLoop *loop;
+};
+
+static void nbd_client_tls_handshake(QIOTask *task, void *opaque)
+{
+struct NBDTLSClientHandshakeData *data = opaque;
+
+qio_task_propagate_error(task, &data->error);
+data->complete = true;
+if (data->loop) {
+g_main_loop_quit(data->loop);
+}
+}
+
static QIOChannel *nbd_receive_starttls(QIOChannel *ioc,
QCryptoTLSCreds *tlscreds,
const char *hostname, Error **errp)
{
int ret;
QIOChannelTLS *tioc;
-struct NBDTLSHandshakeData data = { 0 };
+struct NBDTLSClientHandshakeData data = { 0 };
ret = nbd_request_simple_option(ioc, NBD_OPT_STARTTLS, true, errp);
if (ret <= 0) {
@@ -619,18 +637,20 @@ static QIOChannel *nbd_receive_starttls(QIOChannel *ioc,
return NULL;
}
qio_channel_set_name(QIO_CHANNEL(tioc), "nbd-client-tls");
-data.loop = g_main_loop_new(g_main_context_default(), FALSE);
trace_nbd_receive_starttls_tls_handshake();
qio_channel_tls_handshake(tioc,
- nbd_tls_handshake,
+ nbd_client_tls_handshake,
&data,
NULL,
NULL);
if (!data.complete) {
+data.loop = g_main_loop_new(g_main_context_default(), FALSE);
g_main_loop_run(data.loop);
+assert(data.complete);
+g_main_loop_unref(data.loop);
}
-g_main_loop_unref(data.loop);
+
if (data.error) {
error_propagate(errp, data.error);
object_unref(OBJECT(tioc));
diff --git a/nbd/common.c b/nbd/common.c
index 3247c1d618a..589a748cfe6 100644
--- a/nbd/common.c
+++ b/nbd/common.c
@@ -47,17 +47,6 @@ int nbd_drop(QIOChannel *ioc, size_t size, Error **errp)
}
-void nbd_tls_handshake(QIOTask *task,
- void *opaque)
-{
-struct NBDTLSHandshakeData *data = opaque;
-
-qio_task_propagate_error(task, &data->error);
-data->complete = true;
-g_main_loop_quit(data->loop);
-}
-
-
const char *nbd_opt_lookup(uint32_t opt)
{
switch (opt) {
diff --git a/nbd/server.c b/nbd/server.c
index c3484cc1ebc..98ae0e16326 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -748,6 +748,23 @@ static int nbd_negotiate_handle_info(NBDClient *client,
Error **errp)
return rc;
}
+/* Callback to learn when QIO TLS upgrade is complete */
+struct NBDTLSServerHandshakeData {
+bool complete;
+Error *error;
+Coroutine *co;
+};
+
+static void nbd_server_tls_handshake(QIOTask *task, void *opaque)
+{
+struct NBDTLSServerHandshakeData *data = opaque;
+
+qio_task_propagate_error(task, &data->error);
+data->complete = true;
+if (!qemu_coroutine_entered(data->co)) {
+aio_co_wake(data->co);
+}
+}
/* Handle NBD_OPT_STARTTLS. Retur
[PULL 0/2] NBD patches for 2024-04-25
The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707: Merge tag 'pull-tcg-20240424' of https://gitlab.com/rth7680/qemu into staging (2024-04-24 15:51:49 -0700) are available in the Git repository at: https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2024-04-25 for you to fetch changes up to 4fa333e08dd96395a99ea8dd9e4c73a29dd23344: nbd/server: Mark negotiation functions as coroutine_fn (2024-04-25 12:59:19 -0500) NBD patches for 2024-04-25 - Avoid calling poll() within coroutine Eric Blake (1): nbd/server: Mark negotiation functions as coroutine_fn Zhu Yangyang (1): nbd/server: do not poll within a coroutine context nbd/nbd-internal.h | 10 - nbd/client.c | 28 ++-- nbd/common.c | 11 - nbd/server.c | 128 + 4 files changed, 105 insertions(+), 72 deletions(-) -- 2.44.0
Re: [PATCH v4 03/14] util/dsa: Implement DSA device start and stop logic.
Hao Xiang writes:
> * DSA device open and close.
> * DSA group contains multiple DSA devices.
> * DSA group configure/start/stop/clean.
>
> Signed-off-by: Hao Xiang
> Signed-off-by: Bryan Zhang
> ---
> include/qemu/dsa.h | 72 +++
> util/dsa.c | 316 +
> util/meson.build | 1 +
> 3 files changed, 389 insertions(+)
> create mode 100644 include/qemu/dsa.h
> create mode 100644 util/dsa.c
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> new file mode 100644
> index 00..f15c05ee85
> --- /dev/null
> +++ b/include/qemu/dsa.h
> @@ -0,0 +1,72 @@
> +#ifndef QEMU_DSA_H
> +#define QEMU_DSA_H
> +
> +#include "qemu/error-report.h"
> +#include "qemu/thread.h"
> +#include "qemu/queue.h"
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
> +
> +#include
> +#include "x86intrin.h"
> +
> +/**
> + * @brief Initializes DSA devices.
> + *
> + * @param dsa_parameter A list of DSA device path from migration parameter.
> + *
> + * @return int Zero if successful, otherwise non zero.
> + */
> +int dsa_init(const char *dsa_parameter);
> +
> +/**
> + * @brief Start logic to enable using DSA.
> + */
> +void dsa_start(void);
> +
> +/**
> + * @brief Stop the device group and the completion thread.
> + */
> +void dsa_stop(void);
> +
> +/**
> + * @brief Clean up system resources created for DSA offloading.
> + */
> +void dsa_cleanup(void);
> +
> +/**
> + * @brief Check if DSA is running.
> + *
> + * @return True if DSA is running, otherwise false.
> + */
> +bool dsa_is_running(void);
> +
> +#else
> +
> +static inline bool dsa_is_running(void)
> +{
> +return false;
> +}
> +
> +static inline int dsa_init(const char *dsa_parameter)
> +{
> +if (dsa_parameter != NULL && strlen(dsa_parameter) != 0) {
> +error_report("DSA not supported.");
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +static inline void dsa_start(void) {}
> +
> +static inline void dsa_stop(void) {}
> +
> +static inline void dsa_cleanup(void) {}
> +
> +#endif
> +
> +#endif
> diff --git a/util/dsa.c b/util/dsa.c
> new file mode 100644
> index 00..05bbf8e31a
> --- /dev/null
> +++ b/util/dsa.c
> @@ -0,0 +1,316 @@
> +/*
> + * Use Intel Data Streaming Accelerator to offload certain background
> + * operations.
> + *
> + * Copyright (c) 2023 Hao Xiang
> + *Bryan Zhang
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/queue.h"
> +#include "qemu/memalign.h"
> +#include "qemu/lockable.h"
> +#include "qemu/cutils.h"
> +#include "qemu/dsa.h"
> +#include "qemu/bswap.h"
> +#include "qemu/error-report.h"
> +#include "qemu/rcu.h"
> +
> +#ifdef CONFIG_DSA_OPT
This should be done in meson.build. Here you're allowing an empty object
to be generated just so we can expose the struct batch_task to
multifd. In another patch I suggested we stop using it, then we can put
the whole dsa.c under CONFIG_DSA (we can drop the OPT as well) in
meson.build.
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
> +
> +#include
> +#include "x86intrin.h"
> +
> +#define DSA_WQ_SIZE 4096
> +#define MAX_DSA_DEVICES 16
> +
> +typedef QSIMPLEQ_HEAD(dsa_task_queue, dsa_batch_task) dsa_task_queue;
> +
> +struct dsa_device {
> +void *work_queue;
> +};
> +
> +struct dsa_device_group {
> +struct dsa_device *dsa_devices;
> +int num_dsa_devices;
> +/* The index of the next DSA device to be used. */
> +uint32_t device_allocator_index;
> +bool running;
> +QemuMutex task_queue_lock;
> +QemuCond task_queue_cond;
> +dsa_task_queue task_queue;
> +};
> +
> +uint64_t max_retry_count;
> +static struct dsa_device_group dsa_group;
> +
> +
> +/**
> + * @brief This function opens a DSA device's work queue and
> + *maps the DSA device memory into the current process.
>
Re: [PATCH 0/3] Make it possible to compile the x86 binaries without FDC
Hi Thomas, On 25/4/24 20:43, Thomas Huth wrote: For downstream versions of QEMU, we'd like to be able to compile QEMU without the FDC code included (since it's not required for modern VMs anymore and the FDC code has rather a bad reputation, see the VENOM CVE). IIRC you still need to keep the i440fx+piix machine DS due to migration compatibility, right? Are you able to migrate a VM booted with FDC to a non-FDC one? The q35 machine can already be instantiated without FDC, but for being able to link a binary without the FDC code, the Kconfig file needs some tweaks and there are two spots in the pc code that directly call functions from the FDC code - those need to be disabled via #ifdefs. Is it useful to you to have q35 without FDC but i440fx+piix with? Or are you removing it from i440fx+piix due to shared code with q35? The third patch changes the i440fx and isapc machine types so that they can work without the FDC device, too, in case it has not been compiled into the binary. It's marked as RFC since I assume that the FDC was originally a fix compononent of these motherboards, so I'm unsure whether we should allow the disablement there. OTOH, it seems to work fine, and the FDC is only disabled when it is not available in the binary, so I hope this patch is fine, too. Thomas Huth (3): hw/i386/pc: Allow to compile without CONFIG_FDC_ISA hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA hw/i386: Add the possibility to use i440fx and isapc without FDC hw/i386/pc.c | 13 + hw/i386/pc_piix.c | 6 -- hw/i386/Kconfig | 2 +- 3 files changed, 14 insertions(+), 7 deletions(-)
Re: [PATCH v4 04/14] util/dsa: Implement DSA task enqueue and dequeue.
Hao Xiang writes:
> * Use a safe thread queue for DSA task enqueue/dequeue.
> * Implement DSA task submission.
> * Implement DSA batch task submission.
>
> Signed-off-by: Hao Xiang
> ---
> include/qemu/dsa.h | 28 +++
> util/dsa.c | 201 +
> 2 files changed, 229 insertions(+)
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> index f15c05ee85..37cae8d9d2 100644
> --- a/include/qemu/dsa.h
> +++ b/include/qemu/dsa.h
> @@ -13,6 +13,34 @@
> #include
> #include "x86intrin.h"
>
> +typedef enum DsaTaskType {
> +DSA_TASK = 0,
> +DSA_BATCH_TASK
> +} DsaTaskType;
> +
> +typedef enum DsaTaskStatus {
> +DSA_TASK_READY = 0,
> +DSA_TASK_PROCESSING,
> +DSA_TASK_COMPLETION
> +} DsaTaskStatus;
> +
> +typedef void (*dsa_completion_fn)(void *);
> +
> +typedef struct dsa_batch_task {
> +struct dsa_hw_desc batch_descriptor;
> +struct dsa_hw_desc *descriptors;
> +struct dsa_completion_record batch_completion
> __attribute__((aligned(32)));
> +struct dsa_completion_record *completions;
> +struct dsa_device_group *group;
> +struct dsa_device *device;
> +dsa_completion_fn completion_callback;
> +QemuSemaphore sem_task_complete;
> +DsaTaskType task_type;
> +DsaTaskStatus status;
> +int batch_size;
> +QSIMPLEQ_ENTRY(dsa_batch_task) entry;
> +} dsa_batch_task;
> +
> /**
> * @brief Initializes DSA devices.
> *
> diff --git a/util/dsa.c b/util/dsa.c
> index 05bbf8e31a..75739a1af6 100644
> --- a/util/dsa.c
> +++ b/util/dsa.c
> @@ -244,6 +244,205 @@ dsa_device_group_get_next_device(struct
> dsa_device_group *group)
> return &group->dsa_devices[current];
> }
>
> +/**
> + * @brief Empties out the DSA task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + */
> +static void
> +dsa_empty_task_queue(struct dsa_device_group *group)
> +{
> +qemu_mutex_lock(&group->task_queue_lock);
> +dsa_task_queue *task_queue = &group->task_queue;
> +while (!QSIMPLEQ_EMPTY(task_queue)) {
> +QSIMPLEQ_REMOVE_HEAD(task_queue, entry);
> +}
> +qemu_mutex_unlock(&group->task_queue_lock);
> +}
> +
> +/**
> + * @brief Adds a task to the DSA task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + * @param context A pointer to the DSA task to enqueue.
This is wrong^
> + *
> + * @return int Zero if successful, otherwise a proper error code.
> + */
> +static int
> +dsa_task_enqueue(struct dsa_device_group *group,
> + struct dsa_batch_task *task)
> +{
> +dsa_task_queue *task_queue = &group->task_queue;
> +QemuMutex *task_queue_lock = &group->task_queue_lock;
> +QemuCond *task_queue_cond = &group->task_queue_cond;
It's more idiomatic to not hold any of these in a variable, just access
them directly.
> +
> +bool notify = false;
> +
> +qemu_mutex_lock(task_queue_lock);
> +
> +if (!group->running) {
> +error_report("DSA: Tried to queue task to stopped device queue.");
> +qemu_mutex_unlock(task_queue_lock);
> +return -1;
> +}
> +
> +/* The queue is empty. This enqueue operation is a 0->1 transition. */
> +if (QSIMPLEQ_EMPTY(task_queue)) {
> +notify = true;
> +}
> +
> +QSIMPLEQ_INSERT_TAIL(task_queue, task, entry);
> +
> +/* We need to notify the waiter for 0->1 transitions. */
> +if (notify) {
> +qemu_cond_signal(task_queue_cond);
> +}
> +
> +qemu_mutex_unlock(task_queue_lock);
> +
> +return 0;
> +}
> +
> +/**
> + * @brief Takes a DSA task out of the task queue.
> + *
> + * @param group A pointer to the DSA device group.
> + * @return dsa_batch_task* The DSA task being dequeued.
> + */
> +__attribute__((unused))
> +static struct dsa_batch_task *
> +dsa_task_dequeue(struct dsa_device_group *group)
> +{
> +struct dsa_batch_task *task = NULL;
> +dsa_task_queue *task_queue = &group->task_queue;
> +QemuMutex *task_queue_lock = &group->task_queue_lock;
> +QemuCond *task_queue_cond = &group->task_queue_cond;
Same here.
> +
> +qemu_mutex_lock(task_queue_lock);
> +
> +while (true) {
> +if (!group->running) {
> +goto exit;
> +}
> +task = QSIMPLEQ_FIRST(task_queue);
> +if (task != NULL) {
> +break;
> +}
> +qemu_cond_wait(task_queue_cond, task_queue_lock);
> +}
> +
> +QSIMPLEQ_REMOVE_HEAD(task_queue, entry);
> +
> +exit:
> +qemu_mutex_unlock(task_queue_lock);
> +return task;
> +}
> +
> +/**
> + * @brief Submits a DSA work item to the device work queue.
> + *
> + * @param wq A pointer to the DSA work queue's device memory.
> + * @param descriptor A pointer to the DSA work item descriptor.
> + *
> + * @return Zero if successful, non-zero otherwise.
> + */
> +static int
> +submit_wi_int(void *wq, struct dsa_hw_desc *descriptor)
> +{
> +uint64_t retry = 0;
> +
> +_mm_sfence();
> +
> +while (true) {
> +if (_enqcmd(wq, d
Re: [PATCH v4 02/14] util/dsa: Add dependency idxd.
Hao Xiang writes: > Idxd is the device driver for DSA (Intel Data Streaming > Accelerator). The driver is fully functioning since Linux > kernel 5.19. This change adds the driver's header file used > for userspace development. Have you looked at the update-linux-headers script?
Re: [PATCH v3 4/4] qapi: introduce exit-on-error parameter for migrate-incoming
Vladimir Sementsov-Ogievskiy writes:
> Now we do set MIGRATION_FAILED state, but don't give a chance to
> orchestrator to query migration state and get the error.
>
> Let's provide a possibility for QMP-based orchestrators to get an error
> like with outgoing migration.
>
> For hmp_migrate_incoming(), let's enable the new behavior: HMP is not
> and ABI, it's mostly intended to use by developer and it makes sense
> not to stop the process.
>
> For x-exit-preconfig, let's keep the old behavior:
> - it's called from init(), so here we want to keep current behavior by
>default
> - it does exit on error by itself as well
> So, if we want to change the behavior of x-exit-preconfig, it should be
> another patch.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> migration/migration-hmp-cmds.c | 2 +-
> migration/migration.c | 36 --
> migration/migration.h | 3 +++
> qapi/migration.json| 7 ++-
> system/vl.c| 3 ++-
> 5 files changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
> index 7e96ae6ffd..23181bbee1 100644
> --- a/migration/migration-hmp-cmds.c
> +++ b/migration/migration-hmp-cmds.c
> @@ -466,7 +466,7 @@ void hmp_migrate_incoming(Monitor *mon, const QDict
> *qdict)
> }
> QAPI_LIST_PREPEND(caps, g_steal_pointer(&channel));
>
> -qmp_migrate_incoming(NULL, true, caps, &err);
> +qmp_migrate_incoming(NULL, true, caps, true, false, &err);
> qapi_free_MigrationChannelList(caps);
>
> end:
> diff --git a/migration/migration.c b/migration/migration.c
> index 0b15f7ccf4..5cfe420a76 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -72,6 +72,8 @@
> #define NOTIFIER_ELEM_INIT(array, elem)\
> [elem] = NOTIFIER_WITH_RETURN_LIST_INITIALIZER((array)[elem])
>
> +#define INMIGRATE_DEFAULT_EXIT_ON_ERROR true
> +
> static NotifierWithReturnList migration_state_notifiers[] = {
> NOTIFIER_ELEM_INIT(migration_state_notifiers, MIG_MODE_NORMAL),
> NOTIFIER_ELEM_INIT(migration_state_notifiers, MIG_MODE_CPR_REBOOT),
> @@ -234,6 +236,8 @@ void migration_object_init(void)
> qemu_cond_init(¤t_incoming->page_request_cond);
> current_incoming->page_requested = g_tree_new(page_request_addr_cmp);
>
> +current_incoming->exit_on_error = INMIGRATE_DEFAULT_EXIT_ON_ERROR;
> +
> migration_object_check(current_migration, &error_fatal);
>
> blk_mig_init();
> @@ -797,13 +801,18 @@ fail:
>MIGRATION_STATUS_FAILED);
> migration_incoming_state_destroy();
>
> -if (migrate_has_error(s)) {
> -WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
> -error_report_err(s->error);
> +if (mis->exit_on_error) {
> +if (migrate_has_error(s)) {
> +WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
> +error_report_err(s->error);
error_report_err(error_copy(s->error))
...because later on you're reading from s->error at
fill_destination_migration_info.
> +}
> }
> +error_report_err(local_err);
migrate_error_free(s);
> +exit(EXIT_FAILURE);
> +} else {
> +migrate_set_error(s, local_err);
> +error_free(local_err);
> }
> -error_report_err(local_err);
> -exit(EXIT_FAILURE);
> }
>
> /**
> @@ -1312,6 +1321,15 @@ static void
> fill_destination_migration_info(MigrationInfo *info)
> break;
> }
> info->status = mis->state;
> +
> +if (!info->error_desc) {
> +MigrationState *s = migrate_get_current();
> +QEMU_LOCK_GUARD(&s->error_mutex);
> +
> +if (s->error) {
> +info->error_desc = g_strdup(error_get_pretty(s->error));
> +}
> +}
> }
>
> MigrationInfo *qmp_query_migrate(Error **errp)
> @@ -1795,10 +1813,13 @@ void migrate_del_blocker(Error **reasonp)
> }
>
> void qmp_migrate_incoming(const char *uri, bool has_channels,
> - MigrationChannelList *channels, Error **errp)
> + MigrationChannelList *channels,
> + bool has_exit_on_error, bool exit_on_error,
> + Error **errp)
> {
> Error *local_err = NULL;
> static bool once = true;
> +MigrationIncomingState *mis = migration_incoming_get_current();
>
> if (!once) {
> error_setg(errp, "The incoming migration has already been started");
> @@ -1813,6 +1834,9 @@ void qmp_migrate_incoming(const char *uri, bool
> has_channels,
> return;
> }
>
> +mis->exit_on_error =
> +has_exit_on_error ? exit_on_error : INMIGRATE_DEFAULT_EXIT_ON_ERROR;
> +
> qemu_start_incoming_migration(uri, has_channels, channels, &local_err);
>
> if (local_err) {
> diff --git a/migration/migration.h b/migration/migration.h
> index 8045e39c26..95995a818e 100644
> --- a/migration/migration.h
> +++ b/migration/mi
Re: [PATCH v3 3/4] migration: process_incoming_migration_co(): rework error reporting
Vladimir Sementsov-Ogievskiy writes: > Unify error reporting in the function. This simplifies the following > commit, which will not-exit-on-error behavior variant to the function. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Fabiano Rosas
Re: [PATCH v3 2/4] migration: process_incoming_migration_co(): complete cleanup on failure
Vladimir Sementsov-Ogievskiy writes: > Make call to migration_incoming_state_destroy(), instead of doing only > partial of it. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Fabiano Rosas
Re: [PATCH v3 1/4] migration: move trace-point from migrate_fd_error to migrate_set_error
Vladimir Sementsov-Ogievskiy writes: > Cover more cases by trace-point. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Fabiano Rosas
Re: [PATCH] tests/avocado: update sunxi kernel from armbian to 6.6.16
Whoops, forgot to cc the allwinner maintainers/reviewers on this.
Ping for review, please?
thanks
-- PMM
On Mon, 15 Apr 2024 at 16:18, Peter Maydell wrote:
>
> The Linux kernel 5.10.16 binary for sunxi has been removed from
> apt.armbian.com. This means that the avocado tests for these machines
> will be skipped (status CANCEL) if the old binary isn't present in
> the avocado cache.
>
> Update to 6.6.16, in the same way we did in commit e384db41d8661
> when we moved to 5.10.16 in 2021.
>
> Cc: qemu-sta...@nongnu.org
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2284
> Signed-off-by: Peter Maydell
> ---
> At this point in the release cycle I don't think I really want
> to put this into 9.0, though I could just about squeeze it in.
>
> cc'ing stable as an FYI -- since the tests fall back to the
> CANCEL status this doesn't break CI, so it's not a requirement
> to backport to any stable branches. But it would probably be
> preferable to get the coverage back on the stable branches so
> we can detect if we get something wrong on a backport of a
> patch that affects these machines.
> ---
> tests/avocado/boot_linux_console.py | 70 ++---
> tests/avocado/replay_kernel.py | 8 ++--
> 2 files changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/tests/avocado/boot_linux_console.py
> b/tests/avocado/boot_linux_console.py
> index 989b65111c0..d0ab5aaa83a 100644
> --- a/tests/avocado/boot_linux_console.py
> +++ b/tests/avocado/boot_linux_console.py
> @@ -646,12 +646,12 @@ def test_arm_cubieboard_initrd(self):
> :avocado: tags=accel:tcg
> """
> deb_url = ('https://apt.armbian.com/pool/main/l/'
> -
> 'linux-5.10.16-sunxi/linux-image-current-sunxi_21.02.2_armhf.deb')
> -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> +
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> kernel_path = self.extract_from_deb(deb_path,
> -'/boot/vmlinuz-5.10.16-sunxi')
> -dtb_path =
> '/usr/lib/linux-image-current-sunxi/sun4i-a10-cubieboard.dtb'
> +
> '/boot/vmlinuz-6.6.16-current-sunxi')
> +dtb_path =
> '/usr/lib/linux-image-6.6.16-current-sunxi/sun4i-a10-cubieboard.dtb'
> dtb_path = self.extract_from_deb(deb_path, dtb_path)
> initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
>'2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> @@ -690,12 +690,12 @@ def test_arm_cubieboard_sata(self):
> :avocado: tags=accel:tcg
> """
> deb_url = ('https://apt.armbian.com/pool/main/l/'
> -
> 'linux-5.10.16-sunxi/linux-image-current-sunxi_21.02.2_armhf.deb')
> -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> +
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> kernel_path = self.extract_from_deb(deb_path,
> -'/boot/vmlinuz-5.10.16-sunxi')
> -dtb_path =
> '/usr/lib/linux-image-current-sunxi/sun4i-a10-cubieboard.dtb'
> +
> '/boot/vmlinuz-6.6.16-current-sunxi')
> +dtb_path =
> '/usr/lib/linux-image-6.6.16-current-sunxi/sun4i-a10-cubieboard.dtb'
> dtb_path = self.extract_from_deb(deb_path, dtb_path)
> rootfs_url = ('https://github.com/groeck/linux-build-test/raw/'
>'2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> @@ -872,13 +872,13 @@ def test_arm_bpim2u(self):
> :avocado: tags=machine:bpim2u
> :avocado: tags=accel:tcg
> """
> -deb_url = ('https://apt.armbian.com/pool/main/l/linux-5.10.16-sunxi/'
> - 'linux-image-current-sunxi_21.02.2_armhf.deb')
> -deb_hash = '9fa84beda245cabf0b4fa84cf6eaa7738ead1da0'
> +deb_url = ('https://apt.armbian.com/pool/main/l/'
> +
> 'linux-6.6.16/linux-image-current-sunxi_24.2.1_armhf__6.6.16-Seb3e-D6b4a-P2359-Ce96bHfe66-HK01ba-V014b-B067e-R448a.deb')
> +deb_hash = 'f7c3c8c5432f765445dc6e7eab02f3bbe668256b'
> deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> kernel_path = self.extract_from_deb(deb_path,
> -'/boot/vmlinuz-5.10.16-sunxi')
> -dtb_path = ('/usr/lib/linux-image-current-sunxi/'
> +
> '/boot/vmlinuz-6.6.16-current-sunxi')
> +dtb_path = ('/usr/lib/linux-imag
Re: [PATCH] fix bit fields extraction and prevent overflow
On Wed, 24 Apr 2024 at 19:13, Alexandra Diupina wrote: > > Add a type cast and use extract64() instead of extract32() > to avoid integer overflow on addition. Fix bit fields > extraction according to documentation. The commit message here says we make the handling of the address_extension fields match the documentation, and the version of the fixes to this function in the patch "[PATCH v2 RFC] fix host-endianness bug and prevent overflow" did that, but here we seem to have gone back to not changing the shift amounts. We also need to extract all 16 bits of the address_extension fields, not just 12, according to the datasheet. thanks -- PMM
Re: [PATCH] target/arm: Restrict translation disabled alignment check to VMSA
On Mon, 22 Apr 2024 at 18:07, Richard Henderson
wrote:
>
> For cpus using PMSA, when the MPU is disabled, the default memory
> type is Normal, Non-cachable.
>
> Fixes: 59754f85ed3 ("target/arm: Do memory type alignment check when
> translation disabled")
> Reported-by: Clément Chigot
> Signed-off-by: Richard Henderson
> ---
>
> Since v9 will likely be tagged tomorrow without this fixed,
> Cc: qemu-sta...@nongnu.org
Applied to target-arm.next (with the cc:stable added in and a couple of
trivial tweaks to the comment/commit message), thanks.
-- PMM
Re: [PATCH] hvf: arm: Remove PL1_WRITE_MASK
On Mon, 22 Apr 2024 at 10:27, Zenghui Yu wrote:
>
> As it had never been used since the first commit a1477da3ddeb ("hvf: Add
> Apple Silicon support").
>
> Signed-off-by: Zenghui Yu
> ---
> target/arm/hvf/hvf.c | 1 -
Applied to target-arm.next, thanks.
-- PMM
Re: [PATCH] hw/core/clock: remove assert in clock_propagate
On Fri, 19 Apr 2024 at 17:30, Raphael Poggi wrote: > > This commit allows childs clock to propagate their new frequency, > for example, after setting a new multiplier/diviser. > > Signed-off-by: Raphael Poggi Applied to target-arm.next, thanks. I rewrote the commit message to document the conversation we had in the other email thread: hw/core/clock: allow clock_propagate on child clocks clock_propagate() has an assert that clk->source is NULL, i.e. that you are calling it on a clock which has no source clock. This made sense in the original design where the only way for a clock's frequency to change if it had a source clock was when that source clock changed. However, we subsequently added multiplier/divider support, but didn't look at what that meant for propagation. If a clock-management device changes the multiplier or divider value on a clock, it needs to propagate that change down to child clocks, even if the clock has a source clock set. So the assertion is now incorrect. Remove the assertion. -- PMM
Re: [PATCH v4 01/14] meson: Introduce new instruction set enqcmd to the build system.
Hao Xiang writes:
> Enable instruction set enqcmd in build.
>
> Signed-off-by: Hao Xiang
> ---
> meson.build | 14 ++
> meson_options.txt | 2 ++
> scripts/meson-buildoptions.sh | 3 +++
> 3 files changed, 19 insertions(+)
>
> diff --git a/meson.build b/meson.build
> index 95cee7046e..9e008ddc34 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -2824,6 +2824,20 @@ config_host_data.set('CONFIG_AVX512BW_OPT',
> get_option('avx512bw') \
> int main(int argc, char *argv[]) { return bar(argv[0]); }
>'''), error_message: 'AVX512BW not available').allowed())
>
> +config_host_data.set('CONFIG_DSA_OPT', get_option('enqcmd') \
> + .require(have_cpuid_h, error_message: 'cpuid.h not available, cannot
> enable ENQCMD') \
> + .require(cc.links('''
> +#include
> +#include
> +#include
> +static int __attribute__((target("enqcmd"))) bar(void *a) {
> + uint64_t dst[8] = { 0 };
> + uint64_t src[8] = { 0 };
> + return _enqcmd(dst, src);
> +}
> +int main(int argc, char *argv[]) { return bar(argv[argc - 1]); }
> + '''), error_message: 'ENQCMD not available').allowed())
> +
> # For both AArch64 and AArch32, detect if builtins are available.
> config_host_data.set('CONFIG_ARM_AES_BUILTIN', cc.compiles('''
> #include
> diff --git a/meson_options.txt b/meson_options.txt
> index b5c0bad9e7..63c1bf815b 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -121,6 +121,8 @@ option('avx512f', type: 'feature', value: 'disabled',
> description: 'AVX512F optimizations')
> option('avx512bw', type: 'feature', value: 'auto',
> description: 'AVX512BW optimizations')
> +option('enqcmd', type: 'feature', value: 'disabled',
> + description: 'MENQCMD optimizations')
s/MENQCMD/ENQCMD/
> option('keyring', type: 'feature', value: 'auto',
> description: 'Linux keyring support')
> option('libkeyutils', type: 'feature', value: 'auto',
> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
> index 5ace33f167..2cdfc84455 100644
> --- a/scripts/meson-buildoptions.sh
> +++ b/scripts/meson-buildoptions.sh
> @@ -93,6 +93,7 @@ meson_options_help() {
>printf "%s\n" ' avx2AVX2 optimizations'
>printf "%s\n" ' avx512bwAVX512BW optimizations'
>printf "%s\n" ' avx512f AVX512F optimizations'
> + printf "%s\n" ' enqcmd ENQCMD optimizations'
>printf "%s\n" ' blkio libblkio block device driver'
>printf "%s\n" ' bochs bochs image format support'
>printf "%s\n" ' bpf eBPF support'
> @@ -239,6 +240,8 @@ _meson_option_parse() {
> --disable-avx512bw) printf "%s" -Davx512bw=disabled ;;
> --enable-avx512f) printf "%s" -Davx512f=enabled ;;
> --disable-avx512f) printf "%s" -Davx512f=disabled ;;
> +--enable-enqcmd) printf "%s" -Denqcmd=enabled ;;
> +--disable-enqcmd) printf "%s" -Denqcmd=disabled ;;
> --enable-gcov) printf "%s" -Db_coverage=true ;;
> --disable-gcov) printf "%s" -Db_coverage=false ;;
> --enable-lto) printf "%s" -Db_lto=true ;;
[PATCH 0/3] Make it possible to compile the x86 binaries without FDC
For downstream versions of QEMU, we'd like to be able to compile QEMU without the FDC code included (since it's not required for modern VMs anymore and the FDC code has rather a bad reputation, see the VENOM CVE). The q35 machine can already be instantiated without FDC, but for being able to link a binary without the FDC code, the Kconfig file needs some tweaks and there are two spots in the pc code that directly call functions from the FDC code - those need to be disabled via #ifdefs. The third patch changes the i440fx and isapc machine types so that they can work without the FDC device, too, in case it has not been compiled into the binary. It's marked as RFC since I assume that the FDC was originally a fix compononent of these motherboards, so I'm unsure whether we should allow the disablement there. OTOH, it seems to work fine, and the FDC is only disabled when it is not available in the binary, so I hope this patch is fine, too. Thomas Huth (3): hw/i386/pc: Allow to compile without CONFIG_FDC_ISA hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA hw/i386: Add the possibility to use i440fx and isapc without FDC hw/i386/pc.c | 13 + hw/i386/pc_piix.c | 6 -- hw/i386/Kconfig | 2 +- 3 files changed, 14 insertions(+), 7 deletions(-) -- 2.44.0
[PATCH 2/3] hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA
The q35 machine can be used without floppy disk controller (FDC), but due to our current Kconfig setup, the FDC code is still always included in the binary. To fix this, the "PC" config option should only imply the "FDC_ISA" instead of always selecting it. The i440fx and the isa-pc machine currently always instantiate the FDC, so we have to add the select statements now there instead. Signed-off-by: Thomas Huth --- hw/i386/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig index a6ee052f9a..0b08580862 100644 --- a/hw/i386/Kconfig +++ b/hw/i386/Kconfig @@ -32,7 +32,7 @@ config PC imply VGA_PCI imply VIRTIO_VGA imply NVDIMM -select FDC_ISA +imply FDC_ISA select I8259 select I8254 select PCKBD @@ -70,6 +70,7 @@ config I440FX imply VMPORT imply VMMOUSE select ACPI_PIIX4 +select FDC_ISA select PC_PCI select PC_ACPI select PCI_I440FX @@ -83,6 +84,7 @@ config ISAPC bool imply VGA_ISA select ISA_BUS +select FDC_ISA select PC select IDE_ISA # FIXME: it is in the same file as i440fx, and does not compile -- 2.44.0
[PATCH 1/3] hw/i386/pc: Allow to compile without CONFIG_FDC_ISA
The q35 machine can work without FDC. But to be able to also link
a QEMU binary that does not include the FDC code, we have to make
it possible to disable the spots that call into the FDC code.
Signed-off-by: Thomas Huth
---
hw/i386/pc.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 08c7de416f..93c48f6747 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -439,16 +439,19 @@ static void pc_boot_set(void *opaque, const char
*boot_device, Error **errp)
static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice *floppy)
{
-int val, nb, i;
+int val, nb;
FloppyDriveType fd_type[2] = { FLOPPY_DRIVE_TYPE_NONE,
FLOPPY_DRIVE_TYPE_NONE };
+#ifdef CONFIG_FDC_ISA
/* floppy type */
if (floppy) {
-for (i = 0; i < 2; i++) {
+for (int i = 0; i < 2; i++) {
fd_type[i] = isa_fdc_get_drive_type(floppy, i);
}
}
+#endif
+
val = (cmos_get_fd_drive_type(fd_type[0]) << 4) |
cmos_get_fd_drive_type(fd_type[1]);
mc146818rtc_set_cmos_data(rtc_state, 0x10, val);
@@ -1132,7 +1135,7 @@ static void pc_superio_init(ISABus *isa_bus, bool
create_fdctrl,
int i;
DriveInfo *fd[MAX_FD];
qemu_irq *a20_line;
-ISADevice *fdc, *i8042, *port92, *vmmouse;
+ISADevice *i8042, *port92, *vmmouse;
serial_hds_isa_init(isa_bus, 0, MAX_ISA_SERIAL_PORTS);
parallel_hds_isa_init(isa_bus, MAX_PARALLEL_PORTS);
@@ -1142,11 +1145,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
create_fdctrl,
create_fdctrl |= !!fd[i];
}
if (create_fdctrl) {
-fdc = isa_new(TYPE_ISA_FDC);
+#ifdef CONFIG_FDC_ISA
+ISADevice *fdc = isa_new(TYPE_ISA_FDC);
if (fdc) {
isa_realize_and_unref(fdc, isa_bus, &error_fatal);
isa_fdc_init_drives(fdc, fd);
}
+#endif
}
if (!create_i8042) {
--
2.44.0
[RFC PATCH 3/3] hw/i386: Add the possibility to use i440fx and isapc without FDC
The i440fx and the isapc machines can be used in binaries without
FDC, too. We just have to make sure that they don't try to instantiate
the FDC when it is not available.
Signed-off-by: Thomas Huth
---
hw/i386/pc_piix.c | 6 --
hw/i386/Kconfig | 2 --
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8850c49c66..99efb3c45c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -317,8 +317,8 @@ static void pc_init1(MachineState *machine, const char
*pci_type)
}
/* init basic PC hardware */
-pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc, true,
- 0x4);
+pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc,
+ !MACHINE_CLASS(pcmc)->no_floppy, 0x4);
pc_nic_init(pcmc, isa_bus, pcms->pcibus);
@@ -501,6 +501,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
m->default_machine_opts = "firmware=bios-256k.bin";
m->default_display = "std";
m->default_nic = "e1000";
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
@@ -931,6 +932,7 @@ static void isapc_machine_options(MachineClass *m)
pcmc->has_reserved_memory = false;
m->default_nic = "ne2k_isa";
m->default_cpu_type = X86_CPU_TYPE_NAME("486");
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
}
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 0b08580862..f2ef6d1ef2 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -70,7 +70,6 @@ config I440FX
imply VMPORT
imply VMMOUSE
select ACPI_PIIX4
-select FDC_ISA
select PC_PCI
select PC_ACPI
select PCI_I440FX
@@ -84,7 +83,6 @@ config ISAPC
bool
imply VGA_ISA
select ISA_BUS
-select FDC_ISA
select PC
select IDE_ISA
# FIXME: it is in the same file as i440fx, and does not compile
--
2.44.0
[PATCH v3 4/4] qapi: introduce exit-on-error parameter for migrate-incoming
Now we do set MIGRATION_FAILED state, but don't give a chance to
orchestrator to query migration state and get the error.
Let's provide a possibility for QMP-based orchestrators to get an error
like with outgoing migration.
For hmp_migrate_incoming(), let's enable the new behavior: HMP is not
and ABI, it's mostly intended to use by developer and it makes sense
not to stop the process.
For x-exit-preconfig, let's keep the old behavior:
- it's called from init(), so here we want to keep current behavior by
default
- it does exit on error by itself as well
So, if we want to change the behavior of x-exit-preconfig, it should be
another patch.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/migration-hmp-cmds.c | 2 +-
migration/migration.c | 36 --
migration/migration.h | 3 +++
qapi/migration.json| 7 ++-
system/vl.c| 3 ++-
5 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index 7e96ae6ffd..23181bbee1 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -466,7 +466,7 @@ void hmp_migrate_incoming(Monitor *mon, const QDict *qdict)
}
QAPI_LIST_PREPEND(caps, g_steal_pointer(&channel));
-qmp_migrate_incoming(NULL, true, caps, &err);
+qmp_migrate_incoming(NULL, true, caps, true, false, &err);
qapi_free_MigrationChannelList(caps);
end:
diff --git a/migration/migration.c b/migration/migration.c
index 0b15f7ccf4..5cfe420a76 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -72,6 +72,8 @@
#define NOTIFIER_ELEM_INIT(array, elem)\
[elem] = NOTIFIER_WITH_RETURN_LIST_INITIALIZER((array)[elem])
+#define INMIGRATE_DEFAULT_EXIT_ON_ERROR true
+
static NotifierWithReturnList migration_state_notifiers[] = {
NOTIFIER_ELEM_INIT(migration_state_notifiers, MIG_MODE_NORMAL),
NOTIFIER_ELEM_INIT(migration_state_notifiers, MIG_MODE_CPR_REBOOT),
@@ -234,6 +236,8 @@ void migration_object_init(void)
qemu_cond_init(¤t_incoming->page_request_cond);
current_incoming->page_requested = g_tree_new(page_request_addr_cmp);
+current_incoming->exit_on_error = INMIGRATE_DEFAULT_EXIT_ON_ERROR;
+
migration_object_check(current_migration, &error_fatal);
blk_mig_init();
@@ -797,13 +801,18 @@ fail:
MIGRATION_STATUS_FAILED);
migration_incoming_state_destroy();
-if (migrate_has_error(s)) {
-WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
-error_report_err(s->error);
+if (mis->exit_on_error) {
+if (migrate_has_error(s)) {
+WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
+error_report_err(s->error);
+}
}
+error_report_err(local_err);
+exit(EXIT_FAILURE);
+} else {
+migrate_set_error(s, local_err);
+error_free(local_err);
}
-error_report_err(local_err);
-exit(EXIT_FAILURE);
}
/**
@@ -1312,6 +1321,15 @@ static void
fill_destination_migration_info(MigrationInfo *info)
break;
}
info->status = mis->state;
+
+if (!info->error_desc) {
+MigrationState *s = migrate_get_current();
+QEMU_LOCK_GUARD(&s->error_mutex);
+
+if (s->error) {
+info->error_desc = g_strdup(error_get_pretty(s->error));
+}
+}
}
MigrationInfo *qmp_query_migrate(Error **errp)
@@ -1795,10 +1813,13 @@ void migrate_del_blocker(Error **reasonp)
}
void qmp_migrate_incoming(const char *uri, bool has_channels,
- MigrationChannelList *channels, Error **errp)
+ MigrationChannelList *channels,
+ bool has_exit_on_error, bool exit_on_error,
+ Error **errp)
{
Error *local_err = NULL;
static bool once = true;
+MigrationIncomingState *mis = migration_incoming_get_current();
if (!once) {
error_setg(errp, "The incoming migration has already been started");
@@ -1813,6 +1834,9 @@ void qmp_migrate_incoming(const char *uri, bool
has_channels,
return;
}
+mis->exit_on_error =
+has_exit_on_error ? exit_on_error : INMIGRATE_DEFAULT_EXIT_ON_ERROR;
+
qemu_start_incoming_migration(uri, has_channels, channels, &local_err);
if (local_err) {
diff --git a/migration/migration.h b/migration/migration.h
index 8045e39c26..95995a818e 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -227,6 +227,9 @@ struct MigrationIncomingState {
* is needed as this field is updated serially.
*/
unsigned int switchover_ack_pending_num;
+
+/* Do exit on incoming migration failure */
+bool exit_on_error;
};
MigrationIncomingState *migration_incoming_get_current(void);
diff --git a/qapi/migration.json b/qapi/migration.json
index 8c65b90328..9de8b98d0b 100644
--- a/qapi/migration.json
+++ b/qapi/migration.
[PATCH v3 0/4] migration: do not exit on incoming failure
Hi all! The series brings an option to not immediately exit on incoming migration failure, giving a possibility to orchestrator to get the error through QAPI and shutdown QEMU by "quit". v3: - don't refactor the whole code around setting migration error, it seems too much and necessary for the new feature itself - add constant - change behavior for HMP command - split some things to separate patches - and more, by Peter's suggestions New behavior can be demonstrated like this: bash: ( cat <
[PATCH v3 1/4] migration: move trace-point from migrate_fd_error to migrate_set_error
Cover more cases by trace-point.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/migration.c | 4 +++-
migration/trace-events | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index b5af6b5105..2dc6a063e9 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1421,6 +1421,9 @@ static void migrate_fd_cleanup_bh(void *opaque)
void migrate_set_error(MigrationState *s, const Error *error)
{
QEMU_LOCK_GUARD(&s->error_mutex);
+
+trace_migrate_error(error_get_pretty(error));
+
if (!s->error) {
s->error = error_copy(error);
}
@@ -1444,7 +1447,6 @@ static void migrate_error_free(MigrationState *s)
static void migrate_fd_error(MigrationState *s, const Error *error)
{
-trace_migrate_fd_error(error_get_pretty(error));
assert(s->to_dst_file == NULL);
migrate_set_state(&s->state, MIGRATION_STATUS_SETUP,
MIGRATION_STATUS_FAILED);
diff --git a/migration/trace-events b/migration/trace-events
index f0e1cb80c7..d0c44c3853 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -152,7 +152,7 @@ multifd_set_outgoing_channel(void *ioc, const char
*ioctype, const char *hostnam
# migration.c
migrate_set_state(const char *new_state) "new state %s"
migrate_fd_cleanup(void) ""
-migrate_fd_error(const char *error_desc) "error=%s"
+migrate_error(const char *error_desc) "error=%s"
migrate_fd_cancel(void) ""
migrate_handle_rp_req_pages(const char *rbname, size_t start, size_t len) "in
%s at 0x%zx len 0x%zx"
migrate_pending_exact(uint64_t size, uint64_t pre, uint64_t post) "exact
pending size %" PRIu64 " (pre = %" PRIu64 " post=%" PRIu64 ")"
--
2.34.1
[PATCH v3 2/4] migration: process_incoming_migration_co(): complete cleanup on failure
Make call to migration_incoming_state_destroy(), instead of doing only partial of it. Signed-off-by: Vladimir Sementsov-Ogievskiy --- migration/migration.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/migration/migration.c b/migration/migration.c index 2dc6a063e9..0d26db47f7 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -799,10 +799,7 @@ process_incoming_migration_co(void *opaque) fail: migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE, MIGRATION_STATUS_FAILED); -qemu_fclose(mis->from_src_file); - -multifd_recv_cleanup(); -compress_threads_load_cleanup(); +migration_incoming_state_destroy(); exit(EXIT_FAILURE); } -- 2.34.1
[PATCH v3 3/4] migration: process_incoming_migration_co(): rework error reporting
Unify error reporting in the function. This simplifies the following
commit, which will not-exit-on-error behavior variant to the function.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/migration.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 0d26db47f7..0b15f7ccf4 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -735,14 +735,16 @@ static void process_incoming_migration_bh(void *opaque)
static void coroutine_fn
process_incoming_migration_co(void *opaque)
{
+MigrationState *s = migrate_get_current();
MigrationIncomingState *mis = migration_incoming_get_current();
PostcopyState ps;
int ret;
+Error *local_err = NULL;
assert(mis->from_src_file);
if (compress_threads_load_setup(mis->from_src_file)) {
-error_report("Failed to setup decompress threads");
+error_setg(&local_err, "Failed to setup decompress threads");
goto fail;
}
@@ -779,18 +781,12 @@ process_incoming_migration_co(void *opaque)
}
if (ret < 0) {
-MigrationState *s = migrate_get_current();
-
-if (migrate_has_error(s)) {
-WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
-error_report_err(s->error);
-}
-}
-error_report("load of migration failed: %s", strerror(-ret));
+error_setg(&local_err, "load of migration failed: %s", strerror(-ret));
goto fail;
}
if (colo_incoming_co() < 0) {
+error_setg(&local_err, "colo incoming failed");
goto fail;
}
@@ -801,6 +797,12 @@ fail:
MIGRATION_STATUS_FAILED);
migration_incoming_state_destroy();
+if (migrate_has_error(s)) {
+WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
+error_report_err(s->error);
+}
+}
+error_report_err(local_err);
exit(EXIT_FAILURE);
}
--
2.34.1
Re: [RFC 1/2] iova_tree: add an id member to DMAMap
On 4/24/2024 12:33 AM, Eugenio Perez Martin wrote:
On Wed, Apr 24, 2024 at 12:21 AM Si-Wei Liu wrote:
On 4/22/2024 1:49 AM, Eugenio Perez Martin wrote:
On Sat, Apr 20, 2024 at 1:50 AM Si-Wei Liu wrote:
On 4/19/2024 1:29 AM, Eugenio Perez Martin wrote:
On Thu, Apr 18, 2024 at 10:46 PM Si-Wei Liu wrote:
On 4/10/2024 3:03 AM, Eugenio Pérez wrote:
IOVA tree is also used to track the mappings of virtio-net shadow
virtqueue. This mappings may not match with the GPA->HVA ones.
This causes a problem when overlapped regions (different GPA but same
translated HVA) exists in the tree, as looking them by HVA will return
them twice. To solve this, create an id member so we can assign unique
identifiers (GPA) to the maps.
Signed-off-by: Eugenio Pérez
---
include/qemu/iova-tree.h | 5 +++--
util/iova-tree.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/qemu/iova-tree.h b/include/qemu/iova-tree.h
index 2a10a7052e..34ee230e7d 100644
--- a/include/qemu/iova-tree.h
+++ b/include/qemu/iova-tree.h
@@ -36,6 +36,7 @@ typedef struct DMAMap {
hwaddr iova;
hwaddr translated_addr;
hwaddr size;/* Inclusive */
+uint64_t id;
IOMMUAccessFlags perm;
} QEMU_PACKED DMAMap;
typedef gboolean (*iova_tree_iterator)(DMAMap *map);
@@ -100,8 +101,8 @@ const DMAMap *iova_tree_find(const IOVATree *tree, const
DMAMap *map);
* @map: the mapping to search
*
* Search for a mapping in the iova tree that translated_addr overlaps
with the
- * mapping range specified. Only the first found mapping will be
- * returned.
+ * mapping range specified and map->id is equal. Only the first found
+ * mapping will be returned.
*
* Return: DMAMap pointer if found, or NULL if not found. Note that
* the returned DMAMap pointer is maintained internally. User should
diff --git a/util/iova-tree.c b/util/iova-tree.c
index 536789797e..0863e0a3b8 100644
--- a/util/iova-tree.c
+++ b/util/iova-tree.c
@@ -97,7 +97,8 @@ static gboolean iova_tree_find_address_iterator(gpointer key,
gpointer value,
needle = args->needle;
if (map->translated_addr + map->size < needle->translated_addr ||
-needle->translated_addr + needle->size < map->translated_addr) {
+needle->translated_addr + needle->size < map->translated_addr ||
+needle->id != map->id) {
It looks this iterator can also be invoked by SVQ from
vhost_svq_translate_addr() -> iova_tree_find_iova(), where guest GPA
space will be searched on without passing in the ID (GPA), and exact
match for the same GPA range is not actually needed unlike the mapping
removal case. Could we create an API variant, for the SVQ lookup case
specifically? Or alternatively, add a special flag, say skip_id_match to
DMAMap, and the id match check may look like below:
(!needle->skip_id_match && needle->id != map->id)
I think vhost_svq_translate_addr() could just call the API variant or
pass DMAmap with skip_id_match set to true to svq_iova_tree_find_iova().
I think you're totally right. But I'd really like to not complicate
the API of the iova_tree more.
I think we can look for the hwaddr using memory_region_from_host and
then get the hwaddr. It is another lookup though...
Yeah, that will be another means of doing translation without having to
complicate the API around iova_tree. I wonder how the lookup through
memory_region_from_host() may perform compared to the iova tree one, the
former looks to be an O(N) linear search on a linked list while the
latter would be roughly O(log N) on an AVL tree?
Even worse, as the reverse lookup (from QEMU vaddr to SVQ IOVA) is
linear too. It is not even ordered.
Oh Sorry, I misread the code and I should look for g_tree_foreach ()
instead of g_tree_search_node(). So the former is indeed linear
iteration, but it looks to be ordered?
https://github.com/GNOME/glib/blob/main/glib/gtree.c#L1115
The GPA / IOVA are ordered but we're looking by QEMU's vaddr.
If we have these translations:
[0x1000, 0x2000] -> [0x1, 0x11000]
[0x2000, 0x3000] -> [0x6000, 0x7000]
We will see them in this order, so we cannot stop the search at the first node.
Yeah, reverse lookup is unordered indeed, anyway.
But apart from this detail you're right, I have the same concerns with
this solution too. If we see a hard performance regression we could go
to more complicated solutions, like maintaining a reverse IOVATree in
vhost-iova-tree too. First RFCs of SVQ did that actually.
Agreed, yeap we can use memory_region_from_host for now. Any reason why
reverse IOVATree was dropped, lack of users? But now we have one!
No, it is just simplicity. We already have an user in the hot patch in
the master branch, vhost_svq_vring_write_descs. But I never profiled
enough to find if it is a bottleneck or not to be honest.
Right, without vIOMMU or a lot of virtqueues / mappings, it's hard to
profile and see the difference
Re: [PATCH v2 1/3] cpu-models: add "disable-deprecated-feats" option to cpu model expansion
On 4/25/24 02:31, Markus Armbruster wrote:
> Collin Walling writes:
>
>> On 4/24/24 02:19, Markus Armbruster wrote:
>>> Collin Walling writes:
>>>
This optional parameter for query-cpu-model-expansion enables CPU
model features flagged as deprecated to appear in the resulting
list of properties.
This commit does not add support beyond adding a new argument
to the query. All queries with this option present will result
in an error claiming this option is not supported.
Signed-off-by: Collin Walling
---
qapi/machine-target.json | 7 ++-
target/arm/arm-qmp-cmds.c| 7 +++
target/i386/cpu-sysemu.c | 7 +++
target/s390x/cpu_models_sysemu.c | 7 +++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index 29e695aa06..b9da284d2d 100644
--- a/qapi/machine-target.json
+++ b/qapi/machine-target.json
@@ -285,6 +285,10 @@
#
# @type: expansion type, specifying how to expand the CPU model
#
+# @disable-deprecated-feats: include CPU model features that are
+# flagged as deprecated. If supported, these features will appear
+# in the properties list paired with false.
>>>
>>> What's the default?
>>>
>>> Which command result(s) does this affect? Suggest to explain using
>>> unabridged example QMP input and output before and after this series.
>>
>> Fair enough. Bool defaults to false but that's not apparent in the
>> description. I will add more detail.
>
> I didn't mean to ask for example QMP in the doc comment. I need you to
> explain the new member to me. Once I understand what the thing does, I
> may have suggestions on improving the doc comment.
>
> [...]
>
Ah, I misunderstood. The idea behind this "disable-deprecated-feats"
option is to add/override any CPU features that are flagged as
deprecated to the props dictionary (found in the CpuModelInfo struct)
paired with the value false.
For example, the csske feature on s390x is flagged as deprecated. If a
query-cpu-model-expansion command is created with
"disable-deprecated-feats": true, then the csske feature will show up in
the props list as "csske": false. This also overrides any user defined
features and props that would show up in the response normally. E.g. if
the same command was executed and "csske": true was provided in the
model's properties by the user, the response will still show "csske":
false since the "disable-deprecated-feats" option takes priority (there
is a discussion with David H regarding which should take precedence --
this is a flaw in this design).
In the below QMP samples I provide a static expansion on a host model.
Pay close attention to the bpb, te, cte, and csske properties.
Before
This is how query-cpu-model-expansion may be executed today:
{
"execute": "query-cpu-model-expansion",
"arguments": {
"type": "static",
"model": {
"name": "host"
}
}
}
{
"return": {
"model": {
"name": "z14.2-base",
"props": {
"aen": true,
"cmmnt": true,
"aefsi": true,
"diag318": true,
"mepoch": true,
"msa8": true,
"msa7": true,
"msa6": true,
"msa5": true,
"msa4": true,
"msa3": true,
"msa2": true,
"msa1": true,
"sthyi": true,
"edat": true,
"ri": true,
"edat2": true,
"etoken": true,
"vx": true,
"ipter": true,
"mepochptff": true,
"ap": true,
"vxeh": true,
"vxpd": true,
"esop": true,
"apqi": true,
"apft": true,
"els": true,
"iep": true,
"apqci": true,
"cte": true,<--
"ais": true,
"bpb": true,<--
"ctop": true,
"gs": true,
"ppa15": true,
"zpci": true,
"sea_esop2": true,
"te": true, <--
"cmm": true
}
}
}
}
Note: csske does not even show up here.
===
After
===
This is with the optional "disabled-deprecated-feats":
{
"execute": "query-cpu-model-expansion",
"arguments": {
"type": "static",
"model": {
"name": "host"
},
"disabled-deprecated-feats": true
}
}
{
"return": {
"model": {
"name": "z14.2-base",
"props": {
"aen": true,
"cmmnt": true,
"aefsi": true,
"diag318": true,
"mepoch": true,
"msa8": true,
"msa7": true,
"msa6": true,
"msa5": true,
"msa4": true,
"msa3": true,
"msa2": true,
"msa1": true,
"sthyi": true,
"edat": true,
"ri": true,
"edat2": true,
"etoken": true,
"vx": true,
"ipter": true,
"mepochptff": true,
"ap": true,
"vxeh": true,
"vx
Re: [PATCH v5 09/13] hw/cxl/events: Add qmp interfaces to add/release dynamic capacity extents
Markus Armbruster wrote: > fan writes: > > > On Wed, Apr 24, 2024 at 03:09:52PM +0200, Markus Armbruster wrote: > >> nifan@gmail.com writes: > >> > >> > From: Fan Ni > >> > > >> > Since fabric manager emulation is not supported yet, the change > >> > implements > >> > the functions to add/release dynamic capacity extents as QMP interfaces. > >> > >> Will fabric manager emulation obsolete these commands? > > > > If in the future, fabric manager emulation supports commands for dynamic > > capacity > > extent add/release, it is possible we do not need the commands. > > But it seems not to happen soon, we need the qmp commands for the > > end-to-end test with kernel DCD support. > > I asked because if the commands are temporary testing aids, they should > probably be declared unstable. Even if they are permanent testing aids, > unstable might be the right choice. This is for the CXL maintainers to > decide. > > What does "unstable" mean? docs/devel/qapi-code-gen.rst: "Interfaces so > marked may be withdrawn or changed incompatibly in future releases." > > Management applications need stable interfaces. Libvirt developers > generally refuse to touch anything in QMP that's declared unstable. > > Human users and their ad hoc scripts appreciate stability, but they > don't need it nearly as much as management applications do. > > A stability promise increases the maintenance burden. By how much is > unclear. In other words, by promising stability, the maintainers take > on risk. Are the CXL maintainers happy to accept the risk here? > Ah... All great points. Outside of CXL development I don't think there is a strong need for them to be stable. I would like to see more than ad hoc scripts use them though. So I don't think they are going to be changed without some thought though. Ira [snip]
Re: [PATCH v2 2/3] target/s390x: add support for "disable-deprecated-feats" expansion option
On 4/25/24 04:10, David Hildenbrand wrote:
> On 24.04.24 20:33, Collin Walling wrote:
>> On 4/24/24 03:24, David Hildenbrand wrote:
>>> On 23.04.24 23:06, Collin Walling wrote:
Retain a list of deprecated features disjoint from any particular
CPU model. When a query-cpu-model-expansion is provided with the
"disable-deprecated-feats" option set, the resulting properties list
will include all deprecated features paired with false. Example:
{ ... "bpb": false, "csske": false, ...}
It is recommended that s390 guests operate with these features
explicitly disabled to ensure compatability with future hardware.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 14 ++
target/s390x/cpu_features.h | 1 +
target/s390x/cpu_models_sysemu.c | 20
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index d28eb65845..efafc9711c 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -212,6 +212,20 @@ void s390_feat_bitmap_to_ascii(const S390FeatBitmap
features, void *opaque,
};
}
+void s390_get_deprecated_features(S390FeatBitmap features)
+{
+static const int feats[] = {
+ /* CSSKE is deprecated on newer generations */
+ S390_FEAT_CONDITIONAL_SSKE,
+ S390_FEAT_BPB,
+};
+int i;
+
+for (i = 0; i < ARRAY_SIZE(feats); i++) {
+set_bit(feats[i], features);
+}
+}
+
#define FEAT_GROUP_INIT(_name, _group, _desc)\
{\
.name = _name, \
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index a9bd68a2e1..661a8cd6db 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -69,6 +69,7 @@ void s390_add_from_feat_block(S390FeatBitmap features,
S390FeatType type,
uint8_t *data);
void s390_feat_bitmap_to_ascii(const S390FeatBitmap features, void
*opaque,
void (*fn)(const char *name, void
*opaque));
+void s390_get_deprecated_features(S390FeatBitmap features);
/* Definition of a CPU feature group */
typedef struct {
diff --git a/target/s390x/cpu_models_sysemu.c
b/target/s390x/cpu_models_sysemu.c
index ef9fa80efd..b002819188 100644
--- a/target/s390x/cpu_models_sysemu.c
+++ b/target/s390x/cpu_models_sysemu.c
@@ -171,7 +171,8 @@ static void qdict_add_enabled_feat(const char *name,
void *opaque)
/* convert S390CPUDef into a static CpuModelInfo */
static void cpu_info_from_model(CpuModelInfo *info, const S390CPUModel
*model,
-bool delta_changes)
+bool delta_changes,
+bool disable_deprecated_feats)
{
QDict *qdict = qdict_new();
S390FeatBitmap bitmap;
@@ -201,6 +202,13 @@ static void cpu_info_from_model(CpuModelInfo *info,
const S390CPUModel *model,
s390_feat_bitmap_to_ascii(bitmap, qdict,
qdict_add_disabled_feat);
}
+/* features flagged as deprecated */
+if (disable_deprecated_feats) {
+bitmap_zero(bitmap, S390_FEAT_MAX);
+s390_get_deprecated_features(bitmap);
+s390_feat_bitmap_to_ascii(bitmap, qdict, qdict_add_disabled_feat);
+}
>>>
>>> Likely, we should remove these features from the actual bitmap, such
>>> that they won't appear twice in the output? I'd expect the
>>> cpu_info_from_model() caller to handle that.
>>>
>>> Just adding them to the list as disabled is likely wrong.
>>>
>>> For example, if someone were to expend a given model with "... bpb:
>>> true" with disable-deprecated-feat=on, that should be remove from
>>> "bpb:true", and only replaced by "bpb=false" if it would be part of the
>>> CPU model we would be expanding to.
>>>
>>> Or am I missing something?
>>>
>>
>> qdict_add_disabled_feat will handle updating the feature if it already
>> exists. I placed the code to process deprecated features as the last
>> step of cpu_info_from_model to override any features that have already
>> been added to the bitmap. Whether it should be the deprecated feats that
>> take priority, or what the user requests is up in the air, however...
>
> Yes, that's one of my concern. IIRC, if the user specifies the same
> property multiple times, it's unclear which one will win.
>
> "bpb=true,bpb=false" might mean that bpb=true might win.
>
> I think this is something that this interface should so
Re: [PATCH v2 1/3] cpu-models: add "disable-deprecated-feats" option to cpu model expansion
On 4/25/24 09:35, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2024 at 03:12:42PM -0400, Collin Walling wrote:
>> On 4/24/24 13:51, Collin Walling wrote:
>>> On 4/24/24 04:20, Daniel P. Berrangé wrote:
On Tue, Apr 23, 2024 at 05:06:53PM -0400, Collin Walling wrote:
> This optional parameter for query-cpu-model-expansion enables CPU
> model features flagged as deprecated to appear in the resulting
> list of properties.
>
> This commit does not add support beyond adding a new argument
> to the query. All queries with this option present will result
> in an error claiming this option is not supported.
>
> Signed-off-by: Collin Walling
> ---
> qapi/machine-target.json | 7 ++-
> target/arm/arm-qmp-cmds.c| 7 +++
> target/i386/cpu-sysemu.c | 7 +++
> target/s390x/cpu_models_sysemu.c | 7 +++
> 4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> index 29e695aa06..b9da284d2d 100644
> --- a/qapi/machine-target.json
> +++ b/qapi/machine-target.json
> @@ -285,6 +285,10 @@
> #
> # @type: expansion type, specifying how to expand the CPU model
> #
> +# @disable-deprecated-feats: include CPU model features that are
> +# flagged as deprecated. If supported, these features will appear
> +# in the properties list paired with false.
> +#
> # Returns: a CpuModelExpansionInfo describing the expanded CPU model
> #
> # Errors:
> @@ -298,7 +302,8 @@
> ##
> { 'command': 'query-cpu-model-expansion',
>'data': { 'type': 'CpuModelExpansionType',
> -'model': 'CpuModelInfo' },
> +'model': 'CpuModelInfo',
> +'*disable-deprecated-feats': 'bool' },
>'returns': 'CpuModelExpansionInfo',
>'if': { 'any': [ 'TARGET_S390X',
> 'TARGET_I386',
I think this is an odd design approach. Lets consider the
current output:
(QEMU) query-cpu-model-expansion type=static model={"name":"z14"}
{
"return": {
"model": {
"name": "z14-base",
"props": {
"aefsi": true,
"aen": true,
...snip...
"vxpd": true,
"zpci": true
}
}
}
}
If we want to inform a mgmt app of some features being deprecated,
why not just unconditionally include that info in the reply thus:
(QEMU) query-cpu-model-expansion type=static model={"name":"z14"}
{
"return": {
"model": {
"name": "z14-base",
"props": {
"aefsi": true,
"aen": true,
...snip...
"vxpd": true,
"zpci": true
}
"deprecated-props": ["ppa15", "ri"]
}
}
}
With regards,
Daniel
>>>
>>> That's a good idea. In this way, we're not mucking up any of the CPU
>>> model information and this makes it much more clear as to which features
>>> are actually deprecated... I like this more.
>>>
>>> I'll work on this.
>>>
>>
>> Follow-up question as I look more closely to the QMP response data
>> structures: should the "deprecated-props" list be added to the
>> CpuModelInfo struct, or to the CpuModelExpansionInfo struct?
>>
>> The former makes more sense to me, as the deprecated features are tied
>> to the actual CPU model... but unsure if other QMP commands would even
>> care about this info? I will begin with this approach, and if feedback
>> in the interim strongly sways in the other direction, then it should be
>> an easy change :)
>
> I hink CpuModelInfo makes more sense than CpuModelExpansionInfo.
> The CpuModelExpansionInfo struct feels pretty pointless to me
> in fact, since the only thing it contains is CpuModelInfo !
>
Agreed! :)
> I think it should also be added to 'CpuDefinitionInfo', which
> is the return type of 'query-cpu-defintions'. This command already
> has a 'unavailable-features' array listing features which the host
> does not support. Conceptually having a 'deprecated-features' array
> alongside that is a nice fit.
>
Okay. Pending review on the v3 I posted yesterday -- if those patches
look like they're on the right track, then I can add this
"deprecated-props" array to CpuDefinitionInfo as well for the next
iteration.
>
>
> With regards,
> Daniel
--
Regards,
Collin
Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT
On Mon, Apr 22, 2024 at 5:26 PM Peter Maydell wrote:
>
> On Mon, 22 Apr 2024 at 11:46, Peter Maydell wrote:
> >
> > On Sun, 21 Apr 2024 at 06:40, Richard Henderson
> > wrote:
> > > > --- a/target/arm/cpu.c
> > > > +++ b/target/arm/cpu.c
> > > > @@ -1314,8 +1314,18 @@ static void arm_cpu_dump_state(CPUState *cs,
> > > > FILE *f, int flags)
> > > > }
> > > > }
> > > >
> > > > -uint64_t arm_build_mp_affinity(int idx, uint8_t clustersz)
> > > > +uint64_t arm_build_mp_affinity(ARMCPU *cpu, int idx, uint8_t clustersz)
> > > > {
> > > > +if (cpu->has_smt) {
> > > > +/*
> > > > + * Right now, the ARM CPUs with SMT supported by QEMU only have
> > > > + * one thread per core. So Aff0 is always 0.
> > > > + */
> > >
> > > Well, this isn't true.
> > >
> > > -smp
> > > [[cpus=]n][,maxcpus=maxcpus][,drawers=drawers][,books=books][,sockets=sockets]
> > >
> > > [,dies=dies][,clusters=clusters][,cores=cores][,threads=threads]
> > >
> > > I would expect all of Aff[0-3] to be settable with the proper topology
> > > parameters.
> >
> > As I understand it the MPIDR value is more or less independent
> > of the topology information as presented to the guest OS.
> > The options to the -smp command set the firmware topology
> > information, which doesn't/shouldn't affect the reported
> > MPIDR values, and in particular shouldn't change whether
> > the CPU selected has the MT bit set or not.
> >
> > For Arm's CPUs they fall into two categories:
> > * older ones don't set MT in their MPIDR, and the Aff0
> >field is effectively the CPU number
> > * newer ones do set MT in their MPIDR, but don't have
> >SMT, so their Aff0 is always 0 and their Aff1
> >is the CPU number
> >
> > Of all the CPUs we model, none of them are the
> > architecturally-permitted "MT is set, CPU implements
> > actual SMT, Aff0 indicates the thread in the CPU" type.
>
> Looking at the TRM, Neoverse-E1 is "MT is set, actual SMT,
> Aff0 is the thread" (Aff0 can be 0 or 1). We just don't
> model that CPU type yet. But we should probably make
> sure we don't block ourselves into a corner where that
> would be awkward -- I'll have a think about this and
> look at what x86 does with the topology info.
>
Thanks. Let me know what should be done as part of this patch to
properly fix the issue if you get a chance to look at it.
Regards,
Dorjoy
Re: [PULL v2 00/16] CI job updates, header cleanups and other misc patches
On 4/25/24 07:57, Thomas Huth wrote: The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707: Merge tag 'pull-tcg-20240424' ofhttps://gitlab.com/rth7680/qemu into staging (2024-04-24 15:51:49 -0700) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-25 for you to fetch changes up to 17523a38194d80f2955c6a8e0702e0fc86dd083d: target/s390x: Remove KVM stubs in cpu_models.h (2024-04-25 15:15:25 +0200) * Update OpenBSD CI image to 7.5 * Update/remove Ubuntu 20.04 CI jobs * Update (most) CentOS 8 CI jobs to CentOS 9 * Some clean-ups and improvements to travis.yml * Minor test fixes * s390x header clean-ups * Doc updates v2: Drop the problematic patch that updates the custom CentOS 8 runner Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/9.1 as appropriate. r~
Re: [PULL 00/37] target-arm queue
On 4/25/24 03:39, Peter Maydell wrote: Hi; here's the first arm pullreq for 9.1. This includes the reset method function signature change, so it has some chance of compile failures due to merge conflicts if some other pullreq added a device reset method and that pullreq got applied before this one. If so, the changes needed to fix those up can be created by running the spatch rune described in the commit message of the "hw, target: Add ResetType argument to hold and exit phase methods" commit. thanks -- PMM The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707: Merge tag 'pull-tcg-20240424' ofhttps://gitlab.com/rth7680/qemu into staging (2024-04-24 15:51:49 -0700) are available in the Git repository at: https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20240425 for you to fetch changes up to 214652da123e3821657a64691ee556281e9f6238: tests/qtest: Add tests for the STM32L4x5 USART (2024-04-25 10:21:59 +0100) target-arm queue: * Implement FEAT_NMI and NMI support in the GICv3 * hw/dma: avoid apparent overflow in soc_dma_set_request * linux-user/flatload.c: Remove unused bFLT shared-library and ZFLAT code * Add ResetType argument to Resettable hold and exit phase methods * Add RESET_TYPE_SNAPSHOT_LOAD ResetType * Implement STM32L4x5 USART Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/9.1 as appropriate. r~
Re: [PATCH v3 1/2] cxl/core: correct length of DPA field masks
Shiyang Ruan wrote: > > > 在 2024/4/24 5:04, Ira Weiny 写道: > > Alison Schofield wrote: > >> On Wed, Apr 17, 2024 at 03:50:52PM +0800, Shiyang Ruan wrote: > > > > [snip] > > > >>> diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h > >>> index e5f13260fc52..cdfce932d5b1 100644 > >>> --- a/drivers/cxl/core/trace.h > >>> +++ b/drivers/cxl/core/trace.h > >>> @@ -253,7 +253,7 @@ TRACE_EVENT(cxl_generic_event, > >>>* DRAM Event Record > >>>* CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44 > >>>*/ > >>> -#define CXL_DPA_FLAGS_MASK 0x3F > >>> +#define CXL_DPA_FLAGS_MASK 0x3FULL > >>> #define CXL_DPA_MASK(~CXL_DPA_FLAGS_MASK) > >>> > >>> #define CXL_DPA_VOLATILEBIT(0) > >> > >> This works but I'm thinking this is the time to convene on one > >> CXL_EVENT_DPA_MASK for both all CXL events, rather than having > >> cxl_poison event be different. > >> > >> I prefer how poison defines it: > >> > >> cxlmem.h:#define CXL_POISON_START_MASK GENMASK_ULL(63, 6) > >> > >> Can we rename that CXL_EVENT_DPA_MASK and use for all events? > > cxlmem.h:CXL_POISON_START_MASK is defined for MBOX commands (poison > record, the lower 3 bits indicate "Error Source"), but CXL_DPA_MASK here > is for events. They have different meaning though their values are > same. So, I don't think we should consolidate them. By definition the DPA in all these payloads can't use the lower 6 bits. We are defining a mask to get the DPA. This has nothing to do with what may be stored in the other 6 bits. Defining a common DPA mask is correct per both sections of the spec. > > > > > Ah! Great catch. I dont' know why I only masked off the 2 used bits. > > Per spec, the lowest 2 bits of CXL event's DPA are defined for "Volatile > or not" and "not repairable". So there is no mistake here. I appreciate your not calling out my code as a bug. :-D However, bits [5:2] are also Reserved. So it is incorrect to mask off only the lower 2 bits. Even though the reserved bits must be 0 per the spec, it is still better to properly mask all reserved bits because they are by definition not part of the DPA. Could you create a common macro for the next version of the patch? Thanks, Ira > > > That was short sighted of me. > > > > Yes we should consolidate these. > > Ira > > -- > Thanks, > Ruan. >
Re: [PATCH] target/riscv/kvm: implement SBI debug console (DBCN) calls
On Thu, Apr 25, 2024 at 12:50:12PM GMT, Daniel Henrique Barboza wrote: > SBI defines a Debug Console extension "DBCN" that will, in time, replace > the legacy console putchar and getchar SBI extensions. > > The appeal of the DBCN extension is that it allows multiple bytes to be > read/written in the SBI console in a single SBI call. > > As far as KVM goes, the DBCN calls are forwarded by an in-kernel KVM > module to userspace. But this will only happens if the KVM module > actually supports this SBI extension and we activate it. > > We'll check for DBCN support during init time, checking if get-reg-list > is advertising KVM_RISCV_SBI_EXT_DBCN. In that case, we'll enable it via > kvm_set_one_reg() during kvm_arch_init_vcpu(). > > Finally, change kvm_riscv_handle_sbi() to handle the incoming calls for > SBI_EXT_DBCN, reading and writing as required. > > A simple KVM guest with 'earlycon=sbi', running in an emulated RISC-V > host, takes around 20 seconds to boot without using DBCN. With this > patch we're taking around 14 seconds to boot due to the speed-up in the > terminal output. There's no change in boot time if the guest isn't > using earlycon. > > Signed-off-by: Daniel Henrique Barboza > --- > target/riscv/kvm/kvm-cpu.c | 111 + > target/riscv/sbi_ecall_interface.h | 17 + > 2 files changed, 128 insertions(+) > Reviewed-by: Andrew Jones
Re: [PATCH v2 1/1] target/riscv/kvm: tolerate KVM disable ext errors
On Mon, Apr 22, 2024 at 02:14:25PM GMT, Daniel Henrique Barboza wrote:
> Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> enabled, will fail with a kernel oops SIGILL right at the start. The
> reason is that we can't expose zkr without implementing the SEED CSR.
> Disabling zkr in the guest would be a workaround, but if the KVM doesn't
> allow it we'll error out and never boot.
>
> In hindsight this is too strict. If we keep proceeding, despite not
> disabling the extension in the KVM vcpu, we'll not add the extension in
> the riscv,isa. The guest kernel will be unaware of the extension, i.e.
> it doesn't matter if the KVM vcpu has it enabled underneath or not. So
> it's ok to keep booting in this case.
>
> Change our current logic to not error out if we fail to disable an
> extension in kvm_set_one_reg(), but show a warning and keep booting. It
> is important to throw a warning because we must make the user aware that
> the extension is still available in the vcpu, meaning that an
> ill-behaved guest can ignore the riscv,isa settings and use the
> extension.
>
> The case we're handling happens with an EINVAL error code. If we fail to
> disable the extension in KVM for any other reason, error out.
>
> We'll also keep erroring out when we fail to enable an extension in KVM,
> since adding the extension in riscv,isa at this point will cause a guest
> malfunction because the extension isn't enabled in the vcpu.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 6a6c6cae80..03e3fee607 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -427,10 +427,14 @@ static void kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU
> *cpu, CPUState *cs)
> reg = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
> ret = kvm_set_one_reg(cs, id, ®);
> if (ret != 0) {
> -error_report("Unable to %s extension %s in KVM, error %d",
> - reg ? "enable" : "disable",
> - multi_ext_cfg->name, ret);
> -exit(EXIT_FAILURE);
> +if (!reg && ret == -EINVAL) {
> +warn_report("KVM cannot disable extension %s",
> +multi_ext_cfg->name);
> +} else {
> +error_report("Unable to enable extension %s in KVM, error
> %d",
> + multi_ext_cfg->name, ret);
> +exit(EXIT_FAILURE);
> +}
> }
> }
> }
> --
> 2.44.0
>
Reviewed-by: Andrew Jones
Re: [PATCH v2 4/4] vfio/ccw: Make vfio_ccw_register_irq_notifier() return a bool
On 4/25/24 14:55, Eric Farman wrote:
On Thu, 2024-04-25 at 12:56 +0200, Markus Armbruster wrote:
Cédric Le Goater writes:
Since vfio_ccw_register_irq_notifier() takes an 'Error **'
argument,
best practices suggest to return a bool. See the qapi/error.h Rules
section.
Signed-off-by: Cédric Le Goater
---
hw/vfio/ccw.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index
6764388bc47a970329fce2233626ccb8178e0165..1c630f6e9abe93ae0c2b5615d
4409669f096c8c9 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -379,7 +379,7 @@ read_err:
css_inject_io_interrupt(sch);
}
-static void vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
+static bool vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
unsigned int irq,
Error **errp)
{
@@ -405,13 +405,13 @@ static void
vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
break;
default:
error_setg(errp, "vfio: Unsupported device irq(%d)", irq);
- return;
+ return false;
}
if (vdev->num_irqs < irq + 1) {
error_setg(errp, "vfio: IRQ %u not available (number of
irqs %u)",
irq, vdev->num_irqs);
- return;
+ return false;
}
argsz = sizeof(*irq_info);
@@ -421,14 +421,14 @@ static void
vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
if (ioctl(vdev->fd, VFIO_DEVICE_GET_IRQ_INFO,
irq_info) < 0 || irq_info->count < 1) {
error_setg_errno(errp, errno, "vfio: Error getting irq
info");
- return;
+ return false;
}
if (event_notifier_init(notifier, 0)) {
error_setg_errno(errp, errno,
"vfio: Unable to init event notifier for
irq (%d)",
irq);
- return;
+ return false;
}
fd = event_notifier_get_fd(notifier);
@@ -439,6 +439,8 @@ static void
vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
qemu_set_fd_handler(fd, NULL, NULL, vcdev);
event_notifier_cleanup(notifier);
}
+
+ return true;
}
static void vfio_ccw_unregister_irq_notifier(VFIOCCWDevice *vcdev,
@@ -602,20 +604,18 @@ static void vfio_ccw_realize(DeviceState
*dev, Error **errp)
goto out_region_err;
}
- vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX,
&err);
- if (err) {
+ if (!vfio_ccw_register_irq_notifier(vcdev,
VFIO_CCW_IO_IRQ_INDEX, &err)) {
Please pass errp instead of &err.
goto out_io_notifier_err;
}
if (vcdev->crw_region) {
- vfio_ccw_register_irq_notifier(vcdev,
VFIO_CCW_CRW_IRQ_INDEX, &err);
- if (err) {
+ if (!vfio_ccw_register_irq_notifier(vcdev,
VFIO_CCW_CRW_IRQ_INDEX,
+ &err)) {
Likewise.
goto out_irq_notifier_err;
}
}
- vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_REQ_IRQ_INDEX,
&err);
- if (err) {
+ if (!vfio_ccw_register_irq_notifier(vcdev,
VFIO_CCW_REQ_IRQ_INDEX, &err)) {
/*
* Report this error, but do not make it a failing
condition.
* Lack of this IRQ in the host does not prevent normal
operation.
*/
error_report_err(err);
Not this patch's problem, but here goes anyway: since this isn't an
error, we shouldn't use error_report_err(). Would warn_report_err()
be
appropriate? info_report_err() doesn't exist, but it could.
Preferably with errp instead of &err (two times):
Reviewed-by: Markus Armbruster
Don't recall why I used error_report_err() instead of something else
(or creating info_), but probably just familiarity. There's no need for
it (or the equivalent code in -ap) to be error, and could be another
cleanup.
yes. I will send an extra cleanup to replace error_... with warn_...
and another one to use errp.
Thanks,
C.
Reviewed-by: Eric Farman
[PATCH] target/riscv/kvm: implement SBI debug console (DBCN) calls
SBI defines a Debug Console extension "DBCN" that will, in time, replace
the legacy console putchar and getchar SBI extensions.
The appeal of the DBCN extension is that it allows multiple bytes to be
read/written in the SBI console in a single SBI call.
As far as KVM goes, the DBCN calls are forwarded by an in-kernel KVM
module to userspace. But this will only happens if the KVM module
actually supports this SBI extension and we activate it.
We'll check for DBCN support during init time, checking if get-reg-list
is advertising KVM_RISCV_SBI_EXT_DBCN. In that case, we'll enable it via
kvm_set_one_reg() during kvm_arch_init_vcpu().
Finally, change kvm_riscv_handle_sbi() to handle the incoming calls for
SBI_EXT_DBCN, reading and writing as required.
A simple KVM guest with 'earlycon=sbi', running in an emulated RISC-V
host, takes around 20 seconds to boot without using DBCN. With this
patch we're taking around 14 seconds to boot due to the speed-up in the
terminal output. There's no change in boot time if the guest isn't
using earlycon.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/kvm/kvm-cpu.c | 111 +
target/riscv/sbi_ecall_interface.h | 17 +
2 files changed, 128 insertions(+)
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 03e3fee607..54a9ab9fd7 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -409,6 +409,12 @@ static KVMCPUConfig kvm_v_vlenb = {
KVM_REG_RISCV_VECTOR_CSR_REG(vlenb)
};
+static KVMCPUConfig kvm_sbi_dbcn = {
+.name = "sbi_dbcn",
+.kvm_reg_id = KVM_REG_RISCV | KVM_REG_SIZE_U64 |
+ KVM_REG_RISCV_SBI_EXT | KVM_RISCV_SBI_EXT_DBCN
+};
+
static void kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU *cpu, CPUState *cs)
{
CPURISCVState *env = &cpu->env;
@@ -1041,6 +1047,20 @@ static int uint64_cmp(const void *a, const void *b)
return 0;
}
+static void kvm_riscv_check_sbi_dbcn_support(RISCVCPU *cpu,
+ KVMScratchCPU *kvmcpu,
+ struct kvm_reg_list *reglist)
+{
+struct kvm_reg_list *reg_search;
+
+reg_search = bsearch(&kvm_sbi_dbcn.kvm_reg_id, reglist->reg, reglist->n,
+ sizeof(uint64_t), uint64_cmp);
+
+if (reg_search) {
+kvm_sbi_dbcn.supported = true;
+}
+}
+
static void kvm_riscv_read_vlenb(RISCVCPU *cpu, KVMScratchCPU *kvmcpu,
struct kvm_reg_list *reglist)
{
@@ -1146,6 +1166,8 @@ static void kvm_riscv_init_multiext_cfg(RISCVCPU *cpu,
KVMScratchCPU *kvmcpu)
if (riscv_has_ext(&cpu->env, RVV)) {
kvm_riscv_read_vlenb(cpu, kvmcpu, reglist);
}
+
+kvm_riscv_check_sbi_dbcn_support(cpu, kvmcpu, reglist);
}
static void riscv_init_kvm_registers(Object *cpu_obj)
@@ -1320,6 +1342,17 @@ static int kvm_vcpu_set_machine_ids(RISCVCPU *cpu,
CPUState *cs)
return ret;
}
+static int kvm_vcpu_enable_sbi_dbcn(RISCVCPU *cpu, CPUState *cs)
+{
+target_ulong reg = 1;
+
+if (!kvm_sbi_dbcn.supported) {
+return 0;
+}
+
+return kvm_set_one_reg(cs, kvm_sbi_dbcn.kvm_reg_id, ®);
+}
+
int kvm_arch_init_vcpu(CPUState *cs)
{
int ret = 0;
@@ -1337,6 +1370,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
kvm_riscv_update_cpu_misa_ext(cpu, cs);
kvm_riscv_update_cpu_cfg_isa_ext(cpu, cs);
+ret = kvm_vcpu_enable_sbi_dbcn(cpu, cs);
+
return ret;
}
@@ -1394,6 +1429,79 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cs)
return true;
}
+static void kvm_riscv_handle_sbi_dbcn(CPUState *cs, struct kvm_run *run)
+{
+g_autofree uint8_t *buf = NULL;
+RISCVCPU *cpu = RISCV_CPU(cs);
+target_ulong num_bytes;
+uint64_t addr;
+unsigned char ch;
+int ret;
+
+switch (run->riscv_sbi.function_id) {
+case SBI_EXT_DBCN_CONSOLE_READ:
+case SBI_EXT_DBCN_CONSOLE_WRITE:
+num_bytes = run->riscv_sbi.args[0];
+
+if (num_bytes == 0) {
+run->riscv_sbi.ret[0] = SBI_SUCCESS;
+run->riscv_sbi.ret[1] = 0;
+break;
+}
+
+addr = run->riscv_sbi.args[1];
+
+/*
+ * Handle the case where a 32 bit CPU is running in a
+ * 64 bit addressing env.
+ */
+if (riscv_cpu_mxl(&cpu->env) == MXL_RV32) {
+addr |= (uint64_t)run->riscv_sbi.args[2] << 32;
+}
+
+buf = g_malloc0(num_bytes);
+
+if (run->riscv_sbi.function_id == SBI_EXT_DBCN_CONSOLE_READ) {
+ret = qemu_chr_fe_read_all(serial_hd(0)->be, buf, num_bytes);
+if (ret < 0) {
+error_report("SBI_EXT_DBCN_CONSOLE_READ: error when "
+ "reading chardev");
+exit(1);
+}
+
+cpu_physical_memory_write(addr, buf, ret);
+} else {
+cpu_physical_memory_read(addr, buf, num_bytes);
+
+ret = qemu_chr_fe_write_all(s
[PATCH v9 02/11] virtio-gpu: Support context-init feature with virglrenderer
From: Huang Rui
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags. Expose this feature and support creating virglrenderer
context with flags using context_id if libvirglrenderer is new enough.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-gl.c| 4
hw/display/virtio-gpu-virgl.c | 20 ++--
meson.build | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index e06be60dfbfc..ba478124e2c2 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -127,6 +127,10 @@ static void virtio_gpu_gl_device_realize(DeviceState
*qdev, Error **errp)
VIRTIO_GPU_BASE(g)->virtio_config.num_capsets =
virtio_gpu_virgl_get_num_capsets(g);
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+g->parent_obj.conf.flags |= 1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED;
+#endif
+
virtio_gpu_device_realize(qdev, errp);
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 9f34d0e6619c..ef598d8d23ee 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,24 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init) {
+if (!virtio_gpu_context_init_enabled(g->parent_obj.conf)) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: context_init disabled",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+return;
+}
+
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+#endif
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/meson.build b/meson.build
index c6f22f565071..c131db46b2a6 100644
--- a/meson.build
+++ b/meson.build
@@ -2288,6 +2288,7 @@ config_host_data.set('CONFIG_VNC_JPEG', jpeg.found())
config_host_data.set('CONFIG_VNC_SASL', sasl.found())
if virgl.version().version_compare('>=1.0.0')
config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
+ config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
[PATCH v9 11/11] migration/virtio: Add virtio-gpu section
Document virtio-gpu migration specifics. Suggested-by: Akihiko Odaki Signed-off-by: Dmitry Osipenko --- docs/devel/migration/virtio.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/docs/devel/migration/virtio.rst b/docs/devel/migration/virtio.rst index 611a18b82151..67f5fcfed196 100644 --- a/docs/devel/migration/virtio.rst +++ b/docs/devel/migration/virtio.rst @@ -113,3 +113,10 @@ virtio_load() returned (like e.g. code depending on features). Any extension of the state being migrated should be done in subsections added to the core for compatibility reasons. If transport or device specific state is added, core needs to invoke a callback from the new subsection. + +VirtIO-GPU migration + +VirtIO-GPU doesn't adhere to a common virtio migration scheme. It doesn't +support save/loading of virtio device state, instead it uses generic device +migration management on top of the virtio core to save/load GPU state. +Migration of virgl and rutabaga states not supported. -- 2.44.0
[PATCH v9 08/11] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
UUID feature availability is mandatory for Vulkan Venus context.
UUID is intended for sharing dmabufs between virtio devices on host. Qemu
doesn't have second virtio device for sharing, thus a simple stub UUID
implementation is enough. More complete implementation using global UUID
resource table might become interesting for a multi-gpu cases.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
Signed-off-by: Dmitry Osipenko
---
hw/display/trace-events | 1 +
hw/display/virtio-gpu-base.c | 3 +++
hw/display/virtio-gpu-virgl.c | 33 +
3 files changed, 37 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca1570..54d6894c59f4 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4fc7ef8896c1..13014b9a73eb 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -226,6 +226,9 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
virtio_gpu_rutabaga_enabled(g->conf)) {
features |= (1 << VIRTIO_GPU_F_VIRGL);
}
+if (virtio_gpu_virgl_enabled(g->conf)) {
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+}
if (virtio_gpu_edid_enabled(g->conf)) {
features |= (1 << VIRTIO_GPU_F_EDID);
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 73d4acbf1777..de788df155bf 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -14,6 +14,7 @@
#include "qemu/osdep.h"
#include "qemu/error-report.h"
#include "qemu/iov.h"
+#include "qemu/uuid.h"
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
@@ -28,6 +29,7 @@ struct virtio_gpu_virgl_resource {
struct virtio_gpu_simple_resource base;
bool async_unmap_in_progress;
MemoryRegion *mr;
+QemuUUID uuid;
};
static struct virtio_gpu_virgl_resource *
@@ -197,6 +199,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
res->base.format = c2d.format;
res->base.resource_id = c2d.resource_id;
res->base.dmabuf_fd = -1;
+qemu_uuid_generate(&res->uuid);
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c2d.resource_id;
@@ -245,6 +248,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
res->base.format = c3d.format;
res->base.resource_id = c3d.resource_id;
res->base.dmabuf_fd = -1;
+qemu_uuid_generate(&res->uuid);
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c3d.resource_id;
@@ -672,6 +676,7 @@ static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
res->base.resource_id = cblob.resource_id;
res->base.blob_size = cblob.size;
res->base.dmabuf_fd = -1;
+qemu_uuid_generate(&res->uuid);
if (cblob.blob_mem != VIRTIO_GPU_BLOB_MEM_HOST3D) {
ret = virtio_gpu_create_mapping_iov(g, cblob.nr_entries, sizeof(cblob),
@@ -870,6 +875,31 @@ static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
}
#endif /* HAVE_VIRGL_RESOURCE_BLOB */
+static void virgl_cmd_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+struct virtio_gpu_virgl_resource *res;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(&assign, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_virgl_find_resource(g, assign.resource_id);
+if (!res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, assign.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+memset(&resp, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+memcpy(resp.uuid, res->uuid.data, sizeof(resp.uuid));
+virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp));
+}
+
void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -924,6 +954,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+
[PATCH v9 09/11] virtio-gpu: Register capsets dynamically
From: Pierre-Eric Pelloux-Prayer
virtio_gpu_virgl_get_num_capsets will return "num_capsets", but we can't
assume that capset_index 1 is always VIRGL2 once we'll support more capsets,
like Venus and DRM capsets. Register capsets dynamically to avoid that problem.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 34 +++---
include/hw/virtio/virtio-gpu.h | 2 ++
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index de788df155bf..9aa1fd78f1e1 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -597,19 +597,13 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
VIRTIO_GPU_FILL_CMD(info);
memset(&resp, 0, sizeof(resp));
-if (info.capset_index == 0) {
-resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL;
-virgl_renderer_get_cap_set(resp.capset_id,
- &resp.capset_max_version,
- &resp.capset_max_size);
-} else if (info.capset_index == 1) {
-resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL2;
+
+if (info.capset_index < g->capset_ids->len) {
+resp.capset_id = g_array_index(g->capset_ids, uint32_t,
+ info.capset_index);
virgl_renderer_get_cap_set(resp.capset_id,
&resp.capset_max_version,
&resp.capset_max_size);
-} else {
-resp.capset_max_version = 0;
-resp.capset_max_size = 0;
}
resp.hdr.type = VIRTIO_GPU_RESP_OK_CAPSET_INFO;
virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp));
@@ -1159,12 +1153,30 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
return 0;
}
+static void virtio_gpu_virgl_add_capset(VirtIOGPU *g, uint32_t capset_id)
+{
+g_array_append_val(g->capset_ids, capset_id);
+}
+
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
uint32_t capset2_max_ver, capset2_max_size;
+
+if (g->capset_ids) {
+return g->capset_ids->len;
+}
+
+g->capset_ids = g_array_new(false, false, sizeof(uint32_t));
+
+/* VIRGL is always supported. */
+virtio_gpu_virgl_add_capset(g, VIRTIO_GPU_CAPSET_VIRGL);
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
&capset2_max_ver,
&capset2_max_size);
+if (capset2_max_ver) {
+virtio_gpu_virgl_add_capset(g, VIRTIO_GPU_CAPSET_VIRGL2);
+}
-return capset2_max_ver ? 2 : 1;
+return g->capset_ids->len;
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index dc24360656ce..32f38d86c908 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -211,6 +211,8 @@ struct VirtIOGPU {
QTAILQ_HEAD(, VGPUDMABuf) bufs;
VGPUDMABuf *primary[VIRTIO_GPU_MAX_SCANOUTS];
} dmabuf;
+
+GArray *capset_ids;
};
struct VirtIOGPUClass {
--
2.44.0
[PATCH v9 00/11] Support blob memory and venus on qemu
Hello, This series enables Vulkan Venus context support on virtio-gpu. All virglrender and almost all Linux kernel prerequisite changes needed by Venus are already in upstream. For kernel there is a pending KVM patchset that fixes mapping of compound pages needed for DRM drivers using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error from Qemu. [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-steve...@google.com/ Example Qemu cmdline that enables Venus for virtio-gpu: qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,vulkan=true Changes from V8 to V9 - Added resuming of cmdq processing when hostmem MR is freed, as was suggested by Akihiko Odaki. - Added more error messages, suggested by Akihiko Odaki - Dropped superfluous 'res->async_unmap_completed', suggested by Akihiko Odaki. - Kept using cmd->suspended flag. Akihiko Odaki suggested to make virtio_gpu_virgl_process_cmd() return false if cmd processing is suspended, but it's not easy to implement due to ubiquitous VIRTIO_GPU_FILL_CMD() macros that returns void, requiring to change all the virtio-gpu processing code. - Added back virtio_gpu_virgl_resource as was requested by Akihiko Odaki, though I'm not convinced it's really needed. - Switched to use GArray, renamed capset2_max_ver/size vars and moved "vulkan" property definition to the virtio-gpu-gl device in the Venus patch, like was suggested by Akihiko Odaki. - Moved UUID to virtio_gpu_virgl_resource and dropped UUID save/restore since it will require bumping VM version and virgl device isn't miratable anyways. - Fixed exposing UUID feature with Rutabaga - Dropped linux-headers update patch because headers were already updated in Qemu/staging. - Added patch that updates virtio migration doc with a note about virtio-gpu migration specifics, suggested by Akihiko Odaki. - Addressed coding style issue noticed by Akihiko Odaki Changes from V7 to V8 - Supported suspension of virtio-gpu commands processing and made unmapping of hostmem region asynchronous by blocking/suspending cmd processing until region is unmapped. Suggested by Akihiko Odaki. - Fixed arm64 building of x86 targets using updated linux-headers. Corrected the update script. Thanks to Rob Clark for reporting the issue. - Added new patch that makes registration of virgl capsets dynamic. Requested by Antonio Caggiano and Pierre-Eric Pelloux-Prayer. - Venus capset now isn't advertised if Vulkan is disabled with vulkan=false Changes from V6 to V7 - Used scripts/update-linux-headers.sh to update Qemu headers based on Linux v6.8-rc3 that adds Venus capset definition to virtio-gpu protocol, was requested by Peter Maydel - Added r-bs that were given to v6 patches. Corrected missing s-o-bs - Dropped context_init Qemu's virtio-gpu device configuration flag, was suggested by Marc-André Lureau - Added missing error condition checks spotted by Marc-André Lureau and Akihiko Odaki, and few more - Returned back res->mr referencing to memory_region_init_ram_ptr() like was suggested by Akihiko Odaki. Incorporated fix suggested by Pierre-Eric to specify the MR name - Dropped the virgl_gpu_resource wrapper, cleaned up and simplified patch that adds blob-cmd support - Fixed improper blob resource removal from resource list on resource_unref that was spotted by Akihiko Odaki - Change order of the blob patches, was suggested by Akihiko Odaki. The cmd_set_scanout_blob support is enabled first - Factored out patch that adds resource management support to virtio-gpu-gl, was requested by Marc-André Lureau - Simplified and improved the UUID support patch, dropped the hash table as we don't need it for now. Moved QemuUUID to virtio_gpu_simple_resource. This all was suggested by Akihiko Odaki and Marc-André Lureau - Dropped console_has_gl() check, suggested by Akihiko Odaki - Reworked Meson cheking of libvirglrender features, made new features available based on virglrender pkgconfig version instead of checking symbols in header. This should fix build error using older virglrender version, reported by Alex Bennée - Made enabling of Venus context configrable via new virtio-gpu device "vulkan=true" flag, suggested by Marc-André Lureau. The flag is disabled by default because it requires blob and hostmem options to be enabled and configured Changes from V5 to V6 - Move macros configurations under virgl.found() and rename HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS. - Handle the case while context_init is disabled. - Enable context_init by default. - Move virtio_gpu_virgl_resource_unmap() into virgl_cmd_resource_unmap_blob(). - Introduce new struct virgl_gpu_resource to store virgl specific members. - Remove erro handling of g_new0, because glib will abort() on OOM. - Set resource uuid as option. - Implement optional subsection of vmstate_virtio_gpu_resource_uuid_state for virtio live migration. - Use g_int_hash/g_int_equ
[PATCH v9 04/11] virtio-gpu: Add virgl resource management
From: Huang Rui
In a preparation to adding host blobs support to virtio-gpu, add virgl
resource management that allows to retrieve resource based on its ID
and virgl resource wrapper on top of simple resource that will be contain
fields specific to virgl.
Signed-off-by: Huang Rui
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index ef598d8d23ee..7c7ffb0c251e 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -22,6 +22,23 @@
#include
+struct virtio_gpu_virgl_resource {
+struct virtio_gpu_simple_resource base;
+};
+
+static struct virtio_gpu_virgl_resource *
+virtio_gpu_virgl_find_resource(VirtIOGPU *g, uint32_t resource_id)
+{
+struct virtio_gpu_simple_resource *res;
+
+res = virtio_gpu_find_resource(g, resource_id);
+if (!res) {
+return NULL;
+}
+
+return container_of(res, struct virtio_gpu_virgl_resource, base);
+}
+
#if VIRGL_RENDERER_CALLBACKS_VERSION >= 4
static void *
virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
@@ -35,11 +52,34 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_virgl_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
c2d.width, c2d.height);
+if (c2d.resource_id == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = virtio_gpu_virgl_find_resource(g, c2d.resource_id);
+if (res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, c2d.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = g_new0(struct virtio_gpu_virgl_resource, 1);
+res->base.width = c2d.width;
+res->base.height = c2d.height;
+res->base.format = c2d.format;
+res->base.resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
+
args.handle = c2d.resource_id;
args.target = 2;
args.format = c2d.format;
@@ -59,11 +99,34 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_virgl_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
c3d.width, c3d.height, c3d.depth);
+if (c3d.resource_id == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = virtio_gpu_virgl_find_resource(g, c3d.resource_id);
+if (res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, c3d.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = g_new0(struct virtio_gpu_virgl_resource, 1);
+res->base.width = c3d.width;
+res->base.height = c3d.height;
+res->base.format = c3d.format;
+res->base.resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
+
args.handle = c3d.resource_id;
args.target = c3d.target;
args.format = c3d.format;
@@ -82,12 +145,19 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
struct virtio_gpu_resource_unref unref;
+struct virtio_gpu_virgl_resource *res;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
+res = virtio_gpu_virgl_find_resource(g, unref.resource_id);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
@@ -95,6 +165,10 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
}
virgl_renderer_resource_unref(unref.resource_id);
+
+QTAILQ_REMOVE(&g->reslist, &res->base, next);
+
+g_free(res);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
--
2.44.0
[PATCH v9 10/11] virtio-gpu: Support Venus context
From: Antonio Caggiano
Request Venus when initializing VirGL and if vulkan=true flag is set for
virtio-gpu device.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-gl.c | 2 ++
hw/display/virtio-gpu-virgl.c | 22 ++
hw/display/virtio-gpu.c| 13 +
include/hw/virtio/virtio-gpu.h | 3 +++
meson.build| 1 +
5 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index a8892bcc5346..8e475d28f857 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -138,6 +138,8 @@ static void virtio_gpu_gl_device_realize(DeviceState *qdev,
Error **errp)
static Property virtio_gpu_gl_properties[] = {
DEFINE_PROP_BIT("stats", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_STATS_ENABLED, false),
+DEFINE_PROP_BIT("vulkan", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_VENUS_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 9aa1fd78f1e1..969272315c2a 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1135,6 +1135,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
}
#endif
+#ifdef VIRGL_RENDERER_VENUS
+if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
+}
+#endif
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
if (ret != 0) {
@@ -1160,7 +1165,7 @@ static void virtio_gpu_virgl_add_capset(VirtIOGPU *g,
uint32_t capset_id)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset_max_ver, capset_max_size;
if (g->capset_ids) {
return g->capset_ids->len;
@@ -1172,11 +1177,20 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
virtio_gpu_virgl_add_capset(g, VIRTIO_GPU_CAPSET_VIRGL);
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- &capset2_max_ver,
- &capset2_max_size);
-if (capset2_max_ver) {
+ &capset_max_ver,
+ &capset_max_size);
+if (capset_max_ver) {
virtio_gpu_virgl_add_capset(g, VIRTIO_GPU_CAPSET_VIRGL2);
}
+if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ &capset_max_ver,
+ &capset_max_size);
+if (capset_max_size) {
+virtio_gpu_virgl_add_capset(g, VIRTIO_GPU_CAPSET_VENUS);
+}
+}
+
return g->capset_ids->len;
}
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 45c1f2006712..e86326b25a72 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1491,6 +1491,19 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
#endif
}
+if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+#ifdef HAVE_VIRGL_VENUS
+if (!virtio_gpu_blob_enabled(g->parent_obj.conf) ||
+!virtio_gpu_hostmem_enabled(g->parent_obj.conf)) {
+error_setg(errp, "venus requires enabled blob and hostmem
options");
+return;
+}
+#else
+error_setg(errp, "old virglrenderer, venus unsupported");
+return;
+#endif
+}
+
if (!virtio_gpu_base_device_realize(qdev,
virtio_gpu_handle_ctrl_cb,
virtio_gpu_handle_cursor_cb,
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 32f38d86c908..7af81131499c 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -99,6 +99,7 @@ enum virtio_gpu_base_conf_flags {
VIRTIO_GPU_FLAG_BLOB_ENABLED,
VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
VIRTIO_GPU_FLAG_RUTABAGA_ENABLED,
+VIRTIO_GPU_FLAG_VENUS_ENABLED,
};
#define virtio_gpu_virgl_enabled(_cfg) \
@@ -117,6 +118,8 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_RUTABAGA_ENABLED))
#define virtio_gpu_hostmem_enabled(_cfg) \
(_cfg.hostmem > 0)
+#define virtio_gpu_venus_enabled(_cfg) \
+(_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED))
struct virtio_gpu_base_conf {
uint32_t max_outputs;
diff --git a/meson.build b/meson.build
index 5ef50811b6ba..4e03349c9d10 100644
--- a/meson.build
+++ b/meson.build
@@ -2290,6 +2290,7 @@ if virgl.version().version_compare('>=1.0.0')
config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
config_host_data.set('HAVE_VIRGL_RESOURCE_BLOB', 1)
+ config_host_data.set('HAVE_VIRGL_VENUS', 1)
endif
config_host_dat
[PATCH v9 01/11] virtio-gpu: Use pkgconfig version to decide which virgl features are available
New virglrerenderer features were stabilized with release of v1.0.0.
Presence of symbols in virglrenderer.h doesn't guarantee ABI compatibility
with pre-release development versions of libvirglerender. Use virglrenderer
version to decide reliably which virgl features are available.
Signed-off-by: Dmitry Osipenko
---
meson.build | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/meson.build b/meson.build
index 553b9409995b..c6f22f565071 100644
--- a/meson.build
+++ b/meson.build
@@ -2286,11 +2286,8 @@ config_host_data.set('CONFIG_PNG', png.found())
config_host_data.set('CONFIG_VNC', vnc.found())
config_host_data.set('CONFIG_VNC_JPEG', jpeg.found())
config_host_data.set('CONFIG_VNC_SASL', sasl.found())
-if virgl.found()
- config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT',
- cc.has_member('struct
virgl_renderer_resource_info_ext', 'd3d_tex2d',
- prefix: '#include ',
- dependencies: virgl))
+if virgl.version().version_compare('>=1.0.0')
+ config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
[PATCH v9 07/11] virtio-gpu: Handle resource blob commands
From: Antonio Caggiano
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio Caggiano
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 268 ++
hw/display/virtio-gpu.c | 4 +-
2 files changed, 271 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 0feaa9f2c52e..73d4acbf1777 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -26,6 +26,8 @@
struct virtio_gpu_virgl_resource {
struct virtio_gpu_simple_resource base;
+bool async_unmap_in_progress;
+MemoryRegion *mr;
};
static struct virtio_gpu_virgl_resource *
@@ -49,6 +51,120 @@ virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
}
#endif
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+struct virtio_gpu_virgl_hostmem_region {
+MemoryRegion mr;
+struct VirtIOGPU *g;
+struct virtio_gpu_virgl_resource *res;
+};
+
+static void virtio_gpu_virgl_resume_cmdq(void *opaque)
+{
+VirtIOGPU *g = opaque;
+
+virtio_gpu_process_cmdq(g);
+}
+
+static void virtio_gpu_virgl_hostmem_region_free(void *obj)
+{
+MemoryRegion *mr = MEMORY_REGION(obj);
+struct virtio_gpu_virgl_hostmem_region *vmr;
+VirtIOGPUBase *b;
+
+vmr = container_of(mr, struct virtio_gpu_virgl_hostmem_region, mr);
+vmr->res->async_unmap_in_progress = false;
+
+b = VIRTIO_GPU_BASE(vmr->g);
+b->renderer_blocked--;
+
+/*
+ * memory_region_unref() may be executed from RCU thread context, while
+ * virglrenderer works only on the main-loop thread that's holding GL
+ * context.
+ */
+aio_bh_schedule_oneshot(qemu_get_aio_context(),
+virtio_gpu_virgl_resume_cmdq, vmr->g);
+g_free(vmr);
+}
+
+static int
+virtio_gpu_virgl_map_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res,
+ uint64_t offset)
+{
+struct virtio_gpu_virgl_hostmem_region *vmr;
+VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+MemoryRegion *mr;
+uint64_t size;
+void *data;
+int ret;
+
+if (!virtio_gpu_hostmem_enabled(b->conf)) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: hostmem disabled\n", __func__);
+return -EOPNOTSUPP;
+}
+
+ret = virgl_renderer_resource_map(res->base.resource_id, &data, &size);
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map virgl resource\n",
+ __func__);
+return -ret;
+}
+
+vmr = g_new0(struct virtio_gpu_virgl_hostmem_region, 1);
+vmr->res = res;
+vmr->g = g;
+
+mr = &vmr->mr;
+memory_region_init_ram_ptr(mr, OBJECT(mr), "blob", size, data);
+memory_region_add_subregion(&b->hostmem, offset, mr);
+memory_region_set_enabled(mr, true);
+
+/*
+ * Potentially, MR could outlive the resource if MR's reference is held
+ * outside of virtio-gpu. In order to prevent unmapping resource while
+ * MR is alive, and thus, making the data pointer invalid, we will block
+ * virtio-gpu command processing until MR is fully unreferenced and
+ * released.
+ */
+OBJECT(mr)->free = virtio_gpu_virgl_hostmem_region_free;
+
+res->mr = mr;
+
+return 0;
+}
+
+static bool
+virtio_gpu_virgl_unmap_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res)
+{
+VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+
+if (!res->async_unmap_in_progress && res->mr) {
+/* memory region owns self res->mr object and frees it by itself */
+MemoryRegion *mr = res->mr;
+res->mr = NULL;
+
+res->async_unmap_in_progress = true;
+
+/* render will be unblocked when MR is freed */
+b->renderer_blocked++;
+
+memory_region_set_enabled(mr, false);
+memory_region_del_subregion(&b->hostmem, mr);
+object_unparent(OBJECT(mr));
+}
+
+if (res->async_unmap_in_progress) {
+return false;
+}
+
+virgl_renderer_resource_unmap(res->base.resource_id);
+
+return true;
+}
+#endif /* HAVE_VIRGL_RESOURCE_BLOB */
+
static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -162,6 +278,14 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
return;
}
+if (res->mr || cmd->suspended) {
+bool unmapped = virtio_gpu_virgl_unmap_resource_blob(g, res);
+cmd->suspended = !unmapped;
+if (cmd->suspended) {
+return;
+}
+}
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
@@ -512,6 +636,1
[PATCH v9 05/11] virtio-gpu: Support blob scanout using dmabuf fd
From: Robert Beckett
Support displaying blob resources by handling SET_SCANOUT_BLOB
command.
Signed-by: Antonio Caggiano
Signed-off-by: Robert Beckett
Signed-off-by: Huang Rui
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 109 +
hw/display/virtio-gpu.c| 12 ++--
include/hw/virtio/virtio-gpu.h | 7 +++
meson.build| 1 +
4 files changed, 123 insertions(+), 6 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 7c7ffb0c251e..14e94a82dd6a 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -17,6 +17,8 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
+#include "hw/virtio/virtio-gpu-pixman.h"
#include "ui/egl-helpers.h"
@@ -78,6 +80,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
res->base.height = c2d.height;
res->base.format = c2d.format;
res->base.resource_id = c2d.resource_id;
+res->base.dmabuf_fd = -1;
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c2d.resource_id;
@@ -125,6 +128,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
res->base.height = c3d.height;
res->base.format = c3d.format;
res->base.resource_id = c3d.resource_id;
+res->base.dmabuf_fd = -1;
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c3d.resource_id;
@@ -507,6 +511,106 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_framebuffer fb = { 0 };
+struct virgl_renderer_resource_info info;
+struct virtio_gpu_virgl_resource *res;
+struct virtio_gpu_set_scanout_blob ss;
+uint64_t fbend;
+
+VIRTIO_GPU_FILL_CMD(ss);
+virtio_gpu_scanout_blob_bswap(&ss);
+trace_virtio_gpu_cmd_set_scanout_blob(ss.scanout_id, ss.resource_id,
+ ss.r.width, ss.r.height, ss.r.x,
+ ss.r.y);
+
+if (ss.scanout_id >= g->parent_obj.conf.max_outputs) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout id specified %d",
+ __func__, ss.scanout_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_SCANOUT_ID;
+return;
+}
+
+if (ss.resource_id == 0) {
+virtio_gpu_disable_scanout(g, ss.scanout_id);
+return;
+}
+
+if (ss.width < 16 ||
+ss.height < 16 ||
+ss.r.x + ss.r.width > ss.width ||
+ss.r.y + ss.r.height > ss.height) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout %d bounds for"
+ " resource %d, rect (%d,%d)+%d,%d, fb %d %d\n",
+ __func__, ss.scanout_id, ss.resource_id,
+ ss.r.x, ss.r.y, ss.r.width, ss.r.height,
+ ss.width, ss.height);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+res = virtio_gpu_virgl_find_resource(g, ss.resource_id);
+if (!res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (virgl_renderer_resource_get_info(ss.resource_id, &info)) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not have info %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (res->base.dmabuf_fd < 0) {
+res->base.dmabuf_fd = info.fd;
+}
+if (res->base.dmabuf_fd < 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource not backed by dmabuf
%d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+fb.format = virtio_gpu_get_pixman_format(ss.format);
+if (!fb.format) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: pixel format not supported %d\n",
+ __func__, ss.format);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+fb.bytes_pp = DIV_ROUND_UP(PIXMAN_FORMAT_BPP(fb.format), 8);
+fb.width = ss.width;
+fb.height = ss.height;
+fb.stride = ss.strides[0];
+fb.offset = ss.offsets[0] + ss.r.x * fb.bytes_pp + ss.r.y * fb.stride;
+
+fbend = fb.offset;
+fbend += fb.stride * (ss.r.height - 1);
+fbend += fb.bytes_pp * ss.r.width;
+if (fbend > res->base.blob_size) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: fb end out of range\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+
[PATCH v9 06/11] virtio-gpu: Support suspension of commands processing
Add new "suspended" flag to virtio_gpu_ctrl_command telling cmd
processor that it should stop processing commands and retry again
next time until flag is unset.
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-gl.c | 1 +
hw/display/virtio-gpu-rutabaga.c | 1 +
hw/display/virtio-gpu-virgl.c| 3 +++
hw/display/virtio-gpu.c | 5 +
include/hw/virtio/virtio-gpu.h | 1 +
5 files changed, 11 insertions(+)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index ba478124e2c2..a8892bcc5346 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -79,6 +79,7 @@ static void virtio_gpu_gl_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
cmd->vq = vq;
cmd->error = 0;
cmd->finished = false;
+cmd->suspended = false;
QTAILQ_INSERT_TAIL(&g->cmdq, cmd, next);
cmd = virtqueue_pop(vq, sizeof(struct virtio_gpu_ctrl_command));
}
diff --git a/hw/display/virtio-gpu-rutabaga.c b/hw/display/virtio-gpu-rutabaga.c
index 17bf701a2163..b6e84d436fb2 100644
--- a/hw/display/virtio-gpu-rutabaga.c
+++ b/hw/display/virtio-gpu-rutabaga.c
@@ -1061,6 +1061,7 @@ static void virtio_gpu_rutabaga_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
cmd->vq = vq;
cmd->error = 0;
cmd->finished = false;
+cmd->suspended = false;
QTAILQ_INSERT_TAIL(&g->cmdq, cmd, next);
cmd = virtqueue_pop(vq, sizeof(struct virtio_gpu_ctrl_command));
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 14e94a82dd6a..0feaa9f2c52e 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -687,6 +687,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
break;
}
+if (cmd->suspended) {
+return;
+}
if (cmd->finished) {
return;
}
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 1e57a53d346c..a1bd4d6914c4 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1054,6 +1054,10 @@ void virtio_gpu_process_cmdq(VirtIOGPU *g)
/* process command */
vgc->process_cmd(g, cmd);
+if (cmd->suspended) {
+break;
+}
+
QTAILQ_REMOVE(&g->cmdq, cmd, next);
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
g->stats.requests++;
@@ -1113,6 +1117,7 @@ static void virtio_gpu_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
cmd->vq = vq;
cmd->error = 0;
cmd->finished = false;
+cmd->suspended = false;
QTAILQ_INSERT_TAIL(&g->cmdq, cmd, next);
cmd = virtqueue_pop(vq, sizeof(struct virtio_gpu_ctrl_command));
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 44c676c3ca4a..dc24360656ce 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -132,6 +132,7 @@ struct virtio_gpu_ctrl_command {
struct virtio_gpu_ctrl_hdr cmd_hdr;
uint32_t error;
bool finished;
+bool suspended;
QTAILQ_ENTRY(virtio_gpu_ctrl_command) next;
};
--
2.44.0
[PATCH v9 03/11] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano
Signed-off-by: Huang Rui
Reviewed-by: Antonio Caggiano
Reviewed-by: Marc-André Lureau
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index ae831b6b3e3e..dac272ecadb1 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1472,6 +1472,7 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
if (!virtio_gpu_rutabaga_enabled(g->parent_obj.conf) &&
+!virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
!virtio_gpu_have_udmabuf()) {
error_setg(errp, "need rutabaga or udmabuf for blob resources");
return;
--
2.44.0
Re: [PATCH] ci: move external build environment setups to CentOS Stream 9
On Thu, Apr 25, 2024 at 05:03:43PM +0200, Thomas Huth wrote:
> On 12/04/2024 12.37, Paolo Bonzini wrote:
> > RHEL 9 (and thus also the derivatives) are available since two years
> > now, so according to QEMU's support policy, we can drop the active
> > support for the previous major version 8 now.
> >
> > Thus upgrade our CentOS Stream build environment playbooks to major
> > version 9 now.
> >
> > Signed-off-by: Paolo Bonzini
> > ---
> > .../stream/{8 => 9}/build-environment.yml | 31 ++---
> > .../stream/{8 => 9}/x86_64/configure | 4 +-
> > .../stream/{8 => 9}/x86_64/test-avocado | 0
> > scripts/ci/setup/build-environment.yml| 44 +++
> > 4 files changed, 34 insertions(+), 45 deletions(-)
> > rename scripts/ci/org.centos/stream/{8 => 9}/build-environment.yml (75%)
> > rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/configure (98%)
> > rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/test-avocado (100%)
>
> Hi Paolo!
>
> Not sure whether you've seen my busted pull request, but anyway: It seems
> like this was not enough to update the custom runner. You also need to
> update .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml for this.
>
> By the way, who has access to the s390x custom runner and could update it to
> Ubuntu 22.04 now? It still seems to work with 20.04 which will be out of
> support from the QEMU POV next week...
I rather wish that the custom runners were all using podman/docker,
so we could have the jobs just build containers for the envs, like
we do on shared runners, and/or on the Azure runners. That way we're
not beholden to an admin to manually update OS intsalls.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
On Thu, Apr 25, 2024 at 05:34:52PM +0200, Anthony Harivel wrote:
> Hi Daniel,
>
> Daniel P. Berrangé, Apr 18, 2024 at 18:42:
>
> > > +if (kvm_is_rapl_feat_enable(cs)) {
> > > +if (!IS_INTEL_CPU(env)) {
> > > +error_setg(errp, "RAPL feature can only be\
> > > + enabled with Intel CPU models");
> > > +return false;
> > > +}
> > > +}
> >
> > I see a crash in kvm_is_rapl_feat_enable() from this caller,
> > when I run with this kind of command line:
> >
> > $ qemu-system-x86_64 \
> > -kernel /lib/modules/6.6.9-100.fc38.x86_64/vmlinuz \
> > -initrd tiny-initrd.img -m 2000 -serial stdio -nodefaults \
> > -display none -accel kvm -append "console=ttyS0 quiet"
> >
> >
> > #0 0x55bc14b7 in kvm_is_rapl_feat_enable
> > (cs=cs@entry=0x57b83470) at ../target/i386/kvm/kvm.c:2531
> > #1 0x55bc7534 in kvm_cpu_realizefn (cs=0x57b83470,
> > errp=0x7fffd2a0) at ../target/i386/kvm/kvm-cpu.c:54
> > #2 0x55d2432a in accel_cpu_common_realize (cpu=0x57b83470,
> > errp=0x7fffd2a0) at ../accel/accel-target.c:130
> > #3 0x55cdd955 in cpu_exec_realizefn (cpu=cpu@entry=0x57b83470,
> > errp=errp@entry=0x7fffd2a0) at ../cpu-target.c:137
> > #4 0x55c14b89 in x86_cpu_realizefn (dev=0x57b83470,
> > errp=0x7fffd310) at ../target/i386/cpu.c:7320
> > #5 0x55d58f4b in device_set_realized (obj=,
> > value=, errp=0x7fffd390) at ../hw/core/qdev.c:510
> > #6 0x55d5d78d in property_set_bool (obj=0x57b83470,
> > v=, name=, opaque=0x578558e0,
> > errp=0x7fffd390)
> > at ../qom/object.c:2358
> > #7 0x55d60b0b in object_property_set
> > (obj=obj@entry=0x57b83470, name=name@entry=0x5607c799 "realized",
> > v=v@entry=0x57b8ccb0, errp=0x7fffd390,
> > errp@entry=0x56e210d8 ) at ../qom/object.c:1472
> > #8 0x55d6444f in object_property_set_qobject
> > (obj=obj@entry=0x57b83470, name=name@entry=0x5607c799
> > "realized", value=value@entry=0x57854800,
> > errp=errp@entry=0x56e210d8 )
> > at ../qom/qom-qobject.c:28
> > #9 0x55d61174 in object_property_set_bool
> > (obj=0x57b83470, name=name@entry=0x5607c799 "realized",
> > value=value@entry=true, errp=errp@entry=0x56e210d8 ) at
> > ../qom/object.c:1541
> > #10 0x55d59a3c in qdev_realize (dev=,
> > bus=bus@entry=0x0, errp=errp@entry=0x56e210d8 ) at
> > ../hw/core/qdev.c:292
> > #11 0x55bd51e0 in x86_cpu_new (x86ms=, apic_id=0,
> > errp=0x56e210d8 ) at ../hw/i386/x86.c:105
> > #12 0x55bd52ce in x86_cpus_init (x86ms=x86ms@entry=0x57aaed30,
> > default_cpu_version=) at ../hw/i386/x86.c:156
> > #13 0x55bdc1a7 in pc_init1 (machine=0x57aaed30,
> > pci_type=0x5604aa61 "i440FX") at ../hw/i386/pc_piix.c:185
> > #14 0x55947a11 in machine_run_board_init (machine=0x57aaed30,
> > mem_path=, errp=, errp@entry=0x56e210d8
> > )
> > at ../hw/core/machine.c:1547
> > #15 0x55b020ed in qemu_init_board () at ../system/vl.c:2613
> > #16 qmp_x_exit_preconfig (errp=0x56e210d8 ) at
> > ../system/vl.c:2705
> > #17 0x55b0611e in qemu_init (argc=, argv= > out>) at ../system/vl.c:3739
> > #18 0x55897ca9 in main (argc=, argv=)
> > at ../system/main.c:47
> >
> > The problem is that 'cs->kvm_state' is NULL here
> >
>
> After some investigation it seems that kvm_state is not yet committed
> at this point. Shame, because GDB showed me that we have already pass
> the kvm_accel_instance_init() in accel/kvm/kvm-all.c that sets the
> value "msr_energy.enable" in kvm_state...
>
> So should I dig more to still do the sanity check in kvm_cpu_realizefn()
> or should I already move the RAPL feature from -kvm to -cpu
> like suggested by Zhao from Intel and then access it from the CPUState ?
I'm not so sure about that question. I think Paolo is best placed
to suggest which is better, as the KVM maintainer.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 10/14] migration/multifd: Enable DSA offloading in multifd sender path.
Hao Xiang writes:
> Multifd sender path gets an array of pages queued by the migration
> thread. It performs zero page checking on every page in the array.
> The pages are classfied as either a zero page or a normal page. This
> change uses Intel DSA to offload the zero page checking from CPU to
> the DSA accelerator. The sender thread submits a batch of pages to DSA
> hardware and waits for the DSA completion thread to signal for work
> completion.
>
> Signed-off-by: Hao Xiang
> ---
> migration/multifd-zero-page.c | 99 +--
> migration/multifd.c | 27 +-
> migration/multifd.h | 1 +
> 3 files changed, 120 insertions(+), 7 deletions(-)
>
> diff --git a/migration/multifd-zero-page.c b/migration/multifd-zero-page.c
> index e1b8370f88..4f426289e4 100644
> --- a/migration/multifd-zero-page.c
> +++ b/migration/multifd-zero-page.c
> @@ -37,25 +37,83 @@ static void swap_page_offset(ram_addr_t *pages_offset,
> int a, int b)
> }
>
> /**
> - * multifd_send_zero_page_detect: Perform zero page detection on all pages.
> + * zero_page_detect_cpu: Perform zero page detection using CPU.
> *
> * Sorts normal pages before zero pages in p->pages->offset and updates
> * p->pages->normal_num.
> *
> * @param p A pointer to the send params.
> */
> -void multifd_send_zero_page_detect(MultiFDSendParams *p)
> +static void zero_page_detect_cpu(MultiFDSendParams *p)
> {
> MultiFDPages_t *pages = p->pages;
> RAMBlock *rb = pages->block;
> int i = 0;
> int j = pages->num - 1;
>
> -if (!multifd_zero_page_enabled()) {
> -pages->normal_num = pages->num;
> +/*
> + * Sort the page offset array by moving all normal pages to
> + * the left and all zero pages to the right of the array.
> + */
> +while (i <= j) {
> +uint64_t offset = pages->offset[i];
> +
> +if (!buffer_is_zero(rb->host + offset, p->page_size)) {
> +i++;
> +continue;
> +}
> +
> +swap_page_offset(pages->offset, i, j);
> +ram_release_page(rb->idstr, offset);
> +j--;
> +}
> +
> +pages->normal_num = i;
> +}
> +
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +static void swap_result(bool *results, int a, int b)
> +{
> +bool temp;
> +
> +if (a == b) {
> return;
> }
>
> +temp = results[a];
> +results[a] = results[b];
> +results[b] = temp;
> +}
> +
> +/**
> + * zero_page_detect_dsa: Perform zero page detection using
> + * Intel Data Streaming Accelerator (DSA).
> + *
> + * Sorts normal pages before zero pages in p->pages->offset and updates
> + * p->pages->normal_num.
> + *
> + * @param p A pointer to the send params.
> + */
> +static void zero_page_detect_dsa(MultiFDSendParams *p)
> +{
> +MultiFDPages_t *pages = p->pages;
> +RAMBlock *rb = pages->block;
> +bool *results = p->batch_task->results;
At this point I don't see the need to carry p->batch_task in the multifd
code. results here could be taken from the
buffer_is_zero_dsa_batch_async call below.
> +
> +for (int i = 0; i < p->pages->num; i++) {
> +p->batch_task->addr[i] = (ram_addr_t)(rb->host +
> p->pages->offset[i]);
... and this is just what p->iov[0].iov_base contains.
> +}
> +
> +buffer_is_zero_dsa_batch_async(p->batch_task,
This is not async. You're using the result right after this call. Leave
the 'async' for the functions called from whithin this one, which do the
actual wait part.
> + (const void **)p->batch_task->addr,
> + p->pages->num,
> + p->page_size);
> +
> +int i = 0;
> +int j = pages->num - 1;
> +
> /*
> * Sort the page offset array by moving all normal pages to
> * the left and all zero pages to the right of the array.
> @@ -63,11 +121,12 @@ void multifd_send_zero_page_detect(MultiFDSendParams *p)
> while (i <= j) {
> uint64_t offset = pages->offset[i];
>
> -if (!buffer_is_zero(rb->host + offset, p->page_size)) {
> +if (!results[i]) {
> i++;
> continue;
> }
>
> +swap_result(results, i, j);
> swap_page_offset(pages->offset, i, j);
> ram_release_page(rb->idstr, offset);
> j--;
> @@ -76,6 +135,15 @@ void multifd_send_zero_page_detect(MultiFDSendParams *p)
> pages->normal_num = i;
> }
>
> +#else
> +
> +static void zero_page_detect_dsa(MultiFDSendParams *p)
> +{
> +exit(1);
> +}
> +
> +#endif
> +
> void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> {
> for (int i = 0; i < p->zero_num; i++) {
> @@ -87,3 +155,24 @@ void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> }
> }
> }
> +
> +/**
> + * multifd_send_zero_page_detect: Perform zero page detection on all pages.
> + *
> + * @param p A pointer to the send params.
> + */
> +void multifd_send_zero_page_detect(MultiFDSe
Re: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
Hi Daniel,
Daniel P. Berrangé, Apr 18, 2024 at 18:42:
> > +if (kvm_is_rapl_feat_enable(cs)) {
> > +if (!IS_INTEL_CPU(env)) {
> > +error_setg(errp, "RAPL feature can only be\
> > + enabled with Intel CPU models");
> > +return false;
> > +}
> > +}
>
> I see a crash in kvm_is_rapl_feat_enable() from this caller,
> when I run with this kind of command line:
>
> $ qemu-system-x86_64 \
> -kernel /lib/modules/6.6.9-100.fc38.x86_64/vmlinuz \
> -initrd tiny-initrd.img -m 2000 -serial stdio -nodefaults \
> -display none -accel kvm -append "console=ttyS0 quiet"
>
>
> #0 0x55bc14b7 in kvm_is_rapl_feat_enable
> (cs=cs@entry=0x57b83470) at ../target/i386/kvm/kvm.c:2531
> #1 0x55bc7534 in kvm_cpu_realizefn (cs=0x57b83470,
> errp=0x7fffd2a0) at ../target/i386/kvm/kvm-cpu.c:54
> #2 0x55d2432a in accel_cpu_common_realize (cpu=0x57b83470,
> errp=0x7fffd2a0) at ../accel/accel-target.c:130
> #3 0x55cdd955 in cpu_exec_realizefn (cpu=cpu@entry=0x57b83470,
> errp=errp@entry=0x7fffd2a0) at ../cpu-target.c:137
> #4 0x55c14b89 in x86_cpu_realizefn (dev=0x57b83470,
> errp=0x7fffd310) at ../target/i386/cpu.c:7320
> #5 0x55d58f4b in device_set_realized (obj=,
> value=, errp=0x7fffd390) at ../hw/core/qdev.c:510
> #6 0x55d5d78d in property_set_bool (obj=0x57b83470, v= out>, name=, opaque=0x578558e0, errp=0x7fffd390)
> at ../qom/object.c:2358
> #7 0x55d60b0b in object_property_set (obj=obj@entry=0x57b83470,
> name=name@entry=0x5607c799 "realized", v=v@entry=0x57b8ccb0,
> errp=0x7fffd390,
> errp@entry=0x56e210d8 ) at ../qom/object.c:1472
> #8 0x55d6444f in object_property_set_qobject
> (obj=obj@entry=0x57b83470, name=name@entry=0x5607c799 "realized",
> value=value@entry=0x57854800, errp=errp@entry=0x56e210d8
> )
> at ../qom/qom-qobject.c:28
> #9 0x55d61174 in object_property_set_bool
> (obj=0x57b83470, name=name@entry=0x5607c799 "realized",
> value=value@entry=true, errp=errp@entry=0x56e210d8 ) at
> ../qom/object.c:1541
> #10 0x55d59a3c in qdev_realize (dev=,
> bus=bus@entry=0x0, errp=errp@entry=0x56e210d8 ) at
> ../hw/core/qdev.c:292
> #11 0x55bd51e0 in x86_cpu_new (x86ms=, apic_id=0,
> errp=0x56e210d8 ) at ../hw/i386/x86.c:105
> #12 0x55bd52ce in x86_cpus_init (x86ms=x86ms@entry=0x57aaed30,
> default_cpu_version=) at ../hw/i386/x86.c:156
> #13 0x55bdc1a7 in pc_init1 (machine=0x57aaed30,
> pci_type=0x5604aa61 "i440FX") at ../hw/i386/pc_piix.c:185
> #14 0x55947a11 in machine_run_board_init (machine=0x57aaed30,
> mem_path=, errp=, errp@entry=0x56e210d8
> )
> at ../hw/core/machine.c:1547
> #15 0x55b020ed in qemu_init_board () at ../system/vl.c:2613
> #16 qmp_x_exit_preconfig (errp=0x56e210d8 ) at
> ../system/vl.c:2705
> #17 0x55b0611e in qemu_init (argc=, argv= out>) at ../system/vl.c:3739
> #18 0x55897ca9 in main (argc=, argv=)
> at ../system/main.c:47
>
> The problem is that 'cs->kvm_state' is NULL here
>
After some investigation it seems that kvm_state is not yet committed
at this point. Shame, because GDB showed me that we have already pass
the kvm_accel_instance_init() in accel/kvm/kvm-all.c that sets the
value "msr_energy.enable" in kvm_state...
So should I dig more to still do the sanity check in kvm_cpu_realizefn()
or should I already move the RAPL feature from -kvm to -cpu
like suggested by Zhao from Intel and then access it from the CPUState ?
The last one would require more work but if I can skip a new iteration
because I would need to do it anyway that would save me time in this end.
Thanks
Regards,
Anthony
Re: [PATCH v3] fix endianness bug
On 4/25/24 06:41, Alexandra Diupina wrote:
+static MemTxResult xlnx_dpdma_read_descriptor(XlnxDPDMAState *s,
+uint64_t desc_addr, DPDMADescriptor *desc)
+{
+if (dma_memory_read(&address_space_memory, desc_addr, &desc,
+sizeof(DPDMADescriptor), MEMTXATTRS_UNSPECIFIED))
+return MEMTX_ERROR;
+
Missing { } for docs/devel/style.rst.
+static void xlnx_dpdma_write_descriptor(uint64_t desc_addr,
+DPDMADescriptor *desc)
+{
+/* Convert from host endianness into LE. */
+desc->control = cpu_to_le32(desc->control);
+desc->descriptor_id = cpu_to_le32(desc->descriptor_id);
+desc->xfer_size = cpu_to_le32(desc->xfer_size);
+desc->line_size_stride = cpu_to_le32(desc->line_size_stride);
+desc->timestamp_lsb = cpu_to_le32(desc->timestamp_lsb);
+desc->timestamp_msb = cpu_to_le32(desc->timestamp_msb);
+desc->address_extension = cpu_to_le32(desc->address_extension);
+desc->next_descriptor = cpu_to_le32(desc->next_descriptor);
+desc->source_address = cpu_to_le32(desc->source_address);
+desc->address_extension_23 = cpu_to_le32(desc->address_extension_23);
+desc->address_extension_45 = cpu_to_le32(desc->address_extension_45);
+desc->source_address2 = cpu_to_le32(desc->source_address2);
+desc->source_address3 = cpu_to_le32(desc->source_address3);
+desc->source_address4 = cpu_to_le32(desc->source_address4);
+desc->source_address5 = cpu_to_le32(desc->source_address5);
+desc->crc = cpu_to_le32(desc->crc);
This is incorrect, rewriting in place, because after the call,
if (xlnx_dpdma_desc_completion_interrupt(&desc)) {
the memory block is still live, and the swap here has corrupted it.
+
+dma_memory_write(&address_space_memory, desc_addr, &desc,
This is incorrect because desc is now a pointer so &desc is DPDMADescriptor **.
Do not reply to an existing thread to post a new patch.
r~
Re: [PATCH v2 4/7] target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean
On 25/04/2024 05.12, Zhao Liu wrote: As error.h suggested, the best practice for callee is to return something to indicate success / failure. So make kvm_s390_get_host_cpu_model() return boolean and check the returned boolean in get_max_cpu_model() instead of accessing @err. Signed-off-by: Zhao Liu --- target/s390x/cpu_models.c | 9 - target/s390x/cpu_models.h | 2 +- target/s390x/kvm/kvm.c| 13 +++-- 3 files changed, 12 insertions(+), 12 deletions(-) Reviewed-by: Thomas Huth
Re: [PATCH for-9.1 09/19] target/i386: move 60-BF opcodes to new decoder
On Wed, Apr 24, 2024 at 01:13:01PM +0200, Paolo Bonzini wrote:
> Date: Wed, 24 Apr 2024 13:13:01 +0200
> From: Paolo Bonzini
> Subject: Re: [PATCH for-9.1 09/19] target/i386: move 60-BF opcodes to new
> decoder
>
> On Thu, Apr 11, 2024 at 5:05 PM Zhao Liu wrote:
> > HMM, I met Guest boot failure on this patch because of ata unrecognized.
> > I haven't located the exact error yet, so let me post my log first.
> > If there are other means I can use to dig further, I'd be happy to try
> > that too.
> >
> > # Command (boot a ubuntu Guest via TCG)
> >
> > ./qemu/build/qemu-system-x86_64 \
> > -smp 1 \
> > -name ubuntu -m 4G \
> > -cpu max -accel tcg \
> > -hda ../img_qemu/test.qcow2 -nographic \
> > -kernel ../img_qemu/kernel/vmlinuz-6.4.0-rc6+ \
> > -initrd ../img_qemu/kernel/initrd.img-6.4.0-rc6+ \
> > -append "root=/dev/sda ro console=ttyS0" \
> > -qmp unix:/tmp/qmp-sock,server=on,wait=off
>
> The issue is that INS and OUTS are using the incorrect operand size.
>
> While at it I also made OUTS a bit more similar to OUT:
>
> diff --git a/target/i386/tcg/decode-new.c.inc
> b/target/i386/tcg/decode-new.c.inc
> index 0951b042dfa..46682cfe070 100644
> --- a/target/i386/tcg/decode-new.c.inc
> +++ b/target/i386/tcg/decode-new.c.inc
> @@ -1544,8 +1544,8 @@ static const X86OpEntry opcodes_root[256] = {
> [0x6B] = X86_OP_ENTRY3(IMUL3, G,v, E,v, I,b, sextT0),
> [0x6C] = X86_OP_ENTRYrr(INS, Y,b, 2,w), /* DX */
> [0x6D] = X86_OP_ENTRYrr(INS, Y,z, 2,w), /* DX */
> -[0x6E] = X86_OP_ENTRYrr(OUTS, 2,w, X,b), /* DX */
> -[0x6F] = X86_OP_ENTRYrr(OUTS, 2,w, X,b), /* DX */
> +[0x6E] = X86_OP_ENTRYrr(OUTS, X,b, 2,w), /* DX */
> +[0x6F] = X86_OP_ENTRYrr(OUTS, X,z, 2,w), /* DX */
>
> [0x78] = X86_OP_ENTRYr(Jcc, J,b),
> [0x79] = X86_OP_ENTRYr(Jcc, J,b),
> @@ -1592,7 +1592,7 @@ static void gen_INC(
>
> static void gen_INS(DisasContext *s, CPUX86State *env, X86DecodedInsn
> *decode)
> {
> -MemOp ot = decode->op[0].ot;
> +MemOp ot = decode->op[1].ot;
> TCGv_i32 port = tcg_temp_new_i32();
>
> tcg_gen_trunc_tl_i32(port, s->T1);
> @@ -2310,10 +2310,10 @@ static void gen_OUT(
>
> static void gen_OUTS(DisasContext *s, CPUX86State *env, X86DecodedInsn
> *decode)
> {
> -MemOp ot = decode->op[2].ot;
> +MemOp ot = decode->op[1].ot;
> TCGv_i32 port = tcg_temp_new_i32();
>
> -tcg_gen_trunc_tl_i32(port, s->T0);
> +tcg_gen_trunc_tl_i32(port, s->T1);
> tcg_gen_ext16u_i32(port, port);
> if (!gen_check_io(s, ot, port, SVM_IOIO_STR_MASK)) {
> return;
>
>
> (sorry about any word breaking)
Thanks! With the above fix, now I re-test on each patch, and all patches
could boot Guest properly! If there is a v2, I can continue to test it.
Regards,
Zhao
Re: [PULL 00/17] CI job updates, header cleanups and other misc patches
On 25/04/2024 17.04, Richard Henderson wrote: On 4/24/24 22:11, Thomas Huth wrote: On 24/04/2024 18.21, Richard Henderson wrote: On 4/24/24 00:57, Thomas Huth wrote: The following changes since commit 13b1e9667737132440f4d500c31cb69320c6b15a: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2024-04-23 17:35:57 -0700) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24 for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e: target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 +0200) * Update OpenBSD CI image to 7.5 * Update/remove Ubuntu 20.04 CI jobs * Update CentOS 8 CI jobs to CentOS 9 * Some clean-ups and improvements to travis.yml * Minor test fixes * s390x header clean-ups * Doc updates This introduces a failure in the migration-compat-x86_64 job: https://gitlab.com/qemu-project/qemu/-/jobs/6707154868 It wasn't failing for me: https://gitlab.com/thuth/qemu/-/jobs/6702058896 And according to the diffstat of my pull request, it's only touching test files, docs, and s390x stuff, so I somehow fail to see how it could influence x86 migration at a first glance. It also looks like the job is running on opensuse, and not on CentOS or Ubuntu, so it should likely not be influenced by the changes in this PR. Could you please hit the re-run button of that job? If it then passes, we're likely rather facing an intermitted failure that might have been introduced earlier already... It did pass when re-run. Ok, thanks! So it's likely and intermitted problem indeed... I've now submitted a v2 of the pull request where I just dropped the other problematic patch that tried to update the custom CentOS runner ... I hope that PR should be fine now. Thomas
[PATCH 1/6] migration: Remove 'skipped' field from MigrationStats
The 'skipped' field of the MigrationStats struct has been deprecated
in 8.1. Time to remove it.
Deprecation commit 7b24d32634 ("migration: skipped field is really
obsolete.").
Signed-off-by: Fabiano Rosas
---
docs/about/deprecated.rst | 6 --
docs/about/removed-features.rst | 6 ++
migration/migration-hmp-cmds.c | 2 --
migration/migration.c | 2 --
qapi/migration.json | 8
5 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..4d9d6bf2da 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -488,12 +488,6 @@ option).
Migration
-
-``skipped`` MigrationStats field (since 8.1)
-
-
-``skipped`` field in Migration stats has been deprecated. It hasn't
-been used for more than 10 years.
-
``inc`` migrate command option (since 8.2)
''
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f9cf874f7b..9873f59bee 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -614,6 +614,12 @@ was superseded by ``sections``.
Member ``section-size`` in the return value of ``query-sgx-capabilities``
was superseded by ``sections``.
+``query-migrate`` return value member ``skipped`` (removed in 9.1)
+''
+
+Member ``skipped`` of the ``MigrationStats`` struct hasn't been used
+for more than 10 years. Removed with no replacement.
+
Human Monitor Protocol (HMP) commands
-
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index 7e96ae6ffd..28f776d06d 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -105,8 +105,6 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
info->ram->total >> 10);
monitor_printf(mon, "duplicate: %" PRIu64 " pages\n",
info->ram->duplicate);
-monitor_printf(mon, "skipped: %" PRIu64 " pages\n",
- info->ram->skipped);
monitor_printf(mon, "normal: %" PRIu64 " pages\n",
info->ram->normal);
monitor_printf(mon, "normal bytes: %" PRIu64 " kbytes\n",
diff --git a/migration/migration.c b/migration/migration.c
index 696762bc64..3b433fdb31 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1149,8 +1149,6 @@ static void populate_ram_info(MigrationInfo *info,
MigrationState *s)
info->ram->transferred = migration_transferred_bytes();
info->ram->total = ram_bytes_total();
info->ram->duplicate = stat64_get(&mig_stats.zero_pages);
-/* legacy value. It is not used anymore */
-info->ram->skipped = 0;
info->ram->normal = stat64_get(&mig_stats.normal_pages);
info->ram->normal_bytes = info->ram->normal * page_size;
info->ram->mbps = s->mbps;
diff --git a/qapi/migration.json b/qapi/migration.json
index 8c65b90328..401b8e24ac 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -23,9 +23,6 @@
#
# @duplicate: number of duplicate (zero) pages (since 1.2)
#
-# @skipped: number of skipped zero pages. Always zero, only provided
-# for compatibility (since 1.5)
-#
# @normal: number of normal pages (since 1.2)
#
# @normal-bytes: number of normal bytes sent (since 1.2)
@@ -63,16 +60,11 @@
# between 0 and @dirty-sync-count * @multifd-channels. (since
# 7.1)
#
-# Features:
-#
-# @deprecated: Member @skipped is always zero since 1.5.3
-#
# Since: 0.14
##
{ 'struct': 'MigrationStats',
'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
'duplicate': 'int',
- 'skipped': { 'type': 'int', 'features': [ 'deprecated' ] },
'normal': 'int',
'normal-bytes': 'int', 'dirty-pages-rate': 'int',
'mbps': 'number', 'dirty-sync-count': 'int',
--
2.35.3
[PATCH 4/6] migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in
favor of the more flexible storage migration provided by the
blockdev-mirror driver. Two releases have passed so now it's time to
remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block
migration").
Signed-off-by: Fabiano Rosas
---
MAINTAINERS |1 -
docs/about/deprecated.rst | 10 -
docs/about/removed-features.rst | 14 +
docs/devel/migration/main.rst |2 +-
include/migration/misc.h|6 -
meson.build |2 -
meson_options.txt |2 -
migration/block.c | 1018 ---
migration/block.h | 52 --
migration/colo.c|1 -
migration/meson.build |3 -
migration/migration-hmp-cmds.c | 25 -
migration/migration.c | 17 -
migration/options.c | 36 --
migration/ram.c | 15 -
migration/savevm.c |5 -
qapi/migration.json | 61 +-
scripts/meson-buildoptions.sh |4 -
18 files changed, 26 insertions(+), 1248 deletions(-)
delete mode 100644 migration/block.c
delete mode 100644 migration/block.h
diff --git a/MAINTAINERS b/MAINTAINERS
index f1f6922025..9a53ac9ec2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2877,7 +2877,6 @@ F: util/aio-*.h
F: util/defer-call.c
F: util/fdmon-*.c
F: block/io.c
-F: migration/block*
F: include/block/aio.h
F: include/block/aio-wait.h
F: include/qemu/defer-call.h
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 83adb763e6..409c9e0c4d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -488,16 +488,6 @@ option).
Migration
-
-block migration (since 8.2)
-'''
-
-Block migration is too inflexible. It needs to migrate all block
-devices or none.
-
-Please see "QMP invocation for live storage migration with
-``blockdev-mirror`` + NBD" in docs/interop/live-block-operations.rst
-for a detailed explanation.
-
old compression method (since 8.2)
''
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 0ba94c826a..dd20f37f2c 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -634,6 +634,13 @@ Use blockdev-mirror with NBD instead. See "QMP invocation
for live
storage migration with ``blockdev-mirror`` + NBD" in
docs/interop/live-block-operations.rst for a detailed explanation.
+``migrate-set-capabilities`` ``block`` option (removed in 9.1)
+''
+
+Block migration has been removed. For a replacement, see "QMP
+invocation for live storage migration with ``blockdev-mirror`` + NBD"
+in docs/interop/live-block-operations.rst.
+
Human Monitor Protocol (HMP) commands
-
@@ -708,6 +715,13 @@ Use blockdev-mirror with NBD instead. See "QMP invocation
for live
storage migration with ``blockdev-mirror`` + NBD" in
docs/interop/live-block-operations.rst for a detailed explanation.
+``migrate_set_capability`` ``block`` option (removed in 9.1)
+
+
+Block migration has been removed. For a replacement, see "QMP
+invocation for live storage migration with ``blockdev-mirror`` + NBD"
+in docs/interop/live-block-operations.rst.
+
Host Architectures
--
diff --git a/docs/devel/migration/main.rst b/docs/devel/migration/main.rst
index 54385a23e5..495cdcb112 100644
--- a/docs/devel/migration/main.rst
+++ b/docs/devel/migration/main.rst
@@ -454,7 +454,7 @@ Examples of such API functions are:
Iterative device migration
--
-Some devices, such as RAM, Block storage or certain platform devices,
+Some devices, such as RAM or certain platform devices,
have large amounts of data that would mean that the CPUs would be
paused for too long if they were sent in one section. For these
devices an *iterative* approach is taken.
diff --git a/include/migration/misc.h b/include/migration/misc.h
index c9e200f4eb..bf7339cc1e 100644
--- a/include/migration/misc.h
+++ b/include/migration/misc.h
@@ -45,12 +45,6 @@ bool migrate_ram_is_ignored(RAMBlock *block);
/* migration/block.c */
-#ifdef CONFIG_LIVE_BLOCK_MIGRATION
-void blk_mig_init(void);
-#else
-static inline void blk_mig_init(void) {}
-#endif
-
AnnounceParameters *migrate_announce_params(void);
/* migration/savevm.c */
diff --git a/meson.build b/meson.build
index 84e59dcbb4..2096050fd2 100644
--- a/meson.build
+++ b/meson.build
@@ -2350,7 +2350,6 @@ config_host_data.set('CONFIG_DEBUG_GRAPH_LOCK',
get_option('debug_graph_lock'))
config_host_data.set('CONFIG_DEBUG_MUTEX', get_option('debug_mutex'))
config_host_data.set('CONFIG_DEBUG_STACK_USAGE',
get_option('debug_stack_usage'))
config_host_data.set('CONFIG_DEBUG_TCG', get_option('debug_tcg'))
[PATCH 5/6] migration: Remove non-multifd compression
The 'compress' migration capability enables the old compression code
which has shown issues over the years and is thought to be less stable
and tested than the more recent multifd-based compression. The old
compression code has been deprecated in 8.2 and now is time to remove
it.
Deprecation commit 864128df46 ("migration: Deprecate old compression
method").
Signed-off-by: Fabiano Rosas
---
docs/about/deprecated.rst | 11 -
docs/about/removed-features.rst | 55
hw/core/machine.c | 1 -
migration/meson.build | 1 -
migration/migration-hmp-cmds.c | 47 ---
migration/migration.c | 14 -
migration/migration.h | 7 -
migration/options.c | 164 --
migration/ram-compress.c| 564
migration/ram.c | 151 +
qapi/migration.json | 112 ---
tests/qtest/migration-test.c| 139
12 files changed, 63 insertions(+), 1203 deletions(-)
delete mode 100644 migration/ram-compress.c
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 409c9e0c4d..fadb85f289 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -484,14 +484,3 @@ both, older and future versions of QEMU.
The ``blacklist`` config file option has been renamed to ``block-rpcs``
(to be in sync with the renaming of the corresponding command line
option).
-
-Migration
--
-
-old compression method (since 8.2)
-''
-
-Compression method fails too much. Too many races. We are going to
-remove it if nobody fixes it. For starters, migration-test
-compression tests are disabled because they fail randomly. If you need
-compression, use multifd compression methods.
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index dd20f37f2c..783f6b479d 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -505,6 +505,11 @@ configurations (e.g. -smp 8,sockets=0) is removed since
9.0, users have
to ensure that all the topology members described with -smp are greater
than zero.
+``-global migration.decompress-error-check`` (removed in 9.1)
+'
+
+Removed along with the ``compression`` migration capability.
+
User-mode emulator command line arguments
-
@@ -641,6 +646,31 @@ Block migration has been removed. For a replacement, see
"QMP
invocation for live storage migration with ``blockdev-mirror`` + NBD"
in docs/interop/live-block-operations.rst.
+``migrate-set-parameter`` ``compress-level`` option (removed in 9.1)
+
+
+Use ``multifd-zlib-level`` or ``multifd-zstd-level`` instead.
+
+``migrate-set-parameter`` ``compress-threads`` option (removed in 9.1)
+''
+
+Use ``multifd-channels`` instead.
+
+``migrate-set-parameter`` ``compress-wait-thread`` option (removed in 9.1)
+''
+
+Removed with no replacement.
+
+``migrate-set-parameter`` ``decompress-threads`` option (removed in 9.1)
+
+
+Use ``multifd-channels`` instead.
+
+``migrate-set-capability`` ``compress`` option (removed in 9.1)
+'''
+
+Use ``multifd-compression`` instead.
+
Human Monitor Protocol (HMP) commands
-
@@ -722,6 +752,31 @@ Block migration has been removed. For a replacement, see
"QMP
invocation for live storage migration with ``blockdev-mirror`` + NBD"
in docs/interop/live-block-operations.rst.
+``migrate_set_parameter`` ``compress-level`` option (removed in 9.1)
+
+
+Use ``multifd-zlib-level`` or ``multifd-zstd-level`` instead.
+
+``migrate_set_parameter`` ``compress-threads`` option (removed in 9.1)
+''
+
+Use ``multifd-channels`` instead.
+
+``migrate_set_parameter`` ``compress-wait-thread`` option (removed in 9.1)
+''
+
+Removed with no replacement.
+
+``migrate_set_parameter`` ``decompress-threads`` option (removed in 9.1)
+
+
+Use ``multifd-channels`` instead.
+
+``migrate_set_capability`` ``compress`` option (removed in 9.1)
+'''
+
+Use ``multifd-compression`` instead.
+
Host Architectures
--
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 582c2df37a..596ff77e3c 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -190,7 +190,6 @@ GlobalProper
[PATCH 2/6] migration: Remove 'inc' option from migrate command
The block incremental option for block migration has been deprecated
in 8.2 in favor of using the block-mirror feature. Remove it now.
Deprecation commit 40101f320d ("migration: migrate 'inc' command
option is deprecated.").
Signed-off-by: Fabiano Rosas
---
docs/about/deprecated.rst | 9 --
docs/about/removed-features.rst | 14 +
migration/block.c | 1 -
migration/migration-hmp-cmds.c | 18 ++-
migration/migration.c | 24 +--
migration/options.c | 30 +-
qapi/migration.json | 54 +++--
7 files changed, 35 insertions(+), 115 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 4d9d6bf2da..25b309dde4 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -488,15 +488,6 @@ option).
Migration
-
-``inc`` migrate command option (since 8.2)
-''
-
-Use blockdev-mirror with NBD instead.
-
-As an intermediate step the ``inc`` functionality can be achieved by
-setting the ``block-incremental`` migration parameter to ``true``.
-But this parameter is also deprecated.
-
``blk`` migrate command option (since 8.2)
''
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 9873f59bee..e62fc760f1 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -620,6 +620,13 @@ was superseded by ``sections``.
Member ``skipped`` of the ``MigrationStats`` struct hasn't been used
for more than 10 years. Removed with no replacement.
+``migrate`` command option ``inc`` (removed in 9.1)
+'''
+
+Use blockdev-mirror with NBD instead. See "QMP invocation for live
+storage migration with ``blockdev-mirror`` + NBD" in
+docs/interop/live-block-operations.rst for a detailed explanation.
+
Human Monitor Protocol (HMP) commands
-
@@ -680,6 +687,13 @@ This command didn't produce any output already. Removed
with no replacement.
The ``singlestep`` command has been replaced by the ``one-insn-per-tb``
command, which has the same behaviour but a less misleading name.
+``migrate`` command ``-i`` option (removed in 9.1)
+''
+
+Use blockdev-mirror with NBD instead. See "QMP invocation for live
+storage migration with ``blockdev-mirror`` + NBD" in
+docs/interop/live-block-operations.rst for a detailed explanation.
+
Host Architectures
--
diff --git a/migration/block.c b/migration/block.c
index bae6e94891..87ec1a7e68 100644
--- a/migration/block.c
+++ b/migration/block.c
@@ -419,7 +419,6 @@ static int init_blk_migration(QEMUFile *f, Error **errp)
bmds->bulk_completed = 0;
bmds->total_sectors = sectors;
bmds->completed_sectors = 0;
-bmds->shared_base = migrate_block_incremental();
assert(i < num_bs);
bmds_bs[i].bmds = bmds;
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index 28f776d06d..f49f061be1 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -332,10 +332,6 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict
*qdict)
monitor_printf(mon, "%s: %u ms\n",
MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
params->x_checkpoint_delay);
-assert(params->has_block_incremental);
-monitor_printf(mon, "%s: %s\n",
-MigrationParameter_str(MIGRATION_PARAMETER_BLOCK_INCREMENTAL),
-params->block_incremental ? "on" : "off");
monitor_printf(mon, "%s: %u\n",
MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
params->multifd_channels);
@@ -616,10 +612,6 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict
*qdict)
p->has_x_checkpoint_delay = true;
visit_type_uint32(v, param, &p->x_checkpoint_delay, &err);
break;
-case MIGRATION_PARAMETER_BLOCK_INCREMENTAL:
-p->has_block_incremental = true;
-visit_type_bool(v, param, &p->block_incremental, &err);
-break;
case MIGRATION_PARAMETER_MULTIFD_CHANNELS:
p->has_multifd_channels = true;
visit_type_uint8(v, param, &p->multifd_channels, &err);
@@ -767,18 +759,12 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
{
bool detach = qdict_get_try_bool(qdict, "detach", false);
bool blk = qdict_get_try_bool(qdict, "blk", false);
-bool inc = qdict_get_try_bool(qdict, "inc", false);
bool resume = qdict_get_try_bool(qdict, "resume", false);
const char *uri = qdict_get_str(qdict, "uri");
Error *err = NULL;
g_autoptr(MigrationChannelList) caps = NULL;
g_autoptr(MigrationChannel) channel = NULL;
-if (inc) {
-warn_report("option '-i' is deprecated;"
-
[PATCH 3/6] migration: Remove 'blk/-b' option from migrate commands
The block migration is considered obsolete and has been deprecated in
8.2. Remove the migrate command option that enables it. This only
affects the QMP and HMP commands, the feature can still be accessed by
setting the migration 'block' capability. The whole feature will be
removed in a future patch.
Deprecation commit 8846b5bfca ("migration: migrate 'blk' command
option is deprecated.").
Signed-off-by: Fabiano Rosas
---
.gitlab-ci.d/buildtest.yml | 2 +-
docs/about/deprecated.rst| 9 --
docs/about/removed-features.rst | 15 +++-
migration/migration-hmp-cmds.c | 9 +-
migration/migration.c| 31 ++-
migration/options.c | 3 +-
qapi/migration.json | 8 --
tests/qemu-iotests/183 | 147 ---
tests/qemu-iotests/183.out | 66 --
tests/qemu-iotests/common.filter | 7 --
10 files changed, 22 insertions(+), 275 deletions(-)
delete mode 100755 tests/qemu-iotests/183
delete mode 100644 tests/qemu-iotests/183.out
diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index cfdff175c3..b1a536592f 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -342,7 +342,7 @@ build-tcg-disabled:
- cd tests/qemu-iotests/
- ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 048
052 063 077 086 101 104 106 113 148 150 151 152 157 159 160 163
-170 171 183 184 192 194 208 221 226 227 236 253 277 image-fleecing
+170 171 184 192 194 208 221 226 227 236 253 277 image-fleecing
- ./check -qcow2 028 051 056 057 058 065 068 082 085 091 095 096 102 122
124 132 139 142 144 145 151 152 155 157 165 194 196 200 202
208 209 216 218 227 234 246 247 248 250 254 255 257 258
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 25b309dde4..83adb763e6 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -488,15 +488,6 @@ option).
Migration
-
-``blk`` migrate command option (since 8.2)
-''
-
-Use blockdev-mirror with NBD instead.
-
-As an intermediate step the ``blk`` functionality can be achieved by
-setting the ``block`` migration capability to ``true``. But this
-capability is also deprecated.
-
block migration (since 8.2)
'''
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index e62fc760f1..0ba94c826a 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -627,6 +627,13 @@ Use blockdev-mirror with NBD instead. See "QMP invocation
for live
storage migration with ``blockdev-mirror`` + NBD" in
docs/interop/live-block-operations.rst for a detailed explanation.
+``migrate`` command option ``blk`` (removed in 9.1)
+'''
+
+Use blockdev-mirror with NBD instead. See "QMP invocation for live
+storage migration with ``blockdev-mirror`` + NBD" in
+docs/interop/live-block-operations.rst for a detailed explanation.
+
Human Monitor Protocol (HMP) commands
-
@@ -694,6 +701,13 @@ Use blockdev-mirror with NBD instead. See "QMP invocation
for live
storage migration with ``blockdev-mirror`` + NBD" in
docs/interop/live-block-operations.rst for a detailed explanation.
+``migrate`` command ``-b`` option (removed in 9.1)
+''
+
+Use blockdev-mirror with NBD instead. See "QMP invocation for live
+storage migration with ``blockdev-mirror`` + NBD" in
+docs/interop/live-block-operations.rst for a detailed explanation.
+
Host Architectures
--
@@ -1025,4 +1039,3 @@ There is a newer Rust implementation of ``virtiofsd`` at
stable for some time and is now widely used.
The command line and feature set is very close to the removed
C implementation.
-
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index f49f061be1..5ab204d91d 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -758,26 +758,19 @@ static void hmp_migrate_status_cb(void *opaque)
void hmp_migrate(Monitor *mon, const QDict *qdict)
{
bool detach = qdict_get_try_bool(qdict, "detach", false);
-bool blk = qdict_get_try_bool(qdict, "blk", false);
bool resume = qdict_get_try_bool(qdict, "resume", false);
const char *uri = qdict_get_str(qdict, "uri");
Error *err = NULL;
g_autoptr(MigrationChannelList) caps = NULL;
g_autoptr(MigrationChannel) channel = NULL;
-if (blk) {
-warn_report("option '-b' is deprecated;"
-" use blockdev-mirror with NBD instead");
-}
-
if (!migrate_uri_parse(uri, &channel, &err)) {
hmp_handle_error(mon, err);
return;
}
QAPI_LIST_PREPEND(caps, g_steal_pointer(&channel));
-qmp_migrate(NULL, true, caps, !!blk, blk, false, false,
-
[PATCH 6/6] migration: Deprecate fd: for file migration
The fd: URI can currently trigger two different types of migration, a
TCP migration using sockets and a file migration using a plain
file. This is in conflict with the recently introduced (8.2) QMP
migrate API that takes structured data as JSON-like format. We cannot
keep the same backend for both types of migration because with the new
API the code is more tightly coupled to the type of transport. This
means a TCP migration must use the 'socket' transport and a file
migration must use the 'file' transport.
If we keep allowing fd: when using a file, this creates an issue when
the user converts the old-style (fd:) to the new style ("transport":
"socket") invocation because the file descriptor in question has
previously been allowed to be either a plain file or a socket.
To avoid creating too much confusion, we can simply deprecate the fd:
+ file usage, which is thought to be rarely used currently and instead
establish a 1:1 correspondence between fd: URI and socket transport,
and file: URI and file transport.
Signed-off-by: Fabiano Rosas
---
docs/about/deprecated.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index fadb85f289..11dce324c8 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -484,3 +484,17 @@ both, older and future versions of QEMU.
The ``blacklist`` config file option has been renamed to ``block-rpcs``
(to be in sync with the renaming of the corresponding command line
option).
+
+Migration
+-
+
+``fd:`` URI when used for file migration (since 9.1)
+
+
+The ``fd:`` URI can currently provide a file descriptor that
+references either a socket or a plain file. These are two different
+types of migration. In order to reduce ambiguity, the ``fd:`` URI
+usage of providing a file descriptor to a plain file has been
+deprecated in favor of explicitly using the ``file:`` URI with the
+file descriptor being passed as an ``fdset``. Refer to the ``add-fd``
+command documentation for details on the ``fdset`` usage.
--
2.35.3
[PATCH 0/6] migration removals & deprecations
Hi everyone, Here's some cleaning up of deprecated code. It removes the old block migration and compression code. Both have suitable replacements in the form of the blockdev-mirror driver and multifd compression, respectively. There's also a deprecation for fd: + file to cope with the fact that the new MigrationAddress API defines transports instead of protocols (loose terms) like the old string API did. So we cannot map 1:1 from fd: to any transport because fd: allows *both* file migration and socket migration. CI run: https://gitlab.com/farosas/qemu/-/pipelines/1267859704 Fabiano Rosas (6): migration: Remove 'skipped' field from MigrationStats migration: Remove 'inc' option from migrate command migration: Remove 'blk/-b' option from migrate commands migration: Remove block migration migration: Remove non-multifd compression migration: Deprecate fd: for file migration .gitlab-ci.d/buildtest.yml |2 +- MAINTAINERS |1 - docs/about/deprecated.rst| 51 +- docs/about/removed-features.rst | 104 ++- docs/devel/migration/main.rst|2 +- hw/core/machine.c|1 - include/migration/misc.h |6 - meson.build |2 - meson_options.txt|2 - migration/block.c| 1019 -- migration/block.h| 52 -- migration/colo.c |1 - migration/meson.build|4 - migration/migration-hmp-cmds.c | 97 +-- migration/migration.c| 70 +- migration/migration.h|7 - migration/options.c | 229 --- migration/ram-compress.c | 564 - migration/ram.c | 166 + migration/savevm.c |5 - qapi/migration.json | 205 +- scripts/meson-buildoptions.sh|4 - tests/qemu-iotests/183 | 147 - tests/qemu-iotests/183.out | 66 -- tests/qemu-iotests/common.filter |7 - tests/qtest/migration-test.c | 139 26 files changed, 130 insertions(+), 2823 deletions(-) delete mode 100644 migration/block.c delete mode 100644 migration/block.h delete mode 100644 migration/ram-compress.c delete mode 100755 tests/qemu-iotests/183 delete mode 100644 tests/qemu-iotests/183.out -- 2.35.3
Re: [PULL 00/17] CI job updates, header cleanups and other misc patches
On 4/24/24 22:11, Thomas Huth wrote: On 24/04/2024 18.21, Richard Henderson wrote: On 4/24/24 00:57, Thomas Huth wrote: The following changes since commit 13b1e9667737132440f4d500c31cb69320c6b15a: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2024-04-23 17:35:57 -0700) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24 for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e: target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 +0200) * Update OpenBSD CI image to 7.5 * Update/remove Ubuntu 20.04 CI jobs * Update CentOS 8 CI jobs to CentOS 9 * Some clean-ups and improvements to travis.yml * Minor test fixes * s390x header clean-ups * Doc updates This introduces a failure in the migration-compat-x86_64 job: https://gitlab.com/qemu-project/qemu/-/jobs/6707154868 It wasn't failing for me: https://gitlab.com/thuth/qemu/-/jobs/6702058896 And according to the diffstat of my pull request, it's only touching test files, docs, and s390x stuff, so I somehow fail to see how it could influence x86 migration at a first glance. It also looks like the job is running on opensuse, and not on CentOS or Ubuntu, so it should likely not be influenced by the changes in this PR. Could you please hit the re-run button of that job? If it then passes, we're likely rather facing an intermitted failure that might have been introduced earlier already... It did pass when re-run. r~
Re: [PATCH] ci: move external build environment setups to CentOS Stream 9
On 12/04/2024 12.37, Paolo Bonzini wrote:
RHEL 9 (and thus also the derivatives) are available since two years
now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.
Thus upgrade our CentOS Stream build environment playbooks to major
version 9 now.
Signed-off-by: Paolo Bonzini
---
.../stream/{8 => 9}/build-environment.yml | 31 ++---
.../stream/{8 => 9}/x86_64/configure | 4 +-
.../stream/{8 => 9}/x86_64/test-avocado | 0
scripts/ci/setup/build-environment.yml| 44 +++
4 files changed, 34 insertions(+), 45 deletions(-)
rename scripts/ci/org.centos/stream/{8 => 9}/build-environment.yml (75%)
rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/configure (98%)
rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/test-avocado (100%)
Hi Paolo!
Not sure whether you've seen my busted pull request, but anyway: It seems
like this was not enough to update the custom runner. You also need to
update .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml for this.
By the way, who has access to the s390x custom runner and could update it to
Ubuntu 22.04 now? It still seems to work with 20.04 which will be out of
support from the QEMU POV next week...
Thomas
[PULL v2 00/16] CI job updates, header cleanups and other misc patches
The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707:
Merge tag 'pull-tcg-20240424' of https://gitlab.com/rth7680/qemu into staging
(2024-04-24 15:51:49 -0700)
are available in the Git repository at:
https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-25
for you to fetch changes up to 17523a38194d80f2955c6a8e0702e0fc86dd083d:
target/s390x: Remove KVM stubs in cpu_models.h (2024-04-25 15:15:25 +0200)
* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update (most) CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates
v2: Drop the problematic patch that updates the custom CentOS 8 runner
Brad Smith (1):
tests/vm: update openbsd image to 7.5
Inès Varhol (1):
tests/qtest : Use `g_assert_cmphex` instead of `g_assert_cmpuint`
Manos Pitsidianakis (1):
docs/devel: fix minor typo in submitting-a-patch.rst
Peter Lieven (1):
MAINTAINERS: update email of Peter Lieven
Philippe Mathieu-Daudé (3):
hw/s390x: Include missing 'cpu.h' header
tests/unit: Remove debug statements in test-nested-aio-poll.c
target/s390x: Remove KVM stubs in cpu_models.h
Thomas Huth (8):
Revert ".travis.yml: Cache Avocado cache"
.travis.yml: Remove the unused UNRELIABLE environment variable
.travis.yml: Update the jobs to Ubuntu 22.04
.travis.yml: Do some more testing with Clang
tests: Remove Ubuntu 20.04 container
tests/lcitool/libvirt-ci: Update to the latest master branch
tests/docker/dockerfiles: Run lcitool-refresh after the lcitool update
tests: Update our CI to use CentOS Stream 9 instead of 8
Zhao Liu (1):
docs: i386: pc: Update maximum CPU numbers for PC Q35
MAINTAINERS| 6 +-
docs/devel/submitting-a-patch.rst | 2 +-
docs/system/target-i386-desc.rst.inc | 2 +-
hw/s390x/s390-virtio-hcall.h | 2 +
target/s390x/cpu_models.h | 15 --
hw/s390x/s390-stattrib.c | 1 +
tests/qtest/aspeed_fsi-test.c | 20 +--
tests/qtest/cmsdk-apb-dualtimer-test.c | 2 +-
tests/qtest/cmsdk-apb-watchdog-test.c | 2 +-
tests/qtest/erst-test.c| 2 +-
tests/qtest/ivshmem-test.c | 10 +-
tests/qtest/libqos/ahci.c | 4 +-
tests/qtest/microbit-test.c| 46 +++---
tests/qtest/sse-timer-test.c | 4 +-
tests/qtest/stm32l4x5_exti-test.c | 138 +-
tests/qtest/stm32l4x5_syscfg-test.c| 74 +-
tests/unit/test-nested-aio-poll.c | 7 -
.gitlab-ci.d/buildtest.yml | 16 +--
.gitlab-ci.d/container-core.yml| 4 +-
.travis.yml| 24 +---
tests/docker/dockerfiles/alpine.docker | 3 +-
.../dockerfiles/{centos8.docker => centos9.docker} | 35 ++---
tests/docker/dockerfiles/debian-amd64-cross.docker | 3 +-
tests/docker/dockerfiles/debian-arm64-cross.docker | 3 +-
tests/docker/dockerfiles/debian-armel-cross.docker | 3 +-
tests/docker/dockerfiles/debian-armhf-cross.docker | 3 +-
tests/docker/dockerfiles/debian-i686-cross.docker | 3 +-
.../dockerfiles/debian-mips64el-cross.docker | 3 +-
.../docker/dockerfiles/debian-mipsel-cross.docker | 3 +-
.../docker/dockerfiles/debian-ppc64el-cross.docker | 3 +-
.../docker/dockerfiles/debian-riscv64-cross.docker | 3 +-
tests/docker/dockerfiles/debian-s390x-cross.docker | 3 +-
tests/docker/dockerfiles/debian.docker | 1 +
tests/docker/dockerfiles/fedora-win64-cross.docker | 3 +-
tests/docker/dockerfiles/fedora.docker | 1 +
tests/docker/dockerfiles/opensuse-leap.docker | 1 +
tests/docker/dockerfiles/ubuntu2004.docker | 157 -
tests/docker/dockerfiles/ubuntu2204.docker | 1 +
tests/lcitool/libvirt-ci | 2 +-
tests/lcitool/mappings.yml | 20 ---
tests/lcitool/refresh | 3 +-
tests/vm/centos| 4 +-
tests/vm/openbsd | 6 +-
43 files changed, 225 insertions(+), 423 deletions(-)
rename tests/docker/dockerfiles/{centos8.docker => centos9.docker} (82%)
delete mode 100644 tests/docker/dockerfiles/ubuntu2004.docker
Re: [PATCH v4 03/14] util/dsa: Implement DSA device start and stop logic.
On Thu, Apr 25, 2024 at 02:21:06AM +, Hao Xiang wrote:
> * DSA device open and close.
> * DSA group contains multiple DSA devices.
> * DSA group configure/start/stop/clean.
>
> Signed-off-by: Hao Xiang
> Signed-off-by: Bryan Zhang
> ---
> include/qemu/dsa.h | 72 +++
> util/dsa.c | 316 +
> util/meson.build | 1 +
> 3 files changed, 389 insertions(+)
> create mode 100644 include/qemu/dsa.h
> create mode 100644 util/dsa.c
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> new file mode 100644
> index 00..f15c05ee85
> --- /dev/null
> +++ b/include/qemu/dsa.h
> @@ -0,0 +1,72 @@
> +#ifndef QEMU_DSA_H
> +#define QEMU_DSA_H
> +
> +#include "qemu/error-report.h"
> +#include "qemu/thread.h"
> +#include "qemu/queue.h"
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
> +
> +#include
> +#include "x86intrin.h"
> +
> +/**
> + * @brief Initializes DSA devices.
> + *
> + * @param dsa_parameter A list of DSA device path from migration parameter.
> + *
> + * @return int Zero if successful, otherwise non zero.
> + */
> +int dsa_init(const char *dsa_parameter);
BTW, all these methods should also use 'qemu_dsa_' as a name
prefix, not merely 'dsa_'. The latter is too generic, and
likely to clash with naming of APIs implemnenting 'dsa'
crypto, as well as withthe kernel's dsa devoce header.
Likewise best practice for the structs in the dsa.c file
to also use 'QemuDsa' as a nameprefix, not merely 'Dsa'.
> +
> +/**
> + * @brief Start logic to enable using DSA.
> + */
> +void dsa_start(void);
> +
> +/**
> + * @brief Stop the device group and the completion thread.
> + */
> +void dsa_stop(void);
> +
> +/**
> + * @brief Clean up system resources created for DSA offloading.
> + */
> +void dsa_cleanup(void);
> +
> +/**
> + * @brief Check if DSA is running.
> + *
> + * @return True if DSA is running, otherwise false.
> + */
> +bool dsa_is_running(void);
> +
> +#else
> +
> +static inline bool dsa_is_running(void)
> +{
> +return false;
> +}
> +
> +static inline int dsa_init(const char *dsa_parameter)
> +{
> +if (dsa_parameter != NULL && strlen(dsa_parameter) != 0) {
> +error_report("DSA not supported.");
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +static inline void dsa_start(void) {}
> +
> +static inline void dsa_stop(void) {}
> +
> +static inline void dsa_cleanup(void) {}
> +
> +#endif
> +
> +#endif
> diff --git a/util/dsa.c b/util/dsa.c
> new file mode 100644
> index 00..05bbf8e31a
> --- /dev/null
> +++ b/util/dsa.c
> @@ -0,0 +1,316 @@
> +/*
> + * Use Intel Data Streaming Accelerator to offload certain background
> + * operations.
> + *
> + * Copyright (c) 2023 Hao Xiang
> + *Bryan Zhang
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/queue.h"
> +#include "qemu/memalign.h"
> +#include "qemu/lockable.h"
> +#include "qemu/cutils.h"
> +#include "qemu/dsa.h"
> +#include "qemu/bswap.h"
> +#include "qemu/error-report.h"
> +#include "qemu/rcu.h"
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
> +
> +#include
> +#include "x86intrin.h"
> +
> +#define DSA_WQ_SIZE 4096
> +#define MAX_DSA_DEVICES 16
> +
> +typedef QSIMPLEQ_HEAD(dsa_task_queue, dsa_batch_task) dsa_task_queue;
> +
> +struct dsa_device {
> +void *work_queue;
> +};
> +
> +struct dsa_device_group {
IMHO preferable to use initial-upper case for struct
names, to distinguish from method names. ie
QemuDsaDeviceGroup
also I'd suggest they should all be typedef'd too,
so its not repeating 'struct ' everywhere.
> +struct dsa_device *dsa_devices;
> +int num_dsa_devices;
> +/* The index of the next DSA device to be used. */
> +uint32_t device_allocator_index;
> +bool running;
> +QemuMutex
Re: [PATCH v4 10/14] migration/multifd: Enable DSA offloading in multifd sender path.
On Thu, Apr 25, 2024 at 02:21:13AM +, Hao Xiang wrote:
> Multifd sender path gets an array of pages queued by the migration
> thread. It performs zero page checking on every page in the array.
> The pages are classfied as either a zero page or a normal page. This
> change uses Intel DSA to offload the zero page checking from CPU to
> the DSA accelerator. The sender thread submits a batch of pages to DSA
> hardware and waits for the DSA completion thread to signal for work
> completion.
>
> Signed-off-by: Hao Xiang
> ---
> migration/multifd-zero-page.c | 99 +--
> migration/multifd.c | 27 +-
> migration/multifd.h | 1 +
> 3 files changed, 120 insertions(+), 7 deletions(-)
>
> diff --git a/migration/multifd-zero-page.c b/migration/multifd-zero-page.c
> index e1b8370f88..4f426289e4 100644
> --- a/migration/multifd-zero-page.c
> +++ b/migration/multifd-zero-page.c
> diff --git a/migration/multifd.c b/migration/multifd.c
> index cfd3a92f6c..7316643d0a 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -818,6 +818,8 @@ void multifd_send_shutdown(void)
>
> multifd_send_terminate_threads();
>
> +dsa_cleanup();
> +
> for (i = 0; i < migrate_multifd_channels(); i++) {
> MultiFDSendParams *p = &multifd_send_state->params[i];
> Error *local_err = NULL;
> @@ -1155,11 +1157,20 @@ bool multifd_send_setup(void)
> uint32_t page_count = MULTIFD_PACKET_SIZE / qemu_target_page_size();
> bool use_packets = multifd_use_packets();
> uint8_t i;
> +const char *dsa_parameter = migrate_multifd_dsa_accel();
>
> if (!migrate_multifd()) {
> return true;
> }
>
> +if (dsa_init(dsa_parameter)) {
> +error_setg(&local_err, "multifd: Sender failed to initialize DSA.");
> +error_report_err(local_err);
> +return false;
> +}
This is an example of why all the dsa functions need to report
a via an "Error **err" parameter. The error reported
here is useless as it lacks any meaningful information of what
went wrong.
The multifd_send_setup method itself needs a "Error **errp"
param so it can pass it back up to be reoprted too.
> +
> +dsa_start();
> +
> thread_count = migrate_multifd_channels();
> multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
> multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
> @@ -1393,6 +1404,7 @@ void multifd_recv_cleanup(void)
> qemu_thread_join(&p->thread);
> }
> }
> +dsa_cleanup();
> for (i = 0; i < migrate_multifd_channels(); i++) {
> multifd_recv_cleanup_channel(&multifd_recv_state->params[i]);
> }
> @@ -1568,6 +1580,9 @@ int multifd_recv_setup(Error **errp)
> uint32_t page_count = MULTIFD_PACKET_SIZE / qemu_target_page_size();
> bool use_packets = multifd_use_packets();
> uint8_t i;
> +const char *dsa_parameter = migrate_multifd_dsa_accel();
> +int ret;
> +Error *local_err = NULL;
>
> /*
> * Return successfully if multiFD recv state is already initialised
> @@ -1577,6 +1592,15 @@ int multifd_recv_setup(Error **errp)
> return 0;
> }
>
> +ret = dsa_init(dsa_parameter);
> +if (ret != 0) {
> +error_setg(&local_err, "multifd: Receiver failed to initialize
> DSA.");
> +error_propagate(errp, local_err);
> +return ret;
> +}
> +
> +dsa_start();
> +
> thread_count = migrate_multifd_channels();
> multifd_recv_state = g_malloc0(sizeof(*multifd_recv_state));
> multifd_recv_state->params = g_new0(MultiFDRecvParams, thread_count);
> @@ -1616,13 +1640,12 @@ int multifd_recv_setup(Error **errp)
>
> for (i = 0; i < thread_count; i++) {
> MultiFDRecvParams *p = &multifd_recv_state->params[i];
> -int ret;
> -
> ret = multifd_recv_state->ops->recv_setup(p, errp);
> if (ret) {
> return ret;
> }
> }
> +
> return 0;
> }
>
> diff --git a/migration/multifd.h b/migration/multifd.h
> index 16e27db5e9..b3717fae24 100644
> --- a/migration/multifd.h
> +++ b/migration/multifd.h
> @@ -14,6 +14,7 @@
> #define QEMU_MIGRATION_MULTIFD_H
>
> #include "ram.h"
> +#include "qemu/dsa.h"
>
> typedef struct MultiFDRecvData MultiFDRecvData;
>
> --
> 2.30.2
>
>
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 03/14] util/dsa: Implement DSA device start and stop logic.
On Thu, Apr 25, 2024 at 02:21:06AM +, Hao Xiang wrote:
> * DSA device open and close.
> * DSA group contains multiple DSA devices.
> * DSA group configure/start/stop/clean.
>
> Signed-off-by: Hao Xiang
> Signed-off-by: Bryan Zhang
> ---
> include/qemu/dsa.h | 72 +++
> util/dsa.c | 316 +
> util/meson.build | 1 +
> 3 files changed, 389 insertions(+)
> create mode 100644 include/qemu/dsa.h
> create mode 100644 util/dsa.c
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> new file mode 100644
> index 00..f15c05ee85
> --- /dev/null
> +++ b/include/qemu/dsa.h
> @@ -0,0 +1,72 @@
> +#ifndef QEMU_DSA_H
> +#define QEMU_DSA_H
> +
> +#include "qemu/error-report.h"
> +#include "qemu/thread.h"
> +#include "qemu/queue.h"
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
You've tested in meson.build that the compiler supports
'enqcmd' which is good. I'm not seeing anything that
tests whether the host running this code supports 'enqcmd'.
There needs to be a CPUID check for this at runtime.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 03/14] util/dsa: Implement DSA device start and stop logic.
On Thu, Apr 25, 2024 at 02:21:06AM +, Hao Xiang wrote:
> * DSA device open and close.
> * DSA group contains multiple DSA devices.
> * DSA group configure/start/stop/clean.
>
> Signed-off-by: Hao Xiang
> Signed-off-by: Bryan Zhang
> ---
> include/qemu/dsa.h | 72 +++
> util/dsa.c | 316 +
> util/meson.build | 1 +
> 3 files changed, 389 insertions(+)
> create mode 100644 include/qemu/dsa.h
> create mode 100644 util/dsa.c
>
> diff --git a/include/qemu/dsa.h b/include/qemu/dsa.h
> new file mode 100644
> index 00..f15c05ee85
> --- /dev/null
> +++ b/include/qemu/dsa.h
> @@ -0,0 +1,72 @@
Missing license header.
> +#ifndef QEMU_DSA_H
> +#define QEMU_DSA_H
> +
> +#include "qemu/error-report.h"
> +#include "qemu/thread.h"
> +#include "qemu/queue.h"
> +
> +#ifdef CONFIG_DSA_OPT
> +
> +#pragma GCC push_options
> +#pragma GCC target("enqcmd")
> +
> +#include
> +#include "x86intrin.h"
> +
> +/**
> + * @brief Initializes DSA devices.
> + *
> + * @param dsa_parameter A list of DSA device path from migration parameter.
> + *
> + * @return int Zero if successful, otherwise non zero.
> + */
> +int dsa_init(const char *dsa_parameter);
> +
> +/**
> + * @brief Start logic to enable using DSA.
> + */
> +void dsa_start(void);
> +
> +/**
> + * @brief Stop the device group and the completion thread.
> + */
> +void dsa_stop(void);
> +
> +/**
> + * @brief Clean up system resources created for DSA offloading.
> + */
> +void dsa_cleanup(void);
> +
> +/**
> + * @brief Check if DSA is running.
> + *
> + * @return True if DSA is running, otherwise false.
> + */
> +bool dsa_is_running(void);
> +
> +#else
> +
> +static inline bool dsa_is_running(void)
> +{
> +return false;
> +}
> +
> +static inline int dsa_init(const char *dsa_parameter)
> +{
> +if (dsa_parameter != NULL && strlen(dsa_parameter) != 0) {
> +error_report("DSA not supported.");
Using error_report in this code is undesirable, as it means the
migration code has no way to feed error information back to the
mgmt app.
*all* the APIs in dsa.h/dsa.c that can have errors, need to have
an "Error **errp" parameter, so useful info can be propagated
back the caller in the migration code.
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +static inline void dsa_start(void) {}
> +
> +static inline void dsa_stop(void) {}
> +
> +static inline void dsa_cleanup(void) {}
> +
> +#endif
> +
> +#endif
> diff --git a/util/dsa.c b/util/dsa.c
> new file mode 100644
> index 00..05bbf8e31a
> --- /dev/null
> +++ b/util/dsa.c
> @@ -0,0 +1,316 @@
> +/*
> + * Use Intel Data Streaming Accelerator to offload certain background
> + * operations.
> + *
> + * Copyright (c) 2023 Hao Xiang
> + *Bryan Zhang
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
This is an MIT license header, but QEMU's standard license is GPL-2.0-or-later.
Please keep new contributions under QEMU's normal license unless there's a
reason why you must differ.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 08/14] migration/multifd: Add new migration option for multifd DSA offloading.
On Thu, Apr 25, 2024 at 02:21:11AM +, Hao Xiang wrote: > Intel DSA offloading is an optional feature that turns on if > proper hardware and software stack is available. To turn on > DSA offloading in multifd live migration: > > multifd-dsa-accel="[dsa_dev_path1] [dsa_dev_path2] ... [dsa_dev_pathX]" > > This feature is turned off by default. > > Signed-off-by: Hao Xiang > --- > migration/migration-hmp-cmds.c | 8 > migration/options.c| 30 ++ > migration/options.h| 1 + > qapi/migration.json| 26 +++--- > 4 files changed, 62 insertions(+), 3 deletions(-) > diff --git a/qapi/migration.json b/qapi/migration.json > index 8c65b90328..934fa8839e 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -914,6 +914,12 @@ > # See description in @ZeroPageDetection. Default is 'multifd'. > # (since 9.0) > # > +# @multifd-dsa-accel: If enabled, use DSA accelerator offloading for > +# certain memory operations. Enable DSA accelerator offloading by > +# setting this string to a list of DSA device path separated by space > +# characters. Setting this string to an empty string means disabling > +# DSA accelerator offloading. Defaults to an empty string. (since 9.2) Passing a list of paths as a single space separate string is a design anti-pattern. This needs to use a list type at the QAPI level. Also I don't think we need add 'multifd' on the name - all new features are for multifd. Overall it should be called 'dsa-accel-path' I thjink > @@ -1122,6 +1128,12 @@ > # See description in @ZeroPageDetection. Default is 'multifd'. > # (since 9.0) > # > +# @multifd-dsa-accel: If enabled, use DSA accelerator offloading for > +# certain memory operations. Enable DSA accelerator offloading by > +# setting this string to a list of DSA device path separated by space > +# characters. Setting this string to an empty string means disabling > +# DSA accelerator offloading. Defaults to an empty string. (since 9.2) > +# > # Features: > # > # @deprecated: Member @block-incremental is deprecated. Use > @@ -1176,7 +1188,8 @@ > 'features': [ 'unstable' ] }, > '*vcpu-dirty-limit': 'uint64', > '*mode': 'MigMode', > -'*zero-page-detection': 'ZeroPageDetection'} } > +'*zero-page-detection': 'ZeroPageDetection', > +'*multifd-dsa-accel': 'StrOrNull'} } This needs to be ['str'] not 'StrOrNull' > > ## > # @migrate-set-parameters: > @@ -1354,6 +1367,12 @@ > # See description in @ZeroPageDetection. Default is 'multifd'. > # (since 9.0) > # > +# @multifd-dsa-accel: If enabled, use DSA accelerator offloading for > +# certain memory operations. Enable DSA accelerator offloading by > +# setting this string to a list of DSA device path separated by space > +# characters. Setting this string to an empty string means disabling > +# DSA accelerator offloading. Defaults to an empty string. (since 9.2) > +# > # Features: > # > # @deprecated: Member @block-incremental is deprecated. Use > @@ -1405,7 +1424,8 @@ > 'features': [ 'unstable' ] }, > '*vcpu-dirty-limit': 'uint64', > '*mode': 'MigMode', > -'*zero-page-detection': 'ZeroPageDetection'} } > +'*zero-page-detection': 'ZeroPageDetection', > +'*multifd-dsa-accel': 'str'} } Liekewise needs to be ['str'] Having mgmt apps pass in the path every time though, feels like overkill. Surely there's a standard path that QEMU should use by default, and should only require flag to turn on its usage. IOW, why not extend the ZeroPageDetection enum, to have a further entry for 'dsa' to request ue of dsa accel. Passing paths could be optional. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[PATCH v3] fix endianness bug
Add xlnx_dpdma_read_descriptor() and
xlnx_dpdma_write_descriptor() functions.
xlnx_dpdma_read_descriptor() combines reading a
descriptor from desc_addr by calling dma_memory_read()
and swapping the desc fields from guest memory order
to host memory order. xlnx_dpdma_write_descriptor()
performs similar actions when writing a descriptor.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d3c6369a96 ("introduce xlnx-dpdma")
Signed-off-by: Alexandra Diupina
---
v3: add xlnx_dpdma_write_descriptor()
v2: minor changes in xlnx_dpdma_read_descriptor()
hw/dma/xlnx_dpdma.c | 59 ++---
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git a/hw/dma/xlnx_dpdma.c b/hw/dma/xlnx_dpdma.c
index dd66be5265..7845f43221 100644
--- a/hw/dma/xlnx_dpdma.c
+++ b/hw/dma/xlnx_dpdma.c
@@ -614,6 +614,59 @@ static void xlnx_dpdma_register_types(void)
type_register_static(&xlnx_dpdma_info);
}
+static MemTxResult xlnx_dpdma_read_descriptor(XlnxDPDMAState *s,
+uint64_t desc_addr, DPDMADescriptor *desc)
+{
+if (dma_memory_read(&address_space_memory, desc_addr, &desc,
+sizeof(DPDMADescriptor), MEMTXATTRS_UNSPECIFIED))
+return MEMTX_ERROR;
+
+/* Convert from LE into host endianness. */
+desc->control = le32_to_cpu(desc->control);
+desc->descriptor_id = le32_to_cpu(desc->descriptor_id);
+desc->xfer_size = le32_to_cpu(desc->xfer_size);
+desc->line_size_stride = le32_to_cpu(desc->line_size_stride);
+desc->timestamp_lsb = le32_to_cpu(desc->timestamp_lsb);
+desc->timestamp_msb = le32_to_cpu(desc->timestamp_msb);
+desc->address_extension = le32_to_cpu(desc->address_extension);
+desc->next_descriptor = le32_to_cpu(desc->next_descriptor);
+desc->source_address = le32_to_cpu(desc->source_address);
+desc->address_extension_23 = le32_to_cpu(desc->address_extension_23);
+desc->address_extension_45 = le32_to_cpu(desc->address_extension_45);
+desc->source_address2 = le32_to_cpu(desc->source_address2);
+desc->source_address3 = le32_to_cpu(desc->source_address3);
+desc->source_address4 = le32_to_cpu(desc->source_address4);
+desc->source_address5 = le32_to_cpu(desc->source_address5);
+desc->crc = le32_to_cpu(desc->crc);
+
+return MEMTX_OK;
+}
+
+static void xlnx_dpdma_write_descriptor(uint64_t desc_addr,
+DPDMADescriptor *desc)
+{
+/* Convert from host endianness into LE. */
+desc->control = cpu_to_le32(desc->control);
+desc->descriptor_id = cpu_to_le32(desc->descriptor_id);
+desc->xfer_size = cpu_to_le32(desc->xfer_size);
+desc->line_size_stride = cpu_to_le32(desc->line_size_stride);
+desc->timestamp_lsb = cpu_to_le32(desc->timestamp_lsb);
+desc->timestamp_msb = cpu_to_le32(desc->timestamp_msb);
+desc->address_extension = cpu_to_le32(desc->address_extension);
+desc->next_descriptor = cpu_to_le32(desc->next_descriptor);
+desc->source_address = cpu_to_le32(desc->source_address);
+desc->address_extension_23 = cpu_to_le32(desc->address_extension_23);
+desc->address_extension_45 = cpu_to_le32(desc->address_extension_45);
+desc->source_address2 = cpu_to_le32(desc->source_address2);
+desc->source_address3 = cpu_to_le32(desc->source_address3);
+desc->source_address4 = cpu_to_le32(desc->source_address4);
+desc->source_address5 = cpu_to_le32(desc->source_address5);
+desc->crc = cpu_to_le32(desc->crc);
+
+dma_memory_write(&address_space_memory, desc_addr, &desc,
+sizeof(DPDMADescriptor), MEMTXATTRS_UNSPECIFIED);
+}
+
size_t xlnx_dpdma_start_operation(XlnxDPDMAState *s, uint8_t channel,
bool one_desc)
{
@@ -651,8 +704,7 @@ size_t xlnx_dpdma_start_operation(XlnxDPDMAState *s,
uint8_t channel,
desc_addr = xlnx_dpdma_descriptor_next_address(s, channel);
}
-if (dma_memory_read(&address_space_memory, desc_addr, &desc,
-sizeof(DPDMADescriptor), MEMTXATTRS_UNSPECIFIED)) {
+if (xlnx_dpdma_read_descriptor(s, desc_addr, &desc)) {
s->registers[DPDMA_EISR] |= ((1 << 1) << channel);
xlnx_dpdma_update_irq(s);
s->operation_finished[channel] = true;
@@ -755,8 +807,7 @@ size_t xlnx_dpdma_start_operation(XlnxDPDMAState *s,
uint8_t channel,
/* The descriptor need to be updated when it's completed. */
DPRINTF("update the descriptor with the done flag set.\n");
xlnx_dpdma_desc_set_done(&desc);
-dma_memory_write(&address_space_memory, desc_addr, &desc,
- sizeof(DPDMADescriptor), MEMTXATTRS_UNSPECIFIED);
+xlnx_dpdma_write_descriptor(desc_addr, &desc);
}
if (xlnx_dpdma_desc_completion_interrupt(&desc)) {
--
2.30.2
[PATCH] mc146818rtc: add a way to generate RTC interrupts via QMP
This can be used to force-synchronize the time in guest after a long
stop-cont pause, which can be useful for serverless-type workload.
Signed-off-by: Daniil Tatianin
---
hw/rtc/mc146818rtc.c | 15 +++
include/hw/rtc/mc146818rtc.h | 1 +
qapi/misc-target.json| 16
3 files changed, 32 insertions(+)
diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
index f4c1869232..6980a78d5f 100644
--- a/hw/rtc/mc146818rtc.c
+++ b/hw/rtc/mc146818rtc.c
@@ -116,6 +116,21 @@ void qmp_rtc_reset_reinjection(Error **errp)
}
}
+void qmp_rtc_notify(Error **errp)
+{
+MC146818RtcState *s;
+
+/*
+ * See:
+ * https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt
+ */
+QLIST_FOREACH(s, &rtc_devices, link) {
+s->cmos_data[RTC_REG_B] |= REG_B_UIE;
+s->cmos_data[RTC_REG_C] |= REG_C_IRQF | REG_C_UF;
+qemu_irq_raise(s->irq);
+}
+}
+
static bool rtc_policy_slew_deliver_irq(MC146818RtcState *s)
{
kvm_reset_irq_delivered();
diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
index 97cec0b3e8..5229dffbbd 100644
--- a/include/hw/rtc/mc146818rtc.h
+++ b/include/hw/rtc/mc146818rtc.h
@@ -56,5 +56,6 @@ MC146818RtcState *mc146818_rtc_init(ISABus *bus, int
base_year,
void mc146818rtc_set_cmos_data(MC146818RtcState *s, int addr, int val);
int mc146818rtc_get_cmos_data(MC146818RtcState *s, int addr);
void qmp_rtc_reset_reinjection(Error **errp);
+void qmp_rtc_notify(Error **errp);
#endif /* HW_RTC_MC146818RTC_H */
diff --git a/qapi/misc-target.json b/qapi/misc-target.json
index 4e0a6492a9..20457b0acc 100644
--- a/qapi/misc-target.json
+++ b/qapi/misc-target.json
@@ -19,6 +19,22 @@
{ 'command': 'rtc-reset-reinjection',
'if': 'TARGET_I386' }
+##
+# @rtc-notify:
+#
+# Generate an RTC interrupt.
+#
+# Since: 9.1
+#
+# Example:
+#
+# -> { "execute": "rtc-notify" }
+# <- { "return": {} }
+#
+##
+{ 'command': 'rtc-notify',
+ 'if': 'TARGET_I386' }
+
##
# @SevState:
#
--
2.34.1
Re: [PATCH v2 1/3] cpu-models: add "disable-deprecated-feats" option to cpu model expansion
On Wed, Apr 24, 2024 at 03:12:42PM -0400, Collin Walling wrote:
> On 4/24/24 13:51, Collin Walling wrote:
> > On 4/24/24 04:20, Daniel P. Berrangé wrote:
> >> On Tue, Apr 23, 2024 at 05:06:53PM -0400, Collin Walling wrote:
> >>> This optional parameter for query-cpu-model-expansion enables CPU
> >>> model features flagged as deprecated to appear in the resulting
> >>> list of properties.
> >>>
> >>> This commit does not add support beyond adding a new argument
> >>> to the query. All queries with this option present will result
> >>> in an error claiming this option is not supported.
> >>>
> >>> Signed-off-by: Collin Walling
> >>> ---
> >>> qapi/machine-target.json | 7 ++-
> >>> target/arm/arm-qmp-cmds.c| 7 +++
> >>> target/i386/cpu-sysemu.c | 7 +++
> >>> target/s390x/cpu_models_sysemu.c | 7 +++
> >>> 4 files changed, 27 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> >>> index 29e695aa06..b9da284d2d 100644
> >>> --- a/qapi/machine-target.json
> >>> +++ b/qapi/machine-target.json
> >>> @@ -285,6 +285,10 @@
> >>> #
> >>> # @type: expansion type, specifying how to expand the CPU model
> >>> #
> >>> +# @disable-deprecated-feats: include CPU model features that are
> >>> +# flagged as deprecated. If supported, these features will appear
> >>> +# in the properties list paired with false.
> >>> +#
> >>> # Returns: a CpuModelExpansionInfo describing the expanded CPU model
> >>> #
> >>> # Errors:
> >>> @@ -298,7 +302,8 @@
> >>> ##
> >>> { 'command': 'query-cpu-model-expansion',
> >>>'data': { 'type': 'CpuModelExpansionType',
> >>> -'model': 'CpuModelInfo' },
> >>> +'model': 'CpuModelInfo',
> >>> +'*disable-deprecated-feats': 'bool' },
> >>>'returns': 'CpuModelExpansionInfo',
> >>>'if': { 'any': [ 'TARGET_S390X',
> >>> 'TARGET_I386',
> >>
> >> I think this is an odd design approach. Lets consider the
> >> current output:
> >>
> >> (QEMU) query-cpu-model-expansion type=static model={"name":"z14"}
> >> {
> >> "return": {
> >> "model": {
> >> "name": "z14-base",
> >> "props": {
> >> "aefsi": true,
> >> "aen": true,
> >> ...snip...
> >> "vxpd": true,
> >> "zpci": true
> >> }
> >> }
> >> }
> >> }
> >>
> >>
> >> If we want to inform a mgmt app of some features being deprecated,
> >> why not just unconditionally include that info in the reply thus:
> >>
> >>
> >> (QEMU) query-cpu-model-expansion type=static model={"name":"z14"}
> >> {
> >> "return": {
> >> "model": {
> >> "name": "z14-base",
> >> "props": {
> >> "aefsi": true,
> >> "aen": true,
> >> ...snip...
> >> "vxpd": true,
> >> "zpci": true
> >> }
> >> "deprecated-props": ["ppa15", "ri"]
> >> }
> >> }
> >> }
> >>
> >>
> >>
> >> With regards,
> >> Daniel
> >
> > That's a good idea. In this way, we're not mucking up any of the CPU
> > model information and this makes it much more clear as to which features
> > are actually deprecated... I like this more.
> >
> > I'll work on this.
> >
>
> Follow-up question as I look more closely to the QMP response data
> structures: should the "deprecated-props" list be added to the
> CpuModelInfo struct, or to the CpuModelExpansionInfo struct?
>
> The former makes more sense to me, as the deprecated features are tied
> to the actual CPU model... but unsure if other QMP commands would even
> care about this info? I will begin with this approach, and if feedback
> in the interim strongly sways in the other direction, then it should be
> an easy change :)
I hink CpuModelInfo makes more sense than CpuModelExpansionInfo.
The CpuModelExpansionInfo struct feels pretty pointless to me
in fact, since the only thing it contains is CpuModelInfo !
I think it should also be added to 'CpuDefinitionInfo', which
is the return type of 'query-cpu-defintions'. This command already
has a 'unavailable-features' array listing features which the host
does not support. Conceptually having a 'deprecated-features' array
alongside that is a nice fit.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Timeouts in CI jobs
On Thu, Apr 25, 2024 at 02:27:17PM +0100, Daniel P. Berrangé wrote: > On Wed, Apr 24, 2024 at 08:10:19PM +0200, Stefan Weil wrote: > > > > I did not run tests in my GitLab fork because I still have to figure out how > > to do that. > > It is quite simple: > > git remote add gitlab ssh://g...@gitlab.com//qemu > git push gitlab -o QEMU_CI=2 Sorry, mistake, the second line should be git push gitlab -o ci.variable=QEMU_CI=2 With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] migration/ram.c: API Conversion qemu_mutex_lock(), and qemu_mutex_unlock() to WITH_QEMU_LOCK_GUARD macro
Yes, yes. The list will always be cc'd. I found your email after I had
already sent on the list, so I omitted the list when I sent it to you.
Thanks for the suggestion for further contribution. I am looking at them
On Thu, Apr 25, 2024 at 6:45 PM Peter Xu wrote:
>
> On Thu, Apr 25, 2024 at 09:10:34AM -0400, Peter Xu wrote:
> > Hi,
>
> And I just noticed you didn't copy the list, please normally keep copying
> the list in replies. So before below links, you can also read this first
> just in case you still miss some:
>
> https://www.qemu.org/docs/master/devel/submitting-a-patch.html
>
> >
> > On Thu, Apr 25, 2024 at 06:08:58PM +0530, Vilhelm Gyda wrote:
> > > Hi, I am new here. This trivial patch is my first contribution. I am
> > > not sure who to cc for the review. Checking qemu/MAINTAINERS you guys
> > > seemed to be most relevant for this patch. I am looking for what to
> > > contribute next, let me know if you guys have any ideas on that.
> > > Thanks
> >
> > Maybe can start with looking at some bugs (see the end of the page below),
> > or todos listed here that you think you have an idea to move on:
> >
> > https://wiki.qemu.org/ToDo/LiveMigration
> >
> > >
> > > On Thu, Apr 25, 2024 at 5:12 PM Will Gyda wrote:
> > > >
> > > > migration/ram.c: API Conversion qemu_mutex_lock(),
> > > > and qemu_mutex_unlock() to WITH_QEMU_LOCK_GUARD macro
> > > >
> > > > Signed-off-by: Will Gyda
> >
> > The patch looks okay:
> >
> > Reviewed-by: Peter Xu
> >
> > Thanks,
> >
> > > > ---
> > > > migration/ram.c | 12 ++--
> > > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/migration/ram.c b/migration/ram.c
> > > > index a975c5af16..50df1e9cd2 100644
> > > > --- a/migration/ram.c
> > > > +++ b/migration/ram.c
> > > > @@ -1066,14 +1066,14 @@ static void migration_bitmap_sync(RAMState *rs,
> > > > bool last_stage)
> > > > trace_migration_bitmap_sync_start();
> > > > memory_global_dirty_log_sync(last_stage);
> > > >
> > > > -qemu_mutex_lock(&rs->bitmap_mutex);
> > > > -WITH_RCU_READ_LOCK_GUARD() {
> > > > -RAMBLOCK_FOREACH_NOT_IGNORED(block) {
> > > > -ramblock_sync_dirty_bitmap(rs, block);
> > > > +WITH_QEMU_LOCK_GUARD(&rs->bitmap_mutex) {
> > > > +WITH_RCU_READ_LOCK_GUARD() {
> > > > +RAMBLOCK_FOREACH_NOT_IGNORED(block) {
> > > > +ramblock_sync_dirty_bitmap(rs, block);
> > > > +}
> > > > +stat64_set(&mig_stats.dirty_bytes_last_sync,
> > > > ram_bytes_remaining());
> > > > }
> > > > -stat64_set(&mig_stats.dirty_bytes_last_sync,
> > > > ram_bytes_remaining());
> > > > }
> > > > -qemu_mutex_unlock(&rs->bitmap_mutex);
> > > >
> > > > memory_global_after_dirty_log_sync();
> > > > trace_migration_bitmap_sync_end(rs->num_dirty_pages_period);
> > > > --
> > > > 2.25.1
> > > >
> > >
> >
> > --
> > Peter Xu
>
> --
> Peter Xu
>
Re: Timeouts in CI jobs
On Wed, Apr 24, 2024 at 08:10:19PM +0200, Stefan Weil wrote: > Am 24.04.24 um 19:09 schrieb Daniel P. Berrangé: > > > On Wed, Apr 24, 2024 at 06:27:58PM +0200, Stefan Weil via wrote: > > > I think the timeouts are caused by running too many parallel processes > > > during testing. > > > > > > The CI uses parallel builds: > > > > > > make -j$(expr $(nproc) + 1) all check-build $MAKE_CHECK_ARGS > > Note that command is running both the compile and test phases of > > the job. Overcommitting CPUs for the compile phase is a good > > idea to keep CPUs busy while another process is waiting on > > I/O, and is almost always safe todo. > > > Thank you for your answer. > > Overcommitting for the build is safe, but in my experience the positive > effect is typically very small on modern hosts with fast disk I/O and large > buffer caches. Fine with typical developer machines, but the shared runners in gitlab are fairly resource constrained by comparison, and resources are often under contention from other VMs in their infra. > And there is also a negative impact because this requires scheduling with > process switches. > > Therefore I am not so sure that overcommitting is a good idea, especially > not on cloud servers where the jobs are running in VMs. As a point of reference, 'ninja' defaults to '$nproc + 2'. > > > > In the primary QEMU repo, we have a customer runner registered > > that uses Azure based VMs. Not sure on the resources we have > > configured for them offhand. > > I was talking about the primary QEMU. > > > The important thing there is that what you see for CI speed in > > your fork repo is not neccessarily a match for CI speed in QEMU > > upstream repo. > > I did not run tests in my GitLab fork because I still have to figure out how > to do that. It is quite simple: git remote add gitlab ssh://g...@gitlab.com//qemu git push gitlab -o QEMU_CI=2 this immediately runs all pipelines jobs. USe QEMU_CI=1 to not start any jobs, and let you manually start the subset you are interested in checking > My test environment was an older (= slow) VM with 4 cores. I tested with > different values for --num-processes. As expected higher values raised the > number of timeouts. And the most interesting result was that > `--num-processes 1` avoided timeouts, used less CPU time and did not > increase the duration. > > > > In my tests setting --num-processes to a lower value not only avoided > > > timeouts but also reduced the processing overhead without increasing the > > > runtime. > > > > > > Could we run all tests with `--num-processes 1`? > > The question is what impact that has on the overall job execution > > time. A lot of our jobs are already quite long, which is bad for > > the turnaround time of CI testing. Reliable CI though is arguably > > the #1 priority though, otherwise developers cease trusting it. > > We need to find the balance between avoiding timeouts, while having > > the shortest practical job time. The TCI job you show about came > > out at 22 minutes, which is not our worst job, so there is some > > scope for allowing it to run longer with less parallelism. > > The TCI job terminates after less than 7 minutes in my test runs with less > parallelism. > > Obviously there are tests which already do their own multithreading, and > maybe other tests run single threaded. So maybe we need different values for > `--num-processes` depending on the number of threads which the single tests > use? QEMU has differnt test suites too. The unit tests are likely safe to run fully parallel, but the block I/O tests and qtests are likely to benefit from serialization, since they all spawn many QEMU processes as children that will consume multiple CPUs, so we probably don't need to run the actually test suite in parallel to max out the CPUs. Still needs testing under gitlab CI to prove the theory. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH for-9.1 0/7] target/i386/kvm: Cleanup the kvmclock feature name
On Thu, Apr 25, 2024 at 08:04:46PM +0800, Xiaoyao Li wrote: > Date: Thu, 25 Apr 2024 20:04:46 +0800 > From: Xiaoyao Li > Subject: Re: [PATCH for-9.1 0/7] target/i386/kvm: Cleanup the kvmclock > feature name > > On 4/25/2024 6:29 PM, Zhao Liu wrote: > > On Thu, Apr 25, 2024 at 04:40:10PM +0800, Xiaoyao Li wrote: > > > Date: Thu, 25 Apr 2024 16:40:10 +0800 > > > From: Xiaoyao Li > > > Subject: Re: [PATCH for-9.1 0/7] target/i386/kvm: Cleanup the kvmclock > > > feature name > > > > > > On 4/25/2024 3:17 PM, Zhao Liu wrote: > > > > Hi Xiaoyao, > > > > > > > > On Wed, Apr 24, 2024 at 11:57:11PM +0800, Xiaoyao Li wrote: > > > > > Date: Wed, 24 Apr 2024 23:57:11 +0800 > > > > > From: Xiaoyao Li > > > > > Subject: Re: [PATCH for-9.1 0/7] target/i386/kvm: Cleanup the kvmclock > > > > >feature name > > > > > > > > > > On 3/29/2024 6:19 PM, Zhao Liu wrote: > > > > > > From: Zhao Liu > > > > > > > > > > > > Hi list, > > > > > > > > > > > > This series is based on Paolo's guest_phys_bits patchset [1]. > > > > > > > > > > > > Currently, the old and new kvmclocks have the same feature name > > > > > > "kvmclock" in FeatureWordInfo[FEAT_KVM]. > > > > > > > > > > > > When I tried to dig into the history of this unusual naming and fix > > > > > > it, > > > > > > I realized that Tim was already trying to rename it, so I picked up > > > > > > his > > > > > > renaming patch [2] (with a new commit message and other minor > > > > > > changes). > > > > > > > > > > > > 13 years age, the same name was introduced in [3], and its main > > > > > > purpose > > > > > > is to make it easy for users to enable/disable 2 kvmclocks. Then, in > > > > > > 2012, Don tried to rename the new kvmclock, but the follow-up did > > > > > > not > > > > > > address Igor and Eduardo's comments about compatibility. > > > > > > > > > > > > Tim [2], not long ago, and I just now, were both puzzled by the > > > > > > naming > > > > > > one after the other. > > > > > > > > > > The commit message of [3] said the reason clearly: > > > > > > > > > > When we tweak flags involving this value - specially when we use > > > > > "-", > > > > > we have to act on both. > > > > > > > > > > So you are trying to change it to "when people want to disable > > > > > kvmclock, > > > > > they need to use '-kvmclock,-kvmclock2' instead of '-kvmclock'" > > > > > > > > > > IMHO, I prefer existing code and I don't see much value of > > > > > differentiating > > > > > them. If the current code puzzles you, then we can add comment to > > > > > explain. > > > > > > > > It's enough to just enable kvmclock2 for Guest; kvmclock (old) is > > > > redundant in the presence of kvmclock2. > > > > > > > > So operating both feature bits at the same time is not a reasonable > > > > choice, we should only keep kvmclock2 for Guest. It's possible because > > > > the oldest linux (v4.5) which QEMU i386 supports has kvmclock2. > > > > > > who said the oldest Linux QEMU supports is from 4.5? what about 2.x > > > kernel? > > > > For Host (docs/system/target-i386.rst). > > > > > Besides, not only the Linux guest, whatever guest OS is, it will be broken > > > if the guest is using kvmclock and QEMU starts to drop support of > > > kvmclock. > > > > I'm not aware of any minimum version requirements for Guest supported > > by KVM, but there are no commitment. > > the common commitment is at least keeping backwards compatibility. > > > > So, again, hard NAK to drop the support of kvmclock. It breaks existing > > > guests that use kvmclock. You cannot force people to upgrade their > > > existing > > > VMs to use kvmclock2 instead of kvmclock. > > > > I agree, legacy kvmclock can be left out, if the old kernel does not > > support kvmclock2 and strongly requires kvmclock, it can be enabled > > using 9.1 and earlier machines or legacy-kvmclock, as long as Host still > > supports it. > > > > What's the gap in handling it this way? especially considering that > > kvmclock2 was introduced in v2.6.35, and earlier kernels are no longer > > maintained. The availability of the PV feature requires compatibility > > for both Host and Guest. > > > > Anyway, the above discussion here is about future plans, and this series > > does not prevent any Guest from ignoring kvmclock2 in favor of kvmclock. > > > > What this series is doing, i.e. separating the current two kvmclock and > > ensuring CPUID compatibility via legacy-kvmclock, could balance the > > compatibility requirements of the ancient (unmaintained kernel) with > > the need for future feature changes. > > You introduce a user-visible change that people need to use > "-kvmclock,-kvmclock2" to totally disable kvmclock. > > The only difference between kvmclock and kvmclock2 is the MSR index. And > from users' perspective, they don't care this difference. The existing usage > is simple. When I want kvmclock, use "+kvmclock". When I don't want it, use > "-kvmclock". > > You are complicating things and I don't s
Re: [PATCH v11 00/21] i386: Introduce smp.modules and clean up cache topology
On Thu, Apr 25, 2024 at 10:06:11AM +0200, Philippe Mathieu-Daudé wrote: > Date: Thu, 25 Apr 2024 10:06:11 +0200 > From: Philippe Mathieu-Daudé > Subject: Re: [PATCH v11 00/21] i386: Introduce smp.modules and clean up > cache topology > > Hi Zhao, > > On 24/4/24 17:49, Zhao Liu wrote: > > > --- > > Zhao Liu (20): > >hw/core/machine: Introduce the module as a CPU topology level > >hw/core/machine: Support modules in -smp > >hw/core: Introduce module-id as the topology subindex > >hw/core: Support module-id in numa configuration > > To reduce this series size, I'm taking these 4 patches to via > my hw-misc tree. > Thanks Philippe! Will add module level test in tests/unit/test-smp-parse.c. Regards, Zhao
Re: [PATCH] migration/ram.c: API Conversion qemu_mutex_lock(), and qemu_mutex_unlock() to WITH_QEMU_LOCK_GUARD macro
On Thu, Apr 25, 2024 at 09:10:34AM -0400, Peter Xu wrote:
> Hi,
And I just noticed you didn't copy the list, please normally keep copying
the list in replies. So before below links, you can also read this first
just in case you still miss some:
https://www.qemu.org/docs/master/devel/submitting-a-patch.html
>
> On Thu, Apr 25, 2024 at 06:08:58PM +0530, Vilhelm Gyda wrote:
> > Hi, I am new here. This trivial patch is my first contribution. I am
> > not sure who to cc for the review. Checking qemu/MAINTAINERS you guys
> > seemed to be most relevant for this patch. I am looking for what to
> > contribute next, let me know if you guys have any ideas on that.
> > Thanks
>
> Maybe can start with looking at some bugs (see the end of the page below),
> or todos listed here that you think you have an idea to move on:
>
> https://wiki.qemu.org/ToDo/LiveMigration
>
> >
> > On Thu, Apr 25, 2024 at 5:12 PM Will Gyda wrote:
> > >
> > > migration/ram.c: API Conversion qemu_mutex_lock(),
> > > and qemu_mutex_unlock() to WITH_QEMU_LOCK_GUARD macro
> > >
> > > Signed-off-by: Will Gyda
>
> The patch looks okay:
>
> Reviewed-by: Peter Xu
>
> Thanks,
>
> > > ---
> > > migration/ram.c | 12 ++--
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index a975c5af16..50df1e9cd2 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -1066,14 +1066,14 @@ static void migration_bitmap_sync(RAMState *rs,
> > > bool last_stage)
> > > trace_migration_bitmap_sync_start();
> > > memory_global_dirty_log_sync(last_stage);
> > >
> > > -qemu_mutex_lock(&rs->bitmap_mutex);
> > > -WITH_RCU_READ_LOCK_GUARD() {
> > > -RAMBLOCK_FOREACH_NOT_IGNORED(block) {
> > > -ramblock_sync_dirty_bitmap(rs, block);
> > > +WITH_QEMU_LOCK_GUARD(&rs->bitmap_mutex) {
> > > +WITH_RCU_READ_LOCK_GUARD() {
> > > +RAMBLOCK_FOREACH_NOT_IGNORED(block) {
> > > +ramblock_sync_dirty_bitmap(rs, block);
> > > +}
> > > +stat64_set(&mig_stats.dirty_bytes_last_sync,
> > > ram_bytes_remaining());
> > > }
> > > -stat64_set(&mig_stats.dirty_bytes_last_sync,
> > > ram_bytes_remaining());
> > > }
> > > -qemu_mutex_unlock(&rs->bitmap_mutex);
> > >
> > > memory_global_after_dirty_log_sync();
> > > trace_migration_bitmap_sync_end(rs->num_dirty_pages_period);
> > > --
> > > 2.25.1
> > >
> >
>
> --
> Peter Xu
--
Peter Xu
Re: [PULL 00/17] CI job updates, header cleanups and other misc patches
Daniel P. Berrangé writes: > On Thu, Apr 25, 2024 at 07:11:41AM +0200, Thomas Huth wrote: >> On 24/04/2024 18.21, Richard Henderson wrote: >> > On 4/24/24 00:57, Thomas Huth wrote: >> > > The following changes since commit >> > > 13b1e9667737132440f4d500c31cb69320c6b15a: >> > > >> > > Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into >> > > staging (2024-04-23 17:35:57 -0700) >> > > >> > > are available in the Git repository at: >> > > >> > > https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24 >> > > >> > > for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e: >> > > >> > > target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 >> > > +0200) >> > > >> > > >> > > * Update OpenBSD CI image to 7.5 >> > > * Update/remove Ubuntu 20.04 CI jobs >> > > * Update CentOS 8 CI jobs to CentOS 9 >> > > * Some clean-ups and improvements to travis.yml >> > > * Minor test fixes >> > > * s390x header clean-ups >> > > * Doc updates >> > >> > This introduces a failure in the migration-compat-x86_64 job: >> > >> > https://gitlab.com/qemu-project/qemu/-/jobs/6707154868 >> >> It wasn't failing for me: >> >> https://gitlab.com/thuth/qemu/-/jobs/6702058896 >> >> And according to the diffstat of my pull request, it's only touching test >> files, docs, and s390x stuff, so I somehow fail to see how it could >> influence x86 migration at a first glance. It also looks like the job is >> running on opensuse, and not on CentOS or Ubuntu, so it should likely not be >> influenced by the changes in this PR. >> >> Could you please hit the re-run button of that job? If it then passes, we're >> likely rather facing an intermitted failure that might have been introduced >> earlier already... > > The specific job that's failiing is the multifd cancellation test. > This is exactly the kind of functional area of migration where > non-deterministic failures are likely to appear. So one for the > migration maintainers to look at most likely. > Yes, that's the test that catches any race conditions on error/cleanup. I agree that the PR here doesn't seem to interact with any of that. The previous PR from Peter Xu has code that changes error paths, so it's more likely to be it. The recent changes to the migration tests are out of the picture as well because that CI job uses the previous QEMU version's tests (i.e. 9.0). I tried to reproduce it and no luck so far. Usually these bugs reproduce well on my machine. I'll probably need to leave it running overnight to find the race.
Re: [PATCH v2 4/4] vfio/ccw: Make vfio_ccw_register_irq_notifier() return a bool
On Thu, 2024-04-25 at 12:56 +0200, Markus Armbruster wrote:
> Cédric Le Goater writes:
>
> > Since vfio_ccw_register_irq_notifier() takes an 'Error **'
> > argument,
> > best practices suggest to return a bool. See the qapi/error.h Rules
> > section.
> >
> > Signed-off-by: Cédric Le Goater
> > ---
> > hw/vfio/ccw.c | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> > index
> > 6764388bc47a970329fce2233626ccb8178e0165..1c630f6e9abe93ae0c2b5615d
> > 4409669f096c8c9 100644
> > --- a/hw/vfio/ccw.c
> > +++ b/hw/vfio/ccw.c
> > @@ -379,7 +379,7 @@ read_err:
> > css_inject_io_interrupt(sch);
> > }
> >
> > -static void vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> > +static bool vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> > unsigned int irq,
> > Error **errp)
> > {
> > @@ -405,13 +405,13 @@ static void
> > vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> > break;
> > default:
> > error_setg(errp, "vfio: Unsupported device irq(%d)", irq);
> > - return;
> > + return false;
> > }
> >
> > if (vdev->num_irqs < irq + 1) {
> > error_setg(errp, "vfio: IRQ %u not available (number of
> > irqs %u)",
> > irq, vdev->num_irqs);
> > - return;
> > + return false;
> > }
> >
> > argsz = sizeof(*irq_info);
> > @@ -421,14 +421,14 @@ static void
> > vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> > if (ioctl(vdev->fd, VFIO_DEVICE_GET_IRQ_INFO,
> > irq_info) < 0 || irq_info->count < 1) {
> > error_setg_errno(errp, errno, "vfio: Error getting irq
> > info");
> > - return;
> > + return false;
> > }
> >
> > if (event_notifier_init(notifier, 0)) {
> > error_setg_errno(errp, errno,
> > "vfio: Unable to init event notifier for
> > irq (%d)",
> > irq);
> > - return;
> > + return false;
> > }
> >
> > fd = event_notifier_get_fd(notifier);
> > @@ -439,6 +439,8 @@ static void
> > vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> > qemu_set_fd_handler(fd, NULL, NULL, vcdev);
> > event_notifier_cleanup(notifier);
> > }
> > +
> > + return true;
> > }
> >
> > static void vfio_ccw_unregister_irq_notifier(VFIOCCWDevice *vcdev,
> > @@ -602,20 +604,18 @@ static void vfio_ccw_realize(DeviceState
> > *dev, Error **errp)
> > goto out_region_err;
> > }
> >
> > - vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX,
> > &err);
> > - if (err) {
> > + if (!vfio_ccw_register_irq_notifier(vcdev,
> > VFIO_CCW_IO_IRQ_INDEX, &err)) {
>
> Please pass errp instead of &err.
>
> > goto out_io_notifier_err;
> > }
> >
> > if (vcdev->crw_region) {
> > - vfio_ccw_register_irq_notifier(vcdev,
> > VFIO_CCW_CRW_IRQ_INDEX, &err);
> > - if (err) {
> > + if (!vfio_ccw_register_irq_notifier(vcdev,
> > VFIO_CCW_CRW_IRQ_INDEX,
> > + &err)) {
>
> Likewise.
>
> > goto out_irq_notifier_err;
> > }
> > }
> >
> > - vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_REQ_IRQ_INDEX,
> > &err);
> > - if (err) {
> > + if (!vfio_ccw_register_irq_notifier(vcdev,
> > VFIO_CCW_REQ_IRQ_INDEX, &err)) {
> > /*
> > * Report this error, but do not make it a failing
> > condition.
> > * Lack of this IRQ in the host does not prevent normal
> > operation.
> */
> error_report_err(err);
>
> Not this patch's problem, but here goes anyway: since this isn't an
> error, we shouldn't use error_report_err(). Would warn_report_err()
> be
> appropriate? info_report_err() doesn't exist, but it could.
>
> Preferably with errp instead of &err (two times):
> Reviewed-by: Markus Armbruster
>
Don't recall why I used error_report_err() instead of something else
(or creating info_), but probably just familiarity. There's no need for
it (or the equivalent code in -ap) to be error, and could be another
cleanup.
Reviewed-by: Eric Farman
Re: [PATCH v2 3/5] intel_iommu: Add a framework to do compatibility check with host IOMMU cap/ecap
On 4/25/24 10:46, Duan, Zhenzhong wrote:
Hi Cédric,
-Original Message-
From: Cédric Le Goater
Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
compatibility check with host IOMMU cap/ecap
Hello Zhenzhong,
On 4/18/24 10:42, Duan, Zhenzhong wrote:
Hi Cédric,
-Original Message-
From: Cédric Le Goater
Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
compatibility check with host IOMMU cap/ecap
Hello Zhenzhong
On 4/17/24 11:24, Duan, Zhenzhong wrote:
-Original Message-
From: Cédric Le Goater
Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
compatibility check with host IOMMU cap/ecap
On 4/17/24 06:21, Duan, Zhenzhong wrote:
-Original Message-
From: Cédric Le Goater
Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
compatibility check with host IOMMU cap/ecap
Hello,
On 4/16/24 09:09, Duan, Zhenzhong wrote:
Hi Cédric,
-Original Message-
From: Cédric Le Goater
Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
compatibility check with host IOMMU cap/ecap
On 4/8/24 10:44, Zhenzhong Duan wrote:
From: Yi Liu
If check fails, the host side device(either vfio or vdpa device)
should
not
be passed to guest.
Implementation details for different backends will be in
following
patches.
Signed-off-by: Yi Liu
Signed-off-by: Yi Sun
Signed-off-by: Zhenzhong Duan
---
hw/i386/intel_iommu.c | 35
+++
1 file changed, 35 insertions(+)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 4f84e2e801..a49b587c73 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -35,6 +35,7 @@
#include "sysemu/kvm.h"
#include "sysemu/dma.h"
#include "sysemu/sysemu.h"
+#include "sysemu/iommufd.h"
#include "hw/i386/apic_internal.h"
#include "kvm/kvm_i386.h"
#include "migration/vmstate.h"
@@ -3819,6 +3820,32 @@ VTDAddressSpace
*vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
return vtd_dev_as;
}
+static int vtd_check_legacy_hdev(IntelIOMMUState *s,
+ HostIOMMUDevice *hiod,
+ Error **errp)
+{
+return 0;
+}
+
+static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
+ HostIOMMUDevice *hiod,
+ Error **errp)
+{
+return 0;
+}
+
+static int vtd_check_hdev(IntelIOMMUState *s,
VTDHostIOMMUDevice
*vtd_hdev,
+ Error **errp)
+{
+HostIOMMUDevice *hiod = vtd_hdev->dev;
+
+if (object_dynamic_cast(OBJECT(hiod),
TYPE_HIOD_IOMMUFD))
{
+return vtd_check_iommufd_hdev(s, hiod, errp);
+}
+
+return vtd_check_legacy_hdev(s, hiod, errp);
+}
I think we should be using the .get_host_iommu_info() class
handler
instead. Can we refactor the code slightly to avoid this check on
the type ?
There is some difficulty ini avoiding this check, the behavior of
vtd_check_legacy_hdev
and vtd_check_iommufd_hdev are different especially after
nesting
support introduced.
vtd_check_iommufd_hdev() has much wider check over cap/ecap
bits
besides aw_bits.
I think it is important to fully separate the vIOMMU model from the
host IOMMU backing device.
This comment is true for the structures also.
Could we introduce a new HostIOMMUDeviceClass
handler .check_hdev() handler, which would
call .get_host_iommu_info() ?
This means that HIOD_LEGACY_INFO and HIOD_IOMMUFD_INFO should
be
a common structure 'HostIOMMUDeviceInfo' holding all attributes
for the different backends. Each .get_host_iommu_info() implementation
would translate the specific host iommu device data presentation
into the common 'HostIOMMUDeviceInfo', this is true for host_aw_bits.
I see, it's just not easy to define the unified elements in
HostIOMMUDeviceInfo
so that they maps to bits or fields in host return IOMMU info.
The proposal is adding a vIOMMU <-> HostIOMMUDevice interface and a
new
API needs to be completely defined for it. The IOMMU backend
implementation
could be anything, legacy, iommufd, iommufd v2, some other framework
and
the vIOMMU shouldn't be aware of its implementation.
Exposing the kernel structures as done below should be avoided because
they are part of the QEMU <-> kernel IOMMUFD interface.
Different platform returned host IOMMU info is platform specific.
For vtd and siommu:
struct iommu_hw_info_vtd {
__u32 flags;
__u32 __reserved;
__aligned_u64 cap_reg;
__aligned_u64 ecap_reg;
};
struct iommu_hw_info_arm_smmuv3 {
__u32 flags;
__u32 __reserved;
__u32 idr[6];
__u32 iidr;
__u32 aidr;
};
I can think of two kinds of declaration of HostIOMMUDeviceInfo:
struct HostIOMMUDeviceInfo {
uint8_t aw_bits;
enum iommu_hw_info_type type;
union {
struct iommu_hw_info_vtd vtd;
struct iommu_hw_info_arm_smmuv3;
