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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Peng,

On 09/03/18 09:05, Peng Fan wrote:
> On Thu, Mar 08, 2018 at 03:13:50PM +0000, Julien Grall wrote:
> > On 08/03/18 12:43, Peng Fan wrote:
> > There are a major difference between Dom0 and DomU in your setup.
> > Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
> > For DomU, each vCPU are pinned to a set of pCPUs, so they can move
> > around.
> >
> > But, did you check the DomU has the workaround enabled? I am asking
> > that because it looks like to me the way to detect the workaround is
> > based on a device (scu) and not processor. So I am not convinced that
> > DomU is actually using your workaround.
> Just checked this. Because xen toolstack create device tree
> with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
> but the linux code use "fsl,imx8qm" to detect soc, then call scu
> to get revision of chip.
But how does the guest call the scu?

> After add an entry in linux side "{ .compatible = "xen,xenvm", .data = 
> &imx8qm_soc_data, },"
> It seems works. Passed a map/unmap stress test which easily fail without
> the tlb workaround.
>
> Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
> use this machine compatible other than "xen,xenvm"? Is this acceptable by 
> community?
A user should be able to boot a guest safely on any machine without 
having to hack the configuration file. He should also be able to boot a 
guest with both ACPI and DT as this is independent from the real 
machine. So for me the way to find the workaround at the moment is not 
acceptable for a Xen guest upstream.
What could be acceptable for the community is one of the 3 solutions below:
        1) Only use one of the 2 clusters
        2) Restrict both Xen and Guest to use only 36-bit VA.
	3) Trap all TLBs access from the guest and convert them to TLB 
alle1s/vmalls12e1is
I would be happy to consider any other.

Cheers,

--
Julien Grall

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