[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] PVH and mtrr/PAT.........
On 21/11/13 23:41, Mukesh Rathor wrote:
On Thu, 21 Nov 2013 15:47:43 +0000
George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
On Wed, Nov 20, 2013 at 10:24 PM, Mukesh Rathor
<mukesh.rathor@xxxxxxxxxx> wrote:
On Wed, 20 Nov 2013 18:12:13 +0000
George Dunlap <dunlapg@xxxxxxxxx> wrote:
On Wed, Nov 20, 2013 at 8:42 AM, Jan Beulich <JBeulich@xxxxxxxx>
wrote:
On 20.11.13 at 03:11, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
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....
I'm not incredibly familiar with the PAT / MTRR stuff, either from a
hardware level or a Xen level, so sorry if this is a dumb question. It
sounds like you're saying, because we have virtual MTRRs that are
already translated into EPT types, we should disable virtual MTRRs and
use PAT instead. That doesn't make any kind of sense to me. (I didn't
understand it when Jan said it either.)
If there is already a mechanism to allow HVM guests to set memory types,
and it even works for passed-through devices for HVM guests, why would
we disable it and use something else instead?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
