From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen Project policy on feature flags Date: Mon, 29 Sep 2014 16:00:25 +0100 Message-ID: <1412002825.3801.24.camel@citrix.com> References: <542588A90200007800039B3E@mail.emea.novell.com> <1411741172.26149.75.camel@kazak.uk.xensource.com> <20140926142959.GA19421@laptop.dumpdata.com> <54291F9D.4030705@eu.citrix.com> <20140929093126.GF28628@zion.uk.xensource.com> <54292823.2050502@eu.citrix.com> <54292EE9.9090708@citrix.com> <1411990379.9686.44.camel@kazak.uk.xensource.com> <20140929145528.GE28012@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140929145528.GE28012@laptop.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, keir@xen.org, Tim Deegan , Stefano Stabellini , George Dunlap , Ian Jackson , Lars Kurth , David Vrabel , Jan Beulich , Wei Liu List-Id: xen-devel@lists.xenproject.org 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.