[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.