From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC] Support of non-indirect grant backend on 64KB guest Date: Fri, 21 Aug 2015 12:05:10 -0400 Message-ID: <20150821160510.GE26663@l.oracle.com> References: <55D2D0C4.3070700@citrix.com> <55D2DA15.6070105@citrix.com> <55D37D31.9010401@citrix.com> <55D44338.8030108@citrix.com> <55D498B4.2030804@citrix.com> <55D49E1B.4010405@citrix.com> <55D5906C.7070907@citrix.com> <55D5A15C.80206@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Julien Grall , Ian Campbell , Roger Pau =?iso-8859-1?Q?Monn=E9?= , David Vrabel , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Thu, Aug 20, 2015 at 06:23:16PM +0100, Stefano Stabellini wrote: > On Thu, 20 Aug 2015, David Vrabel wrote: > > On 20/08/15 09:31, Roger Pau Monn=E9 wrote: > > > El 20/08/15 a les 1.44, Stefano Stabellini ha escrit: > > >> On Wed, 19 Aug 2015, Roger Pau Monn=E9 wrote: > > >>> My opinion is that we have already merged quite a lot of this mess = in > > >>> order to support guests with different page sizes. And in this case= , the > > >>> addition of code can be done to a userspace component, which is much > > >>> less risky than adding it to blkfront, also taking into account that > > >>> it's a general improvement for Qdisk that other arches can also lev= erage. > > >>> > > >>> So in one hand you are adding code to a kernel component, that make= s the > > >>> code much more messy and can only be leveraged by ARM. On the other > > >>> hand, you can add code a user-space backend, and that code is also > > >>> beneficial for other arches. IMHO, the decision is quite clear. > > >> > > >> 64K pages not working is entirely a Linux problem, not a Xen problem. > > >> Xen uses 4K pages as usual and exports the same 4K based hypercall > > >> interface as usual. That needs to work, no matter what the guest dec= ides > > >> to put in its own pagetables. > > >> > > >> I remind everybody that Xen interfaces on ARM and ARM64 are fully > > >> maintained for backward compatibility. Xen is not forcing Linux to u= se > > >> 64K pages, that's entirely a Linux decision. The issue has nothing t= o do > > >> with Xen. > > >> > > >> The bug here is that Linux has broken 64K pages support and that sho= uld > > >> be fixed. I don't think is reasonable to make changes to the Xen ABIs > > >> just to accommodate the brokenness of one guest kernel in a particul= ar > > >> configuration. > > > > > > Is it a change to the ABI to mandate indirect-descriptors support in > > > order to run arm64 with 64KB guests? > > > > No (given that there is no guest using 64 KiB guest pages that works ye= t). > = > I think that this is wrong: given that the ABI is completely neutral to > the page granularity used by DomU, this as an ABI change. DomU and Dom0 > can safely mix and match granularity and using 64K pages is purely a > single guest choice, not a platform wide choice. One should be able to > run any DomU with your good old Dom0 kernel. > = > If we wanted to mandate indirect-descriptors (which I think would be a > bad decision), we would have to bump a version number somewhere. I have to concur with that. We can't mandate that ARM 64k page MUST use indirect descriptors. I am not particulary happy about this but the xen-blkfront changes are the best way to make this work. At least we don't have this problem with xen-netfront (right?!)? or other drivers? > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel