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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

>> > 6. Live migration with RMRR region and hotplug.
>> >
>> > Possible solution: Do the checking in tool stack: If the device which
>> > requires RMRR but the corresponding region is not reserved in guest e820 or
>> > have overlap with MMIO, then refuse to do the hotplug.
>> >
>> > One question, should we fix all of them at once or can we fix them one by
>> > one based on severity? For example, the issue 6 happens rarely and I think 
>> > we
>> > can leave it after Xen 4.5.
>> 
>> I really only see two routes for 4.5: Either fix everything properly
>> or disallow assignment of devices associated with RMRRs altogether
>> (with log messages clearly pointing to an override command line
>> option).
> 
> Ok. It makes sense. Do you think it possible to cacth the Xen 4.5 if 
> everything is fixed properly?

Considering it's a bug that gets fixed, I would think so. But as for
anything more involved, Konrad as the release manager will have
the final say.

Jan


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