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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-09-25:
>>>> On 25.09.14 at 03:53, <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-09-24:
>>>>>> On 24.09.14 at 10:23, <yang.z.zhang@xxxxxxxxx> wrote:
>>>> 1. RMRR region isn't reserved in guest e820 table and guest is
>>>> able to touch it.
>>>> 
>>>> Possible solution: set RMRR region as reserved in guest e820
>>>> table and create identity map in EPT and VT-d page table.
>>> 
>>> And relocate guest RAM accordingly.
>> 
>> ok. Let's look into more detail:
>> 1. Whether there has device assigned or not, the RMRR mapping must
>> be created when building e820 table if the VT-d is enabled.

My original propose should be wrong: if there is no device attached when 
creating guest, we should not create the identity map in guest. But I don't 
know how to setup the EPT mapping for RMRR region in this case. Any idea?

>> 2. Despite of share or non-share case, the RMRR region must be
>> identity map in EPT and VT-d page table.
>> 3. Tiejun's patch uses hypercall to get the RMRR info, is it ok? Or
>> should we get it from xenstore, and then both tools and hvmloader
>> can
> access it?
> 
> The hypercall is clearly the route to go imo - xenstore would be a
> pretty crude mechanism for conveying that information (and using the
> hypercall approach precludes neither the tools nor hvmloader from obtaining 
> that data).

Ok. If hypercall is enough, then we can keep it.

> 
>>>> 3. RMRR region isn't checked when updating EPT table and VT-d table.
>>>> 
>>>> Possible solution: Return error when trying to update EPT and
>>>> VT-d table if the gfn is inside RMRR region.
>> 
>> So just do a simple check in EPT table and VT-d table updating is ok?
> 
> I think so - anything more sophisticated (like checking in the tools)
> will not give any better results (except for a more explicit error
> message maybe, but this can certainly be had equally well by using a
> very specific error code should the hypervisor side check fail).

Agree.

Best regards,
Yang



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