xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	"Dong, Eddie" <eddie.dong@intel.com>, Tim Deegan <tim@xen.org>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: PVH and mtrr/PAT.........
Date: Thu, 21 Nov 2013 15:41:39 -0800	[thread overview]
Message-ID: <20131121154139.584a6d4a@mantra.us.oracle.com> (raw)
In-Reply-To: <CAFLBxZayaKLxmj5M7+UG41AfZ8O+rB8GjG83V1wag3TeNnwk1Q@mail.gmail.com>

On Thu, 21 Nov 2013 15:47:43 +0000
George Dunlap <George.Dunlap@eu.citrix.com> wrote:

> On Wed, Nov 20, 2013 at 10:24 PM, Mukesh Rathor
> <mukesh.rathor@oracle.com> wrote:
> > On Wed, 20 Nov 2013 18:12:13 +0000
> > George Dunlap <dunlapg@umich.edu> wrote:
> >
> >> On Wed, Nov 20, 2013 at 8:42 AM, Jan Beulich <JBeulich@suse.com>
> >> wrote:
> >> >>>> On 20.11.13 at 03:11, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>>> wrote:
......
> > Without any changes to epte_get_entry_emt(), all types are being
> > returned as MTRR_TYPE_WRBACK for PVH because of:
> >
> >     if ( !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )
> >             return MTRR_TYPE_WRBACK;
> >
> > This is problem for low level non-ram pages being accessed in dom0,
> > (which interesting gave MCE errors). non-ram IO pages have to be
> > MTRR_TYPE_UNCACHABLE.
> 
> Hmm -- that looks like a bug in the logic there.  AFAICT, there's no
> reason for the lack of IDENT_PT to change the memory type like that.
> 
> Unfortunately the changeset that introduced this (77283249) has
> neither comments nor a proper description of what's going on, so it's
> hard to tell where this came from.

Yeah, I was baffled why that was there, gave up, and took the easy
way out for PVH :).

...
> >
> > After changing this to,
> >     if ( !is_pvh_vcpu(v) &&
> >          !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )
> >
> > I started hitting if ( direct_mmio ), and getting proper UNCACHABLE
> > for io pages, but RAM pages started being returned as UNCACHABLE
> > also thru get_mtrr_type() which I've not investigated.
> 
> Presumably because the PVH guests aren't actually setting up their
> MTRRs, whereas HVM guests do?

Correct.

> One solution of course would be to add MTRRs to the PVH interface.  A
> more flexible option might be to set up default MTRRs in the domain
> builder (which the guest can change if they want).

That was my first thought too, but Jan/Dongxiao pointed out guest is
permitted to write virtual MTRRs and they get translated
to EPT types anyways, the PV approach of just doing the PAT would
be better. I'm trying to figure that out.... 

> Or, we can change this line:
>      gmtrr_mtype = get_mtrr_type(&v->arch.hvm_vcpu.mtrr, (gfn <<
> PAGE_SHIFT));
> 
> to this:
>      gmtrr_mtype = is_hvm_domain(v) ?
> get_mtrr_type(&v->arch.hvm_vcpu.mtrr, (gfn << PAGE_SHIFT)) :
> MTRR_TYPE_WRBACK;
> 
> (Line-wrapped obviously.)

Yup, that would work, and Jan is OK with it as first step. Sending
patch for it....

thanks,
Mukesh

  reply	other threads:[~2013-11-21 23:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20  2:11 PVH and mtrr/PAT Mukesh Rathor
2013-11-20  7:22 ` Xu, Dongxiao
2013-11-20  8:42 ` Jan Beulich
2013-11-20 18:12   ` George Dunlap
2013-11-20 22:24     ` Mukesh Rathor
2013-11-21 15:47       ` George Dunlap
2013-11-21 23:41         ` Mukesh Rathor [this message]
2013-11-22 10:43           ` George Dunlap
2013-11-22 11:09             ` Jan Beulich
2013-11-22 12:16               ` George Dunlap
2013-11-22 12:30                 ` Jan Beulich
2013-11-22 10:29         ` Jan Beulich
2013-12-03  7:20           ` Xu, Dongxiao
2013-12-03 13:54             ` George Dunlap
2013-11-21  2:42   ` Mukesh Rathor
2013-11-21  7:50     ` konrad wilk
2013-11-21 11:40     ` Jan Beulich
2013-11-22  0:42       ` Mukesh Rathor

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=20131121154139.584a6d4a@mantra.us.oracle.com \
    --to=mukesh.rathor@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=tim@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 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).