Re: Using DT overlays for adding virtual hardware

[Jan Kiszka]

On 2016-06-08 18:39, Jan Kiszka wrote:
>>>> The question is since overlays exist and do work, why should he do anything else
>>>> besides using them?
>>>
>>> For one thing, they only work with DT, and there are ACPI ARM server
>>> platforms out there, for which people may wish to use jailhouse. Tying
>>> this to DT is not necessarily the best idea.
>>>
>>
>> I just donât see how an ACPI based hypervisor can ever be certified for
>> safety critical applications. It might be possible but it should be
>> an enormous undertaking; perhaps a subset without AML, but then again
>> can you even boot an ACPI box without it?
> 
> ACPI is out of scope for us. We will probably continue to feed the
> hypervisor with static platform information, generated in advance and
> validated. Can be DT-based one day, but even that is more complex to
> parse than our current structures.
> 
> But does ACPI usually mean that the kernel no longer has DT support and
> would not be able to handle any overlay? That could be a killer.

However, I suspect that those machines with ACPI will also come with
PCI, in which case we do not need the virtual host bridge anyway.

> 
>>
>> DT is safer since it contains state only.
>>
>>> To be clear, I'm not arguing *against* overlays as such, just making
>>> sure that we're not prematurely choosing a solution just becasue it's
>>> the one we're aware of.
> 
> I'm open for any suggestion that is simple. Maybe we can extend a
> trivial existing pci host driver (like pci-host-generic) to work also
> without DT overlays - also fine, at least from Jailhose POV. However,
> any unneeded kernel patch is even better.

OK, trial and error, and some interesting insights: I've played with DT
fragments and the overlay configfs patch of Pantelis [1] to have a
convenient start. Interestingly, I wasn't able to load a fragment that
followed the format specification for overlays ("Failed to resolve
tree"). By chance, I got this one working:

/dts-v1/;
/ {
	fragment {
		target-path = "/soc@01c00000";
		__overlay__ {
			#address-cells = <2>;
			#size-cells = <2>;

			vpci@0x2000000 {
				compatible = "pci-host-cam-generic";
				device_type = "pci";
				#address-cells = <3>;
				#size-cells = <2>;
				reg = <0 0x2000000 0 0x1000000>;
				ranges =
					<0x02000000 0x00 0x10000000 0x00 0x10000000 0x00 0x30000000>;
			};
		};
	};
};

It successfully makes a BananaPi kernel add a pci host with the
specified config space and MMIO window.

[   81.619583] PCI host bridge /soc@01c00000/vpci@0x2000000 ranges:
[   81.619610]   No bus range found for /soc@01c00000/vpci@0x2000000, using [bus 00-ff]
[   81.619634]   MEM 0x10000000..0x3fffffff -> 0x10000000
[   81.620482] pci-host-generic 2000000.vpci: ECAM at [mem 0x02000000-0x02ffffff] for [bus 00-ff]
[   81.620779] pci-host-generic 2000000.vpci: PCI host bridge to bus 0000:00
[   81.620801] pci_bus 0000:00: root bus resource [bus 00-ff]
[   81.620814] pci_bus 0000:00: root bus resource [mem 0x10000000-0x3fffffff]
[   81.620851] PCI: bus0: Fast back to back transfers enabled

So, no /plugin/ statement, no phandles resolution. This format even
builds with the in-kernel dtc. Any explanations? Does the code make
sense (at least it builds without warnings)?

Now I need to back this with some code in Jailhouse.

Jan

[1] https://github.com/pantoniou/linux-beagle-track-mainline/commit/160e68ec89eca33e8ed0abb13d52c07c54d7fc10

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux