eful during the review process we don't
typically want to keep them in the git history for ever!
Otherwise, main comment here is shorten more names.
Jonathan
>
> This v2 patch addresses the feedback from the v1 patch and include some minor
> new changes.
>
> Changes in V2:
&
On Thu, 13 Feb 2025 14:45:58 +0530
Vinayak Holikatti wrote:
> CXL spec 3.1 section 8.2.9.9.5.3 describes media operations commands.
As in previous - please update to the r3.2 spec.
A few comments inline.
Thanks,
Jonathan
> CXL devices supports media operations Sanitize and Write zero c
or style comments inline.
Thanks,
Jonathan
> CXL devices supports media operations discovery command.
>
> Signed-off-by: Vinayak Holikatti
> ---
> hw/cxl/cxl-mailbox-utils.c | 136 +
> 1 file changed, 136 insertions(+)
>
> diff --gi
> > So I'm not keen to change this. Ideally we'd have made this a required
> > parameter from the start, but we didn't and doing so now would result
> > in a backwards compatibility problem.
> >
> > So I think this is kind of a 'won't fix' situation on the qemu side.
> Ok, I see.
>
> Maybe we
icant surgery this would involve, I'd
love to see Mauro's series land first as it cleans up a lot of
how HEST is handled etc.
Jonathan
>
> Gavin Shan (4):
> acpi/ghes: Make ghes_record_cper_errors() static
> acpi/ghes: Use error_report() in ghes_record_cper_errors()
&
e or less reviewed subject to some requested patch reordering and
whilst I haven't checked, seems unlikely that there won't be a
clash with this series (might just be some fuzz)
Jonathan
>
> Gavin Shan (4):
> acpi/ghes: Make ghes_record_cper_errors() static
> acpi/ghes:
lue:
> cci->supported_log_cap[set] = cxl_get_log_cap[set];
As above. This set is the thing I'm suggesting changing.
One general review process thing is it is much more productive
to just crop anything you agree with and just have the discussion
focused on questions etc that are outstanding.
Jonathan
parameter from the start, but we didn't and doing so now would result
in a backwards compatibility problem.
So I think this is kind of a 'won't fix' situation on the qemu side.
Jonathan
>
> Signed-off-by: Yuquan Wang
> ---
> hw/mem/cxl_type3.c | 17 -
&
> >> +static int sanitize_range(CXLType3Dev *ct3d, uint64_t dpa_addr, size_t
> >> length,
> >> + uint8_t fill_value)
> >> +{
> >> +
> >> +MemoryRegion *vmr = NULL, *pmr = NULL;
> >> +uint64_t vmr_size = 0, pmr_size = 0;
> >> +AddressSpace *as = NULL;
> >> +
On Tue, 4 Feb 2025 20:47:49 -0800
Davidlohr Bueso wrote:
> On Mon, 03 Feb 2025, Jonathan Cameron wrote:
>
> >On Tue, 22 Oct 2024 18:00:30 +0100
> >Jonathan Cameron wrote:
> >
> >> On Mon, 21 Oct 2024 20:23:46 -0700
> >> Davidlohr Bueso wrote:
&
On Mon, 3 Feb 2025 11:29:50 +0530
Arpit Kumar wrote:
> Signed-off-by: Arpit Kumar
> Reviewed-by: Alok Rathore
> Reviewed-by: Krishna Kanth Reddy
Likewise, the CEL isn't a dynamic thing. Asking to populate
it makes little sense so the log capability should always
say this is not supported.
are
given before public posting aren't really very useful. Reviews
can mean very different things in different companies / groups within
them. Much prefer to see a final round of review done on the public
mailing list if possible.
Various comments inline.
Jonathan
> ---
> hw/cxl/cxl-m
ick a different log.
Jonathan
> Signed-off-by: Arpit Kumar
> Reviewed-by: Alok Rathore
> Reviewed-by: Krishna Kanth Reddy
> ---
> hw/cxl/cxl-mailbox-utils.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/hw/cxl/cxl-mailbox
o
reflect that.
Great to have you working on these features. Some comments inline.
Main ones are around naming (always tricky!) and suggestion to
handle the arrays of log capabilities as static const pointers.
Thanks,
Jonathan
> ---
> hw/cxl/cxl-ma
On Tue, 4 Feb 2025 14:16:19 +0900
Itaru Kitayama wrote:
> Jonathan,
>
> > On Feb 4, 2025, at 2:30, Jonathan Cameron
> > wrote:
> >
> > Add a single complex case for aarch64 virt machine.
> > Given existing much more comprehensive tests for x86 cover th
Add a single complex case for aarch64 virt machine.
Given existing much more comprehensive tests for x86 cover the
common functionality, a single test should be enough to verify
that the aarch64 part continue to work.
Signed-off-by: Jonathan Cameron
---
tests/qtest/cxl-test.c | 59
machine.
Signed-off-by: Jonathan Cameron
---
include/hw/arm/virt.h| 4 +++
hw/arm/virt-acpi-build.c | 34 +
hw/arm/virt.c| 54
3 files changed, 92 insertions(+)
diff --git a/include/hw/arm/virt.h b/include/hw/arm
my gitlab tree. Note that we need arm support
for some arch specific features in the near future (cache flushing).
Doing kernel development with this need for flexibility on SBSA-ref is not
currently practical. SBSA-ref CXL support is an excellent thing, just
not much use to me for this work.
Th
://lore.kernel.org/linux-cxl/3e84b919-7631-d1db-3e1d-33000f3f3...@fujitsu.com/
Signed-off-by: Yao Xingtao
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-component-utils.c | 9 +++--
hw/mem/cxl_type3.c | 15 +++
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/hw/cxl/cxl
to mistakenly treat failure scenarios as successful and
potentially leading to redundant cleanup operations in ct3_exit().
Signed-off-by: Li Zhijian
Signed-off-by: Jonathan Cameron
---
hw/mem/cxl_type3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/mem/cxl_type3.c b
low
Signed-off-by: Li Zhijian
Signed-off-by: Jonathan Cameron
---
hw/mem/cxl_type3.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index 4775aab0d6..ff6861889b 100644
--- a/hw/mem/cxl_type3.c
+++ b/hw/mem/cxl_type3.c
@@ -893,7 +89
From: Li Zhijian
msix_uninit_exclusive_bar() should be paired with msix_init_exclusive_bar()
Ensure proper resource cleanup by adding the missing
`msix_uninit_exclusive_bar()` call for the Type3 CXL device.
Signed-off-by: Li Zhijian
Signed-off-by: Jonathan Cameron
---
hw/mem/cxl_type3.c | 2
First set of CXL updates for the 10.0 cycle.
- Mixture of cleanup and hardening against a repeat of recent MSI-X
numbering bug.
- Expanded interleave support (been on my tree a long time)
Whilst I think these are in a good state, review always welcome.
Li Zhijian (4):
hw/cxl: Introduce CXL_T3
pertains to the T3 device privately; other endpoints should refrain from
using it, despite its public accessibility to all of them.
Signed-off-by: Li Zhijian
Signed-off-by: Jonathan Cameron
---
include/hw/cxl/cxl_device.h | 4 ++--
hw/cxl/cxl-device-utils.c | 12 +---
hw/cxl/switch
On Tue, 22 Oct 2024 18:00:30 +0100
Jonathan Cameron wrote:
> On Mon, 21 Oct 2024 20:23:46 -0700
> Davidlohr Bueso wrote:
>
> > On Tue, 27 Aug 2024, Jonathan Cameron wrote:\n
> > >No comments inline and LGTM. I'll queue it on my tree and push
> > &
gt; any data from device ranges impacted by sanitize. I believe a simple
> way to achieve this is to disable entire device.
Hmm. That rather destroys the main use case I'm aware of for this
(unlike the general santize commands from earlier CXL versions)/
Superficially sounds like we need a spec clarification as
clearly not super clear!
>
Jonathan
anyway, just
a question of the precise path to that state!
Jonathan
o change
> all fields at the record. Please use:
>
> $ ghes_inject.py arm -h
>
> For more details about its usage.
>
> Signed-off-by: Mauro Carvalho Chehab
Thanks for examples. Given my poor python skills take this one with
a pinch of salt.
Reviewed-by: Jonathan Cameron
> }
> +
> +Device (GEDD)
> +{
> +Name (_HID, "PNP0C33" /* Error Device */) // _HID: Hardware ID
> +Name (_UID, Zero) // _UID: Unique ID
> +}
> }
> }
>
> Signed-off-by: Mauro Carvalho Chehab
Diff looks good.
Reviewed-by: Jonathan Cameron
On Fri, 31 Jan 2025 18:42:49 +0100
Mauro Carvalho Chehab wrote:
> Move the check logic into a common function and simplify the
> code which checks if GHES is enabled and was properly setup.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Jonathan Cameron
> Reviewed-
gned-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
able. This allows
> checking the source ID, the size of the table and the type of the
> HEST error block structures.
>
> Yet, keep the old code, as this is needed for migration purposes.
>
> Signed-off-by: Mauro Carvalho Chehab
Tiny niggle on patch split up inline. Eithe
On Fri, 24 Jan 2025 17:28:02 +0100
Philippe Mathieu-Daudé wrote:
> On 24/1/25 17:20, Jonathan Cameron wrote:
> > On Thu, 23 Jan 2025 09:51:51 +
> > Jonathan Cameron via wrote:
> >
> >> On Wed, 22 Jan 2025 07:56:24 +0100
> >> Philippe Mathieu-Daudé
> >> +static void cxl_accel_class_init(ObjectClass *oc, void *data)
> >> +{
> >> +DeviceClass *dc = DEVICE_CLASS(oc);
> >> +PCIDeviceClass *pc = PCI_DEVICE_CLASS(oc);
> >> +
> >> +pc->realize = cxl_accel_realize;
> >> +pc->exit = cxl_accel_exit;
> >> +
> >> +pc->class_id = PCI
On Thu, 30 Jan 2025 10:28:03 -0800
Pierrick Bouvier wrote:
> On 1/30/25 07:52, Jonathan Cameron wrote:
> > On Wed, 29 Jan 2025 14:31:10 -0800
> > Pierrick Bouvier wrote:
> >
> >> Hi Jonathan,
> >>
> >> On 1/29/25 02:29, Jonathan Cameron w
On Wed, 29 Jan 2025 14:31:10 -0800
Pierrick Bouvier wrote:
> Hi Jonathan,
>
> On 1/29/25 02:29, Jonathan Cameron wrote:
> > On Tue, 28 Jan 2025 12:04:19 -0800
> > Pierrick Bouvier wrote:
> >
> >> On 1/27/25 02:20, Jonathan Cameron wrote:
>
On Wed, 29 Jan 2025 10:14:34 +0900
Itaru Kitayama wrote:
> > On Jan 22, 2025, at 23:07, Jonathan Cameron
> > wrote:
> >
> > On Fri, 17 Jan 2025 09:43:11 +
> > Jonathan Cameron via wrote:
> >
> >> On Fri, 17 Jan 2025 10:13:41 +0900
> &g
On Tue, 28 Jan 2025 12:04:19 -0800
Pierrick Bouvier wrote:
> On 1/27/25 02:20, Jonathan Cameron wrote:
> > On Fri, 24 Jan 2025 12:55:52 -0800
> > Pierrick Bouvier wrote:
> >
> >> Hi Jonathan,
> >>
> >> thanks for posting this. It's a c
On Tue, 28 Jan 2025 11:00:34 +0100
Mauro Carvalho Chehab wrote:
> Em Thu, 23 Jan 2025 10:02:17 +
> Jonathan Cameron escreveu:
>
> > On Wed, 22 Jan 2025 16:46:19 +0100
> > Mauro Carvalho Chehab wrote:
> >
> > > Store HEST table address at GPA, placi
On Fri, 24 Jan 2025 12:55:52 -0800
Pierrick Bouvier wrote:
> Hi Jonathan,
>
> thanks for posting this. It's a creative usage of plugins.
>
> I think that your current approach, decoupling plugins, CHMU and device
> model is a good thing.
>
> I'm not famili
poch_scale=4,\
range_base=0,range_size=4096/ ./stress.sh
where stress.sh is
sleep 2
numactl --membind 3 stress-ng --vm 1 --vm-bytes 1M --vm-keep -t 5s
sleep 2
See the results with
./perf report --dump-raw-trace | grep -A 200 HMU
Enjoy and have a good weekend.
Thanks,
Jonathan
Intended to support enabling in kernel. For now this is dumb and the data
made up. That will change in the near future.
Instantiates 3 instances within one CHMU with separate
interrupts.
Signed-off-by: Jonathan Cameron
---
include/hw/cxl/cxl.h| 1 +
include/hw/cxl/cxl_chmu.h | 154
controlled by the QEMU device implementation.
This is only responsible for the data handling events etc are
a problem for the CXL HMU emulation.
Note that when running this things are fairly slow.
Signed-off-by: Jonathan Cameron
---
contrib/hmu/hmu.c | 312
This allows an external program to act as a hotness tracker.
Signed-off-by: Jonathan Cameron
---
contrib/plugins/cache.c | 75 +
1 file changed, 68 insertions(+), 7 deletions(-)
diff --git a/contrib/plugins/cache.c b/contrib/plugins/cache.c
index
On Thu, 23 Jan 2025 09:51:51 +
Jonathan Cameron via wrote:
> On Wed, 22 Jan 2025 07:56:24 +0100
> Philippe Mathieu-Daudé wrote:
>
> > Map the component I/O region as UnimplementedDevice
> > to be able to trace guest I/O accesses with '-d unimp'.
> >
cxl_dstate);
Ah. You turn it back on here. Specification reference needed.
> +}
> +break;
> case 0x4304: /* scan media */
> {
> CXLType3Dev *ct3d = CXL_TYPE3(cci->d);
> diff --git a/include/hw/cxl/cxl_device.h b/include/hw/cxl/cxl_device.h
> index a64739be25..6d82eb266a 100644
> --- a/include/hw/cxl/cxl_device.h
> +++ b/include/hw/cxl/cxl_device.h
> @@ -581,6 +581,15 @@ typedef struct CXLSetFeatureInfo {
> size_t data_size;
> } CXLSetFeatureInfo;
>
> +struct CXLSanitizeInfo {
> +uint32_t dpa_range_count;
> +uint8_t fill_value;
> +struct {
> +uint64_t starting_dpa;
> +uint64_t length;
> +} dpa_range_list[0];
[]
> +};
> +
> struct CXLType3Dev {
> /* Private */
> PCIDevice parent_obj;
> @@ -651,6 +660,8 @@ struct CXLType3Dev {
> uint8_t num_regions; /* 0-8 regions */
> CXLDCRegion regions[DCD_MAX_NUM_REGION];
> } dc;
> +
> +struct CXLSanitizeInfo *media_op_sanitize;
Here we just need to know there is a definition of struct
CXLSantizeInfo not what form it takes. So use a forwards
defintion and push the definition of struct CXLSanitizeInfo
down to where it is needed only (in the c file).
Thanks,
Jonathan
> };
>
> #define TYPE_CXL_TYPE3 "cxl-type3"
On Thu, 23 Jan 2025 10:39:02 +0530
Vinayak Holikatti wrote:
Hi Vinayak,
Thanks for your patch! Good to add support for this.
Various comments inline, but all fairly minor things.
thanks,
Jonathan
> CXL spec 3.1 section 8.2.9.9.5.3 describes media operations commands.
> CXL d
w gitlab.com/jic23/qemu (latest date
branch).
I'll push out a bit later today.
Few rebase related changes were needed. I've not tested it yet.
Also I have dropped the previous prototype device Niagara on basis this
should give people a better platform to work with.
Jonathan
ecord is supported.
>
> Signed-off-by: Mauro Carvalho Chehab
My Python is poor at best, so take that into account!
Some usage examples might be good to have as well.
Either in explicit docs or the patch description.
Jonathan
> ---
> MAINTAINERS| 3 +
> scr
ju Jose;
> - generic logic to handle block addresses by Jonathan Cameron;
> - generic GHESv2 error inject by Mauro Carvalho Chehab;
>
> Co-authored-by: Jonathan Cameron
> Co-authored-by: Shiju Jose
> Co-authored-by: Mauro Carvalho Chehab
> Signed-off-by: Jonathan Ca
-send-email-ying.hu...@intel.com/
>
> Co-authored-by: Mauro Carvalho Chehab
> Co-authored-by: Jonathan Cameron
> Signed-off-by: Jonathan Cameron
> Signed-off-by: Mauro Carvalho Chehab
> Acked-by: Igor Mammedov
>
> ---
>
> Changes from v8:
>
> - Added a call
On Wed, 22 Jan 2025 16:46:24 +0100
Mauro Carvalho Chehab wrote:
> Move the check logic into a common function and simplify the
> code which checks if GHES is enabled and was properly setup.
>
> Signed-off-by: Mauro Carvalho Chehab
Seems a reasonable cleanup to me.
Reviewed-by: Jonathan Cameron
On Wed, 22 Jan 2025 16:46:23 +0100
Mauro Carvalho Chehab wrote:
> Some error injection notify methods are async, like GPIO
> notify. Add a notifier to be used when the error record is
> ready to be sent to the guest OS.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
dware_errors firmware file.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
On Wed, 22 Jan 2025 16:46:21 +0100
Mauro Carvalho Chehab wrote:
> The GHES migration logic at GED should now support HEST table
> location too.
>
> Signed-off-by: Mauro Carvalho Chehab
I'm not an expert on migration logic, but with that in mind, this looks fine to
me.
Revi
good. A few bits that I think could be made
easier to follow for anyone with the spec open in front of them.
Thanks,
Jonathan
> ---
> hw/acpi/ghes.c | 98 --
> 1 file changed, 88 insertions(+), 10 deletions(-)
>
> diff --git a/h
On Wed, 22 Jan 2025 16:46:19 +0100
Mauro Carvalho Chehab wrote:
> Store HEST table address at GPA, placing its content at
> hest_addr_le variable.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Jonathan Cameron
>
A few trivial things inline.
Jonathan
> --
now just change the logic at table build time, while enforcing that
> it will behave like before with a single source ID.
>
> A future patch will add a HEST table bios pointer and change the logic
> at acpi_ghes_record_errors() to dynamically use the new size.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Jonathan Cameron
but seems
fine to me.
I'd definitely be curious if anything is touching this space so
tracing may be helpful for that!
Reviewed-by: Jonathan Cameron
> ---
> include/hw/cxl/cxl_component.h | 3 ++-
> hw/cxl/cxl-component-utils.c | 14 +++---
> hw/cxl/Kconfig
w this is fine.
We'd have to deal with filling them with plausible values anyway
if that becomes an issue.
Reviewed-by: Jonathan Cameron
I can pick these up and send on in a set to mst, or mst pick up
directly, or got through another tree. Don't mind!
> ---
> include/hw/cxl/cxl_co
On Fri, 17 Jan 2025 09:43:11 +
Jonathan Cameron via wrote:
> On Fri, 17 Jan 2025 10:13:41 +0900
> Itaru Kitayama wrote:
>
> > > On Jan 16, 2025, at 19:58, Jonathan Cameron
> > > wrote:
> > >
> > > On Thu, 16 Jan 2025 15:04:53 +0900
>
.
We need to understand a little more on why this is useful to support.
It's adding another thing we need to test so whilst simple it's not
zero maintenance cost.
Thanks,
Jonathan
> ---
> hw/mem/cxl_type3.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
&
d CXL type-3 emulation features are not
> implemented in a CXL type-2 device.
>
> Co-developed-by: Ira Weiny
> Signed-off-by: Zhi Wang
Hi Zhi,
A few passing comments.
Jonathan
> diff --git a/hw/mem/cxl_accel.c b/hw/mem/cxl_accel.c
> new file mode 100644
> index 00..770
ons. This change seems like a logical enough change without
the reuse.
Also, I'm carrying a patch for 3/6/12 way support so I've merged this on top of
that
in general interest of reducing patches flying around when then are reasonable
on their own.
Jonathan
> hwaddr cxl_
solution like this makes sense rather than a specific reset of registers
as appropriate which allows us to carefully preserve the sticky bits.
Reset for the type 3 has proved a little tricky to fix in the past and
wasn't really a priority. Given we have to do it for type 2 I'd lik
On Thu, 12 Dec 2024 18:10:10 +
Zhi Wang wrote:
> On 12/12/2024 18.49, Alejandro Lucero Palau wrote:
> >
> > On 12/12/24 13:04, Zhi Wang wrote:
> >> Hi folks:
> >>
> >> Per the discussion with Ira/Jonathan in the LPC 2024 and in the CXL
> >
On Tue, 21 Jan 2025 14:58:12 +
Jonathan Cameron wrote:
> On Mon, 20 Jan 2025 11:09:46 +0800
> Li Zhijian wrote:
>
> > Address a memory leak issue by ensuring `regs->special_ops` is freed when
> > `msix_init_exclusive_bar()` encounters an error during CXL Type3 d
could result in errors being overlooked,
> causing the system to mistakenly treat failure scenarios as successful and
> potentially leading to redundant cleanup operations in ct3_exit().
>
> Signed-off-by: Li Zhijian
Looks good to me so just that reordering issue in patch 2.
Thanks fo
ress_space_free to err_msix_uninit
> for better clarity and logical flow
>
> Signed-off-by: Li Zhijian
Hi.
The need to reorder the cleanup calls made me look more
closely at this patch. Either the order was wrong here or in the previous
patch. I think the issue is here.
Jonathan
> ---
> hw/
being clear why.
Also, the new host bridge support needs to be it's own thing, not
in cxl-host.c which is the Host support (so cfmws routing) not
the host bridge support. Probably wants to be in hw/pci-host/cxl.c
alongside gpex etc.
Jonathan
> ---
> hw/cxl/cxl-host-stubs.c
> > Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background
> > completion")
> > Signed-off-by: Li Zhijian
> > ---
> > V3:
> >Just increate the device's msix number, A new enumeration will be
> > introduced in later patch. # J
On Fri, 17 Jan 2025 10:13:41 +0900
Itaru Kitayama wrote:
> > On Jan 16, 2025, at 19:58, Jonathan Cameron
> > wrote:
> >
> > On Thu, 16 Jan 2025 15:04:53 +0900
> > Itaru Kitayama wrote:
> >
> >> Hi Jonathan,
> >>
> >
On Fri, 17 Jan 2025 09:24:15 +0900
Itaru Kitayama wrote:
> > On Jan 16, 2025, at 19:58, Jonathan Cameron
> > wrote:
> >
> > On Thu, 16 Jan 2025 15:04:53 +0900
> > Itaru Kitayama wrote:
> >
> >> Hi Jonathan,
> >>
> >
On Thu, 16 Jan 2025 15:04:53 +0900
Itaru Kitayama wrote:
> Hi Jonathan,
>
> > On Jan 14, 2025, at 19:26, Jonathan Cameron
> > wrote:
> >
> > On Tue, 14 Jan 2025 12:03:03 +0900
> > Itaru Kitayama wrote:
> >
> >> Hi Jonathan,
> &
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:
> >
> >> Introduce the `CXL_T3_MSIX_VECTOR` enumeration to specify MSIX vector
t sufficient which
is why I dropped it again from my trees.
Reset is not currently well handled by the qemu code.
I'm happy to look at patches to fully support it but that fix needs
to be complete and not break any other cases.
Jonathan
>
> Fan
> >
> > On 15/01/2025 04:30,
On Wed, 15 Jan 2025 11:22:14 +
Jonathan Cameron wrote:
> On Wed, 15 Jan 2025 07:48:59 +
> "Zhijian Li (Fujitsu)" wrote:
>
> > On 10/01/2025 23:44, Jonathan Cameron wrote:
> > > On Fri, 13 Dec 2024 17:36:02 +0800
> > > Li Zhijian wrote:
>
define DWORD_BYTE 4
#define CXL_CAPACITY_MULTIPLIER (256 * MiB)
> ---
> V3: new patch to introduce a T3 specific enumeration # Jonathan
> ---
> hw/cxl/cxl-device-utils.c | 12 +---
> hw/cxl/switch-mailbox-cci.c | 4 +++-
> hw/mem/cxl_type3.c | 12 +
l.
Michael, feel free to pick this one up directly if you prefer.
Its a silly mistake I made reordering a couple of series.
A nice cleanup to avoid this problem happening again will follow.
Jonathan
> ---
> V3:
> Just increate the device's msix number, A new enumeration will be
On Wed, 15 Jan 2025 07:48:59 +
"Zhijian Li (Fujitsu)" wrote:
> 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 devi
A further patch will give it a better name.
>
> Signed-off-by: Mauro Carvalho Chehab
Igor tagged this in previous posting. Any reason for dropping?
>
> # Conflicts:
> # roms/edk2
Should clear this out.
A few formatting things inline but beyond that looks good to me.
Reviewed-
On Tue, 14 Jan 2025 12:03:03 +0900
Itaru Kitayama wrote:
> Hi Jonathan,
>
> > On Jan 10, 2025, at 21:31, Jonathan Cameron
> > wrote:
> >
> > On Fri, 10 Jan 2025 09:20:54 +
> > "Zhijian Li (Fujitsu)" via wrote:
> >
> >> On
; Expand the device's MSIX number and use the enum to maintain the *USED*
> and MAX MSIX number
>
> Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background
> completion")
> Signed-off-by: Li Zhijian
> ---
> V2: just increase msix number and add enum to
86 which I only lightly test for stuff that
isn't ready for upstream yet.
Give me a shout if you run into any problems.
The main blocker on upstreaming this is resolving the missing device tree
support for PCI expander bridges. I've not made any progress on this since
talk at Linaro connec
QEMU
and this will all work.
Longer term I don't think there is any way to describe thread private caches
in DT but as you observe, no one builds that hardware anyway.
Hence I'm very much in favor of this change!
Resent as yet again my email client tripped over Daniel's name and scramble
On Tue, 10 Dec 2024 14:13:29 -0500
Gregory Price wrote:
> On Tue, Dec 03, 2024 at 09:15:51PM +, Hongjian Fan wrote:
> > Hi Jonathan,
> >
> > I'm trying to emulate our memory appliance which is similar to a MH-SLD.
> > The memory device is connected to the h
0130: 00 00 00 00 01 1C 00 00 FF 00 00 00 00 00 00 00 //
> 0140: 00 00 20 00 00 08 00 00 10 0F 40 00 04 00 02 02 // .. ...@.
> 0150: 01 1C 00 00 FF 00 00 00 34 01 00 00 00 80 00 00 // 4...
> 0160: 80 00 00 00 04 03 40 00 04 00 01 00 01
uot;smp-cache.2.cache=l2,smp-cache.2.topology=cluster,"
> + "smp-cache.3.cache=l3,smp-cache.3.topology=cluster "
> + "-cpu cortex-a57 "
Trivial but is there a reason the cpu must come after machine / -M bits?
If not I'd leave it
owing device tree will be generated for a scenario
> where we have 2 sockets, 2 clusters, 2 cores and 2 threads, in total 16
> PEs. L1i and L1d are private to each thread, and l2 and l3 are shared at
> socket level as an example.
>
> Limitation: SMT cores cannot share L1 cache for now.
ch that enables this flag will follow later.
>
> Signed-off-by: Alireza Sanaee
Makes sense. Zhao Liu, is this something you plan to use in the x86
code?
Either way
Reviewed-by: Jonathan Cameron
> ---
> hw/core/machine-smp.c | 2 ++
> include/hw/boards.h | 1 +
> 2 files c
anaee
I think this makes sense as a MAX cpu with out an L3 sounds pretty minimal
and it provides a way to exercise the rest of this series in TCG. For KVM
it will come from host registers (or overridden ones) anyway.
Reviewed-by: Jonathan Cameron
> ---
> target/arm/tcg/cpu64.c | 13 ++
On Fri, 13 Dec 2024 13:06:57 -0600
Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> hw/cxl/switch-mailbox-cci.c | 2 +-
Acked-by: Jonathan Cameron
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/cxl/switch-mailbox-cci.c b/hw/cxl/sw
On Thu, 12 Dec 2024 14:52:02 -0500
Gregory Price wrote:
> On Thu, Dec 12, 2024 at 05:40:16PM +0000, Jonathan Cameron via wrote:
> > On Fri, 18 Oct 2024 12:12:52 -0400
> > Gregory Price wrote:
> >
> > > From: Svetly Todorov
> > >
> > > The sh
o each qmp interface independently works fine is
also a bit more complex than I think we would eventually want.
Having a solution in place though will make it much easier to move towards
an eventual upstreamable solution. This is a great place to start from!
Jonathan
> +static bool cxl_mhsld
ing tree an can easily tidy the stuff up I mention
whilst doing so.
Thanks,
Jonathan
> ---
> hw/cxl/cxl-mailbox-utils.c | 28 +++-
> hw/mem/cxl_type3.c | 17 +
> include/hw/cxl/cxl_device.h | 8
> 3 files changed, 52 inse
tests so this sort of silly
bug doesn't happen in future :(
Thanks,
Jonathan
> ---
> hw/cxl/cxl-device-utils.c | 3 ++-
> hw/mem/cxl_type3.c | 15 ++-
> include/hw/cxl/cxl_device.h | 2 ++
> 3 files changed, 18 insertions(+), 2 deletions(-)
>
On Sat, 7 Dec 2024 09:54:14 +0100
Mauro Carvalho Chehab wrote:
> The 'physical_address' value is a faulty page. As such, 0 is
> as valid as any other value.
Still not sure on what faulty pages are :)
Given I tagged previous (after you'd sent this)
Reviewed-by: Jonathan Cam
ge' is. but code looks fine.
Reviewed-by: Jonathan Cameron
> >
> > Suggested-by: Igor Mammedov
> > Signed-off-by: Mauro Carvalho Chehab
>
> Reviewed-by: Igor Mammedov
>
> > ---
> > hw/acpi/ghes.c | 4
> > 1 file changed,
count this as just another one of those.
Jonathan
>
> Signed-off-by: Hongjian Fan
> ---
> hw/mem/cxl_type3.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> index 5cf754b38f..35caa18
modeling platform than SBSA ref.
Various other minor comments inline.
+CC Michael Tsirkin as this is effectively a new PCI host bridge.
Jonathan
> ---
> docs/system/arm/sbsa.rst | 4 +
> hw/arm/sbsa-ref.c | 139 ++-
1 - 100 of 1417 matches
Mail list logo
