From: Sean Christopherson <seanjc@google.com>
To: Jack Allister <jalliste@amazon.co.uk>
Cc: Ivan Orlov <iorlov@amazon.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>, "bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"nh-open-source@amazon.com" <nh-open-source@amazon.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 0/4] Process some MMIO-related errors without KVM exit
Date: Mon, 23 Sep 2024 14:46:17 -0700 [thread overview]
Message-ID: <ZvHhqRWW04jmk8TW@google.com> (raw)
In-Reply-To: <cb06b33acdad04bef8c9541b4247a36f51cf2d36.camel@amazon.co.uk>
On Mon, Sep 23, 2024, Jack Allister wrote:
> On Mon, 2024-09-23 at 10:04 -0700, Sean Christopherson wrote:
> >
> > On Mon, Sep 23, 2024, Ivan Orlov wrote:
> > > Currently, KVM may return a variety of internal errors to VMM when
> > > accessing MMIO, and some of them could be gracefully handled on the
> > > KVM
> > > level instead. Moreover, some of the MMIO-related errors are
> > > handled
> > > differently in VMX in comparison with SVM, which produces certain
> > > inconsistency and should be fixed. This patch series introduces
> > > KVM-level handling for the following situations:
> > >
> > > 1) Guest is accessing MMIO during event delivery: triple fault
> > > instead
> > > of internal error on VMX and infinite loop on SVM
> > >
> > > 2) Guest fetches an instruction from MMIO: inject #UD and resume
> > > guest
> > > execution without internal error
> >
> > No. This is not architectural behavior. It's not even remotely
> > close to
> > architectural behavior. KVM's behavior isn't great, but making up
> > _guest visible_
> > behavior is not going to happen.
>
> Is this a no to the whole series or from the cover letter?
The whole series.
> For patch 1 we have observed that if a guest has incorrectly set it's
> IDT base to point inside of an MMIO region it will result in a triple
> fault (bare metal Cascake Lake Intel).
That happens because the IDT is garbage and/or the CPU is getting master abort
semantics back, not because anything in the x86 architectures says that accessing
MMIO during exception vectoring goes straight to shutdown.
> Yes a sane operating system is not really going to be doing setting it's IDT
> or GDT base to point into an MMIO region, but we've seen occurrences.
> Normally when other external things have gone horribly wrong.
>
> Ivan can clarify as to what's been seen on AMD platforms regarding the
> infinite loop for patch one. This was also tested on bare metal
> hardware. Injection of the #UD within patch 2 may be debatable but I
> believe Ivan has some more data from experiments backing this up.
I have no problems improving KVM's handling of scenarios that KVM can't emulate,
but there needs to be reasonable justification for taking on complexity, and KVM
must not make up guest visible behavior.
next prev parent reply other threads:[~2024-09-24 7:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-23 14:18 [PATCH 0/4] Process some MMIO-related errors without KVM exit Ivan Orlov
2024-09-23 14:18 ` [PATCH 1/4] KVM: vmx, svm, mmu: Fix MMIO during event delivery handling Ivan Orlov
2024-09-23 14:18 ` [PATCH 2/4] KVM: x86: Inject UD when fetching from MMIO Ivan Orlov
2024-09-23 14:18 ` [PATCH 3/4] selftests: KVM: Change expected exit code in test_zero_memory_regions Ivan Orlov
2024-09-23 14:18 ` [PATCH 4/4] selftests: KVM: Add new test for faulty mmio usage Ivan Orlov
2024-09-23 17:04 ` [PATCH 0/4] Process some MMIO-related errors without KVM exit Sean Christopherson
2024-09-23 19:38 ` Allister, Jack
2024-09-23 21:46 ` Sean Christopherson [this message]
2024-09-24 9:54 ` Ivan Orlov
2024-09-26 0:06 ` Sean Christopherson
2024-09-27 12:13 ` Ivan Orlov
2024-09-24 7:38 ` Sean Christopherson
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=ZvHhqRWW04jmk8TW@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=iorlov@amazon.co.uk \
--cc=jalliste@amazon.co.uk \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nh-open-source@amazon.com \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--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