On 7/6/25 17:27, tank0nf wrote:
From: Soumyajyotii_Ssarkar
1. Changed the asset link to one which is working from the PARISC website
2. Abstracted the configure function.
Signed-off-by: Soumyajyotii Ssarkar
---
hw/net/i82596.c | 38 ++
1 file changed, 2
On 6/9/25 18:44, Rorie Reyes wrote:
These functions can be invoked by the function that handles interception
of the CHSC SEI instruction for requests indicating the accessibility of
one or more adjunct processors has changed.
Signed-off-by: Rorie Reyes
Reviewed-by: Anthony Krowiak
---
hw/vfi
On 5/29/25 21:24, Steve Sistare wrote:
Define a list of vfio devices in CPR state, in a subsection so that
older QEMU can be live updated to this version. However, new QEMU
will not be live updateable to old QEMU. This is acceptable because
CPR is not yet commonly used, and updates to older ver
On 5/29/25 21:24, Steve Sistare wrote:
Define vfio_device_free_name to free the name created by
vfio_device_get_name. A subsequent patch will do more there.
No functional change.
Signed-off-by: Steve Sistare
---
include/hw/vfio/vfio-device.h | 1 +
hw/vfio/ap.c | 2 +-
hw/
On 6/9/25 22:47, Steven Sistare wrote:
On 6/9/2025 4:30 PM, Cédric Le Goater wrote:
On 5/29/25 21:24, Steve Sistare wrote:
Register a vfio iommufd container and device for CPR, replacing the generic
CPR register call with a more specific iommufd register call. Add a
blocker if the kernel does
On 5/29/25 21:24, Steve Sistare wrote:
cpr-transfer will use the device name as a key to find the value
of the device descriptor in new QEMU. However, if the descriptor
number is specified by a command-line fd parameter, then
vfio_device_get_name creates a name that includes the fd number.
This
On 07/06/2025 08.04, Haseung Bong wrote:
From: "haseung.bong"
The README file in tests/vm/ points to a non-existent file,
docs/devel/testing.rst. Update the README to point to
docs/devel/testing/main.rst, which now contains information
about VM testing.
Signed-off-by: Haseung Bong
---
tests
From: Thomas Huth
When the testing docs were moved to a separate subfolder, the entries
in the MAINTAINERS file were missed. Update them now.
Fixes: ff41da50308 ("docs/devel: Split testing docs from the build docs and
move to separate folder")
Signed-off-by: Thomas Huth
---
MAINTAINERS | 15 +
在 2025/6/5 下午5:28, Bibo Mao 写道:
Interrupt controller extioi supports 256 vectors, register EXTIOI_COREISR
records pending interrupt status with bitmap method. Size of EXTIOI_COREISR
is 256 / 8 = 0x20 bytes, EXTIOI_COREISR_END should be EXTIOI_COREISR_START
+ 0x20 rather than 0xB20.
Signed-off-by
在 2025/6/4 下午5:05, Alireza Sanaee 写道:
On Wed, 4 Jun 2025 14:55:00 +0800
Bibo Mao wrote:
On big endian host machine such as S390, bios-table-test fails to run.
And also linux kernel fails to boot.
This patches solves these two issues.
Bibo Mao (2):
hw/loongarch/virt: Fix big endian support
In some situations it is desirable to be able to specify the flash type
connected to a board. For example, the target operating system may not
support the default flash type, its support may be broken, or the qemu
emulation is insufficient and the default flash is not detected.
On top of that, the
* Peter Xu (pet...@redhat.com) wrote:
> Add the latency distribution too for blocktime, using order-of-two buckets.
> It accounts for all the faults, from either vCPU or non-vCPU threads. With
> prior rework, it's very easy to achieve by adding an array to account for
> faults in each buckets.
>
* Peter Xu (pet...@redhat.com) wrote:
> Blocktime so far only cares about the time one vcpu (or the whole system)
> got blocked. It would be also be helpful if it can also report the latency
> of page requests, which could be very sensitive during postcopy.
>
> Blocktime itself is sometimes not v
On Mon, Jun 9, 2025 at 11:18 PM Ben Dooks wrote:
>
> Add TYPE_RISCV_CPU_CVA6 for the CVA6 core
>
> Signed-off-by: Ben Dooks
Acked-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu-qom.h | 1 +
> target/riscv/cpu.c | 11 +++
> 2 files changed, 12 insertions(+)
>
> diff --git
On Mon, Jun 9, 2025 at 11:20 PM Ben Dooks wrote:
>
> Change to using TYPE_RISCV_CPU_CVA6 once this is merged.
You can also just change the patch order to not require this patch
>
> Signed-off-by: Ben Dooks
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/riscv/cva6.c | 3 +--
> 1 file cha
On Mon, Jun 9, 2025 at 11:19 PM Ben Dooks wrote:
>
> Add a (currently Genesy2 based) CVA6 machine.
>
> Has SPI and UART, the GPIO and Ethernet are currently black-holed
> as there is no hardware model for them (lowRISC ethernet and Xilinx
> GPIO)
>
> Signed-off-by: Ben Dooks
> ---
> v3:
> - fix m
On Thu, May 29, 2025 at 04:08:01PM +0100, Jonathan Cameron wrote:
> On Wed, 28 May 2025 12:07:23 +0100
> Jonathan Cameron wrote:
>
> > Previously these somewhat device like structures were tracked using a list
> > in the CXLState in each machine. This is proving restrictive in a few
> > cases wh
Add the latency distribution too for blocktime, using order-of-two buckets.
It accounts for all the faults, from either vCPU or non-vCPU threads. With
prior rework, it's very easy to achieve by adding an array to account for
faults in each buckets.
Sample output for HMP (while for QMP it's simply
On Mon, Jun 09, 2025 at 06:05:16PM -0400, Peter Xu wrote:
> On Mon, Jun 09, 2025 at 03:12:54PM -0400, Peter Xu wrote:
> > +static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> > +{
> > +if (info->has_postcopy_blocktime) {
> > +monitor_printf(mon, "Postcopy Blocktime
Looking up the vCPU index for each fault can be expensive when there're
hundreds of vCPUs. Provide a cache for tid->vcpu instead with a hash
table, then lookup from there.
When at it, add another counter to record how many non-vCPU faults it gets.
For example, the main thread can also access a gu
On Mon, Jun 09, 2025 at 03:12:54PM -0400, Peter Xu wrote:
> +static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> +{
> +if (info->has_postcopy_blocktime) {
> +monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> + info->postcopy_bloc
If we have a server running disk requests that is for whatever reason
hanging or not able to process any more IO requests but still has some
in-flight requests previously issued by the guest OS, QEMU will still
try to drain the vring before shutting down even if it was explicitly
asked to do a "for
This can be useful for devices that might take too long to shut down
gracefully, but may have a way to shutdown quickly otherwise if needed
or explicitly requested by a force shutdown.
For now we only consider SIGTERM or the QMP quit() command a force
shutdown, since those bypass the guest entirel
This adds an ability to skip GET_VRING_BASE during device stop entirely,
and thus the expensive drain operation that this call entails as well,
which may be useful during a non-graceful shutdown in case the guest
operating system hangs or refuses to react to a previously requested
ACPI shutdown for
This series aims to address SIGTERM/QMP quit() being a bit too graceful in
respect to devices. Both of the aforementioned ways to stop QEMU completely
bypass the guest OS so in that sense they're basically equal to pulling the
power plug on a computer, yet the device shutdown code still tries to do
On 6/9/2025 4:30 PM, Cédric Le Goater wrote:
On 5/29/25 21:24, Steve Sistare wrote:
Register a vfio iommufd container and device for CPR, replacing the generic
CPR register call with a more specific iommufd register call. Add a
blocker if the kernel does not support IOMMU_IOAS_CHANGE_PROCESS.
On 5/29/25 21:24, Steve Sistare wrote:
Register a vfio iommufd container and device for CPR, replacing the generic
CPR register call with a more specific iommufd register call. Add a
blocker if the kernel does not support IOMMU_IOAS_CHANGE_PROCESS.
This is mostly boiler plate. The fields to to
On Mon, Jun 09, 2025 at 04:41:06PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Mon, Jun 09, 2025 at 03:02:06PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Mon, Jun 09, 2025 at 11:37:02AM -0300, Fabiano Rosas wrote:
> >> >> Peter Xu writes:
> >> >>
> >> >> > On
Before this patch, the blocktime context can be created very early, because
postcopy_ram_supported_by_host() <- migrate_caps_check() can happen during
migration object init.
The trick here is the blocktime context needs system vCPU information,
which seems to be possible to change after that point
Il lun 9 giu 2025, 20:27 Stefan Hajnoczi ha scritto:
> > If you disagree with this change we can certainly live without them---I
> > asked Tanish to start with this as an exercise to get familiar with
> > tracetool, and he's learnt a bunch of things around git anyway so it's
> > all good.
>
> A m
I forgot one additional update here that was necessary because the
plugin_cb_flags getter/setters are now on the hot path and need
inlining, and left a typo, both of which I fixed in v11
(https://lore.kernel.org/qemu-devel/20250609193841.348076-1-rowanbh...@gmail.com/T/#t).
On 6/9/25 12:23 P
I've addressed comments by Alex and Julian WRT the new restrictions on
flags for calling qemu_plugin_read/write_register by relaxing those
restrictions using the same system for setting and getting the current
flag state, and adding a set/clear before each callback invocation.
Please check
htt
Peter Xu writes:
> On Mon, Jun 09, 2025 at 03:02:06PM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Mon, Jun 09, 2025 at 11:37:02AM -0300, Fabiano Rosas wrote:
>> >> Peter Xu writes:
>> >>
>> >> > On Fri, Jun 06, 2025 at 05:23:18PM -0300, Fabiano Rosas wrote:
>> >> >> Peter Xu w
This patch series adds several new API functions focused on enabling use
cases around reading and writing guest memory from QEMU plugins. To support
these new APIs, some utility functionality around retrieving information about
address spaces is added as well.
The new qemu_plugin_write_register ut
From: novafacing
This patch adds functions to the plugins API to allow plugins to read
and write memory via hardware addresses. The functions use the current
address space of the current CPU in order to avoid exposing address
space information to users. A later patch may want to add a function to
From: novafacing
This patch adds a plugin that implements a simple form of hypercalls
from guest code to the plugin by using the register read API. It accepts
only one hypercall, which writes a magic value to guest memory.
Signed-off-by: Rowan Hart
---
tests/tcg/Makefile.target
From: novafacing
This patch updates the plugin version to gate new APIs and adds notes
describing what has been added.
Signed-off-by: Rowan Hart
---
include/qemu/qemu-plugin.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/qemu/qemu-plugin.h b/include/qemu/
This patch adds functionality to enforce the requested QEMU_PLUGIN_CB_
flags level passed when registering a callback function using the
plugins API. Each time a callback is about to be invoked, a thread-local
variable will be updated with the level that callback requested. Then,
called API functio
From: novafacing
This patch adds a plugin that exercises the virtual and hardware memory
read-write API functions added in a previous patch. The plugin takes a
target and patch byte sequence, and will overwrite any instruction
matching the target byte sequence with the patch.
Signed-off-by: Rowa
From: novafacing
This patch adds functions to the plugins API to allow reading and
writing memory via virtual addresses. These functions only permit doing
so on the current CPU, because there is no way to ensure consistency if
plugins are allowed to read or write to other CPUs that aren't current
Hello Everyone,
I want to embed a QEMU window directly in my GUI application. Are Python
APIs available to embed QEMU into a GNOME GUI application?
I am the developer of Cubic (Custom Ubuntu ISO Creator), a tool which
allows users to customize Ubuntu and Debian based Live ISOs.
Screenshots & inf
From: novafacing
This patch adds a function to the plugins API to allow plugins to write
register contents. It also moves the qemu_plugin_read_register function
so all the register-related functions are grouped together in the file.
Reviewed-by: Pierrick Bouvier
Signed-off-by: Rowan Hart
---
From: novafacing
This patch exposes the gdb_write_register function from
gdbstub/gdbstub.c via the exec/gdbstub.h header file to support use in
plugins to write register contents.
Reviewed-by: Alex Bennée
Reviewed-by: Julian Ganz
Reviewed-by: Pierrick Bouvier
Signed-off-by: Rowan Hart
---
g
Currently, the postcopy blocktime feature maintains vCPU fault information
using an array (vcpu_addr[]). It has two issues.
Issue 1: Performance Concern
The old algorithm was almost OK and fast on inserts, except that the lookup
is slow and won't scale if there are a
This series is based on the other series I posted here:
Based-on: <20250609161855.6603-1-pet...@redhat.com>
https://lore.kernel.org/r/20250609161855.6603-1-pet...@redhat.com
v2:
- Collect tags
- Use two spaces always in qapi/ documentations for patch 8/13 [Markus]
- English error fix (s/system-wi
This patch adds functionality to enforce the requested QEMU_PLUGIN_CB_
flags level passed when registering a callback function using the
plugins API. Each time a callback is about to be invoked, a thread-local
variable will be updated with the level that callback requested. Then,
called API functio
From: novafacing
This patch adds a function to the plugins API to allow plugins to write
register contents. It also moves the qemu_plugin_read_register function
so all the register-related functions are grouped together in the file.
Reviewed-by: Pierrick Bouvier
Signed-off-by: Rowan Hart
---
From: novafacing
This patch adds functions to the plugins API to allow plugins to read
and write memory via hardware addresses. The functions use the current
address space of the current CPU in order to avoid exposing address
space information to users. A later patch may want to add a function to
From: novafacing
This patch adds a plugin that implements a simple form of hypercalls
from guest code to the plugin by using the register read API. It accepts
only one hypercall, which writes a magic value to guest memory.
Signed-off-by: Rowan Hart
---
tests/tcg/Makefile.target
From: novafacing
This patch adds functions to the plugins API to allow reading and
writing memory via virtual addresses. These functions only permit doing
so on the current CPU, because there is no way to ensure consistency if
plugins are allowed to read or write to other CPUs that aren't current
From: novafacing
This patch adds a plugin that exercises the virtual and hardware memory
read-write API functions added in a previous patch. The plugin takes a
target and patch byte sequence, and will overwrite any instruction
matching the target byte sequence with the patch.
Signed-off-by: Rowa
This patch series adds several new API functions focused on enabling use
cases around reading and writing guest memory from QEMU plugins. To support
these new APIs, some utility functionality around retrieving information about
address spaces is added as well.
The new qemu_plugin_write_register ut
From: novafacing
This patch exposes the gdb_write_register function from
gdbstub/gdbstub.c via the exec/gdbstub.h header file to support use in
plugins to write register contents.
Reviewed-by: Alex Bennée
Reviewed-by: Julian Ganz
Reviewed-by: Pierrick Bouvier
Signed-off-by: Rowan Hart
---
g
From: novafacing
This patch updates the plugin version to gate new APIs and adds notes
describing what has been added.
Signed-off-by: Rowan Hart
---
include/qemu/qemu-plugin.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/qemu/qemu-plugin.h b/include/qemu/
Add a global property to allow enabling postcopy-blocktime feature.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/options.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/options.c b/migration/options.c
index 162c72cda4..4e923a2e07 100644
--- a/migration/opti
Add a field to count how many remote faults one vCPU has taken. So far
it's still not used, but will be soon.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-r
Blocktime so far only cares about the time one vcpu (or the whole system)
got blocked. It would be also be helpful if it can also report the latency
of page requests, which could be very sensitive during postcopy.
Blocktime itself is sometimes not very important, especially when one
thinks about
With 64-bit fields, it is trivial. The caution is when exposing any values
in QMP, it was still declared with milliseconds (ms). Hence it's needed to
do the convertion when exporting the values to existing QMP queries.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/postcopy-
Now with 64bits, the offseting using start_time is not needed anymore,
because the array can always remember the whole timestamp.
Then drop the unused parameter in get_low_time_offset() altogether.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 10 --
The variable vcpu_total_blocktime isn't easy to follow. In reality, it
wants to capture the case where all vCPUs are stopped, and now there will
be some vCPUs starts running.
The name now starts to conflict with vcpu_blocktime_total[], meanwhile it's
actually not necessary to have the variable at
Now with the mutex protection it's not needed anymore.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 32fa06da
When used to report page fault latencies, the blocktime feature can be
almost useless when KVM async page fault is enabled, because in most cases
such remote fault will kickoff async page faults, then it's not trackable
from blocktime layer.
After all these recent rewrites to blocktime layer, it's
The postcopy blocktime feature was tricky that it used quite some atomic
operations over quite a few arrays and vars, without explaining how that
would be thread safe. The thread safety here is about concurrency between
the fault thread and the fault resolution threads, possible to access the
same
I am guessing it was used to be 32bits because of the atomic ops. Now all
the atomic ops are gone and we're protected by a mutex instead, it's ok we
can switch to 64 bits.
Reasons to move over:
- Allow further patches to change the unit from ms to us: with postcopy
preempt mode, we're really
On Mon, Jun 9, 2025 at 2:21 PM Tanish Desai wrote:
>
> Moved the logic for timestamped logging (~6 lines) from
> a_nocheck__trace_foo(header) into a new qemu_log_timestamp() function in
> util/log.c. This avoids code duplication across binaries and enables reuse as
> a standalone utility.
> Enc
On Sun, Jun 8, 2025 at 1:26 AM Akihiko Odaki
wrote:
> On 2025/06/07 5:50, John Snow wrote:
> > In advance of actually bumping the build system requirements for Sphinx,
> > bump the version used for the static analysis tests. Update the minimum
> > requirements accordingly.
> >
> > This changes th
On Mon, Jun 09, 2025 at 03:02:06PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Mon, Jun 09, 2025 at 11:37:02AM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Fri, Jun 06, 2025 at 05:23:18PM -0300, Fabiano Rosas wrote:
> >> >> Peter Xu writes:
> >> >>
> >> >> > On
On Mon, 9 Jun 2025, BALATON Zoltan wrote:
On Mon, 9 Jun 2025, Tanish Desai wrote:
Moved the logic for timestamped logging (~6 lines) from
a_nocheck__trace_foo(header) into a new qemu_log_timestamp() function in
util/log.c. This avoids code duplication across binaries and enables reuse
as a sta
On Mon, Jun 09, 2025, Andrey Zhadchenko wrote:
> On 6/9/25 18:39, Sean Christopherson wrote:
> > On Mon, Jun 09, 2025, Denis V. Lunev wrote:
> > > > Does anything in edk2 run during the hotplug process (on real hardware
> > > > it does, because the whole hotplug is managed via SMM)? If so maybe tha
On Mon, 9 Jun 2025, Tanish Desai wrote:
Moved the logic for timestamped logging (~6 lines) from
a_nocheck__trace_foo(header) into a new qemu_log_timestamp() function in
util/log.c. This avoids code duplication across binaries and enables reuse as a
standalone utility.
Encapsulation helps reduc
On Thu, Jun 5, 2025 at 2:49 PM Paolo Bonzini wrote:
>
> On 6/5/25 20:37, Stefan Hajnoczi wrote:
> > On Thu, Jun 5, 2025 at 9:57 AM Paolo Bonzini wrote:
> >>> It's easier to understand the code generator and the generated code when
> >>> each trace event is implemented as a single function in the
Two files are attached to show the folder-wise size (in bytes) before and
after the change. Each file lists the folder names along with their
corresponding sizes.
On Mon, Jun 9, 2025 at 11:51 PM Tanish Desai
wrote:
> Moved the logic for timestamped logging (~6 lines) from
> a_nocheck__trace_foo(
Moved the logic for timestamped logging (~6 lines) from
a_nocheck__trace_foo(header) into a new qemu_log_timestamp() function in
util/log.c. This avoids code duplication across binaries and enables reuse as a
standalone utility.
Encapsulation helps reduce build size significantly, particularly w
Peter Xu writes:
> (I had a reply in the other thread, that might have covered most of the
> points but maybe not this one..)
>
> On Mon, Jun 09, 2025 at 05:13:00PM +0100, Daniel P. Berrangé wrote:
>> Even if only a single mgmt app is involved this is still beneficial
>> because the migration in
On Wed, Jun 04, 2025 at 03:27:52PM +0200, Hanna Czenczek wrote:
> Hi,
>
> This series:
> - Fixes some bugs/minor inconveniences,
> - Removes libfuse from the request processing path,
> - Make the FUSE export use coroutines for request handling,
> - Introduces multi-threading into the FUSE export.
On Wed, Jun 04, 2025 at 03:28:12PM +0200, Hanna Czenczek wrote:
> Run qemu-img bench on a simple multi-threaded FUSE export to test that
> it works.
>
> Signed-off-by: Hanna Czenczek
> ---
> tests/qemu-iotests/308 | 51 ++
> tests/qemu-iotests/308.out | 56 +++
On Wed, Jun 04, 2025 at 03:28:10PM +0200, Hanna Czenczek wrote:
> FUSE allows creating multiple request queues by "cloning" /dev/fuse FDs
> (via open("/dev/fuse") + ioctl(FUSE_DEV_IOC_CLONE)).
>
> We can use this to implement multi-threading.
>
> For configuration, we don't need any more informat
On 6/9/25 18:39, Sean Christopherson wrote:
On Mon, Jun 09, 2025, Denis V. Lunev wrote:
On 6/9/25 18:12, Paolo Bonzini wrote:
On 6/9/25 15:23, Andrey Zhadchenko wrote:
When hotplugging vCPUs to the Windows vms, we observed strange instance
crash on Intel(R) Xeon(R) CPU E3-1230 v6:
panic h
Peter Xu writes:
> On Mon, Jun 09, 2025 at 11:37:02AM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Fri, Jun 06, 2025 at 05:23:18PM -0300, Fabiano Rosas wrote:
>> >> Peter Xu writes:
>> >>
>> >> > On Mon, Jun 02, 2025 at 10:38:08PM -0300, Fabiano Rosas wrote:
>> >> >> Allow the m
From: Klaus Jensen
Add i2c_smbus_pec() to calculate the SMBus Packet Error Code for a
message.
Reviewed-by: Jonathan Cameron
Signed-off-by: Klaus Jensen
Acked-by: Corey Minyard
Link: https://lore.kernel.org/r/20230914-nmi-i2c-v6-1-11bbb4f74...@samsung.com
Signed-off-by: Jonathan Cameron
---
The CCI and Fabric Manager APIs are used to configure CXL switches and
devices. DMTF has defined an MCTP binding specification to carry these
messages. The end goal of this work is to hook this up to emulated CXL
switches and devices to allow control of the configuration.
Since this relies on i2c
This posting is primarily about sharing the USB device emulation to get some
early feedback.
RFC reasons:
- Known 'inaccuracies' in emulation (not obeying MTU in the to host direction
for
example)./
- Not sure what to do wrt to Klaus' I2C MCTP support given that has been stalled
for some time
Add initial documentation for the MCTP over I2C management device. At
current time this can only be used with the Aspeed I2C controller which
is only available in aspeed SoCs, though can be added to other
emulated boards.
Signed-off-by: Jonathan Cameron
---
docs/system/devices/cxl.rst | 27 +
On Wed, Jun 04, 2025 at 03:28:08PM +0200, Hanna Czenczek wrote:
> Make BlockExportType.iothread an alternate between a single-thread
> variant 'str' and a multi-threading variant '[str]'.
>
> In contrast to the single-thread setting, the multi-threading setting
> will not change the BDS's context
On Wed, Jun 04, 2025 at 03:28:05PM +0200, Hanna Czenczek wrote:
> Manually read requests from the /dev/fuse FD and process them, without
> using libfuse. This allows us to safely add parallel request processing
> in coroutines later, without having to worry about libfuse internals.
> (Technically,
On Wed, Jun 04, 2025 at 03:28:07PM +0200, Hanna Czenczek wrote:
> Make fuse_process_request() a coroutine_fn (fuse_co_process_request())
> and have read_from_fuse_fd() launch it inside of a newly created
> coroutine instead of running it synchronously. This way, we can process
> requests in parall
Given the challenges in testing systems with the previously
posted i2c based mctp support for x86 / arm64 machines (as only
emulated controller that is suitably capable is the aspeed one)
providing a USB interface greatly simplifies things.
This is a PoC of such an interface.
RFC reasons:
- Not a
On 6/9/25 18:18, Peter Maydell wrote:
Ping^2 on this one?
No objections if it's the easiest way to solve the issue.
Alternatively, is there a Sphinx way to write something in the spirit of
#ifdef DEFINE_THE_LABEL
.. _label
#endif
This way, you could have the nbd label enabled when including
On 6/9/25 18:12, Paolo Bonzini wrote:
On 6/9/25 15:23, Andrey Zhadchenko wrote:
When hotplugging vCPUs to the Windows vms, we observed strange instance
crash on Intel(R) Xeon(R) CPU E3-1230 v6:
panic hyper-v: arg1='0x3e', arg2='0x46d359bbdff',
arg3='0x56d359bbdff', arg4='0x0', arg5='0x0'
Pres
On Mon, 9 Jun 2025 at 17:38, Paolo Bonzini wrote:
>
> On 6/9/25 18:18, Peter Maydell wrote:
> > Ping^2 on this one?
>
> No objections if it's the easiest way to solve the issue.
>
> Alternatively, is there a Sphinx way to write something in the spirit of
>
> #ifdef DEFINE_THE_LABEL
> .. _label
> #
From: Klaus Jensen
Add an abstract MCTP over I2C endpoint model. This implements MCTP
control message handling as well as handling the actual I2C transport
(packetization).
Devices are intended to derive from this and implement the class
methods.
Parts of this implementation is inspired by code
(I had a reply in the other thread, that might have covered most of the
points but maybe not this one..)
On Mon, Jun 09, 2025 at 05:13:00PM +0100, Daniel P. Berrangé wrote:
> Even if only a single mgmt app is involved this is still beneficial
> because the migration infrastructure is used for dis
On 6/9/25 13:54, Zhenzhong Duan wrote:
It's wrong to call into listener_begin callback in vfio_listener_commit().
Currently this impacts vfio-user.
Fixes: d9b7d8b6993b ("vfio/container: pass listener_begin/commit callbacks")
Signed-off-by: Zhenzhong Duan
---
hw/vfio/listener.c | 2 +-
1 file
Register an event notifier handler to process AP configuration
change events by queuing the event and generating a CRW to let
the guest know its AP configuration has changed
Signed-off-by: Rorie Reyes
Reviewed-by: Anthony Krowiak
---
hw/vfio/ap.c | 31 +++
1 file cha
Creates an object indicating that an AP configuration change event
has been received and stores it in a queue. These objects will later
be used to store event information for an AP configuration change
when the CHSC instruction is intercepted.
Signed-off-by: Rorie Reyes
Reviewed-by: Anthony Krowi
Handle interception of the CHSC SEI instruction for requests
indicating the guest's AP configuration has changed.
If configuring --without-default-devices, hw/s390x/ap-stub.c
was created to handle such circumstance. Also added the
following to hw/s390x/meson.build if CONFIG_VFIO_AP is
false, it wi
These functions can be invoked by the function that handles interception
of the CHSC SEI instruction for requests indicating the accessibility of
one or more adjunct processors has changed.
Signed-off-by: Rorie Reyes
Reviewed-by: Anthony Krowiak
---
hw/vfio/ap.c | 40 +++
Changelog:
v13:
- added lock to 'vfio_ap_cfg_chg_notifier_handler' in patch 2
- added RBs for patch 2 and 3 from Tony
v12:
- adding locks to 'ap_chsc_sei_nt0_have_event' and 'ap_chsc_sei_nt0_get_event'
v11:
- reverted return type to int for 'ap_chsc_sei_nt0_get_event'
- files reflected are 'ap
On Mon, Jun 09, 2025 at 05:15:43PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jun 09, 2025 at 11:53:47AM -0400, Peter Xu wrote:
> > On Mon, Jun 09, 2025 at 04:43:40PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Jun 09, 2025 at 11:33:14AM -0400, Peter Xu wrote:
> > > >
> > > > Now I think I know
On Mon, Jun 09, 2025, Denis V. Lunev wrote:
> On 6/9/25 18:12, Paolo Bonzini wrote:
> > On 6/9/25 15:23, Andrey Zhadchenko wrote:
> > > When hotplugging vCPUs to the Windows vms, we observed strange instance
> > > crash on Intel(R) Xeon(R) CPU E3-1230 v6:
> > > panic hyper-v: arg1='0x3e', arg2='0x4
1 - 100 of 204 matches
Mail list logo
