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

[Julien Grall <julien.grall@xxxxxxx>]

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?
> > > 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.
Cheers,

--
Julien Grall

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