public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gregory.price@memverge.com>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-cxl@vger.kernel.org
Subject: Re: Accessing emulated CXL memory is unstable
Date: Sun, 8 Oct 2023 09:29:09 -0400	[thread overview]
Message-ID: <ZSKupRw+mRrASUaY@memverge.com> (raw)
In-Reply-To: <CAB=+i9S4NSJ7iNvqguWKvFvo=cMQC21KeNETsqmJoEpj+iDmig@mail.gmail.com>

On Tue, Oct 10, 2023 at 10:35:03AM +0900, Hyeonggon Yoo wrote:
> Hello folks,
> 
> I experienced strange application crashes/internal KVM errors
> while playing with emulated type 3 CXL memory. I would like to know
> if this is a real issue or I missed something during setup.
> 
> TL;DR: applications crash when accessing emulated CXL memory,
> and stressing VM subsystem causes KVM internal error
> (stressing via stress-ng --bigheap)
>
...
> 
> Hmm... it crashed, and it's 'invalid opcode'.
> Is this because the fetched instruction is different from what's
> written to memory during exec()?
> 

This is a known issue, and the working theory is 2 issues:

1) CXL devices are implemented on top of an MMIO-style dispatch system
   and as a result memory from CXL is non-cacheable.  We think there
   may be an issue with this in KVM but it hasn't been investigated
   fully.

2) When we originally got CXL memory support, we discovered an edge case
   where code pages hosted on CXL memory would cause a crash whenever an
   instruction spanned across a page barrier.  A similar issue could
   affect KVM.

We haven't done much research into the problem beyond this.  For now, we
all just turn KVM off while we continue development.

~Gregory

  reply	other threads:[~2023-10-10 15:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  1:35 Accessing emulated CXL memory is unstable Hyeonggon Yoo
2023-10-08 13:29 ` Gregory Price [this message]
2023-10-11  0:50   ` Hyeonggon Yoo
2023-10-11 14:10     ` Jonathan Cameron

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=ZSKupRw+mRrASUaY@memverge.com \
    --to=gregory.price@memverge.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vishal.l.verma@intel.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