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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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

--
Julien Grall

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