From: konrad wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: PVH and mtrr/PAT.........
Date: Thu, 21 Nov 2013 02:50:53 -0500 [thread overview]
Message-ID: <528DBB5D.9050500@oracle.com> (raw)
In-Reply-To: <20131120184227.2cf85302@mantra.us.oracle.com>
On 11/20/2013 9:42 PM, Mukesh Rathor wrote:> On Wed, 20 Nov 2013
08:42:08 +0000
> "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>>>> On 20.11.13 at 03:11, Mukesh Rathor <mukesh.rathor@oracle.com>
>>>>> wrote:
>>> After rebasing my dom0 on latest, it didn't boot. After debugging
>>> couple days, it turned out to be :
>>>
>>> + if ( is_pvh_domain(d) )
>>> + {
>>> + if ( direct_mmio )
>>> + return MTRR_TYPE_UNCACHABLE;
>>> + return MTRR_TYPE_WRBACK;
>>> + }
>>> +
>>>
>>> I had in my patches, missing in epte_get_entry_emt() in latest.
>>>
>>> So, since I don't know much about this, is an HVM guest setting
>>> MTRR range types? Looking for suggestions on best way to do this
>>> for PVH.
>>
>> A HVM guest is permitted to write to (virtual) MTRRs, whereas a PV
>> guest isn't. I'm inclined to prefer PV behavior here to be used for
>> PVH (since, as explained by Dongxiao, MTRRs don't really matter
>> for VMX guests anyway, i.e. the setting of (virtual) MTRRs needs to
>> get translated to EPT memory types anyway, hence a PVH guest
>> ought to be fine ignoring the MTRRs altogether and handling memory
>> types exclusively via PAT mechanisms).
>
> Ok. So, it appears that for PV, we store the cacheattr
> in page_info and use it during pte update. But in case of PVH,
> the page tables are native, the pte update is native, so we
> don't really have access to PCD/PWT/PAT bits in the pte entry!
Right, which is OK - b/c the mechanism to set a WC page and back
is at odds with how the Linux sets its bits. This is a problem
for PV guests (pvops based) as they cannot do PAT right now.
HVM guest can as they omit all of this.
>
> It says PAT+PWT+PCD selects a PAT entry from the IA32_PAT msr.
Right.
> In case of PVH, the msr is guest managed, and intercept is disabled.
I thought the IA32_PAT MSR was intercepted?
> I assume the EPT should mirror the pte PAT entries?
>
> Or, can we just set WB for all RAM, and UC for all non-ram for
> PVH and keep it simple?
If you are using an i915 it will want to map its MMIO bars as WC.
Ditto for InfiniBand cards, radeon and nouveau cards.
>
> Thanks a lot for the help.
> Mukesh
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
next prev parent reply other threads:[~2013-11-21 2:50 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
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 [this message]
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=528DBB5D.9050500@oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=mukesh.rathor@oracle.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.