Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 9 Mar 2018, Julien Grall wrote:
> Furthermore, the workaround is not in Linux upstream and I doubt this will be
> accepted as it is. So I am not convinced that we should modify Xen interface
> for that.
> 
> Anyway, given that your silicon is going to be respined, then you probably
> want to restrict to run on the same cluster.

Hi Pen,

I think that i.MX8 is a critical platform for the future of embedded
virtualization and I really want to support it in Xen out of the box.

However, I agree with Julien that if there will be a new version of the
silicon with this issue properly fixed in hardware, then it might not
make sense to add workarounds in Xen for this. Unless you think the
version of the hardware with the errata will be commercialized?

Do you plan to upstream your workaround in Linux? If not, then it might
be best for you to carry the workaround for Xen in your Xen tree, the
same way you'll do for Linux. For workarounds that affect/involve both
Linux and Xen, we tend to follow the same policy as the Linux kernel,
unless we have good reasons not to. On the other end, if you intend to
upstream the Linux workaround, then we can discuss what to do for Xen.


Also let me expand on one of Julien's suggestions that actually I think
is quite good. Assuming that we have the tlb maintenance workaround in
the hypervisor, it would be safe to start guests only in the big or only
in the little cluster, right? In other words, you could still use both
clusters but only starting guests in one or the other, not both. This is
a good compromise because it allows full usage of the hardware, a
relatively small patch in Xen, and no guest visible changes (such as
toolstack changes to modify the compatible line). Guest visible and user
visible changes are particularly troublesome to maintain in the long
term and this is reason why we are reticent in introducing them. The tlb
maintenance workaround in the hypervisor is something much easier to
manage and we could consider taking it in if hardware with the errata
will become available to customers.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel