Re: PVH and mtrr/PAT.........

[George Dunlap <george.dunlap@eu.citrix.com>]

On 21/11/13 23:41, Mukesh Rathor wrote:
> On Thu, 21 Nov 2013 15:47:43 +0000
> George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>
>> On Wed, Nov 20, 2013 at 10:24 PM, Mukesh Rathor
>> <mukesh.rathor@oracle.com> wrote:
>>> On Wed, 20 Nov 2013 18:12:13 +0000
>>> George Dunlap <dunlapg@umich.edu> wrote:
>>>
>>>> On Wed, Nov 20, 2013 at 8:42 AM, Jan Beulich <JBeulich@suse.com>
>>>> wrote:
>>>>>>>> On 20.11.13 at 03:11, Mukesh Rathor <mukesh.rathor@oracle.com>
>>>>>>>> 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