[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:
>> 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).


Do you know why this line is having this effect?  For one, is it a
matter of direct_mmio pages being given something other than
UNCACHEABLE, or a matter of non-direct_mmio pages given something
other than WRBACK?

And is the problem that the guest is *not* setting MTRRs, or that the
guest *is* setting MTRRs?

I'd prefer to avoid having a special case for PVH in this path if possible.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.