Am 20.02.25 um 07:02 schrieb Thomas Huth:
On 19/02/2025 20.23, Philippe Mathieu-Daudé wrote:
@@ -62,6 +62,10 @@ class PluginKernelNormal(PluginKernelBase):
('https://storage.tuxboot.com/20230331/arm64/Image'),
'ce95a7101a5fecebe0fe630deee6bd97b32ba41bc8754090e9ad8961ea8674c7')
+
On Thu, Feb 20, 2025 at 12:23:26PM +0530, Ani Sinha wrote:
> Date: Thu, 20 Feb 2025 12:23:26 +0530
> From: Ani Sinha
> Subject: [PATCH v2] microvm: do not use the lastest cpu version
> X-Mailer: git-send-email 2.45.2
>
> commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
> intr
commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
introduced 'default_cpu_version' for PCMachineClass. This created three
categories of CPU models:
- Most unversioned CPU models would use version 1 by default.
- For machines 4.0.1 and older that do not support cpu model aliase
> diff --git a/rust/qemu-api/Cargo.toml b/rust/qemu-api/Cargo.toml
> index 57747bc934..bc0393add4 100644
> --- a/rust/qemu-api/Cargo.toml
> +++ b/rust/qemu-api/Cargo.toml
> @@ -25,6 +25,7 @@ version_check = "~0.9"
> default = ["debug_cell"]
> allocator = []
> debug_cell = []
> +system= []
With
> +use crate::driver::{block_driver, BdrvChild, BlockDriver, Mapping,
> MappingTarget, Request};
> +use crate::SizedIoBuffer;
> +use qemu_api::bindings;
it's better to list all items from bindings here, which helps in understanding
which parts will need a wrapper added later.
> +use qemu_api::er
> +impl BdrvChild {
> +/// Creates a new child reference from a `BlockdevRef`.
> +pub unsafe fn new(
> +parent: *mut bindings::BlockDriverState,
> +bref: *mut bindings::BlockdevRef,
> +errp: *mut *mut bindings::Error,
> +) -> Option {
> +unsafe {
> +
> +/// Use QEMU's event loops to run a Rust [`Future`] to completion and return
> its result.
> +///
> +/// This function must be called in coroutine context. If the future isn't
> ready yet, it yields.
> +pub fn qemu_co_run_future(future: F) -> F::Output {
> +let waker = Waker::from(Arc::new
On 19/02/2025 20.23, Philippe Mathieu-Daudé wrote:
Not all platforms use the '.so' suffix for shared libraries,
which is how plugins are built. Use the recently introduced
dso_suffix() helper to get the proper host suffix.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2804
Suggested-by
On 19/02/2025 20.23, Philippe Mathieu-Daudé wrote:
Introduce a helper to get the default shared library
suffix used on the host.
Suggested-by: Pierrick Bouvier
Signed-off-by: Philippe Mathieu-Daudé
---
tests/functional/qemu_test/__init__.py | 2 +-
tests/functional/qemu_test/cmd.py | 6
Hi Cedric,
> Subject: Re: [PATCH v3 13/28] hw/intc/aspeed: Add Support for AST2700
> INTCIO Controller
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > Introduce a new ast2700 INTCIO class to support AST2700 INTCIO.
> > Added new register definitions for INTCIO, including enable and status
> > register
Hi Cedric,
> Subject: Re: [PATCH v3 01/28] hw/intc/aspeed: Support setting different
> memory and register size
>
> Hello Jamin,
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > According to the AST2700 datasheet, the INTC(CPU DIE) controller has
> > 16KB
> > (0x4000) of register space, and the INTCI
Move the code of calculation of sanitize duration into function
for usability by other sanitize routines
Estimate times based on:
https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
Signed-off-by: Davidlohr Bueso
Signed-off-by: Vinayak Holikatti
---
hw/cxl/cxl-mailbox-utils.c
CXL spec 3.2 section 8.2.10.9.5.3 describes media operations commands.
CXL devices supports media operations Sanitize and Write zero command.
Signed-off-by: Vinayak Holikatti
---
hw/cxl/cxl-mailbox-utils.c | 210 +++-
include/hw/cxl/cxl_device.h | 4 +
2 files
CXL spec 3.2 section 8.2.10.9.5.3 describes media operations commands.
CXL devices supports media operations discovery command.
Signed-off-by: Vinayak Holikatti
---
hw/cxl/cxl-mailbox-utils.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/hw/cxl/cxl-
CXL CCI media operations commands implmented as per CXL Specification
3.2 8.2.10.9.5.3
1) General(00h) - Discovery (00h)
2) Sanitize(01h - Sanitize (00h)
Write zeros (01h)
The patches are generated against the Johnathan's tree
https://gitlab.com/jic23/qemu.git and branch cxl-2024
Hi Cedric,
> Subject: Re: [PATCH v3 00/28] Support AST2700 A1
>
> Hello Jamin,
>
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > v1:
> > 1. Refactor INTC model to support both INTC0 and INTC1.
> > 2. Support AST2700 A1.
> > 3. Create ast2700a0-evb machine.
> >
> > v2:
> >To streamline the
On Thu, 20 Feb 2025 04:24:13 +
"Duan, Zhenzhong" wrote:
> >-Original Message-
> >From: Alex Williamson
> >Subject: Re: [RFC 0/2] hw/vfio/pci: Prevent BARs from being dma mapped in
> >d3hot state
> >
> >On Wed, 19 Feb 2025 18:58:58 +0100
> >Eric Auger wrote:
> >
> >> Since kernel c
>-Original Message-
>From: Alex Williamson
>Subject: Re: [RFC 0/2] hw/vfio/pci: Prevent BARs from being dma mapped in
>d3hot state
>
>On Wed, 19 Feb 2025 18:58:58 +0100
>Eric Auger wrote:
>
>> Since kernel commit:
>> 2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
>> in
Getting the GSource for the AioContext stops fdmon-io_uring from working
because it is not compatible with the glib event loop. Defer the GSource
code until the glib event loop is actually used. For typical IOThreads
this may never be the case and we can use fdmon-io_uring.
Signed-off-by: Stefan H
Hi Cedric,
>
> It's good practice to add "No functional change".
>
Thanks for review and suggestion
Will add "No functional change" in commit log.
Jamin
>
> Looks good to me.
>
>
> Reviewed-by: Cédric Le Goater
>
> Thanks,
>
> C.
>
>
>
> >
> > Signed-off-by: Jamin Lin
> > ---
> >
Hi Cedric,
>
> It's good practice to add "No functional change".
>
> Reviewed-by: Cédric Le Goater
>
> Thanks,
>
> C.
>
Thanks for your review and suggestion.
I will add "No functional change" in commit log.
Jamin
>
> > Signed-off-by: Jamin Lin
> > ---
> > hw/intc/aspeed_intc.c | 62
On 19/2/25 17:33, Chenyi Qiang wrote:
On 2/19/2025 11:49 AM, Alexey Kardashevskiy wrote:
On 19/2/25 12:20, Chenyi Qiang wrote:
On 2/18/2025 5:19 PM, Alexey Kardashevskiy wrote:
[..]
diff --git a/include/system/memory-attribute-manager.h b/include/
system/memory-attribute-manager
For LoongArch th min tlb_ps is 12(4KB), for TLB code,
the tlb_ps may be 0,this may case UndefinedBehavior
Add a check-tlb_ps fuction to check tlb_ps, when use
csrwr insn to write CSR_PWCL PTEBASE, check the PTBASE, and when
use csrwr insn to write STLBPS, check the tlb_ps value.
Signed-off-by: Son
On 2025/2/12 下午3:30, Philippe Mathieu-Daudé wrote:
On 12/2/25 02:56, Xianglai Li wrote:
When the KVM_REG_LOONGARCH_VCPU_RESET command word
is sent to the kernel through the kvm_set_one_reg interface,
the parameter source needs to be a legal address,
otherwise the kernel will return an error and
On 19/02/2025 21:23, Peter Xu wrote:
>> I tried to kill RAM_SAVE_CONTROL_NOT_SUPP, but It seems it doesn't need to
>> touch any postcopy logic
>> "in the QMP migrate / migrate_incoming cmd, at
>> migration_channels_and_transport_compatible()"
>>
>> Is there something I might have overlooked?
>
On Wed, Feb 19, 2025 at 07:12:23PM +0300, Vitalii Mordan wrote:
> TSAN reports a potential data race on the state field of
> ThreadPoolElement. This is fixed by using atomic access to the field.
The tsan output from the bug report:
WARNING: ThreadSanitizer: data race (pid=787043)
Write of size
From: "Maciej S. Szmigiero"
Update the VFIO documentation at docs/devel/migration describing the
changes brought by the multifd device state transfer.
Signed-off-by: Maciej S. Szmigiero
---
docs/devel/migration/vfio.rst | 80 +++
1 file changed, 71 insertions(+)
Il mer 19 feb 2025, 14:02 Kevin Wolf ha scritto:
> > Likewise, even BochsImage should not need a standard Rust Arc.
> > However you need to add your own block::Arc and map
> Clone/Drop to
> > bdrv_ref/bdrv_unref. Then BochsImage can use block::Arc; this
> > makes it even clearer that Mapping sho
Philippe Mathieu-Daudé writes:
> Log FIFO use (availability and depth).
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Am 18. Februar 2025 10:33:26 UTC schrieb Peter Maydell
:
>On Mon, 17 Feb 2025 at 20:21, Bernhard Beschow wrote:
>>
>>
>>
>> Am 17. Februar 2025 13:35:04 UTC schrieb Peter Maydell
>> :
>> >On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>> >>
>> >> While at it and since they are user-cre
We shouldn't receive characters when the full UART or its
receiver is disabled. However we don't want to break the
possibly incomplete "my first bare metal assembly program"s,
so we choose to simply display a warning when this occurs.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu
On Wed, Feb 19, 2025 at 10:19:14PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Instead of comment
> "Keep this type consistent with the nbd-server-start arguments", we
> can simply merge these things.
>
> Note that each field of new base already has "since" tag, equal in both
> original copies. S
In the IOCanReadHandler sh_serial_can_receive(), if the Serial
Control Register 'Receive Enable' bit is set (bit 4), then we
returns a size of (1 << 4) which happens to be equal to 16,
so effectively SH_RX_FIFO_LENGTH.
The IOReadHandler, sh_serial_receive1() takes care to receive
multiple chars, b
While we model a 32-elements RX FIFO since the PL011 model was
introduced in commit 988f2442971 ("hw/char/imx_serial: Implement
receive FIFO and ageing timer") we only read 1 char at a time!
Have the IOCanReadHandler handler return how many elements are
available, and use that in the IOReadHandler
On Wed, 19 Feb 2025 11:58:44 -0700
Alex Williamson wrote:
> On Wed, 19 Feb 2025 18:58:58 +0100
> Eric Auger wrote:
>
> > Since kernel commit:
> > 2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
> > in D3hot power state")
> > any attempt to do an mmap access to a BAR when the devi
Introduce 'fifo_depth' and 'fifo_available' local variables
to better express the 'r' variable use.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/char/pl011.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index 60cea1d9a16..bcd516d682d
On 19/2/25 21:30, Pierrick Bouvier wrote:
Hi Philippe,
On 2/19/25 11:23, Philippe Mathieu-Daudé wrote:
Pierrick kindly helped me to resolve this issue which ended
being trivial (to him!). Not tested on Windows so far.
I'm still having some meson dependency problem, even on Linux:
$ make ch
While we model a 8-elements RX FIFO since the PL011 model was
introduced in commit 97398d900ca ("bcm2835_aux: add emulation
of BCM2835 AUX block") we only read 1 char at a time!
Have the IOCanReadHandler handler return how many elements are
available, and use that in the IOReadHandler handler.
Si
"Chaney, Ben" writes:
> Hello Steve,
>
> Thank you for posting the qemu cpr-transfer patches on qemu-devel. I am
> experimenting with them, and I noticed that cpr-transfer is failing on some
> qemu machine types. cpr-transfer is working for me on the microvm machine
> type but failing on q35 a
While we model a 16-elements RX FIFO since the PL011 model was
introduced in commit cdbdb648b7c ("ARM Versatile Platform Baseboard
emulation"), we only read 1 char at a time!
Have the IOCanReadHandler handler return how many elements are
available, and use that in the IOReadHandler handler.
Examp
Defines FIFO_DEPTH and use it, fixing coding style.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/char/mcf_uart.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/char/mcf_uart.c b/hw/char/mcf_uart.c
index 980a12fcb7d..95f269ee9b7 100644
--- a/hw/char/mcf_uart.c
+
Log FIFO use (availability and depth).
Signed-off-by: Philippe Mathieu-Daudé
---
hw/char/pl011.c | 10 ++
hw/char/trace-events | 7 ---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index bcd516d682d..148a7d0dc60 100644
--- a/
While we model a 4-elements RX FIFO since the PL011 model
was introduced in commit 20dcee94833 ("MCF5208 emulation"),
we only read 1 char at a time!
Have the IOCanReadHandler handler return how many elements are
available, and use that in the IOReadHandler handler.
Signed-off-by: Philippe Mathieu
Some UART devices implement a RX FIFO but their code
(via IOCanReadHandler) only return a size of 1 element,
while we can receive more chars.
This series takes advantage of the full depth.
Inspired by pm215 chat comment on yesterday's community
meeting on the PL011 Rust implementation description
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the target QEMU to allocate unlimited amounts of memory
for buffers-in-flight.
Since this is not expected to b
From: "Maciej S. Szmigiero"
Read packet header first so in the future we will be able to
differentiate between a RAM multifd packet and a device state multifd
packet.
Since these two are of different size we can't read the packet body until
we know which packet type it is.
Reviewed-by: Fabiano
From: "Maciej S. Szmigiero"
Add VFIOStateBuffer(s) types and the associated methods.
These store received device state buffers and config state waiting to get
loaded into the device.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multifd.c | 54 +
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and instance id.
Reviewed-by: Fabiano Rosas
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
includ
From: "Maciej S. Szmigiero"
DEFINE_PROP_ON_OFF_AUTO() property isn't runtime-mutable so using it
would mean that the source VM would need to decide upfront at startup
time whether it wants to do a multifd device state transfer at some
point.
Source VM can run for a long time before being migrate
From: "Maciej S. Szmigiero"
All callers to migration_incoming_state_destroy() other than
postcopy_ram_listen_thread() do this call with BQL held.
Since migration_incoming_state_destroy() ultimately calls "load_cleanup"
SaveVMHandlers and it will soon call BQL-sensitive code it makes sense
to alw
From: "Maciej S. Szmigiero"
Add vfio_multifd_transfer_supported() function that tells whether the
multifd device state transfer is supported.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multifd.c | 6 ++
hw/vfio/migration-multifd.h | 2 ++
2 files changed, 8 insertions(+)
dif
From: "Maciej S. Szmigiero"
multifd_send() function is currently not thread safe, make it thread safe
by holding a lock during its execution.
This way it will be possible to safely call it concurrently from multiple
threads.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
migrat
From: "Maciej S. Szmigiero"
Since it's important to finish loading device state transferred via the
main migration channel (via save_live_iterate SaveVMHandler) before
starting loading the data asynchronously transferred via multifd the thread
doing the actual loading of the multifd transferred d
From: "Maciej S. Szmigiero"
Automatic memory management helps avoid memory safety issues.
Reviewed-by: Fabiano Rosas
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
migration/qemu-file.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/qemu-file.h b/migration/qemu
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to transfer the
particular device state via multifd channels when live migrating that
device.
It defaults to AUTO, which means that VFIO device state transfer via
multifd channels is attempted in configurations that
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.h | 4 ++
migration/meson.build|
Hello Steve,
Thank you for posting the qemu cpr-transfer patches on qemu-devel. I am
experimenting with them, and I noticed that cpr-transfer is failing on some
qemu machine types. cpr-transfer is working for me on the microvm machine type
but failing on q35 and pc-i440fx. When running in those
From: "Maciej S. Szmigiero"
This SaveVMHandler helps device provide its own asynchronous transmission
of the remaining data at the end of a precopy phase via multifd channels,
in parallel with the transfer done by save_live_complete_precopy handlers.
These threads are launched only when multifd
The attachment "Fix qemu-aarch64-static segfaults" seems to be a patch.
If it isn't, please remove the "patch" flag from the attachment, remove
the "patch" tag, and if you are a member of the ~ubuntu-reviewers,
unsubscribe the team.
[This is an automated message performed by a Launchpad user owned
From: "Maciej S. Szmigiero"
This way they can also be referenced in other translation
units than migration.c.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 17 -
include/hw/vfio/vfio-common.h | 17 +
2 files changed, 17 insertions(+), 17
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating its
position in the stream.
The raw device state data is save
From: "Maciej S. Szmigiero"
Load device config received via multifd using the existing machinery
behind vfio_load_device_config_state().
Also, make sure to process the relevant main migration channel flags.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multifd.c | 47
From: "Maciej S. Szmigiero"
This property allows configuring whether to start the config load only
after all iterables were loaded.
Such interlocking is required for ARM64 due to this platform VFIO
dependency on interrupt controller being loaded first.
The property defaults to AUTO, which means
From: "Maciej S. Szmigiero"
So it can be safety accessed from multiple threads.
This variable type needs to be changed to unsigned long since
32-bit host platforms lack the necessary addition atomics on 64-bit
variables.
Using 32-bit counters on 32-bit host platforms should not be a problem
in
From: "Maciej S. Szmigiero"
Add support for VFIOMultifd data structure that will contain most of the
receive-side data together with its init/cleanup methods.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multifd.c | 33 +
hw/vfio/migration-multifd.
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread inside save_live_complete_precopy_thread handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler depending on the
x-migration-multifd-tra
From: "Maciej S. Szmigiero"
Add a hw_compat entry for recently added x-migration-multifd-transfer VFIO
property.
Signed-off-by: Maciej S. Szmigiero
---
hw/core/machine.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 21c3bde92f08..d0a87f5ccbaa 1
From: "Maciej S. Szmigiero"
And rename existing load_device_config_state trace event to
load_device_config_state_end for consistency since it is triggered at the
end of loading of the VFIO device config state.
This way both the start and end points of particular device config
loading operation (
From: "Maciej S. Szmigiero"
This way bytes_transferred can also be incremented in other translation
units than migration.c.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 7 ++-
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
di
From: Peter Xu
The newly introduced device state buffer can be used for either storing
VFIO's read() raw data, but already also possible to store generic device
states. After noticing that device states may not easily provide a max
buffer size (also the fact that RAM MultiFDPages_t after all als
From: "Maciej S. Szmigiero"
This QEMU_VM_COMMAND sub-command and its switchover_start SaveVMHandler is
used to mark the switchover point in main migration stream.
It can be used to inform the destination that all pre-switchover main
migration stream data has been sent/received so it can start to
From: "Maciej S. Szmigiero"
Add basic types and flags used by VFIO multifd device state transfer
support.
Since we'll be introducing a lot of multifd transfer specific code,
add a new file migration-multifd.c to home it, wired into main VFIO
migration code (migration.c) via migration-multifd.h h
From: "Maciej S. Szmigiero"
Automatic memory management helps avoid memory safety issues.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
include/qapi/error.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/qapi/error.h b/include/qapi/error.h
index f5fe2162623e..41e
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations don't block the rest of the migration process.
Add a migration core managed thread pool to facilitate this use c
From: "Maciej S. Szmigiero"
Since device state transfer via multifd channels requires multifd
channels with packets and is currently not compatible with multifd
compression add an appropriate query function so device can learn
whether it can actually make use of it.
Reviewed-by: Fabiano Rosas
R
From: "Maciej S. Szmigiero"
Add a basic support for receiving device state via multifd channels -
channels that are shared with RAM transfers.
Depending whether MULTIFD_FLAG_DEVICE_STATE flag is present or not in the
packet header either device state (MultiFDPacketDeviceState_t) or RAM
data (exi
From: "Maciej S. Szmigiero"
This way if there are fields there that needs explicit disposal (like, for
example, some attached buffers) they will be handled appropriately.
Add a related assert to multifd_set_payload_type() in order to make sure
that this function is only used to fill a previously
From: "Maciej S. Szmigiero"
It's possible for {load,save}_cleanup SaveVMHandlers to get called without
the corresponding {load,save}_setup handler being called first.
One such example is if {load,save}_setup handler of a proceeding device
returns error.
In this case the migration core cleanup co
From: "Maciej S. Szmigiero"
This function name conflicts with one used by a future generic thread pool
function and it was only used by one test anyway.
Update the trace event name in thread_pool_submit_aio() accordingly.
Acked-by: Fabiano Rosas
Reviewed-by: Cédric Le Goater
Reviewed-by: Pete
From: "Maciej S. Szmigiero"
These names conflict with ones used by future generic thread pool
equivalents.
Generic names should belong to the generic pool type, not specific (AIO)
type.
Acked-by: Fabiano Rosas
Reviewed-by: Cédric Le Goater
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigi
From: "Maciej S. Szmigiero"
Migration code wants to manage device data sending threads in one place.
QEMU has an existing thread pool implementation, however it is limited
to queuing AIO operations only and essentially has a 1:1 mapping between
the current AioContext and the AIO ThreadPool in us
From: "Maciej S. Szmigiero"
This is an updated v5 patch series of the v4 series located here:
https://lore.kernel.org/qemu-devel/cover.1738171076.git.maciej.szmigi...@oracle.com/
Changes from v3:
* Use "unsigned long" for VFIO bytes transferred counter to fixes
test issues on 32-bit platforms.
Hi Philippe,
On 2/19/25 11:23, Philippe Mathieu-Daudé wrote:
Pierrick kindly helped me to resolve this issue which ended
being trivial (to him!). Not tested on Windows so far.
I'm still having some meson dependency problem, even on Linux:
$ make check-functional-aarch64
...
Traceback
Since kernel commit:
2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
in D3hot power state")
any attempt to do an mmap access to a BAR when the device is in d3hot
state will generate a fault.
On system_powerdown, if the VFIO device is translated by an IOMMU,
the device is moved to D3
On 2/19/25 11:23, Philippe Mathieu-Daudé wrote:
Not all platforms use the '.so' suffix for shared libraries,
which is how plugins are built. Use the recently introduced
dso_suffix() helper to get the proper host suffix.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2804
Suggested-by: P
Prasad Pandit writes:
> Hello Fabiano,
>
> On Tue, 18 Feb 2025 at 19:52, Fabiano Rosas wrote:
>> Do you concede that this code has a hidden assumption? Either that
>> migrate_multifd() != migrate_postcopy_preempt() or that multifd channels
>> must be set up before postcopy preempt channel? Becau
On 2/19/25 11:23, Philippe Mathieu-Daudé wrote:
Introduce a helper to get the default shared library
suffix used on the host.
Suggested-by: Pierrick Bouvier
Signed-off-by: Philippe Mathieu-Daudé
---
tests/functional/qemu_test/__init__.py | 2 +-
tests/functional/qemu_test/cmd.py | 6 ++
Introduce a helper to get the default shared library
suffix used on the host.
Suggested-by: Pierrick Bouvier
Signed-off-by: Philippe Mathieu-Daudé
---
tests/functional/qemu_test/__init__.py | 2 +-
tests/functional/qemu_test/cmd.py | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-
Not all platforms use the '.so' suffix for shared libraries,
which is how plugins are built. Use the recently introduced
dso_suffix() helper to get the proper host suffix.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2804
Suggested-by: Pierrick Bouvier
Suggested-by: Daniel P. Berrangé
Pierrick kindly helped me to resolve this issue which ended
being trivial (to him!). Not tested on Windows so far.
I'm still having some meson dependency problem, even on Linux:
$ make check-functional-aarch64
...
Traceback (most recent call last):
File "python/qemu/qmp/protocol.py", li
Instead of comment
"Keep this type consistent with the nbd-server-start arguments", we
can simply merge these things.
Note that each field of new base already has "since" tag, equal in both
original copies. So "since" information is saved.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
v2: reb
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/2072564
Title:
qemu-aarch64-static segfaults running ldconfig.real (amd64 host)
Status in QEMU:
On Wed, 19 Feb 2025 18:58:58 +0100
Eric Auger wrote:
> Since kernel commit:
> 2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
> in D3hot power state")
> any attempt to do an mmap access to a BAR when the device is in d3hot
> state will generate a fault.
>
> On system_powerdown, if
NPCM8XX adds a few new registers and have a different set of reset
values to the CLK modules. This patch supports them.
This patch doesn't support the new clock values generated by these
registers. Currently no modules use these new clock values so they
are not necessary at this point.
Implementat
NPCM7XX and NPCM8XX have a different set of GCRs and the GCR module
needs to fit both. This commit changes the name of the GCR module.
Future commits will add the support for NPCM8XX GCRs.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/meson.build | 2 +-
These 2 values are different between NPCM7XX and NPCM8XX
CLKs. So we add them to the class and assign different values
to them.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_clk.c | 18 --
hw/misc/npcm_gcr.c | 2 ++
include/hw/misc/npcm_clk.h
This allows different FIUs to have different flash sizes, useful
in NPCM8XX which has multiple different sized FIU modules.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
Reviewed-by: Philippe Mathieu-Daude
---
hw/arm/npcm7xx.c | 6 ++
hw/ssi/npcm7xx_fiu.c | 16 +
Changes since v4:
1. Bump vmstate versions on NPCM CLK and GCR modules.
2. Remove "hw/boards.h" include in npcm8xx.h and add it in npcm8xx*.c
3. Use cpu_to_le32 instead of tswap32 in npcm8xx.c
Changes since v3:
1. Removed REGS_END constants according to code review.
2. Added a few asserts accord
NPCM8XX boot block stores the DRAM size in SCRPAD_B register in GCR
module. Since we don't simulate a detailed memory controller, we
need to store this information directly similar to the NPCM7XX's
INCTR3 register.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c
The PCS exists in NPCM8XX's GMAC1 and is used to control the SGMII
PHY. This implementation contains all the default registers and
the soft reset feature that are required to load the Linux kernel
driver. Further features have not been implemented yet.
Signed-off-by: Hao Wu
Reviewed-by: Peter May
1 - 100 of 217 matches
Mail list logo
