From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
Davidlohr Bueso <dave@stgolabs.net>, <x86@kernel.org>,
<nvdimm@lists.linux.dev>, <linux-cxl@vger.kernel.org>,
<peterz@infradead.org>, <akpm@linux-foundation.org>,
<dave.jiang@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <a.manzanares@samsung.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] memregion: Add arch_flush_memregion() interface
Date: Thu, 8 Sep 2022 14:00:11 +0100 [thread overview]
Message-ID: <20220908140011.000003e8@huawei.com> (raw)
In-Reply-To: <6319916ba0f9d_5801629437@dwillia2-xfh.jf.intel.com.notmuch>
On Wed, 7 Sep 2022 23:53:31 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> Borislav Petkov wrote:
> > On Wed, Sep 07, 2022 at 09:52:17AM -0700, Dan Williams wrote:
> > > To be clear nfit stuff and CXL does run in guests, but they do not
> > > support secure-erase in a guest.
> > >
> > > However, the QEMU CXL enabling is building the ability to do *guest
> > > physical* address space management, but in that case the driver can be
> > > paravirtualized to realize that it is not managing host-physical address
> > > space and does not need to flush caches. That will need some indicator
> > > to differentiate virtual CXL memory expanders from assigned devices.
> >
> > Sounds to me like that check should be improved later to ask
> > whether the kernel is managing host-physical address space, maybe
> > arch_flush_memregion() should check whether the address it is supposed
> > to flush is host-physical and exit early if not...
>
> Even though I raised the possibility of guest passthrough of a CXL
> memory expander, I do not think it could work in practice without it
> being a gigantic security nightmare. So it is probably safe to just do
> the hypervisor check and assume that there's no such thing as guest
> management of host physical address space.
Agreed. Other than occasional convenience of doing driver development
in a VM (they reboot quickly ;) can't see why a product system would need
to pass a CXL type 3 device through and as you say security would be 'interesting'
if it were done. Might be GPU usecases down the line but I'm doubtful on that
as well.
Jonathan
next prev parent reply other threads:[~2022-09-08 13:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 21:29 [PATCH -next] memregion: Add arch_flush_memregion() interface Davidlohr Bueso
2022-08-29 23:02 ` Dan Williams
2022-09-07 14:36 ` Davidlohr Bueso
2022-09-07 16:46 ` Dan Williams
2022-09-07 16:05 ` Borislav Petkov
2022-09-07 16:22 ` Davidlohr Bueso
2022-09-07 16:52 ` Dan Williams
2022-09-07 17:24 ` Davidlohr Bueso
2022-09-08 4:35 ` Borislav Petkov
2022-09-08 6:53 ` Dan Williams
2022-09-08 13:00 ` Jonathan Cameron [this message]
2022-09-08 4:31 ` Borislav Petkov
2022-09-07 22:30 ` Andrew Morton
2022-09-08 1:07 ` Dan Williams
2022-09-08 13:13 ` Jonathan Cameron
2022-09-08 22:51 ` Dan Williams
2022-09-08 23:00 ` Andrew Morton
2022-09-08 23:22 ` Dan Williams
2022-09-09 11:43 ` Jonathan Cameron
2022-09-13 15:56 ` Davidlohr Bueso
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=20220908140011.000003e8@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.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