Re: [GIT preview] for-6.3/cxl-ram-region

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Wed, 1 Feb 2023 19:44:47 -0500
Gregory Price <gregory.price@memverge.com> wrote:

> On Thu, Feb 02, 2023 at 10:18:33AM -0800, Dan Williams wrote:
> > Gregory Price wrote:
> > [..]  
> > > To me, the solution here isn't to change QEMU, it's to change the kernel
> > > to try to get it to aggressively keep executable regions out of CXL by
> > > marking CXL regions into a new zone type that essentially says "Use this
> > > as a last resort only for X pages".  But that would likely require
> > > adding migration code to the likes of mprotect and friends.  
> > 
> > No, this can't be the path forward as far as I can see. QEMU is a test
> > vehicle for CXL enabling, there's no expectation that QEMU is running
> > CXL emulation in production. The quirks of how the QEMU-CXL memory
> > behaves are not something the kernel should worry about mitigating. CXL
> > is "System RAM" especially in the case when it is mapped by
> > platform-firmware. If it's not suitable to be treated as "System RAM"
> > then the onus is on platform-firmware to keep it out of the general
> > purpose pool.
> >   
> 
> Eh, you're right, just spitballing.  On real hardware this isn't an
> issue so there's no reason to change the kernel.  QEMU should just model
> the hardware.

FYI.  Richard Henderson has posted a fix. 
We should be fine going forwards on QEMU TCG. Waiting on confirmation
that it fixes the reported the instruction straddling the QEMU normal
to MMIO boundary, but looks right to me (and it's confirmed to fix
a different issue that hit same restriction).  Thanks Richard!

https://lore.kernel.org/qemu-devel/20230206193809.1153124-1-richard.henderson@linaro.org/

I hadn't even gotten a reproducer up yet so very much appreciate that
I might not have to ;)

Jonathan