When a memory device, such as CXL1.1 type3 memory, is emulated as
normal memory (E820_TYPE_RAM), the memory device is indistinguishable
from normal DRAM in terms of memory tiering with the current implementation.
The current memory tiering assigns all detected normal memory nodes
to the same DRAM t
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c | 20 ++--
The current implementation treats emulated memory devices, such as
CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
(E820_TYPE_RAM). However, these emulated devices have different
characteristics than traditional DRAM, making it important to
distinguish them. Thus, we mod
"Ho-Ren (Jack) Chuang" writes:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics than traditional DRAM, making it im
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
> -Original Message-
> From: Taylor Simpson
> Sent: Wednesday, March 6, 2024 9:23 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsi
On Thu, Mar 28, 2024 at 6:23 PM wrote:
> From: Marc-André Lureau
>
> ../migration/dirtyrate.c:186:5: error: ‘records’ may be used uninitialized
> [-Werror=maybe-uninitialized]
> ../migration/dirtyrate.c:168:12: error: ‘gen_id’ may be used uninitialized
> [-Werror=maybe-uninitialized]
> ../migrat
On 28/03/2024 23:01, Peter Xu wrote:
> On Thu, Mar 28, 2024 at 11:18:04AM -0300, Fabiano Rosas wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> The whole RDMA subsystem was deprecated in commit e9a54265f5
>>> ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem")
>>> released in v8.2.
>>
> -Original Message-
> From: Taylor Simpson
> Sent: Thursday, February 1, 2024 4:34 AM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylor
> -Original Message-
> From: Taylor Simpson
> Sent: Thursday, February 1, 2024 4:34 AM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylor
> -Original Message-
> From: Peter Xu
> Sent: Thursday, March 28, 2024 11:16 PM
> To: Liu, Yuan1
> Cc: Daniel P. Berrangé ; faro...@suse.de; qemu-
> de...@nongnu.org; hao.xi...@bytedance.com; bryan.zh...@bytedance.com; Zou,
> Nanhai
> Subject: Re: [PATCH v5 5/7] migration/multifd: implem
> -Original Message-
> From: Taylor Simpson
> Sent: Thursday, February 1, 2024 4:34 AM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> Marco Liebel (QUIC) ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylor
On Thu, Mar 28, 2024 at 5:59 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_RAM). However, these emulated devices have
On Thu, Mar 28, 2024 at 12:12 PM Jason Wang wrote:
>
> On Wed, Mar 27, 2024 at 5:33 PM Cindy Lu wrote:
> >
> > On Wed, Mar 27, 2024 at 5:12 PM Jason Wang wrote:
> > >
> > > On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu wrote:
> > > >
> > > > On Wed, Mar 27, 2024 at 3:54 PM Jason Wang wrote:
> > > >
Hi Michael,
>-Original Message-
>From: Michael S. Tsirkin
>Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
>sync host IOMMU cap/ecap
>
>On Mon, Mar 18, 2024 at 02:20:50PM +0100, Eric Auger wrote:
>> Hi Michael,
>>
>> On 3/13/24 12:17, Michael S. Tsirkin wrote:
>> > O
On Fri, Mar 29, 2024 at 11:02 AM Cindy Lu wrote:
>
> On Thu, Mar 28, 2024 at 12:12 PM Jason Wang wrote:
> >
> > On Wed, Mar 27, 2024 at 5:33 PM Cindy Lu wrote:
> > >
> > > On Wed, Mar 27, 2024 at 5:12 PM Jason Wang wrote:
> > > >
> > > > On Wed, Mar 27, 2024 at 4:28 PM Cindy Lu wrote:
> > > >
When using the post-copy preemption feature to perform post-copy live
migration, the below scenario could lead to a deadlock and the migration
will never finish:
- Source connect() the preemption channel in postcopy_start().
- Source and the destination side TCP stack finished the 3-way handshak
> -Original Message-
> From: Peter Xu
> Sent: Thursday, March 28, 2024 11:22 PM
> To: Liu, Yuan1
> Cc: faro...@suse.de; qemu-devel@nongnu.org; hao.xi...@bytedance.com;
> bryan.zh...@bytedance.com; Zou, Nanhai
> Subject: Re: [PATCH v5 0/7] Live Migration With IAA
>
> On Thu, Mar 28, 2024
Hi Daniel,
On 3/25/24 16:55, Daniel P. Berrangé wrote:
On Mon, Mar 25, 2024 at 01:35:58PM +0800, Shaoqin Huang wrote:
Hi Daniel,
Thanks for your reviewing. I see your comments in the v7.
I have some doubts about what you said about the QAPI. Do you want me to
convert the current design into t
On 3/28/24 20:55, Peter Maydell wrote:
On Wed, 27 Mar 2024 at 05:41, Harsh Prateek Bora wrote:
On 3/26/24 21:32, Peter Maydell wrote:
On Tue, 12 Mar 2024 at 17:11, Nicholas Piggin wrote:
From: Harsh Prateek Bora
Introduce the nested PAPR hcalls:
- H_GUEST_GET_STATE which is us
Check for flag bit in H_GUEST_GETSET_STATE_FLAG_GUEST_WIDE need to use
bitwise NOT operator to ensure no other flag bits are set.
Reported by Coverity as CID 1540008, 1540009.
Reported-by: Peter Maydell
Signed-off by: Harsh Prateek Bora
---
hw/ppc/spapr_nested.c | 2 +-
1 file changed, 1 insert
On 2024/03/29 6:44, BALATON Zoltan wrote:
On Thu, 28 Mar 2024, Rene Engel wrote:
I wanted to discuss this topic with you again, there was already a
patch series that worked well under Qemu with
Pegasos2/AmigaOneXe/Same460 and AmigaOs4.1. The option zoom-to-fit=on
should be used to adjust all re
The current implementation treats emulated memory devices, such as
CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
(E820_TYPE_RAM). However, these emulated devices have different
characteristics than traditional DRAM, making it important to
distinguish them. Thus, we mod
When a memory device, such as CXL1.1 type3 memory, is emulated as
normal memory (E820_TYPE_RAM), the memory device is indistinguishable
from normal DRAM in terms of memory tiering with the current implementation.
The current memory tiering assigns all detected normal memory nodes
to the same DRAM t
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c | 20 ++--
I noticed the issue in the commit message 'ffvat' should be 'vvfat',
I'll fix it in the next version.
On Thu, Mar 28, 2024 at 04:11:27AM +0800, Amjad Alsharafi wrote:
> When reading with `read_cluster` we get the `mapping` with
> `find_mapping_for_cluster` and then we call `open_file` for this
> m
- target_ipc_perm::mode and target_ipc_perm::__seq fields are 32-bit wide
on xtensa and thus need to use tswap32
- target_msqid_ds::msg_*time field pairs are reversed on big-endian
xtensa
Both issues result in incorrect conversion results on big-endian xtensa
targets, spotted by the libc-test h
If poison is detected(reported from cxl memdev), OS should be notified to
handle it. So, introduce this helper function for later use:
1. translate DPA to HPA;
2. enqueue records into memory_failure's work queue;
Signed-off-by: Shiyang Ruan
---
Currently poison injection from debugfs always
Currently driver only traces cxl events, poison injection (for both vmem
and pmem type) on cxl memdev is silent. OS needs to be notified then it
could handle poison range in time. Per CXL spec, the device error event
could be signaled through FW-First and OS-First methods.
So, add poison event h
Changes:
RFCv1 -> RFCv2:
1. update commit message of PATCH 1
2. use memory_failure_queue() instead of MCE
3. also report poison in debugfs when injecting poison
4. correct DPA->HPA logic:
find memdev's endpoint decoder to find the region it belongs to
5. distinguish transaction_type of GMER, o
The length of Physical Address in General Media Event Record/DRAM Event
Record is 64-bit, so the field mask should be defined as such length.
Otherwise, this causes cxl_general_media and cxl_dram tracepoints to
mask off the upper-32-bits of DPA addresses. The cxl_poison event is
unaffected.
If use
Poison injection from debugfs is silent too. Add calling
cxl_mem_report_poison() to make it able to do memory_failure().
Signed-off-by: Shiyang Ruan
---
drivers/cxl/core/memdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
index e976
The GMER only has "Physical Address" field, no such one indicates length.
So, when a poison event is received, we could use GET_POISON_LIST command
to get the poison list. Now driver has cxl_mem_get_poison(), so
reuse it and add a parameter 'bool report', report poison record to MCE
if set true.
The transaction types are defined in General Media Event Record/DRAM Event
per CXL rev 3.0 Section 8.2.9.2.1.1; Table 8-43 and
Section 8.2.9.2.1.2; Table 8-44. Add them for Event Record handler use.
Signed-off-by: Shiyang Ruan
---
include/linux/cxl-event.h | 17 +++--
1 file changed
201 - 241 of 241 matches
Mail list logo
