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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 29 Sep 2014, Ian Campbell wrote:
> 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.

FYI the virtual mapping is needed because required cache flushing ops
on ARM take a virtual address as argument.

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