[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 20/08/2015 02:43, 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 need to correct you here, there is no Linux guests using 64KB page granularity. It's possible to come up with a guests using 64KB and working with non-indirect grant.

It's not easily possible to do it in Linux because the block framework is always passing a Linux page size (i.e 4KB or 64KB). So we are exposing broken Linux PV drivers/interface to the backend.

IMHO, it is not, and none of the proposed solutions (either change
blkfront or Qdisk) include any change to the Xen ABI. In this case my
preference would be to perform the change in the backend for the reasons
detailed above.

Anyway, I'm not going to block such a change, I just think there are
technically better ways to solve this issue.

I'm already unhappy about the complexity of the stop-gap support for 64
KiB guest pages in Linux and if there's a way to get it working by
adding a useful missing feature to qemu's disk backend then that is what
should be done.

I'd like to remind you that assuming that Linux and Xen was using the same page size was wrong. There is nothing in the Xen interface requiring a such things. So we ought to do it at some point given that ARM is not the only architecture supporting 2 different page size.

Regards,

--
Julien Grall

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

 


Rackspace

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