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

From: Julien Grall <julien.grall@arm.com>
To: Peng Fan <van.freenix@gmail.com>
Cc: Peng Fan <peng.fan@nxp.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v4 0/7] unsafe big.LITTLE support
Date: Fri, 9 Mar 2018 10:22:09 +0000	[thread overview]
Message-ID: <983abafd-e8c9-57d4-2d7a-74291a2a24c5@arm.com> (raw)
In-Reply-To: <20180309090529.GA20107@shlinux2>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel