On Thu, 26 Sep 2024 19:33:18 +0800
Yicong Yang wrote:
> From: Yicong Yang
>
> OS like Linux is using PPTT processor node's identical implementation
> flag [1] to infer whether the whole system or a certain CPU cluster is
> homogeneous or not [2]. QEMU currently only support building homogeneous
On Wed, 25 Sep 2024 06:04:20 +0200
Mauro Carvalho Chehab wrote:
> While the spec defines a CPER size of 4KiB for each record,
> currently it is set to 1KiB. Fix the documentation and add
> a pointer to the macro name there, as this may help to keep
> it updated.
>
> Signed-off-by: Mauro Carvalho
On Wed, 25 Sep 2024 06:04:19 +0200
Mauro Carvalho Chehab wrote:
> The hardware error firmware is where HEST error structures are
> stored. Those can be GHESv2, but they can also be other types.
>
> Better name the location of the hardware error.
>
> No functional changes.
>
> Signed-off-by: Ma
On Wed, 25 Sep 2024 06:04:18 +0200
Mauro Carvalho Chehab wrote:
> Now that we have also have a file to store HEST data location,
> which is part of GHES, better name the file where CPER records
> are stored.
>
> No functional changes.
>
> Reviewed-by: Igor Mammedov
> Signed-off-by: Mauro Carva
On Wed, 25 Sep 2024 06:04:17 +0200
Mauro Carvalho Chehab wrote:
> Instead, produce an error and continue working
>
> Signed-off-by: Mauro Carvalho Chehab
Make sense as defense in depth. Can we actually hit this for existing
systems, or is the injection stuff disabled if the ged isn't configured
On Wed, 25 Sep 2024 06:04:16 +0200
Mauro Carvalho Chehab wrote:
> The current function used to generate GHES data is specific for
> memory errors. Give a better name for it, as we now have a generic
> function as well.
>
> Reviewed-by: Igor Mammedov
> Signed-off-by: Mauro Carvalho Chehab
In ge
On Wed, 25 Sep 2024 06:04:15 +0200
Mauro Carvalho Chehab wrote:
> Currently, CPER address location is calculated as an offset of
> the hardware_errors table. It is also badly named, as the
> offset actually used is the address where the CPER data starts,
> and not the beginning of the error sourc
On Wed, 25 Sep 2024 06:04:14 +0200
Mauro Carvalho Chehab wrote:
> Split the code into separate functions to allow using the
> common CPER filling code by different error sources.
>
> The generic code was moved to ghes_record_cper_errors(),
> and ghes_gen_err_data_uncorrectable_recoverable() now
On Wed, 25 Sep 2024 06:04:13 +0200
Mauro Carvalho Chehab wrote:
> The current code is actually dependent on having just one
> error structure with a single source.
>
> As the number of sources should be arch-dependent, as it
> will depend on what kind of synchronous/assynchronous
> notifications
On Wed, 25 Sep 2024 06:04:12 +0200
Mauro Carvalho Chehab wrote:
> HEST source ID is actually a 16-bit value
Indeed.
Reviewed-by: Jonathan Cameron
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> hw/acpi/ghes-stub.c| 2 +-
> hw/acpi/ghes.c | 2 +-
> include/hw/acpi/ghes.h | 2 +-
>
On Wed, 25 Sep 2024 06:04:11 +0200
Mauro Carvalho Chehab wrote:
> acpi_ghes_record_errors() has an assert() at the beginning
> to ensure that source_id will be lower than
> ACPI_GHES_ERROR_SOURCE_COUNT. Remove a duplicated check.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Igor Mamm
On Wed, 25 Sep 2024 06:04:10 +0200
Mauro Carvalho Chehab wrote:
> The first argument is source ID and not notification type.
Maybe call out that the header already differs from the two
implementations in naming this parameter. This just corrects
that.
>
> Signed-off-by: Mauro Carvalho Chehab
R
On Wed, 25 Sep 2024 06:04:09 +0200
Mauro Carvalho Chehab wrote:
> GHES has two fields that are stored on HEST error source
> blocks:
>
> - notification type, which is a number defined at the ACPI spec
> containing several arch-specific synchronous and assynchronous
> types;
> - source id, wh
On Wed, 25 Sep 2024 06:04:08 +0200
Mauro Carvalho Chehab wrote:
> The GHES driver requires not only a HEST table, but also a
> separate firmware file to store Error Structure records.
> It can't do one without the other.
>
> Simplify the caller logic for it to require one function.
>
> This pre
On Wed, 25 Sep 2024 06:04:07 +0200
Mauro Carvalho Chehab wrote:
> Reduce the ident of the function and prepares it for
> the next changes.
>
> No functional changes.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Igor Mammedov
Some of the alignment doesn't seem to match local style w
On Wed, 25 Sep 2024 06:04:06 +0200
Mauro Carvalho Chehab wrote:
> This is just duplicating ACPI_GHES_ERROR_SOURCE_COUNT, which
> has a better name. So, drop the duplication.
>
> Signed-off-by: Mauro Carvalho Chehab
> Reviewed-by: Igor Mammedov
FWIW
Reviewed-by: Jonathan Cameron
Plan is currently to meet at lpc registration desk 2pm tomorrow Wednesday and
we will find a room.
J
Jonathan Cameron
Mobile: +44-7870588074
Mail: jonathan.came...@huawei.com
From:Jonathan Cameron
mailto:jonathan.came...@huawei.com>>
To:John Groves mailto:j.
On Tue, 17 Sep 2024 11:09:16 +0300
Dmitry Frolov wrote:
> The sum offset + length may overflow uint32. Since this sum is
> compared with uint64_t return value of get_lsa_size(), it makes
> sense to choose uint64_t type for offset and length.
>
> Found by Linux Verification Center (linuxtesting.o
Given this is a new configuration, there are affects on APIC, CEDT
and DSDT, but the key elements are in SRAT (plus related data in
HMAT). The configuration has node to exercise many different combinations.
0) CPUs + Memory
1) GI only
2) GP only
3) CPUS only
4) Memory only
5) CPUs + HP memory
GI
Add a test with 6 nodes to exercise most interesting corner cases of SRAT
and HMAT generation including the new Generic Initiator and Generic Port
Affinity structures. More details of the set up in the following patch
adding the table data.
Signed-off-by: Jonathan Cameron
---
tests/qtest/bios-t
The test to be added exercises many corner cases of the SRAT and HMAT table
generation.
Signed-off-by: Jonathan Cameron
---
tests/qtest/bios-tables-test-allowed-diff.h | 5 +
tests/data/acpi/x86/q35/APIC.acpihmat-generic-x | 0
tests/data/acpi/x86/q35/CEDT.acpihmat-generic-x | 0
tests/d
>From review of the Generic Ports support.
These properties had no description set so add one.
Signed-off-by: Jonathan Cameron
---
v6: New patch based on Igor's review of Generic Ports patch.
---
hw/acpi/pci.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c
>From review of generic port introduction.
The value is handled as a uint32_t so store it in that type.
The value cannot in reality exceed MAX_NODES which is currently
128 but if the types are matched there is no need to rely on that
restriction.
Signed-off-by: Jonathan Cameron
---
v6: New patch
These are very similar to the recently added Generic Initiators
but instead of representing an initiator of memory traffic they
represent an edge point beyond which may lie either targets or
initiators. Here we add these ports such that they may
be targets of hmat_lb records to describe the latenc
To establish performance characteristics of a CXL device when used via a
particular CXL topology (root ports, switches, end points) it is necessary
to set the appropriate link speed and width in the PCI Express capability
structure. Provide x-speed and x-link properties for this.
Signed-off-by: J
To establish performance characteristics of a CXL device when used via a
particular CXL topology (root ports, switches, end points) it is necessary
to set the appropriate link speed and width in the PCI Express capability
structure. Provide x-speed and x-link properties for this.
Signed-off-by: J
Whilst similar to existing PCIESlot link configuration a few registers
need to be set differently so that the downstream device presents
a 'configured' state that is then used to 'train' the upstream port
on the link. Basically that means setting the status register to
reflect it succeeding in tra
Whilst not all link related registers are common between RP / Switch DSP
and EP / Switch USP many of them are. Factor that group out to save
on duplication when adding EP / Swtich USP configurability.
Signed-off-by: Jonathan Cameron
---
hw/pci/pcie.c | 87 ---
Copied from gen_pcie_root_port.c
Drop the previous code that ensured a valid value in s->width, s->speed
as now a default is provided so this will always be set.
Note this changes the default settings but it is unlikely to have a negative
effect on software as will only affect ports with now downs
Approach copied from gen_pcie_root_port.c
Previously the link defaulted to a maximum of 2.5GT/s and 1x. Enable setting
it's maximum values. The actual value after 'training' will depend on the
downstream device configuration.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/cxl_root_port.c |
Changes since RFC:
- rebase
Question:
- I could enable this for all PCIe device (including ports).
Does that makes sense, or is it better to limit this to my cases?
It is quite easy to build broken setups (downstream device reports
faster link than the port etc) because QEMU 'link' training'
Reduce the direct use of PCI internals inside ACPI table creation.
Suggested-by: Igor Mammedov
Tested-by: "Huang, Ying"
Reviewed-by: Igor Mammedov
Signed-off-by: Jonathan Cameron
---
hw/pci-host/gpex-acpi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/pci-host/gp
Rather than relying on PCI internals, use the new acpi_property
to obtain the ACPI _UID values. These are still the same
as the PCI Bus numbers so no functional change.
Suggested-by: Igor Mammedov
Tested-by: "Huang, Ying"
Reviewed-by: Igor Mammedov
Signed-off-by: Jonathan Cameron
---
hw/i386
Enable ACPI table creation for PCI Expander Bridges to be independent
of PCI internals. Note that the UID is currently the PCI bus number.
This is motivated by the forthcoming ACPI Generic Port SRAT entries
which can be made completely independent of PCI internals.
Suggested-by: Igor Mammedov
Te
Whilst ACPI SRAT Generic Initiator Afinity Structures are able to refer to
both PCI and ACPI Device Handles, the QEMU implementation only implements
the PCI Device Handle case. For now move the code into the existing
hw/acpi/pci.c file and header. If support for ACPI Device Handles is
added in th
Using a property allows us to hide the internal details of the PCI device
from the code to build a SRAT Generic Initiator Affinity Structure with
PCI Device Handle.
Suggested-by: Igor Mammedov
Reviewed-by: Igor Mammedov
Signed-off-by: Jonathan Cameron
---
hw/acpi/acpi_generic_initiator.c | 14
Igor noted that this function only builds one instance, so was rather
misleadingly named. Fix that.
Suggested-by: Igor Mammedov
Reviewed-by: Igor Mammedov
Tested-by: "Huang, Ying"
Signed-off-by: Jonathan Cameron
---
hw/acpi/acpi_generic_initiator.c | 4 ++--
1 file changed, 2 insertions(+), 2
Rather than attempting to create a generic function with mess of the two
different device handle types, use a PCI handle specific variant. If the
ACPI handle form is needed then that can be introduced alongside this
with little duplicated code.
Drop the PCIDeviceHandle in favor of just passing th
Before making additional modification, tidy up this misleading indentation.
Reviewed-by: Ankit Agrawal
Reviewed-by: Igor Mammedov
Tested-by: "Huang, Ying"
Signed-off-by: Jonathan Cameron
---
hw/acpi/acpi_generic_initiator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/h
The ordering in ACPI specification [1] has bus number in the lowest byte.
As ACPI tables are little endian this is the reverse of the ordering
used by PCI_BUILD_BDF(). As a minimal fix split the QEMU BDF up
into bus and devfn and write them as single bytes in the correct
order.
[1] ACPI Spec 6.3,
v6 changes:
- 2 new patches (11 and 12) to improve things in existing code after
Igor pointed them out in the new code.
- More detailed example provided for docs for control of Generic Ports.
This has proved a difficult concept to convey.
Note there is one question Igor raised for Markus:
-
On Thu, 12 Sep 2024 14:38:26 +0100
Alireza Sanaee wrote:
> This commit adds IsDefined flag to the object and this helps in avoiding
> extra checks for every single layer of caches in both x86 and ARM.
Hi Ali,
You mention x86 here, but no code changes to support that?
Jonathan
>
> Signed-off-b
On Fri, 13 Sep 2024 07:20:25 +0200
Mauro Carvalho Chehab wrote:
> Em Thu, 12 Sep 2024 14:42:33 +0200
> Igor Mammedov escreveu:
>
> > On Wed, 11 Sep 2024 16:34:36 +0100
> > Jonathan Cameron wrote:
> >
> > > On Wed, 11 Sep 2024 15:21:32 +0200
> > > Igor Mammedov wrote:
> > >
> > > > On Su
On Wed, 11 Sep 2024 15:21:32 +0200
Igor Mammedov wrote:
> On Sun, 25 Aug 2024 05:29:23 +0200
> Mauro Carvalho Chehab wrote:
>
> > Em Mon, 19 Aug 2024 14:51:36 +0200
> > Igor Mammedov escreveu:
> >
> > > > +read_ack = 1;
> > > > +cpu_physical_memory_write(read_ack_start_addr,
On Tue, 10 Sep 2024 12:01:05 +0100
Salil Mehta wrote:
> HI Zhao,
A few trivial comments inline.
>
> > From: Zhao Liu
> > Sent: Monday, September 9, 2024 4:28 PM
> > To: Salil Mehta
> >
> > On Wed, Sep 04, 2024 at 05:37:21PM +, Salil Mehta wrote:
> > > Date: Wed, 4 Sep 2024 17:37
On Fri, 30 Aug 2024 12:15:55 +0800
Yuquan Wang wrote:
> RFC because
> - Many contents are ported from Jonathan' patch on qemu virt design
>
> - Bring plenty of PCDs values and modifying the original PCIE values
>
> - Less experience and not particularly confident in ACPI area so this might be
>
On Fri, 30 Aug 2024 10:11:17 +0800
Yuquan Wang wrote:
One request - when cross posting to multiple lists, it is useful to
add something to the patch title to make it clear what is EDK2, what
is QEMU etc.
[RFC EDK2 PATCH 1/1]
It might irritate the EDK2 folk but it is useful for everyone else
to
On Fri, 30 Aug 2024 11:15:44 +0800
Yuquan Wang wrote:
> This adds relevant definitions and descriptions of acpi0016 and
> acpi0017 to support CXL.
>
> With the implementation of pxb-cxl on the original pcie host bridge,
> the previous space layout of mmio32 & mmio64 have to be divided to
> provi
On Fri, 30 Aug 2024 11:15:45 +0800
Yuquan Wang wrote:
> Provide CXL Early Discovery Table that describes the static CXL
> Platform Components of sbsa-ref.
>
> This adds a static CXL Host Bridge structure and a CXL Fixed Memory
> Window structure which are implemented as two independent space on
On Fri, 30 Aug 2024 12:15:57 +0800
Yuquan Wang wrote:
> In order to provide CFMWs on sbsa-ref, this extends 1TB space
> from the hole above RAM Memory [SBSA_MEM] for CXL Fixed Memory
> Window. 0xA00 is chosen as the base address of this
> space because of 3 reasons:
>
> 1) It is more sui
On Fri, 30 Aug 2024 12:15:56 +0800
Yuquan Wang wrote:
> The memory layout places 1M space for 16 host bridge register regions
> in the sbsa-ref memmap. In addition, this creates a default pxb-cxl
> (bus_nr=0xfe) bridge with one cxl-rp on sbsa-ref.
If you are only supporting 1 host bridge you cou
On Fri, 12 Jul 2024 13:24:08 +0100
Jonathan Cameron wrote:
> Based-on: [PATCH v5 00/13] acpi: NUMA nodes for CXL HB as GP + complex NUMA
> test
> Based-on: Message-ID: 20240712110837.1439736-1-jonathan.came...@huawei.com
Hi All,
I'd like to get this missing piece in 9.2. So if anyone has time
On Mon, 15 Jul 2024 16:48:41 +0200
Igor Mammedov wrote:
> On Fri, 12 Jul 2024 12:08:14 +0100
> Jonathan Cameron wrote:
>
> > These are very similar to the recently added Generic Initiators
> > but instead of representing an initiator of memory traffic they
> > represent an edge point beyond whi
On Tue, 27 Aug 2024 09:40:04 -0700
nifan@gmail.com wrote:
> From: Fan Ni
>
> Per cxl spec r3.1, for multiple dynamic capacity event records grouped via
> the More flag, the last record in the sequence should clear the More flag.
>
> Before the change, the More flag of the event record is cl
On Tue, 27 Aug 2024 09:40:05 -0700
nifan@gmail.com wrote:
> From: Fan Ni
>
> When inserting multiple dynamic capacity event records grouped via More flag,
> we should only trigger interrupt after the last record is inserted into the
> event log. Achieving the goal by letting cxl_event_insert
On Tue, 27 Aug 2024 16:01:54 +
ajay.opensrc wrote:
> > From: Davidlohr Bueso
> >
> > On Mon, 29 Jul 2024, ajay.open...@micron.com wrote:\n
> > >From: Ajay Joshi
> > >
> > >The current completion percentage calculation does not account for the
> > >relative time since the start of the bac
On Tue, 13 Aug 2024 15:12:55 -0700
Davidlohr Bueso wrote:
> As of 3.1 spec, background commands can be canceled with a new
> abort command. Implement the support, which is advertised in
> the CEL. No ad-hoc context undoing is necessary as all the
> command logic of the running bg command is done
On Sun, 28 Apr 2024 16:00:45 +0900
Akihiko Odaki wrote:
> Since qemu_set_vnet_hdr_len() is always called when
> qemu_using_vnet_hdr() is called, we can merge them and save some code.
>
> For consistency, express that the virtio-net header is not in use by
> returning 0 with qemu_get_vnet_hdr_len
On Fri, 16 Aug 2024 07:53:24 +0200
Mauro Carvalho Chehab wrote:
> Em Wed, 14 Aug 2024 13:33:21 +0100
> Jonathan Cameron escreveu:
>
> > On Wed, 14 Aug 2024 01:23:23 +0200
> > Mauro Carvalho Chehab wrote:
> >
> > > Adds a generic error device to handle generic hardware error
> > > events as
On Wed, 14 Aug 2024 01:23:26 +0200
Mauro Carvalho Chehab wrote:
> Creates a QMP command to be used for generic ACPI APEI hardware error
> injection (HEST) via GHESv2.
>
> The actual GHES code will be added at the followup patch.
>
> Signed-off-by: Mauro Carvalho Chehab
> Signed-off-by: Shiju J
On Wed, 14 Aug 2024 01:23:25 +0200
Mauro Carvalho Chehab wrote:
> From: Jonathan Cameron
>
> As a GED error device is now defined, add another type
> of notification.
>
> Add error notification to GHES v2 using a GED error device GED
> triggered via interrupt.
>
> [mchehab: do some cleanups a
On Wed, 14 Aug 2024 01:23:24 +0200
Mauro Carvalho Chehab wrote:
> Adds support to ARM virtualization to allow handling
> generic error ACPI Event via GED & error source device.
>
> It is aligned with Linux Kernel patch:
> https://lore.kernel.org/lkml/1272350481-27951-8-git-send-email-ying.hu...@
On Wed, 14 Aug 2024 01:23:23 +0200
Mauro Carvalho Chehab wrote:
> Adds a generic error device to handle generic hardware error
> events as specified at ACPI 6.5 specification at 18.3.2.7.2:
> https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#event-notification-for-generic-error-so
On Thu, 08 Aug 2024 19:51:26 +0200
Markus Armbruster wrote:
> Hi Jonathan,
>
> You added the type in commit 415442a1b4a (hw/mem/cxl_type3: Add CXL RAS
> Error Injection Support.) The doc comment is missing a description of
> @retry-threshold. Can you supply me one? I'm happy to do the actual
On Tue, 6 Aug 2024 16:31:13 +0200
Igor Mammedov wrote:
> On Fri, 2 Aug 2024 23:44:01 +0200
> Mauro Carvalho Chehab wrote:
>
> > Provide a generic interface for error injection via GHESv2.
> >
> > This patch is co-authored:
> > - original ghes logic to inject a simple ARM record by Shiju J
On Wed, 7 Aug 2024 09:47:50 +0200
Mauro Carvalho Chehab wrote:
> Em Tue, 6 Aug 2024 16:31:13 +0200
> Igor Mammedov escreveu:
>
> > PS:
> > looking at the code, ACPI_GHES_MAX_RAW_DATA_LENGTH is 1K
> > and it is the total size of a error block for a error source.
> >
> > However acpi_hest_ghes.r
On Fri, 2 Aug 2024 23:44:01 +0200
Mauro Carvalho Chehab wrote:
> Provide a generic interface for error injection via GHESv2.
>
> This patch is co-authored:
> - original ghes logic to inject a simple ARM record by Shiju Jose;
> - generic logic to handle block addresses by Jonathan Camero
On Fri, 2 Aug 2024 23:44:00 +0200
Mauro Carvalho Chehab wrote:
> Creates a QMP command to be used for generic ACPI APEI hardware error
> injection (HEST) via GHESv2.
>
> The actual GHES code will be added at the followup patch.
>
> Signed-off-by: Mauro Carvalho Chehab
Looks good to me.
Review
On Fri, 2 Aug 2024 23:43:59 +0200
Mauro Carvalho Chehab wrote:
> From: Jonathan Cameron
>
> Add error notification to GHES v2 using the GPIO source.
The gpio / external interrupt follows through.
>
> [mchehab: do some cleanups at ACPI_HEST_SRC_ID_* checks]
>
> Signed-off-by: Jonathan Camer
On Fri, 2 Aug 2024 23:43:58 +0200
Mauro Carvalho Chehab wrote:
Do we need to rename this now there is a GED involved?
Is it even technically a GPIO any more?
Spec says in 18.3.2.7
HW-reduced ACPI platforms signal the error using a GPIO
interrupt or another interrupt declared under
a generic eve
On Fri, 2 Aug 2024 23:43:57 +0200
Mauro Carvalho Chehab wrote:
> Adds a Generic Event Device to handle generic hardware error
> events, supporting General Purpose Event (GPE) as specified at
> ACPI 6.5 specification at 18.3.2.7.2:
> https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.ht
On Fri, 26 Apr 2024 03:36:07 +
"Zhijian Li (Fujitsu)" wrote:
> ping
>
>
Hi.
I'm going to drop this again from my tree as it breaks the CDAT DOE
(I was testing Dave's patches with Mike's numa memblk and access0/1
were empty :(
I haven't looked in detail but it's probably because each PCIe
On Thu, 1 Aug 2024 14:56:37 +0200
Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2024 10:40:28 +0200
> Igor Mammedov escreveu:
>
> > > diff --git a/include/hw/acpi/ghes.h b/include/hw/acpi/ghes.h
> > > index 674f6958e905..4f1ab1a73a06 100644
> > > --- a/include/hw/acpi/ghes.h
> > > +++ b/include
On Wed, 31 Jul 2024 09:11:33 +0200
Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2024 13:17:09 +0200
> Igor Mammedov escreveu:
>
> > On Mon, 22 Jul 2024 08:45:56 +0200
> > Mauro Carvalho Chehab wrote:
> >
> > that's quite a bit of code that in 99% won't ever be used
> > (assuming error inject
On Tue, 30 Jul 2024 07:13:30 +0200
Mauro Carvalho Chehab wrote:
> Em Mon, 29 Jul 2024 17:08:40 +0100
> Jonathan Cameron escreveu:
>
> > On Mon, 29 Jul 2024 15:21:06 +0200
> > Mauro Carvalho Chehab wrote:
> >
> > > From: Jonathan Cameron
> > >
> > > Creates a Generic Event Device (GED) as
On Mon, 29 Jul 2024 15:21:10 +0200
Mauro Carvalho Chehab wrote:
> Add an ACPI APEI GHES error injection logic for ARM
> processor CPER, allowing to set fields at from
> UEFI spec 2.10 tables N.16 and N.17 to any valid
> value.
>
> As some GHES functions require handling addresses, add
> a helper
On Mon, 29 Jul 2024 15:21:06 +0200
Mauro Carvalho Chehab wrote:
> From: Jonathan Cameron
>
> Creates a Generic Event Device (GED) as specified at
I wrote this a while back and wasn't aware of the naming
mess around GED in the ACPI spec. This one is just
referred to as 'error device' whereas t
On Thu, 25 Jul 2024 14:50:50 +0100
David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at 01:2
On Mon, 22 Jul 2024 08:45:59 +0200
Mauro Carvalho Chehab wrote:
> Enrich CPER error injection logic for ARM processor to allow
> setting values to from UEFI 2.10 tables N.16 and N.17.
>
> It should be noticed that, with such change, all arguments are
> now optional, so, once QMP is negotiated w
On Mon, 22 Jul 2024 08:45:57 +0200
Mauro Carvalho Chehab wrote:
> There is a logic at helper to properly fill the mpidr information.
> This is needed for ARM Processor error injection, so store the
> value inside a cpu opaque value, to allow it to be used.
>
> Signed-off-by: Mauro Carvalho Cheha
A few quick replies from me.
I'm sure Mauro will add more info.
> > + 'tlb-error',
> > + 'bus-error',
> > + 'micro-arch-error']
> > +}
> > +
> > +##
> > +# @arm-inject-error:
> > +#
> > +# Inject ARM Processor error.
> > +#
> > +# @errortypes: ARM processor error type
On Mon, 22 Jul 2024 08:45:56 +0200
Mauro Carvalho Chehab wrote:
> From: Jonathan Cameron
>
> 1. Some GHES functions require handling addresses. Add a helper function
>to support it.
>
> 2. Add support for ACPI CPER (firmware-first) ARM processor error injection.
>
> Compliance with N.2.4.
On Mon, 22 Jul 2024 08:45:54 +0200
Mauro Carvalho Chehab wrote:
> From: Jonathan Cameron
>
> Creates a GED - Generic Event Device and set a GPIO to
The wonder of confusing names in ACPI. I thought I'd
fixed this but clearly not.
This GED isn't a Generic Event Device, it's a
Generic Error (De
On Fri, 19 Jul 2024 16:29:26 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Add CPUID enumeration for intel RDT monitoring and allocation, as well
> as the flags used in the enumeration code.
>
> Signed-off-by: Hendrik Wüthrich
> ---
> hw/i386/rdt.c | 29 ++
On Fri, 19 Jul 2024 16:29:25 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Implement rdmsr and wrmsr for the following MSRs:
> * MSR_IA32_PQR_ASSOC
> * MSR_IA32_QM_EVTSEL
> * MSR_IA32_QM_CTR
> * IA32_L3_QOS_Mask_n
> * IA32_L2_QOS_Mask_n
> * IA32_L2_QoS_Ext_BW_Thrtl_n
>
> This al
On Fri, 19 Jul 2024 16:29:24 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Add RDT code to Associate CLOSID with RMID / set RMID for monitoring,
> write COS, and read monitoring data. This patch does not add code for
> the guest to interact through these things with MSRs, only th
On Fri, 19 Jul 2024 16:29:23 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Add code to initialize all necessary state for the RDT device.
>
> Signed-off-by: Hendrik Wüthrich
> ---
> hw/i386/rdt.c | 28
> 1 file changed, 28 insertions(+)
>
> diff -
On Fri, 19 Jul 2024 16:29:23 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Add code to initialize all necessary state for the RDT device.
>
> Signed-off-by: Hendrik Wüthrich
Spell check (typo in patch title).
On Fri, 19 Jul 2024 16:29:22 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Add structures and variables needed to emulate Intel RDT, including
> module-internal sturctures and state in ArchCPU. No functionality yet.
>
> Signed-off-by: Hendrik Wüthrich
A few general comments inl
On Fri, 19 Jul 2024 16:29:21 +
Hendrik Wuethrich wrote:
> From: Hendrik Wüthrich
>
> Change config to show RDT, add minimal code to the rdt.c module to make
> sure things still compile.
>
> Signed-off-by: Hendrik Wüthrich
Hi Hendrik
Great to see emulation of this. Will be handy for tes
On Wed, 24 Jul 2024 07:53:48 +0300
Michael Tokarev wrote:
> 05.07.2024 14:39, Jonathan Cameron via wrote:
> > From: Zhao Liu
> >
> > QEMU crashes (Segmentation fault) when getting cxl-fmw property via
> > qmp:
> >
> > (QEMU) qom-get path=machine propert
On Thu, 25 Jul 2024 11:50:59 +0100
Jonathan Cameron wrote:
Resending as this bounced due (I think) to an address typo.
> Hi Markus, Zhao Liu
>
> From the ARM server side this is something I want to see as well.
> So I can comment on why we care.
>
> > >> This series adds a way to configure cac
On Fri, 19 Jul 2024 12:57:33 +0800
luzhixing12345 wrote:
> Add more information with CXL type1 and type2 devices.
>
> Original doc says "May also have device private memory accessible
> via means such as PCI memory reads and writes to BARs.", but actually
> CXL type1 devices doesn't have device
On Thu, 18 Jul 2024 05:07:53 -0400
Yao Xingtao wrote:
> When injecting a new poisoned region through qmp_cxl_inject_poison(),
> the newly injected region should not overlap with existing poisoned
> regions.
>
> The current validation method does not consider the following
> overlapping region:
>
On Wed, 17 Jul 2024 11:11:06 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Jul 17, 2024 at 04:02:58PM +0100, Jonathan Cameron wrote:
> > On Mon, 15 Jul 2024 16:48:41 +0200
> > Igor Mammedov wrote:
> >
> > > On Fri, 12 Jul 2024 12:08:14 +0100
> > > Jonathan Cameron wrote:
> > >
> > > > These
On Fri, 12 Jul 2024 15:15:08 +0200
Mauro Carvalho Chehab wrote:
> Having magic numbers inside the code is not a good idea, as it
> is error-prone. So, instead, create a macro with the number
> definition.
>
> Signed-off-by: Mauro Carvalho Chehab
Seems sensible to me.
Reviewed-by: Jonathan Cam
On Mon, 15 Jul 2024 16:48:41 +0200
Igor Mammedov wrote:
> On Fri, 12 Jul 2024 12:08:14 +0100
> Jonathan Cameron wrote:
>
> > These are very similar to the recently added Generic Initiators
> > but instead of representing an initiator of memory traffic they
> > represent an edge point beyond whi
On Fri, 5 Jul 2024 13:30:38 +0100
Jonathan Cameron wrote:
> From: Shiju Jose
>
> CXL spec 3.1 section 8.2.9.9.11.2 describes the DDR5 Error Check Scrub (ECS)
> control feature.
Hi Michael / all,
Silly stray white space issue inline that checkpatch will catch.
> diff --git a/hw/mem/cxl_type3.
To establish performance characteristics of a CXL device when used via a
particular CXL topology (root ports, switches, end points) it is necessary
to set the appropriate link speed and width in the PCI Express capability
structure. Provide x-speed and x-link properties for this.
Signed-off-by: J
To establish performance characteristics of a CXL device when used via a
particular CXL topology (root ports, switches, end points) it is necessary
to set the appropriate link speed and width in the PCI Express capability
structure. Provide x-speed and x-link properties for this.
Signed-off-by: J
1 - 100 of 1184 matches
Mail list logo
