From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
bsd@redhat.com, guangrong.xiao@linux.intel.com,
Yang Zhang <yang.z.zhang@intel.com>,
wanpeng.li@linux.intel.com
Subject: Re: [RFC PATCH 00/13] KVM: x86: SMM support
Date: Wed, 6 May 2015 19:14:32 +0200 [thread overview]
Message-ID: <20150506171428.GB17718@potion.brq.redhat.com> (raw)
In-Reply-To: <5549F8A0.4080904@redhat.com>
2015-05-06 13:18+0200, Paolo Bonzini:
> On 05/05/2015 20:40, Radim Krčmář wrote:
> > - Whole SMRAM is writeable. Spec says that parts of state should be
> > read-only. (This seems hard to fix without trapping all writes.)
>
> Read-only here just means that you shouldn't touch it. It says "Some
> register images are read-only, and must not be modified (modifying these
> registers will result in unpredictable behavior)".
I haven't seen the note that they musn't be modified, sorry.
> But actually the behavior is very predictable, and can be very fun. You
> can do stuff such as interrupting a VM86 task with an SMI, and prepare
> an SMM handler that returns to VM86 with CPL=0 (by setting SS.DPL=0 in
> the SS access rights field). That's very illegal compared to big real
> mode. :)
>
> Or you can fake a processor reset straight after RSM, which includes
> setting the right segment base, limit and access rights (again you need
> to set SS.DPL=0 to affect the CPL).
>
> Worst case, you get a failed VM entry (e.g. if you set up an invalid
> combination of segment limit and segment G flag). If you care, disable
> unrestricted_guest. :)
Nice, thanks.
> > - I/O restarting is not enabled. (APM 2:10.2.4 SMM-Revision Identifier
> > says that AMD64 always sets this bit.)
>
> Yes, unfortunately if I do enable it SeaBIOS breaks. So it's left for
> later.
>
> I/O restarting is meant for stuff like emulating the i8042 on top of a
> USB keyboard. We luckily don't care (do not get strange ideas about
> reducing the QEMU attack surface).
Ok. (SMM handlers doing sanity checks on their environment are probably
the biggest obstacle.)
> > - SMM and userspace.
> > We can get if smm is enabled at two separate places (flag from KVM_RUN
> > and in KVM_GET_VCPU_EVENTS) and toggle it via KVM_SET_VCPU_EVENTS.
> >
> > It's not an event, so I wouldn't include it in EVENTS API ...
>
> Well, neither is nmi.masked or interrupt.shadow. In the end, smi.smm is
> just "smi.masked" (except that it also doubles as "is RSM allowed/is
> SMRAM accessible").
Yeah, that double function is bugging me ... SMI can be masked for
reasons other than being in SMM, so the connection is not obvious.
(But all cases I know of are handled differently in KVM.)
Other case is that when emulating the SMM switch in userspace, EVENTS
ioctl wouldn't be the place where I where I would expect a toggle for
KVM to be.
> > Letting the flag in KVM_RUN also toggle SMM would be easiest.
>
> I'm worried about breaking userspace with that. I would probably have
> to enable the SMM capability manually.
>
> By comparison, the current implementation is entirely transparent as
> long as the guest only generates SMIs through the APIC: all QEMU changes
> are needed to support SMRAM and generation of SMIs through port 0xB2,
> but the feature otherwise has zero impact on userspace.
They should be equally transparent. Userspace needs to preserve all
reserved bits, and hopefully does. (It's the same with SET_EVENTS.)
> But the main point in favor of "smi.smm" IMO is that it doubles as
> "smi.masked".
True. 'smi.masked_as_we_are_in_smm' :)
> > Otherwise, wouldn't GET/SET_ONE_REG be a better match for it?
>
> Perhaps, but then smi.pending would still be a better match for
> KVM_GET_VCPU_EVENTS than for ONE_REG. (And again, so would
> "smi.masked"---it just happens that "masked SMIs == CPU in SMM").
smi.pending makes sense in events, it would be split ...
Your original solution is a good one. (Others aren't any better.)
next prev parent reply other threads:[~2015-05-06 17:14 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 11:35 [RFC PATCH 00/13] KVM: x86: SMM support Paolo Bonzini
2015-04-30 11:36 ` [PATCH 01/13] KVM: MMU: fix for CR4.SMEP=1, CR0.WP=0? Paolo Bonzini
2015-05-08 2:52 ` Xiao Guangrong
2015-04-30 11:36 ` [PATCH 02/13] KVM: reuse memslot in kvm_write_guest_page Paolo Bonzini
2015-05-05 15:03 ` Bandan Das
2015-05-05 16:29 ` Radim Krčmář
2015-04-30 11:36 ` [PATCH 03/13] KVM: export __gfn_to_pfn_memslot, drop gfn_to_pfn_async Paolo Bonzini
2015-04-30 11:36 ` [PATCH 04/13] KVM: remove unnecessary arg from mark_page_dirty_in_slot, export it Paolo Bonzini
2015-04-30 11:36 ` [PATCH 05/13] KVM: x86: pass host_initiated to functions that read MSRs Paolo Bonzini
2015-05-04 14:01 ` Radim Krčmář
2015-05-04 16:04 ` Paolo Bonzini
2015-04-30 11:36 ` [PATCH 06/13] KVM: x86: pass the whole hflags field to emulator and back Paolo Bonzini
2015-05-05 15:47 ` Bandan Das
2015-05-05 16:16 ` Paolo Bonzini
2015-05-06 16:49 ` Bandan Das
2015-04-30 11:36 ` [PATCH 07/13] KVM: x86: API changes for SMM support Paolo Bonzini
2015-05-04 15:37 ` Radim Krčmář
2015-05-04 16:02 ` Paolo Bonzini
2015-05-05 16:36 ` Bandan Das
2015-05-05 16:45 ` Paolo Bonzini
2015-04-30 11:36 ` [PATCH 08/13] KVM: x86: stubs " Paolo Bonzini
2015-05-04 17:51 ` Radim Krčmář
2015-05-05 9:37 ` Paolo Bonzini
2015-05-05 18:38 ` Bandan Das
2015-05-05 18:48 ` Radim Krčmář
2015-04-30 11:36 ` [PATCH 09/13] KVM: x86: save/load state on SMM switch Paolo Bonzini
2015-05-04 19:59 ` Radim Krčmář
2015-05-05 9:37 ` Paolo Bonzini
2015-05-05 12:48 ` Radim Krčmář
2015-05-05 13:18 ` Paolo Bonzini
2015-05-05 20:44 ` Bandan Das
2015-05-06 10:39 ` Paolo Bonzini
2015-05-06 17:55 ` Bandan Das
2015-05-06 19:38 ` Paolo Bonzini
2015-05-12 23:56 ` Bandan Das
2015-05-13 6:58 ` Paolo Bonzini
2015-04-30 11:36 ` [PATCH 10/13] KVM: x86: add vcpu-specific functions to read/write/translate GFNs Paolo Bonzini
2015-04-30 11:36 ` [PATCH 11/13] KVM: x86: add SMM to the MMU role Paolo Bonzini
2015-04-30 11:36 ` [PATCH 12/13] KVM: x86: add KVM_MEM_X86_SMRAM memory slot flag Paolo Bonzini
2015-05-05 17:17 ` Radim Krčmář
2015-05-06 9:47 ` Paolo Bonzini
2015-05-06 16:24 ` Radim Krčmář
2015-05-06 18:15 ` Bandan Das
2015-05-06 19:43 ` Paolo Bonzini
2015-05-15 20:32 ` Avi Kivity
2015-05-18 8:31 ` Paolo Bonzini
2015-04-30 11:36 ` [PATCH 13/13] KVM: x86: advertise KVM_CAP_X86_SMM Paolo Bonzini
2015-05-05 18:40 ` [RFC PATCH 00/13] KVM: x86: SMM support Radim Krčmář
2015-05-06 11:18 ` Paolo Bonzini
2015-05-06 17:14 ` Radim Krčmář [this message]
2015-05-19 14:25 ` Zhang, Yang Z
2015-05-19 14:27 ` Paolo Bonzini
2015-05-20 1:03 ` Zhang, Yang Z
2015-05-20 15:22 ` Andi Kleen
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=20150506171428.GB17718@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=bsd@redhat.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=wanpeng.li@linux.intel.com \
--cc=yang.z.zhang@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;
as well as URLs for NNTP newsgroup(s).