On 27/01/20 9:30 pm, Ralf Ramsauer wrote:
On 27/01/2020 15:49, Jan Kiszka wrote:
On 27.01.20 14:56, nikhil.nd via Jailhouse wrote:
From: Nikhil Devshatwar <nikhil...@ti.com>
This series adds support for partitioning registers across different
cells
in the Jailhouse. Jailhouse supports partitioning memory regions;
where it uses
MMU mapping for page aligned regions and subpage handler for non
aligned regions.
However, most of the embedded platforms will have common set of
registers which
need to be partitioned at the granularity of single register. One such
example is
the pinmux registers avaialble in many platforms including K3 J721e.
This series implements a regmap unit which allows to describe the
ownerhip of the
registers using a simple bitmap. This scales well when you have to
partition
hundreds of control module or pinmux registers.
Nikhil Devshatwar (4):
configs: arm64: k3-j721e-linux: Add USB mem_regions
core: Introduce regmaps in cell config for partitioning registers
core: Implement regmap unit for partitioning registers
configs: k3-j721e: Add regmaps for PADCONFIG registers
configs/arm64/k3-j721e-evm-linux-demo.c | 41 +++-
configs/arm64/k3-j721e-evm.c | 15 ++
hypervisor/Makefile | 2 +-
hypervisor/include/jailhouse/cell.h | 2 +
hypervisor/include/jailhouse/regmap.h | 47 +++++
hypervisor/regmap.c | 258 ++++++++++++++++++++++++
include/jailhouse/cell-config.h | 22 +-
tools/jailhouse-cell-linux | 5 +-
tools/jailhouse-hardware-check | 2 +-
9 files changed, 387 insertions(+), 7 deletions(-)
create mode 100644 hypervisor/include/jailhouse/regmap.h
create mode 100644 hypervisor/regmap.c
Worthwhile to discuss, indeed. The key question for me is how well it
could map on other SoCs. Ralf, do you think it could be that simple,
based on your experiments? Or could we also face scenarios where we
The question is what you try to achieve:
Jan, when you introduced subpaging, the goal was to allow to assign
devices to different domains, if multiple devices are located on the
same page. We can observe that pattern on many platforms, and subpaging
provides a "generic" solution.
So what do you try to achieve with subpaging on a byte-wise/bit-wise
granularity? Make a non-partitionable device partitionable? That will
only work for some rare cases.
The main intention here was not to partition peripheral devices, but
just the registers
which are not really related to any device.
Most SoCs will have something like this where pinmux registers,
efuse registers, internal muxes, MAC addresses, and other config options
are provided.
This series was intended to solve these kind of register partitioning.
However, those cases exist, and I think it can really be helpful.
would have to dispatch bits of a registers? We already do in some GIC
Yes, unfortunately I can imagine such scenarios, and even bitwise
dispatching is not enough. Two examples:
1) Reset controllers. E.g., the Jetson TK1/TX1 have bitwise granularity
(cf. reset.png). Here we need bitwise granularity. But that's still
easy.
2) Clock controllers. The semantic of a bit in a register may depend on
the configuration of a higher-level clock. On the other hand,
the reconfiguration of a higher might affect lower-level clocks
clocking, power management, reset should be handled via a common
software entity, It is designed considering virtualization in mind.
Typical clocks are trees, where you need to change multiple parent
clocks and muxes.
I believe this problem cannot be and should not be solved by Hypervisors.
On TI k3 devices, DMSC (Device mangement and security controlled) does
this job
and Linux drivers use firmware APIs to get this done.
Regards,
Nikhil D
across multiple cells.
Let me just share the thoughts we had back then...
So for 1), bitwise granularity would really be helpful. But keep in mind
that upstream drivers usually don't like that. What would you do, if
your inmate violates the permissions? Probably panic the cell. But by
default and in case of Linux, many drivers aren't aware that they only
see a subset of the device's functionality.
~Two years ago, I evaluated a similar approach. I ended up in rewriting
kernel drivers (with no benefit for upstream)...
And I see no easy way to solve 2) despite a constant, static (freeze)
configuration. That comes with a lot of drawbacks, as inmates aren't
able to dynamically reconfigure the device. In case of a clock device,
they aren't able to, e.g., change the speed of I2C, SPI, you name it.
We thought of paravirtualisation. In case of Jailhouse this is surely no
solution: It requires to provide an abstract device model together with
an implementation for thousands of different devices - no chance.
The third approach would be to implement the device's functionality in
the firmware in a partitionable manner, and use jailhouse only to
moderate access. Only feasible from the Jailhouse PoV.
HTH,
Ralf
regs, clock gates may be another case.
Jan
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/c02f19d0-183e-a12c-5364-ccb391a2cab8%40ti.com.
