[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <575828C0.5000008@siemens.com>
Date: Wed, 8 Jun 2016 16:16:32 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: devicetree <devicetree@...r.kernel.org>,
Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jailhouse <jailhouse-dev@...glegroups.com>,
Måns Rullgård <mans@...x.de>,
Antonios Motakis <antonios.motakis@...wei.com>
Subject: Using DT overlays for adding virtual hardware
Hi all,
already started the discussion off-list with Pantelis, but it's better
done in public:
I'm currently exploring ways to make Linux recognize dynamically added
virtual hardware when running under the Jailhouse hypervisor [1]. We
need to load drivers for inter-partition communication devices that only
appear after Jailhouse started (which is done from within Linux, i.e.
long after boot) or when a partition was added later on. Probably, we
will simply add a virtual PCI host bridge on systems without physical
PCI and let the IPC device be explored that way (already works on x86).
Still, that leaves us with hotplug and unplug on hypervisor activation
and deactivation.
Inspired by how FPGA bitstream loaders and the caps/hats for BeagleBones
and RasPis work, I thought of using device tree overlays for this.
However, it seems there are still some gaps in upstream Linux /wrt
overlays. So I would like to find out what already works and what may
need further patches.
The plan (open for suggestions) is as follows:
- have an overlay template for a virtual platform device
- compile it into the Jailhouse loader kernel module
- adjust key parameters (e.g. register base addresses) after
instantiating a device (of_update_property?)
- push modified dt into of_overlay_create
To my understanding, the last step will trigger driver probing which
will cause the device being activated (provided the driver is available,
of course).
I played with the fragment from
Documentation/devicetree/overlay-notes.txt, but already that failed
because the in-kernel dtc does not support /plugin/ yet, right? (Why
not, btw?) What else do I need to patch/update to make the above work?
Or are the simpler ways to achieve what we need?
Thanks,
Jan
[1] https://github.com/siemens/jailhouse
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Powered by blists - more mailing lists