Re: [Xen-devel] [PATCH] x86/PCI: Intercept Dom0 MMCFG from dom0s in HVM containers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.12.15 at 14:55, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 12/17/2015 04:46 AM, Jan Beulich wrote:
>>>>> On 16.12.15 at 20:34, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 12/16/2015 04:04 AM, Jan Beulich wrote:
>>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>>> @@ -3116,6 +3116,21 @@ int hvm_hap_nested_page_fault(paddr_t gpa, 
>>>>> unsigned 
> long gla,
>>>>>            goto out_put_gfn;
>>>>>        }
>>>>>    
>>>>> +    if ( (p2mt == p2m_mmio_direct) && is_hardware_domain(currd) )
>>>> The PV condition includes a PFEC_page_present check, and I think
>>>> an equivalent should be added here too.
>>> Hmm.. So how would I determine that? I can see how this is available in
>>> SVM (although it is not reflected in npfec) but in VMX I don't see
>>> direct indication of whether the page was present.
>> That's what bits 3..5 of the exit qualification can be used for. Really
>> you could leverage the more fine grained reporting by EPT to make
>> the condition here "bit 1 must be set" (i.e. npfec.write_access) and
>> "bit 3 must be set" (readable, which implies present) and "bit 4 must
>> be clear" (and we might even demand bit 5 to be clear too).
> 
> OK, but these bits are not mapped into npfec structure so we'd need to 
> expand it.
> 
> (And then SVM does not provide this much information so we may need to 
> get creative there).

Yes and yes (sadly).

Jan


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