On Thu, 11 Aug 2022 18:08:57 +0100
Jonathan Cameron via wrote:
> On Tue, 9 Aug 2022 17:08:25 +0100
> Jonathan Cameron wrote:
>
> > On Tue, 9 Aug 2022 21:07:06 +0800
> > Bobo WL wrote:
> >
> > > Hi Jonathan
> > >
> > > Thanks for y
On Fri, 12 Aug 2022 09:03:02 -0700
Dan Williams wrote:
> Jonathan Cameron wrote:
> > On Thu, 11 Aug 2022 18:08:57 +0100
> > Jonathan Cameron via wrote:
> >
> > > On Tue, 9 Aug 2022 17:08:25 +0100
> > > Jonathan Cameron wrote:
> > >
> &
On Tue, 18 Jul 2023 17:30:57 -0400
Gregory Price wrote:
> On Mon, Jul 17, 2023 at 06:16:39PM +0100, Jonathan Cameron wrote:
> > @@ -397,8 +401,9 @@ struct CXLType3Dev {
> > AddressSpace hostpmem_as;
> > CXLComponentState cxl_cstate;
> > CXLDeviceState
On Wed, 19 Jul 2023 14:49:07 -0400
Gregory Price wrote:
> On Wed, Jul 19, 2023 at 09:19:47AM +0100, Jonathan Cameron wrote:
> > On Tue, 18 Jul 2023 17:30:57 -0400
> > Gregory Price wrote:
> >
> > > On Mon, Jul 17, 2023 at 06:16:39PM +0100, Jonathan Cameron wro
mu-devel on lore
https://lore.kernel.org/all/sg2pr06mb3397f3e74a083607f7492fa4b2...@sg2pr06mb3397.apcprd06.prod.outlook.com/
Might be a backlog somewhere that will take a while to drain...
Fan, perhaps just resend the lot and make sure the threading works so we can
find them more easily.
Jonathan
>
> Ira
&
nd with better names ;)
-smp
16,sockets=1,clusters=4,threads=2,cache-cluster-start-level=2,cache-node-start-level=3
Perhaps we can come up with a common scheme that covers both usecases?
It gets more fiddly to define if we have variable topology across different
clusters
- and that
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
>
> Based on CXL spec 3.0 Table 8-94 (Identify Memory Device Output
> Payload), dynamic capacity event log size should be part of
> output of the Identify command.
> Add dc_event_log_size to the output payload for the host to get t
On Fri, 21 Jul 2023 12:35:04 -0400
Gregory Price wrote:
Typo in patch title. reference
> This allows devices to have fully customized CCIs, along with complex
> devices where wrapper devices can override or add additional CCI
> commands without having to replicate full command structures or
> po
le, with custom commands outside the specification)
without the need to change the base device.
The also enabled the base device to dispatch those commands without
requiring additional driver support.
Signed-off-by: Gregory Price
Link: https://lore.kernel.org/r/20230721163505.191
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
You should fix the author on these to match the SoB
git commit --amend --author="Fan Ni " fixes them.
I'm trying to pick these up for my tree as I review them (where they aren't
invasive). So I'll fix this stuff whilst doing so.
y: Fan Ni
Looks good. I've picked this up with the author change.
Note that just because I've starting picking these up, doesn't
mean you can't keep changing them, but if you start from where my
gitlab.com/jic23/qemu tree is that will make life easier given
we have a lot of stuf
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
>
> With the change, when setting up memory for type3 memory device, we can
> create DC regions
> A property 'num-dc-regions' is added to ct3_props to allow users to pass the
> number of DC regions to create. To make it easier, oth
On Tue, 25 Jul 2023 18:39:56 +
Fan Ni wrote:
> From: Fan Ni
>
> Add (file/memory backed) host backend, all the dynamic capacity regions
> will share a single, large enough host backend. Set up address space for
> DC regions to support read/write operations to dynamic capacity for DCD.
>
>
across the series. Given I'm
rebasing this anyway to give myself something to test I'll tidy things up
(feel free to disagree with and revert any changes !)
and push a tree out in next day or two. I'll message when I've done so.
Jonathan
> ---
> hw/mem/cxl_type3.c
On Mon, 7 Aug 2023 09:53:42 +0100
Jonathan Cameron via wrote:
> On Tue, 25 Jul 2023 18:39:56 +
> Fan Ni wrote:
>
> > From: Fan Ni
> >
> > Not all dpa range in the dc regions is valid to access until an extent
> > covering the range has been added
quirement of @errp, add missing ERRP_GUARD() in
> cxl_usp_realize().
>
> Suggested-by: Markus Armbruster
> Signed-off-by: Zhao Liu
> Reviewed-by: Markus Armbruster
Acked-by: Jonathan Cameron
> ---
> Suggested by credit:
> Markus: Referred his explanation about
> cxl_fixed_memory_window_config() hasn't triggered the bug that
> dereferencing the NULL @errp.
>
> To follow the requirement of @errp, add missing ERRP_GUARD() in
> cxl_fixed_memory_window_config().
>
> Suggested-by: Markus Armbruster
> Signed-off-by: Zhao Liu
> Reviewed-by: Mar
rement of @errp, add missing ERRP_GUARD() in
> ct3_realize().
>
> Suggested-by: Markus Armbruster
> Signed-off-by: Zhao Liu
> Reviewed-by: Markus Armbruster
Acked-by: Jonathan Cameron
> ---
> Suggested by credit:
> Markus: Referred his explanation about ERRP_GUAR
of a list seems overkill.
Otherwise looks good to me. I need Generic Ports support for CXL
stuff so will copy your approach for that as it's ended up nice
and simple.
Jonathan
> ---
> hw/acpi/acpi-generic-initiator.c | 84
> hw/arm/virt-acpi-build.c
On Fri, 23 Feb 2024 12:42:23 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieve
9.9.1, add 'Get Dynamic Capacity
> Configuration' mailbox support.
>
> Note: decode_len of a dc region is aligned to 256*MiB, divided by
> 256 * MiB before returned to the host for "Get Dynamic Capacity Configuration"
> mailbox command.
>
> Signed-off-by: Fan Ni
C regions;
> 2. mailbox command support for adding/releasing DC extents.
"This will be added later in the series."
>
> Signed-off-by: Fan Ni
Without the above additions it sounds like this patch series only partly
does the job :)
A forwards reference is good, or just don't mention it.
No guarantee of code doing anything useful, beyond not crashing
at mid point of a series.
Jonathan
On Wed, 21 Feb 2024 10:15:59 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add (file/memory backed) host backend, all the dynamic capacity regions
> will share a single, large enough host backend. Set up address space for
> DC regions to support read/write operations to dynamic capacity fo
On Wed, 21 Feb 2024 10:16:00 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add dynamic capacity extent list representative to the definition of
> CXLType3Dev and add get DC extent list mailbox command per
> CXL.spec.3.1:.8.2.9.9.9.2.
>
> Signed-off-by: Fan Ni
Follow on from earlier comme
f-by: Fan Ni
Hi Fan,
Comments on this are all about corner cases. If we can I think we need
to cover a few more. Linux won't hit them (I think) so it will be
a bit of a pain to test but maybe raw commands enabled and some
userspace code will let us exercise the corner cases?
Jonathan
On Wed, 21 Feb 2024 10:16:02 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Since fabric manager emulation is not supported yet, the change implements
> the functions to add/release dynamic capacity extents as QMP interfaces.
>
> Note: we skips any FM issued extent release request if the e
On Mon, 26 Feb 2024 17:01:22 -0800
fan wrote:
> On Mon, Feb 26, 2024 at 06:04:17PM +0000, Jonathan Cameron wrote:
> > On Wed, 21 Feb 2024 10:16:01 -0800
> > nifan@gmail.com wrote:
> >
> > > From: Fan Ni
> > >
> > > Per CXL spec 3.1,
On Tue, 27 Feb 2024 17:20:25 +0800
Zhao Liu wrote:
> Hi Jonathan,
>
> > Hi Zhao Liu
> >
> > I like the scheme. Strikes a good balance between complexity of description
> > and systems that actually exist. Sure there are systems with more cache
> > levels e
On Fri, 23 Feb 2024 12:42:23 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieve
> diff --git a/include/hw/acpi/acpi-generic-initiator.h
> b/include/hw/acpi/acpi-generic-initiator.h
> new file mode 100644
> index 00..2f183b029a
> --- /dev/null
> +++ b/include/hw/acpi/acpi-generic-initiator.h
> +typedef struct AcpiGenericInitiatorClass {
> +ObjectClass parent
On Tue, 27 Feb 2024 08:37:15 +
Ankit Agrawal wrote:
> Thanks Jonathan for reviewing the change.
>
> Comments inline.
>
> >> The structure needs a PCI device handle [2] that consists of the device
> >> BDF.
> >> The vfio-pci device corresponding
On Tue, 27 Feb 2024 17:11:15 +
Jonathan Cameron via wrote:
> On Tue, 27 Feb 2024 08:37:15 +
> Ankit Agrawal wrote:
>
> > Thanks Jonathan for reviewing the change.
> >
> > Comments inline.
> >
> > >> The structure needs a PCI device handl
#x27;acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> >'authz-list': 'AuthZListProperties',
> >'authz-listfile': 'AuthZListFileProperties',
> >'authz-pam': 'AuthZPAMProperties',
>
> Jonathan, you pointed out interface design issues in your review of v2.
> Are you fully satisfied with the interface in v3?
Yes. I'm fine with the interface in this version (though it's v7, so I'm lost
on v2 vs v3!)
Jonathan
>
On Wed, 28 Feb 2024 16:50:30 +
Ankit Agrawal wrote:
> >>> Jonathan, you pointed out interface design issues in your review of v2.>
> >> Are you fully satisfied with the interface in v3?
> >>
> >> Yes. I'm fine with the interface in this versio
On Thu, 29 Feb 2024 11:22:24 +0100
Heinrich Schuchardt wrote:
> On 29.02.24 02:11, Peter Xu wrote:
> > On Wed, Feb 28, 2024 at 08:07:47PM +0100, Heinrich Schuchardt wrote:
> >> On 28.02.24 19:39, Peter Maydell wrote:
> >>> On Wed, 28 Feb 2024 at 18:28, Heinrich Schuchardt
> >>> wrote:
> >>
On Thu, 15 Feb 2024 14:28:14 +
Jonathan Cameron via wrote:
Any comments? Almost all the other fixes I need for CXL memory to
work as normal ram are queued up so I'd love it if we can solve this one as
well.
This looks like a big series, but it's really just a refactor + trivia
hink the case I saw
was split descriptors in virtio via address space caches
https://elixir.bootlin.com/qemu/latest/source/hw/virtio/virtio.c#L4043
One bounce buffer is in use for the outer loop and another for the descriptors
it is pointing to.
Matthias' series makes this work fine. I need to circle back and check
how big a cache this needs. I'm carrying a silly size because of the
side effect of the address space bug here
https://lore.kernel.org/qemu-devel/20240215142817.1904-1-jonathan.came...@huawei.com/#t
and can probably set it to much less than my currently 1GiB.
Jonathan
>
> -- PMM
>
elevant table dumps.
>
> Sorry it isn't clear where do you want me to add this. In the git commit
> message?
I meant as part of the test. Typically you then include the relevant snippet
as part of the commit message to show what the key part of the test is.
Thanks,
Jonathan
If you have preference for
> not having it, I can change that too.
Not my area, so up to maintainers of hw/acpi to comment if they care!
I'd not wait for that though before v8.
*impatient user who has some other stuff queued on top of this!*
:)
Jonathan
On Tue, 27 Feb 2024 17:36:21 +
Jonathan Cameron wrote:
> On Tue, 27 Feb 2024 17:11:15 +
> Jonathan Cameron via wrote:
>
> > On Tue, 27 Feb 2024 08:37:15 +
> > Ankit Agrawal wrote:
> >
> > > Thanks Jonathan for reviewing the
overly optimistic beyond CXL where the kernel will use
them and which drove their introduction.
Jonathan Cameron (2):
hmat acpi: Do not add Memory Proximity Domain Attributes Structure
targetting non existent memory.
hmat acpi: Fix out of bounds access due to missing use of indirection
it breaks Linux HMAT passing and the table is rejected.
https://elixir.bootlin.com/linux/latest/source/drivers/acpi/numa/hmat.c#L444
Signed-off-by: Jonathan Cameron
---
hw/acpi/hmat.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 3042d223c8
array.
Stash the reverse lookup when writing the initiator list and use
it to get the correct array index index.
Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth
Information Structure(s)")
Signed-off-by: Jonathan Cameron
---
hw/acpi/hmat.c | 6 +-
1 file
On Thu, 29 Feb 2024 13:00:27 +
Ankit Agrawal wrote:
> >> >>> Jonathan, you pointed out interface design issues in your review of
> >> >>> v2.>
> >> >> Are you fully satisfied with the interface in v3?
> >> >>
> &g
On Thu, 29 Feb 2024 12:28:51 -0500
Gregory Price wrote:
> On Thu, Feb 29, 2024 at 04:25:44PM +0000, Jonathan Cameron wrote:
> > If qemu is started with a proximity node containing CPUs alone,
> > it will provide one of these structures to say memory in this
> > node is
the ct3_load_cdat() function: The local char *buf variable is
> assigned to uint8_t *buf in CDATObject, i.e. a pointer of a different
> type. Change the local variable to the same type as buf in CDATObject
> to avoid the error.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Jonathan Came
hat's
not in general true of the CXL spec structures.
Maybe alternative if we run into problems with future versions
of these structures will be to define struct CDATSubHeader as packed.
Still we can cross that bridge when we come to it.
>
> Signed-off-by: Thomas Huth
Reviewed-b
On Mon, 4 Mar 2024 11:44:06 +0100
Thomas Huth wrote:
> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> glib adds type safety checks to the g_steal_pointer() macro. This
> triggers errors in the ct3_build_cdat_entries_for_mr() function which
> uses the g_steal_pointer() fo
On Mon, 4 Mar 2024 15:06:51 +
Jonathan Cameron wrote:
> On Mon, 4 Mar 2024 11:44:05 +0100
> Thomas Huth wrote:
>
> > When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> > glib adds type safety checks to the g_steal_pointer() macro. This
>
,pci-dev=dev0,node=2 \
> >>
> >> Moreover based on a quick grep, I don't see any other test that
> >> have -device vfio-pci argument.
> >>
> >> Jonathan, Alex, do you know how we may add tests that is dependent
> >> on the vfio-pci device?
On Tue, 5 Mar 2024 08:27:52 +0100
Thomas Huth wrote:
> On 04/03/2024 16.10, Jonathan Cameron wrote:
> > On Mon, 4 Mar 2024 11:44:06 +0100
> > Thomas Huth wrote:
> >
> >> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> >&
and? I can see something like this being useful.
A few comments inline.
Jonathan
>
> Signed-off-by: Fan Ni
> ---
> hw/mem/cxl_type3.c | 80
> hw/mem/cxl_type3_stubs.c | 12 ++
> qapi/cxl.json| 32
On Mon, 26 Feb 2024 16:42:29 +
Jonathan Cameron via wrote:
> On Fri, 23 Feb 2024 12:42:23 +
> wrote:
>
> > From: Ankit Agrawal
> >
> > ACPI spec provides a scheme to associate "Generic Initiators" [1]
> > (e.g. heterogeneous processors a
On Wed, 6 Mar 2024 10:33:17 +
Ankit Agrawal wrote:
> >> >> Jonathan, Alex, do you know how we may add tests that is dependent
> >> >> on the vfio-pci device?
> >> >
> >> > There are none.
> >> >
> >> > This would
On Wed, 6 Mar 2024 19:27:07 +0800
Yuquan Wang wrote:
> Hello, Jonathan
>
> Recently I met some problems on CXL RAS tests.
>
> I tried to use "cxl-inject-uncorrectable-errors" and
> "cxl-inject-correctable-error"
> qmp to inject CXL errors,
params). The admin can get the
> distance among nodes in hardware using `numactl -H`.
That's a lot of description when you could just have claimed you want a normal
GI node for HMAT and we'd have all believed you ;)
>
> Link: https://www.nvidia.com/en-in/technologies/multi-insta
of the device BDF.
> The vfio-pci device corresponding to the acpi-generic-initiator object is
> located to determine the BDF.
>
> [1] ACPI Spec 6.3, Section 5.2.16.6
> [2] ACPI Spec 6.3, Table 5.80
>
> Cc: Jonathan Cameron
> Cc: Alex Williamson
> Cc: Cedric Le Goater
if pass
> > > 3. do real release: in the pass, we will not need to detect extent
> > > errors;
> > >
> > > Does the above solution sound reasonable? If so, do we want to go this
> > > way? do we need to introduce the bitmap earlier in the series?
&
On Thu, 22 Feb 2024 09:07:03 -1000
Richard Henderson wrote:
> On 2/19/24 07:31, Jonathan Cameron wrote:
> > v2: Changes documented in patch 3.
> > - I have not addressed Richard's comment on recursive locks as that
> > seems to be a more general issue not
.2.1/source/hw/cxl/cxl-device-utils.c#L204
>
> Signed-off-by: Fan Ni
Good point.
I've applied this to my local tree - not rushing on this one.
Jonathan
> ---
> hw/cxl/cxl-mailbox-utils.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/hw/cxl/cxl-
output payload for the host to get the info.
>
> Signed-off-by: Fan Ni
I'm going to give tags on this mostly so I can easily see what I was happy
with on any future versions if we need them.
If I end up sending the code to Michael, a may squash them into
just a SoB.
Reviewed-by: Jonathan Cameron
mmand per
> specification.
>
> Signed-off-by: Fan Ni
Really minor nice to have type comments inline.
Reviewed-by: Jonathan Cameron
> ---
> hw/cxl/cxl-mailbox-utils.c | 99 +
> include/hw/cxl/cxl_device.h | 16 ++
> 2 files changed,
Signed-off-by: Fan Ni
Reviewed-by: Jonathan Cameron
cho $region > /sys/bus/cxl/drivers/cxl_region/bind
>
> Signed-off-by: Fan Ni
Suggested changes are trivial formatting things
Reviewed-by: Jonathan Cameron
> ---
> hw/mem/cxl_type3.c | 46 ++
> 1 file changed, 46 insertions(+)
>
On Mon, 4 Mar 2024 11:34:00 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> The function ct3_build_cdat_entries_for_mr only uses size of the passed
> memory region argument, refactor the function definition to make the passed
> arguments more specific.
Typo in title, instead
-by: Fan Ni
Reviewed-by: Jonathan Cameron
for dynamic capacity for read/write support;
> 3. Create cdat entries for each dynamic capacity region;
> 4. Fix dvsec range registers to include DC regions.
>
> Signed-off-by: Fan Ni
Hi Fan,
This one has a few more significant comments inline.
thanks,
Jonathan
> ---
>
On Mon, 4 Mar 2024 11:34:02 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add dynamic capacity extent list representative to the definition of
> CXLType3Dev and add get DC extent list mailbox command per
> CXL.spec.3.1:.8.2.9.9.9.2.
>
> Signed-off-by: Fan Ni
Hi Fan,
A small thing in he
a wrapper around a struct Range though
so that we can use the comparison stuff directly.
+ we can use the list manipulation in there as the basis for a future
extent merging infrastructure that is tag and sequence number (if
provided - so shared capacity or pmem) aware.
Jonathan
> ---
> +
On Mon, 4 Mar 2024 11:34:04 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Since fabric manager emulation is not supported yet, the change implements
> the functions to add/release dynamic capacity extents as QMP interfaces.
We'll need them anyway, or to implement an fm interface via QMP
eared when the extent is released.
>
> Signed-off-by: Fan Ni
Reviewed-by: Jonathan Cameron
the device, the release can be
> performed.
>
> Signed-off-by: Fan Ni
Ouch this is more complex than I was thinking, but seems correct to me.
A few minor comments inline
Jonathan
> +/*
> + * Detect potential extent overflow caused by extent split during processing
> + * extent relea
On Mon, 4 Mar 2024 11:34:07 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Before the change, the QMP interface used for add/release DC extents
> only allows to release extents that exist in either pending-to-add list
> or accepted list in the device, which means the DPA range of the exten
On Thu, 7 Mar 2024 03:03:02 +
Ankit Agrawal wrote:
> >>
> >> [1] ACPI Spec 6.3, Section 5.2.16.6
> >> [2] ACPI Spec 6.3, Table 5.80
> >>
> >> Cc: Jonathan Cameron
> >> Cc: Alex Williamson
> >> Cc: Cedric Le Goater
> &g
said
he
was happy to take it through NVME but wanted a PCI Ack first.
Michael / Marcel, if you have time to look at it that would be great.
Thanks,
Jonathan
>
> 1: https://github.com/DMTF/libspdm
>
> v5:
> - Update MAINTAINERS
> v4:
> - Rebase
> v3:
> - Spel
is one. The function called is trivial
(other than some magic to handle very large memory regions) so
this is just a readability question, not a perf one.
Whatever, don't leave the question behind. Find to have something
that says they are always the same size if you don't get rid
of the total_capacity representation.
Jonathan
ither. My assumption is that in
error cases there are no side effects, but I don't see a clear statement of
that.
So I think we are in the world of best practice, not spec compliance.
If we wanted to recover from such an error case we'd have to verify the current
extent list. I'll fire off a question to relevant folk in appropriate forum.
Jonathan
> > > +static void cxl_destroy_dc_regions(CXLType3Dev *ct3d)
> > > +{
> > > +CXLDCExtent *ent;
> > > +
> > > +while (!QTAILQ_EMPTY(&ct3d->dc.extents)) {
> > > +ent = QTAILQ_FIRST(&ct3d->dc.extents);
> > > +cxl_remove_extent_from_extent_list(&ct3d->dc.extents, ent);
> >
>
. I'd missed the fact you store into the extent without a check on validity
but only move the index on if they were valid. Then rely on not passing a
trailing
entry at the end.
If would be more readable I think if local variables were used for the
parameters
until we've decided not to skip and the this ended with
if (!skip_extent) {
extents[i] = (DCXLDCExtentRaw) {
.start_dpa = ...
...
};
i++
}
We have local len already so probably just need
uint64_t start_dpa = offset + dcd->dc.regions[rid].base;
Also maybe skip_extent_evlog or something like that to explain we are only
skipping that part.
Helps people like me who read it completely wrong!
Jonathan
ast.
> > Maybe we need
> > to do two passes so we know this has happened early (or perhaps this is a
> > later
> > patch in which case a todo here would help).
>
> If the second skip_extent case, I will reject earlier instead of
> skipping.
That was me misunderstanding the flow. I think this is fine as you have it
already.
Jonathan
On Fri, 1 Mar 2024 13:35:26 +0800
Peter Xu wrote:
> On Fri, Mar 01, 2024 at 01:29:04PM +0800, Peter Xu wrote:
> > On Thu, Feb 15, 2024 at 02:28:16PM +, Jonathan Cameron wrote:
> > > This code will be reused for the address_space_cached accessors
> > > shortl
On Fri, 1 Mar 2024 13:44:01 +0800
Peter Xu wrote:
> On Thu, Feb 15, 2024 at 02:28:17PM +0000, Jonathan Cameron wrote:
>
> Can we rename the subject?
>
> physmem: Fix wrong MR in large address_space_read/write_cached_slow()
>
> IMHO "wrong MR" is misleading, a
ative mr_addr.
To avoid duplicating most of the code, the next 2 patches factor out
the common parts of flatview_read_continue() and flatview_write_continue()
so they can be reused.
Write path has not been tested but it so similar to the read path I've
included it here.
Jonathan Cameron (4):
parameter in address_space_read/write_cached_slow()
Suggested-by: Peter Xu
Signed-off-by: Jonathan Cameron
---
v2: New patch.
- I have kept the renames to only the code I'm touching later in this
series, but they could be applied much more widely.
---
system/physmem.c
Precursor to factoring out the inner loops for reuse.
Reviewed-by: Peter Xu
Signed-off-by: Jonathan Cameron
---
v2: Picked up tag from Peter.
system/physmem.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/system/physmem.c b
This code will be reused for the address_space_cached accessors
shortly.
Also reduce scope of result variable now we aren't directly
calling this in the loop.
Signed-off-by: Jonathan Cameron
---
v2: Thanks to Peter Xu
- Fix alignment of code.
- Drop unused addr parameter.
- Carry throug
this by adding new address_space_read_continue_cached()
and address_space_write_continue_cached() which share all the logic
with the flatview versions except for the MemoryRegion lookup which
is unnecessary as the MemoryRegionCache only covers one MemoryRegion.
Signed-off-by: Jonathan Cameron
---
v2
Previously: tcg/i386: Page tables in MMIO memory fixes (CXL)
Richard Henderson picked up patches 1 and 3 which were architecture independent
leaving just this x86 specific patch.
No change to the patch. Resending because it's hard to spot individual
unapplied patches in a larger series.
Original
dy handles MMIO accesses.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Suggested-by: Peter Maydell
Signed-off-by: Gregory Price
Signed-off-by: Jonathan Cameron
---
v3: No change.
target/i386/tcg/sysemu/excp_helper.c | 57 +++-
1 file changed, 30
such systems will use Generic Port
Affinity Structures (and I have patches for those to follow shortly)
but that's overly optimistic beyond CXL where the kernel will use
them and which drove their introduction.
Jonathan Cameron (2):
hmat acpi: Do not add Memory Proximity Domain Attri
it breaks Linux HMAT passing and the table is rejected.
https://elixir.bootlin.com/linux/v6.7/source/drivers/acpi/numa/hmat.c#L444
Signed-off-by: Jonathan Cameron
v2: Fix link in patch description to be stable.
---
hw/acpi/hmat.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw
array.
Stash the reverse lookup when writing the initiator list and use
it to get the correct array index index.
Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth
Information Structure(s)")
Signed-off-by: Jonathan Cameron
---
hw/acpi/hmat.c | 6 +-
1 file
On Fri, 9 Feb 2024 19:54:11 +0800
Shiyang Ruan wrote:
> The "Volatile" should be set if current device is a volatile memory.
> Per CXL Spec r3.0 8.2.9.2.1.1, Table 8-43.
Whilst true, we haven't previously adjusted the injected record
to conform to the device. I don't think there is anything pr
to fill them all in based on just the DPA
but allow them to be overridden from the existing GMER
injection (so other test cases can be poked).
One comment inline.
Jonathan
>
> Signed-off-by: Shiyang Ruan
> ---
> hw/mem/cxl_type3.c | 5 +
> 1 file changed, 5 insertions(+)
&g
ke timer expiry are definitely ruled out and rename the function
to make it clear it might not find poison.
Jonathan
; - 'fatal']
> + 'fatal',
> + 'dyncap']
> }
Needs a docs update.
Upstream QEMU seems to have gained some stricter checks
so this just broke my build after a rebase.
Jonathan
Precursor to factoring out the inner loops for reuse.
Signed-off-by: Jonathan Cameron
---
system/physmem.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/system/physmem.c b/system/physmem.c
index 6a3c9de512..39b5ac751e 100644
--- a
. To avoid duplicating most of the
code, the first 2 patches factor out the common parts of
flatview_read_continue() and flatview_write_continue() so they can
be reused.
Write path has not been tested but it so similar to the read path I've
included it here.
Jonathan Cameron (3):
physme
This code will be reused for the address_space_cached accessors
shortly.
Also reduce scope of result variable now we aren't directly
calling this in the loop.
Signed-off-by: Jonathan Cameron
---
system/physmem.c | 165 ---
1 file change
this by adding new address_space_read_continue_cached()
and address_space_write_continue_cached() which share all the logic
with the flatview versions except for the MemoryRegion lookup.
Signed-off-by: Jonathan Cameron
---
system/physmem.c | 78
1
401 - 500 of 2719 matches
Mail list logo
