From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424113AbcFIHVR (ORCPT ); Thu, 9 Jun 2016 03:21:17 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:65155 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161273AbcFIHVP convert rfc822-to-8bit (ORCPT ); Thu, 9 Jun 2016 03:21:15 -0400 From: Arnd Bergmann To: Jan Kiszka Cc: Pantelis Antoniou , Mark Rutland , devicetree , Linux Kernel Mailing List , Jailhouse , =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , Antonios Motakis Subject: Re: Using DT overlays for adding virtual hardware Date: Thu, 09 Jun 2016 09:22:09 +0200 Message-ID: <3626899.Rd8tgT5L4H@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <57584A2C.4030507@siemens.com> References: <575828C0.5000008@siemens.com> <999B1CFF-C204-4C19-AE76-AF9DB54E51E4@konsulko.com> <57584A2C.4030507@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K0:eD/gAVOC18jkdM23r1d9xBlH+rgaxeobyM9i6F8QZ2Gc4ZvmBu0 II9oIoPw0SQagsHEapY4Ao8UHofofNalRjAbypMQASAv4EK9SaFEweMWXiOKkRsKfDpxI9w n2fClVqOU5fJcc4s5FHWVKxE9AyovT747SM7iM6Tfzm0jlsheHetS7oFLXPjw8QzsjlwdUk UAaPTbmBtHfjsjo8Ooj9w== X-UI-Out-Filterresults: notjunk:1;V01:K0:fdEdVD9NcDE=:ak9UzZso8rERRV4miOgQD1 pZB6UD6P8ndQcvDChol8oXfddoDJysVs7NG7V7Q51Dl5OXPmQfKV7qru4M42ra8iWr6OQn9Yq zZ4yp8kEqixre8kv8WJCgL4UXXLbLcHg4xVblxMSlQ1xqQwB+hqxUiLwRcK9+16c/xSv3DRLX GpPrmTm8rFpCHPFPpTecYgmzthrSrOgEk563a/HO1izl+qfs4Dci3FTvW2FoQ6IS9QZKjcK2g GKSRk1qGCjmkwARsmvO4hMIkyAh6mUxwXptm3dlQABbywR12IiDMIzjpAhWmMsArquY6oWoS/ Gj8ZQ6qZCoGnjn9C4Kfhe+LhXZT+RC91EydtCm+cd+y4fFWsopI79iL3X1XC0w1Keuck/q4Dk EU+CLw+9f+KvhgrwtJlHZqvlvbTs3jLbbwuqmHjowKiUj1VvG10LOssn+SL/oSNkZbuTWEzkC MBmi99UBt8NDxEzsI+6RjOwlwdbqIWucFBnu+wheVN/7O1iuQpTf3mt4v38M3VIES7mJi9Tad A8ZDy3U+e5KPNgkfMkvXqJC11dyjaOCTq5GVZskKaH17p2QSKgWhTD+1Syh0GmKpNH3S0KXks 5gaS8xOsTMr7DrscztXODiOg7TQVt6bTRKrMpafQCNhccgnfrPgKRrNU6PWkwBnN58oBXlPQ9 dWBIln6ZeP9u+SiJJwonig2nzWS7jOgfH+ELRksLIjz9fYOFIaeZI23CBv9m+vVb0WpfDmKhL dKfeT0LKpYMb206B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, June 8, 2016 6:39:08 PM CEST Jan Kiszka wrote: > >> > > > > 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. The kernel always has DT support built-in, but there may be some code paths that do not look at DT properties when it was booted from ACPI. In particular, communicating things like interrupt mappings may be hard, as they are represented very differently on ACPI, so you no longer have an 'interrupt-parent' node to point to from your overlay. It's hard to say how things would work out when trying to load DT overlays in this configuration. My guess is that it's actually easier to do on x86 (which doesn't normally rely on ACPI for describing the core system) than on arm64. > > 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. A few more observations: - you can easily have an arbitrary number of PCI host bridges, so you can always add another PCI bridge just for the virtual devices even on systems that have access to physical PCI devices in passthrough. - PCIe hotplugging seems well-defined enough to just make that work, without needing DT overlays. - The really tricky question is what to do about passthrough of host devices that are not PCI. The current generation of server class arm64 machines tend to have a bunch of those, and the expectation seems to be that hardware passthrough is the only way to get decent I/O performance to make up for the relatively slow CPU cores. If you are only concerned about emulated devices, that won't be a problem though. Arnd