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

[Julien Grall <julien.grall@citrix.com>]

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@lists.xen.org
http://lists.xen.org/xen-devel