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

[Peng Fan <van.freenix@xxxxxxxxx>]

Hi Stefano,
On Fri, Mar 09, 2018 at 05:09:20PM -0800, Stefano Stabellini wrote:
>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?

Understand. I just thought some kernel code use machine
compatible string to do some check for passthrough case.

Some early customers might use the 1.0 chip to do their development,
but I think all will switch to use new Silicon in the end.

>
>Do you plan to upstream your workaround in Linux? If not, then it might

No plan. This workaround might not be accepted by Linux community.

>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

I am a bit lost here. Are you refering Julien's suggestion 3?
"3) Trap all TLBs access from the guest and convert them to TLB 
alle1s/vmalls12e1is"

Currently, only use one the of the 2 clusters, I do not meet issue.
No change to xen and domu not aware of linux workaround.

Do you mean it is not safe without tlb maintenance workaround on my current
hardware, even if restricting Guest OS only have one kind of cpu?

A naive question, what case would require tlb broadcast from A53 to A72 in XEN? 
page balloon?

Thanks
Peng.

>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