[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



> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, July 24, 2014 2:32 AM
> 
> >>> 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.
> 

yes, that's a problem. we need some way (possibly a new hypercall) to
tell user space reserving a list of GFN holes in guest e820. I'm not sure
the sequence of current e820 construction and device pass-through. A
simpler policy may be always reserve those holes even when no device
is assigned.

Thanks
Kevin

_______________________________________________
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®.