[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 19/08/2015 08:17, Roger Pau Monnà wrote:

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.

I'm just saying that DOM0 distribution may not be the same a the guest distributions. So we would have to reach out any distributions to have QEMU patched. Rather than only having the guest distributions fixed.

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?

Because you would have to update your platform with a new QEMU in order to support indirect grants. Unless we backport the patch to Xen 4.5 too. Although, IIRC, backporting a feature is not common.

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.

I need to correct you on one point here, the mess is Linux assuming that he is using the same page size as Xen, not adding support of different page size. It was a mistake when PV drivers has been created and had to be fixed in any case.


Julien Grall

Xen-devel mailing list



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