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

[Peng Fan <van.freenix@gmail.com>]

Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +0000, Julien Grall wrote:
>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?

We are doing GPU and display passthrough, also some other IPs passthrough.
we could not totally rely on Dom0 to configure the pinmux, gpio, clk,
relying on dom0 to do that would bring much hack code to our kernel, also
runtime clk set rate in domu could not be done.

So we expose an interface to domu to directly communicate with SCU(system
control unit). 

>
>>
>>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.

I have no idea about ACPI (:
we are mainly working on embedded case, and mostly we are partitioning
our IPs. So our kernel normally only work with the dedicated DTB.
I am not asking to replace "xen,xenvm", just would like to add a option
that if user specific a machine compatible in cfg or else, xen toolstack
could add that in the final device tree.

Anyway new silicon will have issue fixed.
>
>What could be acceptable for the community is one of the 3 solutions below:
>	1) Only use one of the 2 clusters
The easiest way:)
>	2) Restrict both Xen and Guest to use only 36-bit VA.
I have no idea, need to check
>	3) Trap all TLBs access from the guest and convert them to TLB
>alle1s/vmalls12e1is
This will introduce performance penalty. I would not do this.

Thanks,
Peng.
>
>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