From: "Jørgen Hansen" <Jorgen.Hansen@wdc.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Gregory Price <gregory.price@memverge.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>
Subject: Re: [RFC] CXL: TCG/KVM instruction alignment issue discussion default
Date: Wed, 1 Mar 2023 14:51:52 +0000 [thread overview]
Message-ID: <e199668a-c808-ef35-3e75-7e3d95bdf990@wdc.com> (raw)
In-Reply-To: <20230228104916.00003d9a@Huawei.com>
On 2/28/23 11:49, Jonathan Cameron wrote:
>>> Second there's the performance issue:
>>>
>>> 0) Do we actually care about performance? How likely are users to
>>> attempt to run software out of CXL memory?
>>>
>>> 1) If we do care, is there a potential for converting CXL away from the
>>> MMIO design? The issue is coherency for shared memory. Emulating
>>> coherency is a) hard, and b) a ton of work for little gain.
>>>
>>> Presently marking CXL memory as MMIO basically enforces coherency by
>>> preventing caching, though it's unclear how this is enforced
>>> by KVM (or if it is, i have to imagine it is).
>>
>> Having the option of doing device specific processing of accesses to a
>> CXL type 3 device (that the MMIO based access allows) is useful for
>> experimentation with device functionality, so I would be sad to see that
>> option go away. Emulating cache line access to a type 3 device would be
>> interesting, and could potentially be implemented in a way that would
>> allow caching of device memory in a shadow page in RAM, but that it a
>> rather large project.
>
> Absolutely agree. Can sketch a solution that is entirely in QEMU and
> works with KVM on a white board, but it doesn't feel like a small job
> to actually implement it and I'm sure there are nasty corners
> (persistency is going to be tricky)
>
> If anyone sees this as a 'fun challenge' and wants to take it on though
> that would be great!
I'd be interested in getting more details on your thoughts on this and
potentially work on it. We'd like to get closer to the CXL.mem traffic
that a physical system would see, ideally seeing read requests only on
LLC cache misses - although that seems hard to achieve.
Thanks,
Jorgen
next prev parent reply other threads:[~2023-03-01 14:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 10:22 [RFC] CXL: TCG/KVM instruction alignment issue discussion default Gregory Price
2023-02-27 11:06 ` Jørgen Hansen
2023-02-28 10:49 ` Jonathan Cameron
2023-03-01 14:51 ` Jørgen Hansen [this message]
2023-03-02 1:17 ` Ajay Joshi
2023-02-28 12:42 ` Philippe Mathieu-Daudé
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=e199668a-c808-ef35-3e75-7e3d95bdf990@wdc.com \
--to=jorgen.hansen@wdc.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=gregory.price@memverge.com \
--cc=linux-cxl@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/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