Re: Xen Project policy on feature flags

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Sep 29, 2014 at 12:32:59PM +0100, Ian Campbell wrote:
> 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).

And there goes my plan for an relaxed-release.

I don't recall seeing my answer about distangling CONFIG_ARM_LPAE and
the DMA_ADDR_64_BIT (or whatever it is called) config option. Which
was meant to allow an 32-bit OS to deal with 64-bit PCI devices - which
would have allowed us to still to program 64-bit PCI devices without
the page table support for it. Is that an option?

> 
> Ian.
>