On 12/03/18 02:57, Peng Fan wrote:
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.

Usually you give access to a device and describe it in the device-tree. The kernel will then use the appropriate driver for that device.

You should never need to know what the machine is. Can you describe why this would be necessary in your use 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.

Based on what you said above, I would not even consider to upstream workaround for Xen.

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 

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?

I think so. But this is only based on how I understood the description provided in the commit message you pointed early on.

I have no insight whether TLB flush in hypervisor are going to be affected by the workaround. I would recommend to speak with your hardware team for that.

A naive question, what case would require tlb broadcast from A53 to A72 in XEN? 
page balloon?
Xen is sharing page-table between all the pCPU. As the hypervisor will run on the both cluster, you would need to convert all innershareable
TLBs flush by VA to a full innershareable.


Julien Grall

Xen-devel mailing list

Reply via email to