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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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