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

[Peng Fan <van.freenix@xxxxxxxxx>]

On Fri, Mar 09, 2018 at 02:40:25PM +0000, Julien Grall wrote:
>Hi,
>
>On 09/03/18 13:30, Peng Fan wrote:
>>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).
>
>Do you always expect a domain to access the SCU? Even with no
>passthrough involved?

only needed when a domain only needs to directly access hardware.

>
>>
>>>
>>>>
>>>>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.
>
>I know you were suggesting that and my point stands. Xen VM are not
>compatible with IMX8 platform.
>
>And again, a user should not have to tweak his configuration file,
>have to passthrough some device to an untrusted guest in order to
>have a guest booting normally on your platform. That is breaking the
>whole purpose of virtualization.
>
>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.

Understand.

Thanks,
Peng.

>
>Cheers,
>
>-- 
>Julien Grall

-- 

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