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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

hypervisor provided list can be a reference, not a must. User space can
detect the confliction e.g. with large BIOS size and then reject assignment
of devices associated with conflicting region. but that also means exposing
not just the hole, but also the exact RMRR knowledge to user space...

Thanks
Kevin

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