[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |