All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0
Date: Mon, 14 May 2018 17:33:49 +0100	[thread overview]
Message-ID: <20180514163349.5pb3hvmtcdnjaojm@MacBook-Pro-de-Roger.local> (raw)
In-Reply-To: <5AF99C9602000078001C2848@prv1-mh.provo.novell.com>

On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
> >>> On 10.05.18 at 19:15, <roger.pau@citrix.com> wrote:
> > Copy the state found on the hardware when creating a PVH Dom0. Since
> > the memory map provided to a PVH Dom0 is based on the native one using
> > the same set of MTRR ranges should provide Dom0 with a sane MTRR state
> > without having to manually build it in Xen.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> >  xen/arch/x86/hvm/mtrr.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> > index 95a3deabea..1cb000388a 100644
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
> >          ((uint64_t)PAT_TYPE_UC_MINUS << 48) |       /* PAT6: UC- */
> >          ((uint64_t)PAT_TYPE_UNCACHABLE << 56);      /* PAT7: UC */
> >  
> > +    if ( is_hardware_domain(v->domain) )
> > +    {
> > +        /* Copy values from the host. */
> > +        struct domain *d = v->domain;
> > +        unsigned int i;
> > +
> > +        if ( mtrr_state.have_fixed )
> > +            for ( i = 0; i < NUM_FIXED_MSR; i++ )
> > +                mtrr_fix_range_msr_set(d, m, i,
> > +                                      ((uint64_t *)mtrr_state.fixed_ranges)[i]);
> 
> The presence/absence of fixed range MTRRs needs to be reflected in the
> capabilities MSR. Strictly speaking in their absence MSR access attempts to
> the fixed range MSRs should also cause #GP, as should any attempt to
> enable them in defType.

My intention was to always provide the fixed range MTRR capability,
regardless of whether the underlying hardware has it or not. Then of
course fixed ranges won't be enabled by default in the deftype MSR if
the underlying hardware also hasn't got them enabled.

> > +        for ( i = 0; i < num_var_ranges; i++ )
> > +        {
> > +            mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSBASE(i),
> > +                                   mtrr_state.var_ranges[i].base);
> > +            mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSMASK(i),
> > +                                   mtrr_state.var_ranges[i].mask);
> > +        }
> > +
> > +        mtrr_def_type_msr_set(d, m, mtrr_state.def_type |
> > +                                    (mtrr_state.enabled << 10));
> 
> In the interest of no further proliferation of this and similar literal numbers,
> could I ask you to introduce #define-s into msr-index.h?

Sure.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-05-14 16:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 17:15 [PATCH 0/5] PVH MTRR initial state Roger Pau Monne
2018-05-10 17:15 ` [PATCH 1/5] hvm/mtrr: add emacs local variables block with formatting info Roger Pau Monne
2018-05-10 17:15 ` [PATCH 2/5] hvm/mtrr: use the hardware number of variable ranges for Dom0 Roger Pau Monne
2018-05-14 14:14   ` Jan Beulich
2018-05-10 17:15 ` [PATCH 3/5] hvm/mtrr: copy hardware state " Roger Pau Monne
2018-05-14 14:26   ` Jan Beulich
2018-05-14 16:33     ` Roger Pau Monné [this message]
2018-05-15  7:52       ` Jan Beulich
2018-05-15  8:35         ` Roger Pau Monné
2018-05-15  8:48           ` Jan Beulich
2018-05-15  9:16             ` Roger Pau Monné
2018-05-15  9:50               ` Jan Beulich
2018-05-10 17:15 ` [PATCH 4/5] libxc/pvh: set default MTRR type to write-back Roger Pau Monne
2018-05-14 16:00   ` Wei Liu
2018-05-14 16:02     ` Roger Pau Monné
2018-05-14 16:42       ` Wei Liu
2018-05-14 16:50         ` Wei Liu
2018-05-14 16:53         ` Roger Pau Monné
2018-05-15 11:43   ` Wei Liu
2018-05-15 12:22     ` Jan Beulich
2018-05-10 17:15 ` [PATCH 5/5] docs/pvh: document initial MTRR state Roger Pau Monne
2018-05-14 16:03   ` Wei Liu
2018-05-14 16:13     ` Jan Beulich
2018-05-14 16:18       ` Wei Liu
2018-05-15  7:51         ` Jan Beulich
2018-05-15  8:30           ` Wei Liu
2018-05-15  8:30           ` Roger Pau Monné
2018-05-15  8:38             ` Jan Beulich
2018-05-14 16:16     ` Roger Pau Monné
2018-05-14 16:27       ` Wei Liu

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=20180514163349.5pb3hvmtcdnjaojm@MacBook-Pro-de-Roger.local \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --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.