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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Sep 25, 2014 at 09:08:14AM +0100, Jan Beulich wrote:
> >>> 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.

What are the non-bugs (features) that we speak of? Are the the ones that had
been posted (and then one written by Jan and then reworked)?

Please do be aware that the feature freeze window time has just elapsed 
(yesterday)
so anything to be considered a feature should have been posted before or on 
that date.

Please keep in mind that bug-fixes can be posted and checked in _after_ the
feature freeze. But as the RCs numbers increases the likehood of bugs being
checked in goes down (to reduce the risk of further regressions instroduced
by bug-fixes).
> 
> Jan
> 

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