qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: qemu-devel@nongnu.org, "Fan Ni" <fan.ni@samsung.com>,
	linux-cxl@vger.kernel.org, linuxarm@huawei.com,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Alison Schofield" <alison.schofield@intel.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	"Mike Maslenkin" <mike.maslenkin@gmail.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>
Subject: Re: [PATCH v5 0/6] hw/cxl: Poison get, inject, clear
Date: Fri, 19 May 2023 04:49:46 -0400	[thread overview]
Message-ID: <20230519030942-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230423162013.4535-1-Jonathan.Cameron@huawei.com>

On Sun, Apr 23, 2023 at 05:20:07PM +0100, Jonathan Cameron wrote:
> v5: More details in each patch.
>  - Simpler algorithm to find entry when clearing.
>  - Improvements to debugability and docs for 24 bit endian functions.
>  - Use of ROUND_DOWN() to simplify the various alignment questions.
>  - Use CXL_CACHELINE_SIZE define to explain the mysterious 64 byte
>    granularity
>  - Use memory_region_size() instead of direct accesses.


picked first 3 but dropped the rest for now due to build errors.

> Many of the precursors listed for v4 have now been applied, but
> a few minor fixes have come up in the meantime so there are still
> a few precursors including the volatile support left from v4
> precursors.
> 
> Depends on 
> [PATCH 0/2] hw/cxl: CDAT file handling fixes.
> [PATCH v2 0/3] hw/cxl: Fix decoder commit and uncommit handling
> [PATCH 0/3] docs/cxl: Gathering of fixes for 8.0 CXL docs.
> [PATCH v5 0/3] hw/mem: CXL Type-3 Volatile Memory Support
>  
> Based on: Message-ID: 20230421132020.7408-1-Jonathan.Cameron@huawei.com
> Based on: Message-ID: 20230421135906.3515-1-Jonathan.Cameron@huawei.com
> Based on: Message-ID: 20230421134507.26842-1-Jonathan.Cameron@huawei.com
> Based on: Message-ID: 20230421160827.2227-1-Jonathan.Cameron@huawei.com
> 
> The kernel support for Poison handling is currently in the cxl/pending
> branch and hopefully should be in the CXL pull request next week.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git/log/?h=pending
> 
> This code has been very useful for testing and helped identify various
> corner cases.
> 
> Updated cover letter.
> 
> The series supports:
> 1) Injection of variable length poison regions via QMP (to fake real
>    memory corruption and ensure we deal with odd overflow corner cases
>    such as clearing the middle of a large region making the list overflow
>    as we go from one long entry to two smaller entries.
> 2) Read of poison list via the CXL mailbox.
> 3) Injection via the poison injection mailbox command (limited to 64 byte
>    entries - spec constraint)
> 4) Clearing of poison injected via either method.
> 
> The implementation is meant to be a valid combination of impdef choices
> based on what the spec allowed. There are a number of places where it could
> be made more sophisticated that we might consider in future:
> * Fusing adjacent poison entries if the types match.
> * Separate injection list and main poison list, to test out limits on
>   injected poison list being smaller than the main list.
> * Poison list overflow event (needs event log support in general)
> * Connecting up to the poison list error record generation (rather complex
>   and not needed for currently kernel handling testing).
> * Triggering the synchronous and asynchronous errors that occur on reads
>   and writes of the memory when the host receives poison.
> 
> As the kernel code is currently fairly simple, it is likely that the above
> does not yet matter but who knows what will turn up in future!
> 
> 
> Ira Weiny (2):
>   hw/cxl: Introduce cxl_device_get_timestamp() utility function
>   bswap: Add the ability to store to an unaligned 24 bit field
> 
> Jonathan Cameron (4):
>   hw/cxl: rename mailbox return code type from ret_code to CXLRetCode
>   hw/cxl: QMP based poison injection support
>   hw/cxl: Add poison injection via the mailbox.
>   hw/cxl: Add clear poison mailbox command support.
> 
>  docs/devel/loads-stores.rst |   1 +
>  hw/cxl/cxl-device-utils.c   |  15 ++
>  hw/cxl/cxl-mailbox-utils.c  | 289 ++++++++++++++++++++++++++++++------
>  hw/mem/cxl_type3.c          |  93 ++++++++++++
>  hw/mem/cxl_type3_stubs.c    |   6 +
>  include/hw/cxl/cxl.h        |   1 +
>  include/hw/cxl/cxl_device.h |  23 +++
>  include/qemu/bswap.h        |  25 ++++
>  qapi/cxl.json               |  18 +++
>  9 files changed, 429 insertions(+), 42 deletions(-)
> 
> -- 
> 2.37.2



  parent reply	other threads:[~2023-05-19  8:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-23 16:20 [PATCH v5 0/6] hw/cxl: Poison get, inject, clear Jonathan Cameron via
2023-04-23 16:20 ` [PATCH v5 1/6] hw/cxl: rename mailbox return code type from ret_code to CXLRetCode Jonathan Cameron via
2023-04-23 16:20 ` [PATCH v5 2/6] hw/cxl: Introduce cxl_device_get_timestamp() utility function Jonathan Cameron via
2023-04-23 16:20 ` [PATCH v5 3/6] bswap: Add the ability to store to an unaligned 24 bit field Jonathan Cameron via
2023-05-19 11:33   ` Jonathan Cameron via
2023-05-19 13:42     ` Jonathan Cameron via
2023-04-23 16:20 ` [PATCH v5 4/6] hw/cxl: QMP based poison injection support Jonathan Cameron via
2023-05-22  6:38   ` Markus Armbruster
2023-04-23 16:20 ` [PATCH v5 5/6] hw/cxl: Add poison injection via the mailbox Jonathan Cameron via
2023-04-23 16:20 ` [PATCH v5 6/6] hw/cxl: Add clear poison mailbox command support Jonathan Cameron via
2023-05-19  7:05   ` Michael S. Tsirkin
2023-05-19  9:21     ` Jonathan Cameron via
2023-05-19  8:49 ` Michael S. Tsirkin [this message]
2023-05-19 11:07   ` [PATCH v5 0/6] hw/cxl: Poison get, inject, clear Jonathan Cameron via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230519030942-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dave.jiang@intel.com \
    --cc=eblake@redhat.com \
    --cc=fan.ni@samsung.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=mike.maslenkin@gmail.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).