On Mon, Jul 21, 2025 at 05:07:55PM -0400, Stefan Hajnoczi wrote:
> io_uring may not be available at runtime due to system policies (e.g.
> the io_uring_disabled sysctl) or creation could fail due to file
> descriptor resource limits.
>
> Handle failure scenarios as follows:
>
> If another AioCont
On Tue, Jul 15, 2025 at 03:30:11PM +0100, Daniel P. Berrangé wrote:
> We need to call get_event_loop but have no way of knowing ahead
> of time whether the current thread has an event loop of not. We
s/of not /or not /
> can handle a missing event loop, but we need to hide the warning
> python wi
On Fri, 2025-07-11 at 17:10 -0400, Zhuoying Cai wrote:
> DIAG 320 subcode 1 provides information needed to determine
> the amount of storage to store one or more certificates.
>
> The subcode value is denoted by setting the left-most bit
> of an 8-byte field.
>
> The verification-certificate-stor
On 7/21/25 17:30, Collin Walling wrote:
> On 7/11/25 17:10, Zhuoying Cai wrote:
>> DIAG 320 is supported when the certificate-store (CS) facility
>> is installed.
>>
>> Availability of CS facility is determined by byte 134 bit 5 of the
>> SCLP Read Info block. Byte 134's facilities cannot be repres
Leverage the kernel extended features manipulation ioctls(), if
available, and fallback to old ops otherwise. Error out when setting
extended features but kernel support is not available.
Note that extended support for get/set backend features is not needed,
as the only feature that can be changed
Use the extended types and helpers to manipulate the virtio_net
features.
Note that offloads are still 64bits wide, as per specification,
and extended offloads will be mapped into such range.
Signed-off-by: Paolo Abeni
---
v3 -> v4:
- use new virtio_features macro names
v2 -> v3:
- rebased
When any host or guest GSO over UDP tunnel offload is enabled the
virtio net header includes the additional tunnel-related fields,
update the size accordingly.
Push the GSO over UDP tunnel offloads all the way down to the tap
device extending the newly introduced NetFeatures struct, and
eventually
Such annotation is present into the kernel uAPI headers since
v6.7, and will be used soon by the vhost_type.h. Deal with it
just stripping it.
Signed-off-by: Paolo Abeni
---
scripts/update-linux-headers.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/update-linux-headers.sh b/scri
Extend the VirtioDeviceFeatures struct with an additional u64
to track unknown features in the 64-127 bit range and decode
the full virtio features spaces for vhost and virtio devices.
Also add entries for the soon-to-be-supported virtio net GSO over
UDP features.
Signed-off-by: Paolo Abeni
---
Tap devices support GSO over UDP tunnel offload. Probe for such
feature in a similar manner to other offloads.
GSO over UDP tunnel needs to be enabled in addition to a "plain"
offload (TSO or USO).
No need to check separately for the outer header checksum offload:
ithe kernel is going to support
Extend the features configuration space to 128 bits. If the virtio
device supports any extended features, allow the common read/write
operation to access all of it, otherwise keep exposing only the
lower 64 bits.
On migration, save the 128 bit version of the features only if the
upper bits are non
The virtio specifications allows for up to 128 bits for the
device features. Soon we are going to use some of the 'extended'
bits features (bit 64 and above) for the virtio net driver.
Represent the virtio features bitmask with a fixes size array, and
introduce a few helpers to help manipulate the
Update headers to include the virtio GSO over UDP tunnel features
Signed-off-by: Paolo Abeni
--
Note: while the relevant change are not into Linus's tree yet, they have
been merged in the net-next tree and they should land into the vanilla
tree during the next merge window.
---
include/standard-
If the driver uses any of the extended features (i.e. 64 or above),
store the extended features range (64-127 bits).
At load time, let legacy features initialize the full features range
and pass it to the set helper; sub-states loading will have filled-up
the extended part as needed.
This is one
Similar to virtio infra, vhost core maintains the features status
in the full extended format and allows the devices to implement
extended version of the getter/setter.
Note that 'protocol_features' are not extended: they are only
used by vhost-user, and the latter device is not going to implement
Provide extended version of the features manipulation helpers,
and let the device initialization deal with the full features space,
adjusting the relevant format strings accordingly.
Signed-off-by: Paolo Abeni
---
v3 -> v4:
- add missing features initialization
- use new virtio_features macro
The virtio specifications allows for up to 128 bits for the
device features. Soon we are going to use some of the 'extended'
bits features for the virtio net driver.
Add support to allow extended features negotiation on a per
devices basis. Devices willing to negotiated extended features
need to i
The set_offload() argument list is already pretty long and
we are going to introduce soon a bunch of additional offloads.
Replace the offload arguments with a single struct and update
all the relevant call-sites.
No functional changes intended.
Signed-off-by: Paolo Abeni
---
v3 -> v4:
- style
Some virtualized deployments use UDP tunnel pervasively and are impacted
negatively by the lack of GSO support for such kind of traffic in the
virtual NIC driver.
The virtio_net specification recently introduced support for GSO over
UDP tunnel, and the kernel side of the implementation has been me
>From time to time it is needed to remove all bitmaps from the image.
Before this patch the process is not very convinient. One should
perform
qemu-img info
and parse the output to obtain all names. After that one should
sequentially call
qemu-img bitmap --remove
for each present bitmap.
T
On 7/23/25 19:31, Denis V. Lunev wrote:
On 7/23/25 19:04, Nikolai Barybin wrote:
QMP query-dump-guest-memory-capability reports win dump as available for
any x86 VM, which is false.
This patch implements proper query of vmcoreinfo and calculation of
guest note size. Based on that we can surely
Save/restore the nested flag of an exception during VM save/restore
and live migration to ensure a correct event stack level is chosen
when a nested exception is injected through FRED event delivery.
The event stack level used by FRED event delivery depends on whether
the event was a nested except
On Mon, 2025-07-21 at 17:26 -0400, Collin Walling wrote:
> On 7/11/25 17:10, Zhuoying Cai wrote:
> > DIAGNOSE 320 is introduced to support certificate store facility,
> > which includes operations such as query certificate storage
> > information and provide certificates in the certificate store.
>
On 7/23/25 19:04, Nikolai Barybin wrote:
QMP query-dump-guest-memory-capability reports win dump as available for
any x86 VM, which is false.
This patch implements proper query of vmcoreinfo and calculation of
guest note size. Based on that we can surely report whether win dump
available or not.
This is largely derived from existing Darwin support. FreeBSD
apparently has better support for *at() system calls so doesn't require
workarounds for a missing mknodat(). The implementation has a couple of
warts however:
- The extattr(2) system calls don't support anything akin to
XATTR_CREATE
On 7/23/25 09:54, Peter Maydell wrote:
In our implementation of the SVE2p1 contiguous load to 128-bit
element insns such as LD1D (scalar plus scalar, single register), we
got the order of the arguments to the DO_LD1_2() macro wrong. Here
the first argument is the element size and the second is t
On 7/23/25 19:04, Nikolai Barybin wrote:
QMP query-dump-guest-memory-capability reports win dump as available for
any x86 VM, which is false.
This patch implements proper query of vmcoreinfo and calculation of
guest note size. Based on that we can surely report whether win dump
available or not.
On 7/23/25 09:54, Peter Maydell wrote:
Our implementation of the helper functions for the LD1Q and ST1Q
insns reused the existing DO_LD1_ZPZ_D and DO_ST1_ZPZ_D macros. This
passes the wrong esize (8, not 16) to sve_ldl_z().
Create new macros DO_LD1_ZPZ_Q and DO_ST1_ZPZ_Q which pass the
correct
On 7/23/25 09:54, Peter Maydell wrote:
Unlike the "LD1D (scalar + vector)" etc instructions, LD1Q is
vector + scalar. This means that:
* the vector and the scalar register are in opposite fields
in the encoding
* 31 in the scalar register field is XZR, not XSP
The same applies for ST1Q.
QMP query-dump-guest-memory-capability reports win dump as available for
any x86 VM, which is false.
This patch implements proper query of vmcoreinfo and calculation of
guest note size. Based on that we can surely report whether win dump
available or not.
For further reference one may review this
From: Richard Henderson
Failure to confirm an argument set first may result in
the selection of a format which leaves extra arguments
to be filled in by the pattern.
Signed-off-by: Richard Henderson
Message-id: 20250722183343.273533-1-richard.hender...@linaro.org
Reviewed-by: Philippe Mathieu-D
From: Richard Henderson
Instead of trying to pack mtedesc into the upper 17 bits of a 32-bit
gvec descriptor, pass the gvec descriptor in the lower 32 bits and
the mte descriptor in the upper 32 bits of a 64-bit operand.
This fixes two bugs:
(1) in gen_sve_ldr() and gen_sve_str() call gen_mte_c
Unlike the "LD1D (scalar + vector)" etc instructions, LD1Q is
vector + scalar. This means that:
* the vector and the scalar register are in opposite fields
in the encoding
* 31 in the scalar register field is XZR, not XSP
The same applies for ST1Q.
This means we can't reuse the trans_LD1_zpr
Our implementation of the helper functions for the LD1Q and ST1Q
insns reused the existing DO_LD1_ZPZ_D and DO_ST1_ZPZ_D macros. This
passes the wrong esize (8, not 16) to sve_ldl_z().
Create new macros DO_LD1_ZPZ_Q and DO_ST1_ZPZ_Q which pass the
correct esize, and use them for the LD1Q and ST1Q
In our implementation of the SVE2p1 contiguous load to 128-bit
element insns such as LD1D (scalar plus scalar, single register), we
got the order of the arguments to the DO_LD1_2() macro wrong. Here
the first argument is the element size and the second is the memory
size, and the element size is a
This patchset fixes some bugs in the load/store insns newly
introduced with SVE2p1. The first three patches are all from Richard
and have already appeared on the list: I gathered them up here since
they're hard dependencies for this (and for patch 2 expanded the
commit message to say which bugs it
On 7/23/25 16:28, Markus Armbruster wrote:
Noise starting with "stdout: " has been polluting output of "make check"
for a while. I traced it to qos-test. Output of "make
check-qtest-aarch64" appended as an example.
Blessed silence if I revert commit 30ea13e9d97d (tests/qtest: use
qos_printf in
Hi Ben,
On 23/7/25 16:55, Ben Dooks wrote:
I am currently trying to track down two errors with mmc-spi.
The first looks like u-boot is sending a couple of CMDs (9, 10)
in the wrong state (currently this works however with a real SD
card) so I have a tmp-fix in to just ignore the two checks in
On 23/7/25 18:00, Peter Maydell wrote:
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
Call generic (including accelerator) cpu_realize() handlers
*before* setting @gt_cntfrq_hz default
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/arm/cpu.c |
On 23/7/25 17:49, Peter Maydell wrote:
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
Allow accelerators to set vCPU properties before its realization.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
include/accel/accel-cpu-ops.h | 1 +
accel/accel-c
On 21/7/25 17:33, Alex Bennée wrote:
This is a simple test case that runs an image with kvmtool and
kvm-unit-tests which can validate virtualisation works. This is useful
for exercising TCG but can also be applied to any nested virt setup
which is why it doesn't specify an accelerator.
Signed-of
Commit a59d06305fff ("vfio/pci: Introduce x-pci-class-code option")
allows user to expose non-VGA IGD device as VGA controller to the
guest. However, legacy mode requires host VGA range access. Check
that GGC.IVD == 0 before enabling legacy mode to ensure IGD is a real
VGA device claiming host VGA
In commit a59d06305fff ("vfio/pci: Introduce x-pci-class-code option"),
pci_register_vga() has been moved ouside of vfio_populate_vga(). As a
result, IGD VGA ranges are no longer properly exposed to guest.
To fix this, call pci_register_vga() after vfio_populate_vga() legacy
mode. A wrapper functi
This patchset aims to fix 2 bugs on legacy mode brought by commit
a59d06305fff ("vfio/pci: Introduce x-pci-class-code option").
1. QEMU tries to enable VGA access on device emulated to VGA controller.
2. pci_register_vga() is not called after calling vfio_populate_vga().
Tomita Moeko (2):
vfio
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
>
> Setting ARMCPU::gt_cntfrq_hz in hvf_arch_init_vcpu() is
> not correct because the timers have already be initialized
> with the default frequency.
>
> Set it earlier in the AccelOpsClass::cpu_target_realize()
> handler instead, and as
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
>
> Implement HVF AccelOpsClass::cpu_target_realize() hook as
> empty stubs. Target implementations will come separately.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
--
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
>
> Call generic (including accelerator) cpu_realize() handlers
> *before* setting @gt_cntfrq_hz default
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Richard Henderson
> ---
> target/arm/cpu.c | 65 -
On Wed, 23 Jul 2025 at 14:52, Philippe Mathieu-Daudé wrote:
>
> Allow accelerators to set vCPU properties before its realization.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Richard Henderson
> ---
> include/accel/accel-cpu-ops.h | 1 +
> accel/accel-common.c | 5 +
>
On Wed, Jul 23, 2025 at 8:44 AM Albert Esteve wrote:
>
> On Wed, Jul 23, 2025 at 2:32 PM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi,
> >
> > On 23/7/25 14:19, Albert Esteve wrote:
> > > In the last version of the SHMEM MAP/UNMAP [1] there was a
> > > comment [2] from Stefan about the lifecycle of
On 23/07/2025 14:38, Peter Maydell wrote:
On Wed, 23 Jul 2025 at 13:47, Alex Bennée wrote:
Ben Dooks writes:
(Add maintainers to CC)
You should get your patch workflow to use scripts/get_maintainer.pl so
they get CC'd and reduces the chance of it being missed in the fire-hose
of qemu-devel.
Noise starting with "stdout: " has been polluting output of "make check"
for a while. I traced it to qos-test. Output of "make
check-qtest-aarch64" appended as an example.
Blessed silence if I revert commit 30ea13e9d97d (tests/qtest: use
qos_printf instead of g_test_message).
Alex, what shall w
Call generic (including accelerator) cpu_realize() handlers
*before* setting @gt_cntfrq_hz default
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/arm/cpu.c | 65
1 file changed, 33 insertions(+), 32 deletions(-)
Allow accelerators to set vCPU properties before its realization.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
include/accel/accel-cpu-ops.h | 1 +
accel/accel-common.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/accel/accel-cpu-ops.h b
On 23/7/25 15:15, Markus Armbruster wrote:
parse_keyboard_layout() passes a possibly null @filename to
trace_keymap_parse(). Trace backend log then formats it with %s,
which crashes on some systems.
Fix by moving the null check before the trace_keymap_parse().
While there, improve the error me
(Series fully reviewed)
When using HVF, the accelerator gets the host Generic Timer
frequency and update cpu->gt_cntfrq_hz; it is however too
late, as the timers have been created in arm_cpu_realizefn()
using the default frequency. Then guest virtualization code
depending on timers ends very slow
Implement HVF AccelOpsClass::cpu_target_realize() hook as
empty stubs. Target implementations will come separately.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
include/system/hvf_int.h | 2 ++
accel/hvf/hvf-accel-ops.c | 2 ++
target/arm/hvf/hvf.c | 5 +
t
Setting ARMCPU::gt_cntfrq_hz in hvf_arch_init_vcpu() is
not correct because the timers have already be initialized
with the default frequency.
Set it earlier in the AccelOpsClass::cpu_target_realize()
handler instead, and assert the value is correct when
reaching hvf_arch_init_vcpu().
Fixes: a147
On Wed, Jul 23, 2025 at 5:15 PM Markus Armbruster wrote:
> parse_keyboard_layout() passes a possibly null @filename to
> trace_keymap_parse(). Trace backend log then formats it with %s,
> which crashes on some systems.
>
> Fix by moving the null check before the trace_keymap_parse().
>
> While t
On Wed, 23 Jul 2025 at 13:47, Alex Bennée wrote:
>
> Ben Dooks writes:
>
> (Add maintainers to CC)
>
> You should get your patch workflow to use scripts/get_maintainer.pl so
> they get CC'd and reduces the chance of it being missed in the fire-hose
> of qemu-devel.
>
> > If we get "ssi_sd: error:
Markus Armbruster (2):
i386/kvm/vmsr_energy: Plug memory leak on failure to connect socket
vfio scsi ui: Error-check qio_channel_socket_connect_sync() the same
way
hw/vfio-user/proxy.c | 2 +-
scsi/pr-manager-helper.c | 9 ++---
target/i386/kvm/vmsr_energy.c | 6 +-
vmsr_open_socket() leaks the Error set by
qio_channel_socket_connect_sync(). Plug the leak by not creating the
Error.
Fixes: 0418f90809ae (Add support for RAPL MSRs in KVM/Qemu)
Signed-off-by: Markus Armbruster
---
target/i386/kvm/vmsr_energy.c | 6 +-
1 file changed, 1 insertion(+), 5 dele
qio_channel_socket_connect_sync() returns 0 on success, and -1 on
failure, with errp set. Some callers check the return value, and some
check whether errp was set.
For consistency, always check the return value, and always check it's
negative.
Signed-off-by: Markus Armbruster
---
hw/vfio-user/
parse_keyboard_layout() passes a possibly null @filename to
trace_keymap_parse(). Trace backend log then formats it with %s,
which crashes on some systems.
Fix by moving the null check before the trace_keymap_parse().
While there, improve the error messages a bit.
Fixes: d3b787fa7dde (keymaps:
On 23.07.25 14:48, Albert Esteve wrote:
On Wed, Jul 23, 2025 at 2:43 PM David Hildenbrand wrote:
On 23.07.25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussion, David
On 23.07.25 14:45, David Hildenbrand wrote:
On 23.07.25 14:42, Albert Esteve wrote:
On Wed, Jul 23, 2025 at 2:32 PM Philippe Mathieu-Daudé
wrote:
Hi,
On 23/7/25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle
On Wed, Jul 23, 2025 at 2:43 PM David Hildenbrand wrote:
>
> On 23.07.25 14:19, Albert Esteve wrote:
> > In the last version of the SHMEM MAP/UNMAP [1] there was a
> > comment [2] from Stefan about the lifecycle of the memory
> > regions.
> >
> > After some discussion, David Hildenbrand proposed
>
On 23.07.25 14:42, Albert Esteve wrote:
On Wed, Jul 23, 2025 at 2:32 PM Philippe Mathieu-Daudé
wrote:
Hi,
On 23/7/25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussio
Ben Dooks writes:
(Add maintainers to CC)
You should get your patch workflow to use scripts/get_maintainer.pl so
they get CC'd and reduces the chance of it being missed in the fire-hose
of qemu-devel.
> If we get "ssi_sd: error: Unexpected response to cmd" then having
> the bad s->arglen would
On 23.07.25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussion, David Hildenbrand proposed
to detect RAM regions and handle refcounting differently
to clear the initial co
On Wed, Jul 23, 2025 at 2:32 PM Philippe Mathieu-Daudé
wrote:
>
> Hi,
>
> On 23/7/25 14:19, Albert Esteve wrote:
> > In the last version of the SHMEM MAP/UNMAP [1] there was a
> > comment [2] from Stefan about the lifecycle of the memory
> > regions.
> >
> > After some discussion, David Hildenbran
Hi,
On 23/7/25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussion, David Hildenbrand proposed
to detect RAM regions and handle refcounting differently
to clear the initia
On 7/23/2025 8:06 PM, Philippe Mathieu-Daudé wrote:
On 23/7/25 09:09, Xiaoyao Li wrote:
Current QEMU unconditionally sets the mmem.guest_memfd_offset in
kvm_set_user_memory_region(), which leads to the trace of
kvm_set_user_memory
look as:
kvm_set_user_memory AddrSpace#0 Slot#4 flags=0x2 gpa=
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussion, David Hildenbrand proposed
to detect RAM regions and handle refcounting differently
to clear the initial concern. This RFC patch is
meant for gatheri
Hi Denis,
On 22/7/25 12:17, ger...@altlinux.org wrote:
From: Denis Rastyogin
Use 1ULL << psn to ensure the shift is done in 64-bit arithmetic,
avoiding overflow for large psn values. The 6-bit psn field allows
values up to 63, so 64-bit shift is required for correctness.
If you are really wo
On 23/7/25 09:09, Xiaoyao Li wrote:
Current QEMU unconditionally sets the mmem.guest_memfd_offset in
kvm_set_user_memory_region(), which leads to the trace of kvm_set_user_memory
look as:
kvm_set_user_memory AddrSpace#0 Slot#4 flags=0x2 gpa=0xe size=0x2
ua=0x7f5840de guest_memfd=-1
On 23/7/25 09:09, Xiaoyao Li wrote:
Zero out the entire mem explicitly before it's used, to ensure the unused
feilds (pad1, pad2) are all zeros. Otherwise, it might cause problem when
the pad fields are extended by future KVM.
Fixes: ce5a983233b4 ("kvm: Enable KVM_SET_USER_MEMORY_REGION2 for mem
Cc'ing Gustavo.
On 22/7/25 22:14, Vacha Bhavsar wrote:
The QEMU GDB stub does not expose the ZA storage SME register to GDB via
the remote serial protocol, which can be a useful functionality to debug SME
code. To provide this functionality in Aarch64 target, this patch registers the
SME registe
On 22/7/25 20:33, Richard Henderson wrote:
Failure to confirm an argument set first may result in
the selection of a format which leaves extra arguments
to be filled in by the pattern.
Signed-off-by: Richard Henderson
---
scripts/decodetree.py | 7 ---
tests/decode/meson.build
On 7/23/25 7:47 AM, Jason Wang wrote:
> On Tue, Jul 22, 2025 at 3:37 PM Paolo Abeni wrote:
>>
>> On 7/22/25 5:28 AM, Jason Wang wrote:
>>> On Fri, Jul 18, 2025 at 4:53 PM Paolo Abeni wrote:
Extend the features configuration space to 128 bits, and allow the
common read/write operati
On Tue, 22 Jul 2025 at 19:33, Richard Henderson
wrote:
>
> Failure to confirm an argument set first may result in
> the selection of a format which leaves extra arguments
> to be filled in by the pattern.
>
> Signed-off-by: Richard Henderson
> ---
> scripts/decodetree.py | 7 ---
>
On Tue, Jul 22 2025, Sebastian Ott wrote:
> On Mon, 21 Jul 2025, Cornelia Huck wrote:
>> +/* pretty-print a KVM register */
>> +#define CP_REG_ARM64_SYSREG_OP(_reg, _op) \
>> +((uint8_t)((_reg & CP_REG_ARM64_SYSREG_ ## _op ## _MASK) >> \
>> + CP_REG_ARM64_S
Update OpenSBI and the pre-built opensbi32 and opensbi64 images to
version 1.7.
It has been almost an year since we last updated OpenSBI (at the time,
up to v1.5.1) and we're missing a lot of good stuff from both v1.6 and
v1.7, including SBI 3.0 and RPMI 1.0.
The changelog is too large and tediou
Hi,
It has been awhile since we last updated OpenSBI - we're still running
v1.5.1, updated almost a year ago. We're missing out a lot of fixes and
goodies (including SBI 3.0) from v1.6 and v1.7.
This update didn't trigger any regressions in our opensbi tests so I
would like to update the roms for
On 7/23/25 12:23 PM, Michael S. Tsirkin wrote:
On Wed, Jul 23, 2025 at 12:16:08PM +0300, Daniil Tatianin wrote:
On 7/23/25 12:14 PM, Michael S. Tsirkin wrote:
On Wed, Jul 23, 2025 at 12:01:28PM +0300, Daniil Tatianin wrote:
This is useful to be able to indicate various supported features to t
On Thu, 2025-06-19 at 21:42 +0200, Mathias Krause wrote:
> KVM has a weird behaviour when a guest executes VMCALL on an AMD system
> or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
> exception (#UD) as they are just the wrong instruction for the CPU
> given. But instead of for
On Wed, Jul 23, 2025 at 12:16:08PM +0300, Daniil Tatianin wrote:
>
> On 7/23/25 12:14 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 23, 2025 at 12:01:28PM +0300, Daniil Tatianin wrote:
> > > This is useful to be able to indicate various supported features to the
> > > guest, or freeze a specific v
On 7/23/25 12:14 PM, Michael S. Tsirkin wrote:
On Wed, Jul 23, 2025 at 12:01:28PM +0300, Daniil Tatianin wrote:
This is useful to be able to indicate various supported features to the
guest, or freeze a specific version of SeaBIOS to prevent guest visible
changes between BIOS updates. This is
On Wed, Jul 23, 2025 at 12:01:28PM +0300, Daniil Tatianin wrote:
> This is useful to be able to indicate various supported features to the
> guest, or freeze a specific version of SeaBIOS to prevent guest visible
> changes between BIOS updates. This is currently not possible since the
> extension b
On Wed, Jul 23, 2025 at 08:27:14AM +0200, Cédric Le Goater wrote:
> Commit 350785d41d8b ("ramfb: Add property to control if load the
> romfile") introduced the `use-legacy-x86-rom` property for the
> `vfio-pci-nohotplug` device, allowing control over VGA BIOS ROM
> loading. However, the property co
This is useful to be able to indicate various supported features to the
guest, or freeze a specific version of SeaBIOS to prevent guest visible
changes between BIOS updates. This is currently not possible since the
extension bytes indicated by SeaBIOS are slightly different than those
QEMU sets by
On 7/23/2025 4:42 PM, Xiaoyao Li wrote:
On 7/23/2025 3:53 PM, Mathias Krause wrote:
I would leave it to Paolo to decide whether a compat property is needed
to disable the hypercall patching by default for newer machine, and keep
the old machine with old behavior (hypercall patching is enabled) b
On Wed, Jul 23, 2025 at 08:27:14AM +0200, Cédric Le Goater wrote:
> Commit 350785d41d8b ("ramfb: Add property to control if load the
> romfile") introduced the `use-legacy-x86-rom` property for the
> `vfio-pci-nohotplug` device, allowing control over VGA BIOS ROM
> loading. However, the property co
On 7/23/2025 3:53 PM, Mathias Krause wrote:
I would leave it to Paolo to decide whether a compat property is needed
to disable the hypercall patching by default for newer machine, and keep
the old machine with old behavior (hypercall patching is enabled) by
default.
Bleh, I just noticed that the
On 23.07.25 08:54, Xiaoyao Li wrote:
> On 7/23/2025 4:43 AM, Mathias Krause wrote:
>> KVM has a weird behaviour when a guest executes VMCALL on an AMD system
>> or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
>> exception (#UD) as they are just the wrong instruction for the CP
Patch 1 changes to check guest memfd CAP on VM instance.
Patch 2 is a fix for KVM_SET_USER_MEMORY_REGION2.
Patch 3 is an enhancement for guest_memfd_offset.
Xiaoyao Li (3):
accel/kvm: Switch to check KVM_CAP_GUEST_MEMFD and
KVM_CAP_USER_MEMORY2 on VM
accel/kvm: Zero out mem explicitly in
Zero out the entire mem explicitly before it's used, to ensure the unused
feilds (pad1, pad2) are all zeros. Otherwise, it might cause problem when
the pad fields are extended by future KVM.
Fixes: ce5a983233b4 ("kvm: Enable KVM_SET_USER_MEMORY_REGION2 for memslot")
Signed-off-by: Xiaoyao Li
---
It returns more accruate result on checking KVM_CAP_GUEST_MEMFD and
KVM_CAP_USER_MEMORY2 on VM instance instead of on KVM platform.
Signed-off-by: Xiaoyao Li
---
accel/kvm/kvm-all.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
Current QEMU unconditionally sets the mmem.guest_memfd_offset in
kvm_set_user_memory_region(), which leads to the trace of kvm_set_user_memory
look as:
kvm_set_user_memory AddrSpace#0 Slot#4 flags=0x2 gpa=0xe size=0x2
ua=0x7f5840de guest_memfd=-1 guest_memfd_offset=0x3e ret=0
It'
Shaoqin,
On 7/23/25 08:27, Cédric Le Goater wrote:
Commit 350785d41d8b ("ramfb: Add property to control if load the
romfile") introduced the `use-legacy-x86-rom` property for the
`vfio-pci-nohotplug` device, allowing control over VGA BIOS ROM
loading.
Could you please send a patch adding a pr
99 matches
Mail list logo
