linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "Pantelis Antoniou" <pantelis.antoniou@konsulko.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	Jailhouse <jailhouse-dev@googlegroups.com>,
	"Måns Rullgård" <mans@denx.de>,
	"Antonios Motakis" <antonios.motakis@huawei.com>
Subject: Re: Using DT overlays for adding virtual hardware
Date: Thu, 09 Jun 2016 09:22:09 +0200	[thread overview]
Message-ID: <3626899.Rd8tgT5L4H@wuerfel> (raw)
In-Reply-To: <57584A2C.4030507@siemens.com>

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

  parent reply	other threads:[~2016-06-09  7:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08 14:16 Using DT overlays for adding virtual hardware Jan Kiszka
2016-06-08 15:17 ` Mark Rutland
2016-06-08 15:27   ` Jan Kiszka
2016-06-08 15:57   ` Pantelis Antoniou
2016-06-08 16:23     ` Mark Rutland
2016-06-08 16:31       ` Pantelis Antoniou
2016-06-08 16:39         ` Jan Kiszka
2016-06-09  6:03           ` Jan Kiszka
2016-06-21 10:13             ` Jan Kiszka
2016-06-21 10:24               ` Pantelis Antoniou
2016-06-21 11:22                 ` Jan Kiszka
2016-06-21 11:35                   ` Pantelis Antoniou
2016-06-21 11:43                     ` Jan Kiszka
2016-06-21 11:45                       ` Pantelis Antoniou
2016-06-21 11:59                         ` Jan Kiszka
2016-06-21 13:12                           ` Jan Kiszka
2016-06-21 13:29                             ` Pantelis Antoniou
2016-06-09  7:22           ` Arnd Bergmann [this message]
2016-06-10 14:57             ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3626899.Rd8tgT5L4H@wuerfel \
    --to=arnd@arndb.de \
    --cc=antonios.motakis@huawei.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jailhouse-dev@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mans@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=pantelis.antoniou@konsulko.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).