From: Jan Beulich <jbeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: iwj@xenproject.org, wl@xen.org, anthony.perard@citrix.com,
andrew.cooper3@citrix.com, roger.pau@citrix.com,
jun.nakajima@intel.com, kevin.tian@intel.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/4] x86: Allow non-faulting accesses to non-emulated MSRs if policy permits this
Date: Fri, 22 Jan 2021 13:51:17 +0100 [thread overview]
Message-ID: <c9ee36ca-e19d-0408-d137-8dcee4110ef3@suse.com> (raw)
In-Reply-To: <1611182952-9941-4-git-send-email-boris.ostrovsky@oracle.com>
On 20.01.2021 23:49, Boris Ostrovsky wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -164,6 +164,34 @@ int init_vcpu_msr_policy(struct vcpu *v)
> return 0;
> }
>
> +/* Returns true if policy requires #GP to the guest. */
> +bool guest_unhandled_msr(const struct vcpu *v, uint32_t msr, uint64_t *val,
> + bool is_write, bool is_guest_msr_access)
Would you mind dropping the "_msr" infix from the last
parameter's name? We're anyway aware we're talking about MSR
accesses here, from the function name.
As a nit - while I'm okay with the uint64_t *, I think the
uint32_t would better be unsigned int - see ./CODING_STYLE.
Finally, this being a policy function and policy being per-
domain here, I think the first parameter wants to be const
struct domain *.
> +{
> + u8 ignore_msrs = v->domain->arch.msr->ignore_msrs;
uint8_t please or, as per above, even better unsigned int.
> +
> + /*
> + * Accesses to unimplemented MSRs as part of emulation of instructions
> + * other than guest's RDMSR/WRMSR should never succeed.
> + */
> + if ( !is_guest_msr_access )
> + ignore_msrs = MSR_UNHANDLED_NEVER;
Wouldn't you better "return true" here? Such accesses also
shouldn't be logged imo (albeit I agree that's a change from
current behavior).
> + if ( unlikely(ignore_msrs != MSR_UNHANDLED_NEVER) )
> + *val = 0;
I don't understand the conditional here, even more so with
the respective changelog entry. In any event you don't
want to clobber the value ahead of ...
> + if ( likely(ignore_msrs != MSR_UNHANDLED_SILENT) )
> + {
> + if ( is_write )
> + gdprintk(XENLOG_WARNING, "WRMSR 0x%08x val 0x%016"PRIx64
> + " unimplemented\n", msr, *val);
... logging it.
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -850,4 +850,10 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt)
> ctxt->event = (struct x86_event){};
> }
>
> +static inline bool x86_emul_guest_msr_access(struct x86_emulate_ctxt *ctxt)
The parameter wants to be pointer-to-const. In addition I wonder
whether this wouldn't better be a sibling to
x86_insn_is_cr_access() (without a "state" parameter, which
would be unused and unavailable to the callers), which may end
up finding further uses down the road.
> +{
> + return ctxt->opcode == X86EMUL_OPC(0x0f, 0x32) || /* RDMSR */
> + ctxt->opcode == X86EMUL_OPC(0x0f, 0x30); /* WRMSR */
> +}
Personally I'd prefer if this was a single comparison:
return (ctxt->opcode | 2) == X86EMUL_OPC(0x0f, 0x32);
But maybe nowadays' compilers are capable of this
transformation?
I notice you use this function only from PV priv-op emulation.
What about the call paths through hvmemul_{read,write}_msr()?
(It's also questionable whether the write paths need this -
the only MSR written outside of WRMSR emulation is
MSR_SHADOW_GS_BASE, which can't possibly reach the "unhandled"
logic anywhere. But maybe better to be future proof here in
case new MSR writes appear in the emulator, down the road.)
Jan
next prev parent reply other threads:[~2021-01-22 12:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 22:49 [PATCH v2 0/4] Permit fault-less access to non-emulated MSRs Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 1/4] xl: Add support for ignore_msrs option Boris Ostrovsky
2021-01-21 14:56 ` Wei Liu
2021-01-21 22:43 ` Boris Ostrovsky
2021-01-22 9:52 ` Julien Grall
2021-01-22 18:28 ` Boris Ostrovsky
2021-01-22 18:33 ` Julien Grall
2021-01-22 18:39 ` Boris Ostrovsky
2021-01-22 20:42 ` Julien Grall
2021-02-18 10:42 ` Roger Pau Monné
2021-02-18 11:54 ` Jan Beulich
2021-02-18 15:52 ` Roger Pau Monné
2021-02-18 15:57 ` Jan Beulich
2021-02-19 14:50 ` Boris Ostrovsky
2021-02-22 10:24 ` Roger Pau Monné
2021-02-22 10:33 ` Jan Beulich
2021-01-20 22:49 ` [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED Boris Ostrovsky
2021-01-22 11:51 ` Jan Beulich
2021-01-22 18:56 ` Boris Ostrovsky
2021-02-02 17:01 ` Boris Ostrovsky
2021-02-18 10:51 ` Roger Pau Monné
2021-02-19 14:56 ` Boris Ostrovsky
2021-02-22 11:08 ` Roger Pau Monné
2021-02-22 21:19 ` Boris Ostrovsky
2021-02-23 7:57 ` Jan Beulich
2021-02-23 9:34 ` Roger Pau Monné
2021-02-23 10:15 ` Jan Beulich
2021-02-23 12:17 ` Roger Pau Monné
2021-02-23 13:23 ` Jan Beulich
2021-02-23 15:39 ` Boris Ostrovsky
2021-02-23 16:10 ` Jan Beulich
2021-02-23 18:00 ` Roger Pau Monné
2021-02-23 16:11 ` Roger Pau Monné
2021-02-23 16:40 ` Boris Ostrovsky
2021-02-23 18:02 ` Roger Pau Monné
2021-02-23 18:45 ` Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 3/4] x86: Allow non-faulting accesses to non-emulated MSRs if policy permits this Boris Ostrovsky
2021-01-22 12:51 ` Jan Beulich [this message]
2021-01-22 19:52 ` Boris Ostrovsky
2021-01-25 10:22 ` Jan Beulich
2021-01-25 18:42 ` Boris Ostrovsky
2021-01-26 9:05 ` Jan Beulich
2021-01-26 16:02 ` Boris Ostrovsky
2021-01-26 16:35 ` Jan Beulich
2021-02-18 11:24 ` Roger Pau Monné
2021-02-18 11:57 ` Jan Beulich
2021-02-18 15:53 ` Roger Pau Monné
2021-01-20 22:49 ` [PATCH v2 4/4] tools/libs: Apply MSR policy to a guest Boris Ostrovsky
2021-01-21 14:58 ` Wei Liu
2021-01-22 9:56 ` Julien Grall
2021-01-22 18:35 ` Boris Ostrovsky
2021-02-18 11:48 ` Roger Pau Monné
2021-02-19 14:57 ` Boris Ostrovsky
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=c9ee36ca-e19d-0408-d137-8dcee4110ef3@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=iwj@xenproject.org \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.