Re: [RFC] Support of non-indirect grant backend on 64KB guest

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

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é wrote:
> > > El 20/08/15 a les 1.44, Stefano Stabellini ha escrit:
> > >> On Wed, 19 Aug 2015, Roger Pau Monné 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 leverage.
> > >>>
> > >>> So in one hand you are adding code to a kernel component, that makes 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 decides
> > >> 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 use
> > >> 64K pages, that's entirely a Linux decision. The issue has nothing to do
> > >> with Xen.
> > >>
> > >> The bug here is that Linux has broken 64K pages support and that should
> > >> 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 particular
> > >> 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 yet).
> 
> 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.

<sigh> 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