Re: [Xen-devel] Xen Project policy on feature flags

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-09-29 at 11:05 +0100, David Vrabel wrote:
> On 29/09/14 10:36, George Dunlap wrote:
> > On 09/29/2014 10:31 AM, Wei Liu wrote:
> >> On Mon, Sep 29, 2014 at 10:00:13AM +0100, George Dunlap wrote:
> >>> On 09/26/2014 03:49 PM, Stefano Stabellini wrote:
> >>>>> Let me rephrase - will it boot in the same fashion (And with the same
> >>>>> bugs) as it did prior to this functionality being introduced?
> >>>> 3.15 -> dom0 on ARM broken (if netback is used)
> >>>> 3.17 -> dom0 on ARM is fixed, only if the kernel is compiled with
> >>>> CONFIG_ARM_LPAE
> >>>>
> >>>> Reverting the XENFEAT_grant_map_identity related changes would give you
> >>>> a system broken even with CONFIG_ARM_LPAE.
> >>>> Reverting Zoltan's changes to netback would give you a working system.
> >> FWIW reverting isn't practical as many more fixes have gone in.
> >>
> >> I think a possible workaround is to copy directly xen-netback directory
> >> from 3.14 and build it against new kernel. Netback itself is quite
> >> self-contained.
> > 
> > Could we provide a patch which would just disable the problematic behavior?
> 
> No.  This would require re-introducing the grant copy from-guest path to
> netback.  This would be expensive since netback has seen significant
> changes since (multi-queue support in particular).
> 
> It would also not fix the underlying ARM-specific bug and other users of
> grant mapping would be similarly broken.
> 
> I think we should:
> 
> 1. Revert XENFEAT_grant_map_identity.
> 2. Add the flush-cache-by-bus-address hypercall.
> 3. Add the Linux support this this cache operation and tag this for stable.
> 4. Backport the hypercall to 4.4.x.
> 
> I think this is critical to fix in 4.5 and should have a freeze
> exception.  I would even consider slipping the 4.5 release to get this
> fixed.

I agree with this plan of action.

If the new h/call doesn't make 4.5.0 for some reason then it absolutely
must make it for 4.5.1 (and I have no doubt that it would).

Ian.


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