Re: Xen Project policy on feature flags

[Ian Campbell <Ian.Campbell@citrix.com>]

On Mon, 2014-09-29 at 10:55 -0400, Konrad Rzeszutek Wilk wrote:
> 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?

The root issue here is that the guest needs a virtual address mapping of
a 64-bit DMA address, which simply isn't possible with a non-LPAE guest
kernel.

Ian.