[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 18:56, <kevin.tian@xxxxxxxxx> wrote: >> 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. Yes, that would be desirable, but not necessarily possible: On the one system entertaining RMRRs that I have here, these regions are in the range E9000...EEFFF, i.e. are - with a BIOS image of more than 64k size - overlapping the base BIOS, at least until the resident size of the BIOS has been determined. I'm not sure about the consequences of this overlap. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |