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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> 11/21/13 3:42 AM >>>
>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:
>> > 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?

Mirroring would be the simplest possible solution, since then EMT and
PAT are always in agreement. But EMT is really there to allow modifying
the (guest controlled) PAT selection. I.e. (not for PVH, but as a general
example) while a guest would map the LAPIC page UC, the hypervisor
would generally be happy with it being WB.

>Or, can we just set WB for all RAM, and UC for all non-ram for 
>PVH and keep it simple?

As a first step it could be that simple, but as soon as possible at least
WC should be taken into consideration.

Jan


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