From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425081AbcFIGEw (ORCPT ); Thu, 9 Jun 2016 02:04:52 -0400 Received: from david.siemens.de ([192.35.17.14]:58622 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161753AbcFIGEu (ORCPT ); Thu, 9 Jun 2016 02:04:50 -0400 Subject: Re: Using DT overlays for adding virtual hardware To: Pantelis Antoniou , Mark Rutland References: <575828C0.5000008@siemens.com> <20160608151745.GB13355@leverpostej> <28BC1AEC-6A7D-4A97-82F4-5670E884C41D@konsulko.com> <20160608162343.GD13355@leverpostej> <999B1CFF-C204-4C19-AE76-AF9DB54E51E4@konsulko.com> <57584A2C.4030507@siemens.com> Cc: devicetree , Linux Kernel Mailing List , Jailhouse , =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= , Antonios Motakis From: Jan Kiszka Message-ID: <5759069B.4080800@siemens.com> Date: Thu, 9 Jun 2016 08:03:07 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <57584A2C.4030507@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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