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

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

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


Xen-devel mailing list



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