Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file

[Julien Grall <julien.grall@xxxxxxx>]

On 23/10/2019 17:11, Oleksandr wrote:
> On 16.10.19 18:04, Julien Grall wrote:
Hi,

> > > Below is example from linux kernel sources:
> > >
> > > linux/sound/ppc/awacs.c:741:    if (of_machine_is_compatible("PowerBook3,1")
> > > linux/sound/ppc/awacs.c:742:        ||
> > > of_machine_is_compatible("PowerBook3,2")) {
> > > linux/sound/ppc/awacs.c:770:#define IS_PM7500
> > > (of_machine_is_compatible("AAPL,7500") \
> > > linux/sound/ppc/awacs.c:771:        || of_machine_is_compatible("AAPL,8500") \
> > > linux/sound/ppc/awacs.c:772:        || of_machine_is_compatible("AAPL,9500"))
> > > ...
> > > linux/arch/arm/mach-omap2/pdata-quirks.c:703:        if
> > > (of_machine_is_compatible(quirks->compatible)) {
> > > linux/arch/arm/mach-omap2/pdata-quirks.c:717:    if
> > > (of_machine_is_compatible("ti,omap2420") ||
> > > linux/arch/arm/mach-omap2/pdata-quirks.c:718:
> > > of_machine_is_compatible("ti,omap3"))
> > > linux/arch/arm/mach-omap2/pdata-quirks.c:721:    if
> > > (of_machine_is_compatible("ti,omap3"))
> > > ...
> > >
> > > Also see [1]
> > >
> > > [1] 
> > > https://source.codeaurora.org/external/imx/imx-xen/commit/?h=imx_4.14.98_2.0.0_ga&id=6e58d478203639e71da3da69ffeae3fa5dc0197b 
> > So this is a grep from Linux, I have already done that. What I am looking at 
> > is an exact description of your problem. Can you tell me what you are trying 
> > to passthrough? Can you also provide a pointer to the Linux code checking the 
> > compatible for your problem?
> I have no idea whether it is ok or not to pass machine/SoC compatible to a guest 
> from the safety PoV, so I am not going to comment regarding safety.
> I just would like to provide description of the problem we could face when not 
> passing machine/SoC compatible to a guest which runs real H/W (not PV) devices.
> ...
>
> I have just checked without passing real "dt_compatible" to a guest on the M3N 
> board. So, this can be considered as real example.
> I noticed that at least two H/W devices (which are pass throughed to the guest) 
> suffered from the lack of compatible: sdhi_internal_dmac and xhci-hcd. And as 
> result SD card and USB host are not functional.
> Why this happened? There is SoC Identification framework which purpose is to 
> detect SoC's id/revision for the future use in drivers to properly apply some 
> quirks (if needed). And without real compatible string in place the framework fails
> to proceed leaving the SoC attributes unregistered [1]. This results in SDHI 
> Internal DMAC controller fails to identify the SoC [2], so can't operate.
Thank you for giving more information on the problem.

Usually when you have quirks required for a device, they will be the same for 
all platforms using the same device revision. So it feels a bit odd to base it 
on a SoC ID/revision.
The problem you described above would also happen if you move to a new SoC with 
the same device revision. You will need to update Linux in order to use that device.
Xen VM is comparable to a "SoC". For instance, we needed to add Xen knowledge in 
Linux so it can boot. In the case of Device assignment, you can view this as a 
derivation of Xen VM (let's call it "Xen VM Bar").
As for any new SoC, if you want your OS to function on "Xen VM Bar", you may be 
required to modify it.
The approach suggested in this patch may work for you, but I don't think this is 
an approach that should be taken by Xen upstream. Instead, we should work with 
the community to replace quirks based on SoC/ID with quirks based on device 
binding property.
Cheers,

--
Julien Grall

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