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

Re: [Xen-devel] [v2][PATCH 1/1] xen:vtd: missing RMRR mapping while share EPT



>>> On 24.07.14 at 11:11, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/07/14 10:03, Chen, Tiejun wrote:
>> On 2014/7/24 16:57, Andrew Cooper wrote:
>>> On 24/07/14 09:50, Tiejun Chen wrote:
>>>> --- a/xen/drivers/passthrough/vtd/iommu.c
>>>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>>> @@ -41,6 +41,7 @@
>>>>   #include "extern.h"
>>>>   #include "vtd.h"
>>>>   #include "../ats.h"
>>>> +#include "../../../arch/x86/mm/mm-locks.h"
>>>
>>> <asm/mm/mm-locks.h>
>>
>> iommu.c:38:29: fatal error: asm/mm/mm-locks.h: No such file or directory
>>  #include <asm/mm/mm-locks.h>
>>                              ^
>> compilation terminated.
>>
>> Tiejun
> 
> Hmm - my mistake.  The lack of easy access to this header file goes to
> emphasise that it is private to arch/x86/mm, and there are indeed no
> current users outside of that part of the tree.
> 
> Would it not be better have some public p2m_set_identity() function in
> p2m.c ?

Actually I think this should be using set_mmio_p2m_entry(), which in
turn points out another problem: What is happening with the GFN
that gets replaced here? How will the guest know this is not RAM? I
pointed out on an earlier occasion that passing through devices with
associated RMRR is problematic/dangerous - this is another proof.
Perhaps this should be disallowed, at least when sharing page tables.

Jan


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


 


Rackspace

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