Re: [Xen-devel] PVH and mtrr/PAT.........

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Wed, 20 Nov 2013 08:42:08 +0000
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 20.11.13 at 03:11, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >>> 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!

It says PAT+PWT+PCD selects a PAT entry from the IA32_PAT msr.
In case of PVH, the msr is guest managed, and intercept is disabled.
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?

Thanks a lot for the help.
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel