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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.08.15 at 01:44, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 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.

I would agree if the proposal was to add hacks or workarounds to the
ABI, but afaics neither what Roger suggested nor what I said go in
that kind of a direction.

Jan

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