On 28/09/2023 21:19, Markus Armbruster wrote:
> qemu_rdma_data_init() neglects to set an Error when it fails because
> @host_port is null. Fortunately, no caller passes null, so this is
> merely a latent bug. Drop the flawed code handling null argument.
>
> Signed-off-by: Markus Armbruster
R
On 04/10/2023 02:57, Juan Quintela wrote:
> commit c638f66121ce30063fbf68c3eab4d7429cf2b209
> Author: Juan Quintela
> Date: Tue Oct 3 20:53:38 2023 +0200
>
> migration: Non multifd migration don't care about multifd flushes
>
> RDMA was having trouble because
> migrate_mul
On 12/10/2023 04:55, Juan Quintela wrote:
> RDMA was having trouble because
> migrate_multifd_flush_after_each_section() can only be true or false,
> but we don't want to send any flush when we are not in multifd
> migration.
>
> CC: Fabiano Rosas Fixes: 294e5a4034e81b3d8db03b4e0f691386f20d6ed3
On 30/05/2023 23:14, Jonathan Cameron via wrote:
> On Mon, 29 May 2023 15:59:56 +0800
> Li Zhijian wrote:
>
>> Only 'fw' pointer is marked as g_autofree, so we shoud free other
>> resource manually in error path.
>>
> Good spot.
>
> Patch title typo
> hw/cxl:>
OMG, it was the 2nd time i have
On 31/05/2023 13:45, Philippe Mathieu-Daudé wrote:
> Hi Li,
>
> On 31/5/23 04:34, Li Zhijian wrote:
>> Only 'fw' pointer is marked as g_autofree, so we shoud free other
>> resource manually in error path.
>>
>> Signed-off-by: Li Zhijian
>> ---
>> V2: Delete unnecesarry check
>> ---
>> hw/cxl/
On 31/08/2023 21:25, Markus Armbruster wrote:
> qemu_rdma_save_page() reports polling error with error_report(), then
> succeeds anyway. This is because the variable holding the polling
> status *shadows* the variable the function returns. The latter
> remains zero.
>
> Broken since day one, a
On 19/10/2023 18:50, Jonathan Cameron wrote:
> On Wed, 18 Oct 2023 16:24:07 +0800
> Li Zhijian wrote:
>
>> cache_mem_ops.{read,write}() interprets opaque as
>> CXLComponentState(cxl_cstate) instead of ComponentRegisters(cregs).
>>
>> Fortunately, cregs is the first member of cxl_cstate, so thei
On 12/10/2023 04:35, Juan Quintela wrote:
> Helper to say if we are doing a migration over rdma.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/migration.h | 2 ++
> migration/options.h | 1 +
> migration/migration.c | 1 +
> migrat
On 12/10/2023 04:35, Juan Quintela wrote:
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/rdma.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/migration/rdma.c b/migration/rdma.c
> index d3bba05262..932d4ed
On 12/10/2023 04:35, Juan Quintela wrote:
> Instead of going trhough ram_control_load_hook(), call
> qemu_rdma_registration_handle() directly.
>
s/trhough/through
Reviewed-by: Li Zhijian
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
> ---
> migration/qemu-file.h | 1 -
> migr
On 12/10/2023 04:35, Juan Quintela wrote:
> The only user was rdma, and its use is gone.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/qemu-file.h | 4
> migration/qemu-file.c | 6 --
> migration/rdma.c | 9 -
>
On 12/10/2023 04:35, Juan Quintela wrote:
> Once there:
> - Remove unused data parameter
> - unfold it in its callers
> - change all callers to call qemu_rdma_registration_stop()
> - We need to call QIO_CHANNEL_RDMA() after we check for migrate_rdma()
>
> Reviewed-by: Peter Xu
> Signed-off-by:
On 12/10/2023 04:35, Juan Quintela wrote:
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/qemu-file.h | 17 -
> migration/rdma.h | 16
> migration/ram.c | 2 +-
> 3 files changed, 17 insertion
On 12/10/2023 04:35, Juan Quintela wrote:
> The only user of ram_control_save_page() and save_page() hook was
> rdma. Just move the function to rdma.c, rename it to
> rdma_control_save_page().
>
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
[...]
>
> +int rdma_control_save_page(Q
On 12/10/2023 04:35, Juan Quintela wrote:
> Functions are long enough even without this.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/rdma.h | 12 ++--
> migration/ram.c| 14 +++---
> migration/rdma.c
On 12/10/2023 04:35, Juan Quintela wrote:
> There is only one flag called with: RAM_CONTROL_BLOCK_REG.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/qemu-file.h | 11 ---
> migration/rdma.h | 3 +++
> migration/qemu-file
On 12/10/2023 04:35, Juan Quintela wrote:
> Once there, all the uses are local to the for, so declare the variable
> inside the for statement.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
> ---
> migration/rdma.c | 49 ++--
> 1 file
On 12/10/2023 04:35, Juan Quintela wrote:
> Declare all variables that are only used inside a for loop inside the
> for statement.
>
> This makes clear that they are not used outside of the for loop.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
On 12/10/2023 04:35, Juan Quintela wrote:
> Once there:
> - Remove unused data parameter
> - unfold it in its callers.
> - change all callers to call qemu_rdma_registration_start()
> - We need to call QIO_CHANNEL_RDMA() after we check for migrate_rdma()
>
> Reviewed-by: Peter Xu
> Signed-off-by
On 12/10/2023 04:35, Juan Quintela wrote:
> Change code that is:
>
> int ret;
> ...
>
> ret = foo();
> if (ret[ < 0]?) {
>
> to:
>
> if (foo()[ < 0]) {
>
> Signed-off-by: Juan Quintela
Reviewed-by: Li Zhijian
On 16/10/2023 20:11, Jason Gunthorpe wrote:
> On Sat, Oct 07, 2023 at 03:40:50AM +0000, Zhijian Li (Fujitsu) wrote:
>> +rdma-core
>>
>>
>> Is global variable *errno* reliable when the documentation only states
>> "returns 0 on success, or the value of
On 13/10/2023 16:52, Philippe Mathieu-Daudé wrote:
> On 13/10/23 03:55, Li Zhijian wrote:
>> void cxl_component_register_block_init(Object *obj,
>> CXLComponentState *cxl_cstate,
>> const char *type)
>> {
>> Comp
Jonathan,
There is a new user for cfmw_list now
https://lore.kernel.org/qemu-devel/20240704093404.1848132-1-zhao1@linux.intel.com/
So I think we should drop this patch.
On 02/07/2024 22:34, Jonathan Cameron wrote:
> From: Li Zhijian
>
> There is no user for this member. All '-M cxl-fmw.N
On 05/07/2024 10:15, Zhao Liu wrote:
>> There is a new user for cfmw_list now
>> https://lore.kernel.org/qemu-devel/20240704093404.1848132-1-zhao1@linux.intel.com/
>>
>> So I think we should drop this patch.
> Hi Zhijian,
>
> I'm not a "real" user and that bug was originally found by code r
On 04/07/2024 17:34, Zhao Liu wrote:
> From: Zhao Liu
>
> Guest crashes (Segmentation fault) when getting cxl-fmw property via
> qmp:
>
IMO, it's fair to say "Guest crashes" which generally means the guest kernel
panic etc.
I'd prefer the subject like:
hw/cxl/cxl-host: Fix segmentation fault
On 12/11/2024 16:40, Zhang Chen wrote:
> Signed-off-by: Zhang Chen
Reviewed-by: Li Zhijian
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 095420f8b0..3f10529d9c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
Merry Christmas and a Happy New Year!
And kindly ping...
On 13/12/2024 17:36, Li Zhijian wrote:
> This assertion always happens when we sanitize the CXL memory device.
> $ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
>
> It is incorrect to register an MSIX number beyond the device's ca
>From: Jonathan Cameron
>Sent: Thursday, December 12, 2024 20:02
>
>On Thu, 12 Dec 2024 16:55:33 +0800
>Li Zhijian via wrote:
>
>> This assertion always happens when we sanitize the CXL memory device.
>> $ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
>>
>> It is incorrect to register an M
On 21/01/2025 23:19, Jonathan Cameron wrote:
>>> -msix_uninit_exclusive_bar(pci_dev);
>>> g_free(regs->special_ops);
>>> -err_address_space_free:
>>> +err_msix_uninit:
>>> +msix_uninit_exclusive_bar(pci_dev);
>> This reorder doesn't look correct.
>>
>> Should end up I think as
>> er
On 10/01/2025 23:44, Jonathan Cameron wrote:
> On Fri, 13 Dec 2024 17:36:02 +0800
> Li Zhijian wrote:
>
>> This assertion always happens when we sanitize the CXL memory device.
>> $ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
>>
>> It is incorrect to register an MSIX number beyond the
Cced QEMU,
Hi Fan,
I recalled we had a reboot issue[1] months ago
I guess your issue was caused by some registers not reset during reboot.
[1]
https://lore.kernel.org/linux-cxl/20240409075846.85370-1-lizhij...@fujitsu.com/
On 15/01/2025 04:30, Fan Ni wrote:
> Hi,
>
> Recently, while testing
On 15/01/2025 21:51, Jonathan Cameron wrote:
> On Wed, 15 Jan 2025 15:58:46 +0800
> Li Zhijian wrote:
>
>> Introduce the `CXL_T3_MSIX_VECTOR` enumeration to specify MSIX vector
>> assignments specific to the Type 3 (T3) CXL device.
>>
>> The primary goal of this change is to encapsulate the MSI
On 10/01/2025 13:29, Itaru Kitayama wrote:
> Hi,
> Is anybody working on the CXL emulation on aarch64?
I'm not currently working on the CXL emulation on aarch64.
However, IIRC the CXL maintainer's tree should work.
https://gitlab.com/jic23/qemu/
Thanks
Zhijian
> If there’s a WIP branch, a po
On 16/01/2025 18:50, Jonathan Cameron wrote:
> On Thu, 16 Jan 2025 01:18:28 +
> "Zhijian Li (Fujitsu)" wrote:
>
>> On 15/01/2025 21:51, Jonathan Cameron wrote:
>>> On Wed, 15 Jan 2025 15:58:46 +0800
>>> Li Zhijian wrote:
>>>
&g
Ping
Only if (dsp_count==1 && hdm_for_passthrough==true), the QEMU shouldn't
implement
the HDM decodder for the Host-bridge.
But previous code didn't follow this.
Thanks
Zhijian
On 23/03/2025 16:04, Li Zhijian wrote:
> Reverse the logical condition for HDM passthrough support in
> pci_expander
Please fix this compiling error.
cc -m64 -mcx16 -Ilibcommon.a.p -Isubprojects/libvduse -I../subprojects/libvduse
-I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0
-I/usr/include/glib-2.0 -I/usr
Hi Jonathan,
I apologize for the delayed response; I have just returned from vacation.
On 16/04/2025 00:47, Jonathan Cameron wrote:
> On Mon, 7 Apr 2025 02:59:20 +
> "Zhijian Li (Fujitsu)" wrote:
>
>> Ping
>
> Sorry, I wrote half a reply but then lost it
On 30/04/2025 16:28, Li Zhijian wrote:
>
>
> On 30/04/2025 05:09, Peter Xu wrote:
>> On Thu, Mar 27, 2025 at 10:12:34AM +0800, Li Zhijian wrote:
>>> Recently, we removed ipv6 restriction[0] from RDMA migration, add a
>>> test for it.
>>>
>>> [0]
>>> https://lore.kernel.org/qemu-devel/202503260
On 30/04/2025 05:09, Peter Xu wrote:
> On Thu, Mar 27, 2025 at 10:12:34AM +0800, Li Zhijian wrote:
>> Recently, we removed ipv6 restriction[0] from RDMA migration, add a
>> test for it.
>>
>> [0]
>> https://lore.kernel.org/qemu-devel/20250326095224.9918-1-jinpu.w...@ionos.com/
>>
>> Cc: Jack Wan
On 30/04/2025 16:48, Zhijian Li (Fujitsu) via wrote:
>>> stderr:
>>> qemu-system-x86_64: cannot get rkey
>>> qemu-system-x86_64: error while loading state section id 2(ram)
>>> qemu-system-x86_64: load of migration failed: Operation not permitted
>>
On 19/02/2025 06:40, Peter Xu wrote:
> On Tue, Feb 18, 2025 at 06:03:48PM -0300, Fabiano Rosas wrote:
>> Li Zhijian via writes:
>>
>>> This qtest requirs there is RXE link in the host.
>>>
>>> Here is an example to show how to add this RXE link:
>>> $ ./new-rdma-link.sh
>>> 192.168.22.93
>>>
>>>
On 19/02/2025 06:03, Peter Xu wrote:
> On Tue, Feb 18, 2025 at 05:30:40PM -0300, Fabiano Rosas wrote:
>> Li Zhijian via writes:
>>
>>> Address an error in RDMA-based migration by ensuring RDMA is prioritized
>>> when saving pages in `ram_save_target_page()`.
>>>
>>> Previously, the RDMA protocol
On 14/02/2025 01:59, Fabiano Rosas wrote:
> Remove all instances of _fd_ from the migration generic code. These
> functions have grown over time and the _fd_ part is now just
> confusing.
>
> migration_fd_error() -> migration_error() makes it a little
> vague. Since it's only used for migration_
Fabiano
Thanks for your testing.
On 28/02/2025 21:49, Fabiano Rosas wrote:
> Li Zhijian via writes:
>
>> This qtest requires there is a RDMA(RoCE) link in the host.
>> In order to make the test work smoothly, introduce a
>> scripts/rdma-migration-helper.sh to
>> - setup a new Soft-RoCE(aka RXE)
On 10/03/2025 22:36, Peter Xu wrote:
> On Mon, Mar 10, 2025 at 08:33:14AM +0000, Zhijian Li (Fujitsu) wrote:
>> Hi Stefan,
>>
>> Copied to gitlab CI,
>>
>> On 08/03/2025 16:42, Stefan Hajnoczi wrote:
>>> On Sat, Mar 8, 2025 at 2:01 PM Philip
Hi Fabiano,
A minor improvement inline below,
On 11/03/2025 10:42, Li Zhijian wrote:
> This qtest requires there is a RDMA(RoCE) link in the host.
> In order to make the test work smoothly, introduce a
> scripts/rdma-migration-helper.sh to detect existing RoCE link before
> running the test.
>
Hi Stefan,
Copied to gitlab CI,
On 08/03/2025 16:42, Stefan Hajnoczi wrote:
> On Sat, Mar 8, 2025 at 2:01 PM Philippe Mathieu-Daudé
> wrote:
>>
>> Hi,
>>
>> On 7/3/25 19:15, Fabiano Rosas wrote:
>>> From: Li Zhijian
>>>
>>> This qtest requires there is a RDMA(RoCE) link in the host.
>>> In ord
Hi Philippe,
Thanks for your testing.
On 08/03/2025 14:00, Philippe Mathieu-Daudé wrote:
> Hi,
>
> On 7/3/25 19:15, Fabiano Rosas wrote:
>> From: Li Zhijian
>>
>> This qtest requires there is a RDMA(RoCE) link in the host.
>> In order to make the test work smoothly, introduce a
>> scripts/rdma
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 20/02/2025 23:55, Peter Xu wrote:
> On Thu, Feb 20, 2025 at 05:40:38PM +0800, Li Zhijian wrote:
>> On 19/02/2025 22:11, Peter Xu wrote:
>>> then
>>> in the test it tries to detect rdma link and fetch the ip only
>> It should work without root permission if we just*detect* and*fetc
On 25/02/2025 04:00, Peter Xu wrote:
> On Fri, Feb 21, 2025 at 02:36:11PM +0800, Li Zhijian wrote:
>> Since we have disabled RDMA + postcopy, it's safe to remove
>> the migration_in_postcopy() that follows the migration_rdma().
>>
>> Signed-off-by: Li Zhijian
>> ---
>> migration/ram.c | 2 +-
On 25/02/2025 03:58, Peter Xu wrote:
> On Fri, Feb 21, 2025 at 02:36:09PM +0800, Li Zhijian wrote:
>> Similar to migration_channels_and_transport_compatible(), introduce a
>> new helper migration_capabilities_and_transport_compatible() to check if
>> the capabilites is compatible with the transpo
On 26/02/2025 23:51, Peter Xu wrote:
> On Wed, Feb 26, 2025 at 02:30:42PM +0800, Li Zhijian wrote:
>> control_save_page() is for RDMA only, unfold it to make the code more
>> clear.
>> In addition:
>> - Similar to other branches style in ram_save_target_page(), involve RDMA
>> only if the c
On 25/02/2025 22:48, Peter Xu wrote:
> On Tue, Feb 25, 2025 at 06:37:21AM +0000, Zhijian Li (Fujitsu) wrote:
>>
>>
>> On 25/02/2025 03:58, Peter Xu wrote:
>>> On Fri, Feb 21, 2025 at 02:36:09PM +0800, Li Zhijian wrote:
>>>> Similar to migration_channe
On 09/05/2025 23:32, Peter Xu wrote:
> Does this mean I'll need to setup twice, one for each v?
>
> Even if so, I did this:
>
> ===8<===
> $ sudo ../scripts/rdma-migration-helper.sh setup
> Setup new rdma/rxe wlp0s20f3_rxe for wlp0s20f3 with 192.168.68.123
> $ sudo IP_FAMILY=ipv6 ../scripts/rdm
On 12/05/2025 21:56, Peter Xu wrote:
> On Mon, May 12, 2025 at 02:01:35PM +0800, Li Zhijian wrote:
>> Recently, we removed ipv6 restriction[0] from RDMA migration, add a
>> test for it.
>>
>> [0]
>> https://lore.kernel.org/qemu-devel/20250326095224.9918-1-jinpu.w...@ionos.com/
>>
>> Cc: Jack Wan
On 01/05/2025 05:52, Peter Xu wrote:
>> +#include
>> +#define REQUIRED_MEMLOCK (128 * 1024 * 1024) // 128MB
> How does the 128M come from? Is it correlated to the VM size somehow?
> Btw, migrate_start() says for x86 we use 150MB VM.
Good question, After a brief debugging session, it was discov
On 15/05/2025 04:01, Peter Xu wrote:
> A new parameter "-a" is added to "info migrate" to dump all info, while
> when not specified it only dumps the important ones. When at it, reorg
> everything to make it easier to read for human.
>
> The general rule is:
>
>- Put important things at th
copy=1.39 GiB
> Page Types: normal=367713, zero=41195
>Page Rates (pps): transfer=40900, dirty=4
>Others: dirty_syncs=2, postcopy_req=57503
>
> Cc: Zhijian Li (Fujitsu)
> Suggested-by: Dr. David Alan Gilbert
> Signed-off-by: Peter Xu
Thanks for
On 13/05/2025 19:14, Jonathan Cameron via 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 where we need to iterate through these without being aware of the
> machine type. Just mak
On 13/05/2025 19:14, Jonathan Cameron via wrote:
> To enable these to be found in a fixed order, that order needs
> to be known. This will later be used to sort a list of these
> structures that address map and ACPI table entries are predictable.
>
> Signed-off-by: Jonathan Cameron
Reviewed-
On 13/05/2025 19:14, Jonathan Cameron via wrote:
>
> +hwaddr cxl_fmws_set_memmap(hwaddr base, hwaddr max_addr)
> +{
> +GSList *cfmws_list, *iter;
> +
> +struct cfmw_update_state cfmwss = {
> +.base = base,
> +.maxaddr = max_addr,
> +.update_mmio = false,
> +
On 22/05/2025 05:04, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
>> On Wed, May 21, 2025 at 08:43:37AM +, Zhijian Li (Fujitsu) wrote:
>> [...]
>>>> After this change, sample output (default, no "-a" specified):
>>>>
&
On 21/05/2025 22:03, Peter Xu wrote:
> On Wed, May 21, 2025 at 08:43:37AM +0000, Zhijian Li (Fujitsu) wrote:
> [...]
>>> After this change, sample output (default, no "-a" specified):
>>>
>>> Status: postcopy-active
>>> Time (m
On 22/05/2025 21:16, Peter Xu wrote:
> I followed up with Dave's idea, but then added all entries into it, below.
>
>Status: postcopy-active
>Time (ms): total=40504, setup=14, down=145
>RAM info:
> Throughput (Mbps): 6102.65
> Sizes (KiB):pagesize=4, total=16777992
On 13/06/2025 16:07, Daniel P. Berrangé wrote:
> On Fri, Jun 13, 2025 at 12:40:02PM +0800, Li Zhijian via wrote:
>> This leak was detected by the valgrind.
>>
>> The crs_range_merge() function unconditionally allocated a GPtrArray
>> 'even when range->len was zero, causing an early return without
On 12/06/2025 21:43, 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 where we need to iterate through these without being aware of the
> machine type. Just make the
On 29/05/2025 21:48, Jonathan Cameron via wrote:
> This has been wrong from day 1. For now we only have
> two entries (component and device registers).
Wow, I finally understood this.
>
> The wrong size could lead to arbitrary data off the stack being presented
> in PCIe config space.
>
> S
In patch 2/5, we introduced `cxl_fmws_set_memmap_and_update_mmio()`.
Initially, I assumed patch 3/5 would split
`cxl_fmws_set_memmap_and_update_mmio()` into two steps:
1. Traverse CXLFixedWindow and update `fw->base`.
2. Call `sysbus_mmio_map(SYS_BUS_DEVICE(fw), 0, fw->base)`.
For example (my pe
On 28/05/2025 19:07, Jonathan Cameron via 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 where we need to iterate through these without being aware of the
> machine type. Just mak
On 28/05/2025 19:07, Jonathan Cameron via wrote:
> Jonathan Cameron (5):
>hw/cxl-host: Add an index field to CXLFixedMemoryWindow
>hw/cxl: Make the CXL fixed memory windows devices.
>hw/cxl-host: Allow split of establishing memory address and mmio
> setup.
With above 3 patches +
On 12/06/2025 21:43, Jonathan Cameron wrote:
> To enable these to be found in a fixed order, that order needs to be known.
> This will later be used to sort a list of these structures so that address
> map and ACPI table entries are predictable.
>
> Reviewed-by: Li Zhijian
> Reviewed-by: Fan Ni
101 - 172 of 172 matches
Mail list logo
