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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

Hello,

El 19/08/15 a les 16.54, Julien Grall ha escrit:
> On 19/08/2015 01:50, Roger Pau Monnà wrote:
>> Why can this be fixed in the Qemu side and the fix backported to 4.6.1?
> 
> And what about any other backend not supporting indirect grant?

The only other backend I know of is tapdisk/blktap, and I'm not even
sure if that's an option on ARM. IMHO at this point we should not worry
about out-of-tree backends, there's only one, and I don't think it's so
outrageous to force indirect-descriptors support for ARM guests.

>> If you want to fix it in Linux you will also have to wait for the next
>> release anyway, and then asks users to use a specific kernel version
>> (because distros won't pick the change that fast).
> 
> Aarch64 distros are not yet out officially. There is still work going
> out and they are planning to target to use Linux 4.2/4.3. We have
> distributions willing to take patches in their tree in order to support
> Xen guests.

So they are willing to take Linux kernel patches for allowing 64KB
guests but not Qemu patches? This seems quite weird IMHO, patching the
kernel is much more risky than patching Qemu.

> Although, if we have to patch QEMU, we also need to push on distribution
> that may not need 4KB enabled in order to use them as DOM0...
>
>> Overall I still think this should be fixed in Qemu, as said above users
>> will have to update anyway, either their kernels or their Qemu version.
> 
> Let's take the problem in another way. Your are a big cloud provider
> using Aarch64 hardware. You decided to use Xen 4.5 (and not Xen 4.6) as
> the base version and a DOM0 using 4KB page granularity. Now one of the
> small customer decides to use a distribution which have 64KB pages
> enabled, if booting using Qdisk it won't work at all. Why on the earth
> the cloud provider will update his QEMU to support this kind of guest?

Well, you are a could provider, you make money out of this, why on earth
won't you patch/update Qemu if it's needed by your customers?

> I think this is a really bad idea given that 64KB should work out-of-box
> and not depending on the backend side.

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.

Roger.

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