Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 30/01/2020 15:11, Jan Kiszka wrote: > On 30.01.20 14:38, Ralf Ramsauer wrote: >> On 28/01/2020 09:09, 'Nikhil Devshatwar' via Jailhouse wrote: >>> >>> >>> On 28/01/20 2:41 am, Jan Kiszka wrote: On 27.01.20 20:41, Nikhil Devshatwar wrote: > > > On 27/01/20 10:03 pm, Jan Kiszka wrote: >> On 27.01.20 17:13, Nikhil Devshatwar wrote: >>> >>> >>> 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 >> >> 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. >> >> Can you point out another SoC that we support which would benefit >> from >> this description method? >> > > e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit > from this. > There are lots of pinctrl nodes in the mainline Linux kernel device > tree[0] and [1] > > Currently, the pinmux configuration is described in root cell device > tree [2] but not available in inmate device tree [3] > > [0] - > https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 > > > [1] - > https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 > > > [2] - > https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 > > > [3] - > https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts > > > > With this regmap framwork, it is possible to define the pinmux node > such > that > inmate Linux kernel can configure the pinmux when running in > Jailhouse
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 30.01.20 14:38, Ralf Ramsauer wrote: On 28/01/2020 09:09, 'Nikhil Devshatwar' via Jailhouse wrote: On 28/01/20 2:41 am, Jan Kiszka wrote: On 27.01.20 20:41, Nikhil Devshatwar wrote: On 27/01/20 10:03 pm, Jan Kiszka wrote: On 27.01.20 17:13, Nikhil Devshatwar wrote: 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 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. Can you point out another SoC that we support which would benefit from this description method? e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit from this. There are lots of pinctrl nodes in the mainline Linux kernel device tree[0] and [1] Currently, the pinmux configuration is described in root cell device tree [2] but not available in inmate device tree [3] [0] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 [1] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 [2] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 [3] - https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts With this regmap framwork, it is possible to define the pinmux node such that inmate Linux kernel can configure the pinmux when running in Jailhouse cell. This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? Yes But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up to PAGE_SIZE-1, a regmap currently only 256 bytes. regmap implentation can be changed to support 4k pages as well. That way, a bitmap can be generated to pass to regmap. But there is additional overhead of checking the offset. But yes, regmap can replace subpage, however, this change should be transparant without having to change the jailhouse_memory descriptions. I wonder if we can combine both, maybe expand the memory region to optionally refer to a bitmap for finer-grained access control. Yes, that is also a good option, This will increas the size of cell config though. I don't think so, at least not noteworthy. One benefit of combining both would be benefiting from the more
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 28/01/2020 09:09, 'Nikhil Devshatwar' via Jailhouse wrote: > > > On 28/01/20 2:41 am, Jan Kiszka wrote: >> On 27.01.20 20:41, Nikhil Devshatwar wrote: >>> >>> >>> On 27/01/20 10:03 pm, Jan Kiszka wrote: On 27.01.20 17:13, Nikhil Devshatwar wrote: > > > 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 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. Can you point out another SoC that we support which would benefit from this description method? >>> >>> e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit >>> from this. >>> There are lots of pinctrl nodes in the mainline Linux kernel device >>> tree[0] and [1] >>> >>> Currently, the pinmux configuration is described in root cell device >>> tree [2] but not available in inmate device tree [3] >>> >>> [0] - >>> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 >>> >>> [1] - >>> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 >>> >>> [2] - >>> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 >>> >>> [3] - >>> https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts >>> >>> >>> With this regmap framwork, it is possible to define the pinmux node such >>> that >>> inmate Linux kernel can configure the pinmux when running in >>> Jailhouse cell. >>> > > This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? >>> Yes But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 28/01/20 2:41 am, Jan Kiszka wrote: On 27.01.20 20:41, Nikhil Devshatwar wrote: On 27/01/20 10:03 pm, Jan Kiszka wrote: On 27.01.20 17:13, Nikhil Devshatwar wrote: 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 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. Can you point out another SoC that we support which would benefit from this description method? e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit from this. There are lots of pinctrl nodes in the mainline Linux kernel device tree[0] and [1] Currently, the pinmux configuration is described in root cell device tree [2] but not available in inmate device tree [3] [0] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 [1] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 [2] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 [3] - https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts With this regmap framwork, it is possible to define the pinmux node such that inmate Linux kernel can configure the pinmux when running in Jailhouse cell. This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? Yes But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up to PAGE_SIZE-1, a regmap currently only 256 bytes. regmap implentation can be changed to support 4k pages as well. That way, a bitmap can be generated to pass to regmap. But there is additional overhead of checking the offset. But yes, regmap can replace subpage, however, this change should be transparant without having to change the jailhouse_memory descriptions. I wonder if we can combine both, maybe expand the memory region to optionally refer to a bitmap for finer-grained access control. Yes, that is also a good option, This will increas the size of cell config though. I don't think so, at least not noteworthy. One benefit of combining both would be benefiting from the more precise access size control features of the memory region. The regmap only supports one register
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 27.01.20 20:41, Nikhil Devshatwar wrote: On 27/01/20 10:03 pm, Jan Kiszka wrote: On 27.01.20 17:13, Nikhil Devshatwar wrote: 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 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. Can you point out another SoC that we support which would benefit from this description method? e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit from this. There are lots of pinctrl nodes in the mainline Linux kernel device tree[0] and [1] Currently, the pinmux configuration is described in root cell device tree [2] but not available in inmate device tree [3] [0] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 [1] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 [2] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 [3] - https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts With this regmap framwork, it is possible to define the pinmux node such that inmate Linux kernel can configure the pinmux when running in Jailhouse cell. This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? Yes But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up to PAGE_SIZE-1, a regmap currently only 256 bytes. regmap implentation can be changed to support 4k pages as well. That way, a bitmap can be generated to pass to regmap. But there is additional overhead of checking the offset. But yes, regmap can replace subpage, however, this change should be transparant without having to change the jailhouse_memory descriptions. I wonder if we can combine both, maybe expand the memory region to optionally refer to a bitmap for finer-grained access control. Yes, that is also a good option, This will increas the size of cell config though. I don't think so, at least not noteworthy. One benefit of combining both would be benefiting from the more precise access size control features of the memory region. The regmap only supports one register size, memory region all of them. Also, we may save quite a bit of
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 27/01/20 10:03 pm, Jan Kiszka wrote: On 27.01.20 17:13, Nikhil Devshatwar wrote: 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 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. Can you point out another SoC that we support which would benefit from this description method? e.g. We support jetson-tk1 which uses Nvidia tegra124. It can benefit from this. There are lots of pinctrl nodes in the mainline Linux kernel device tree[0] and [1] Currently, the pinmux configuration is described in root cell device tree [2] but not available in inmate device tree [3] [0] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124.dtsi#L334 [1] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L83 [2] - https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/tegra124-jetson-tk1.dts#L1035 [3] - https://github.com/siemens/jailhouse/blob/master/configs/arm/dts/inmate-jetson-tk1.dts With this regmap framwork, it is possible to define the pinmux node such that inmate Linux kernel can configure the pinmux when running in Jailhouse cell. This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? Yes But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up to PAGE_SIZE-1, a regmap currently only 256 bytes. regmap implentation can be changed to support 4k pages as well. That way, a bitmap can be generated to pass to regmap. But there is additional overhead of checking the offset. But yes, regmap can replace subpage, however, this change should be transparant without having to change the jailhouse_memory descriptions. I wonder if we can combine both, maybe expand the memory region to optionally refer to a bitmap for finer-grained access control. Yes, that is also a good option, This will increas the size of cell config though. Regards, Nikhil D -- 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
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 27.01.20 17:13, Nikhil Devshatwar wrote: 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 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. Can you point out another SoC that we support which would benefit from this description method? This series was intended to solve these kind of register partitioning. So, subpaging does not scale when we have a scattered access map, right? But can we use this description method to replace subpaging? The latter registers an contiguous mmio dispatch region, your approach additionally checks within that region a bitmap. A subpage entry can handle up to PAGE_SIZE-1, a regmap currently only 256 bytes. I wonder if we can combine both, maybe expand the memory region to optionally refer to a bitmap for finer-grained access control. 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/7222df54-40c7-6958-570e-9eb50365e905%40web.de.
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
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 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
Re: [RFC PATCH v1 0/4] Add support for partitioning registers
On 27.01.20 14:56, nikhil.nd via Jailhouse wrote: From: Nikhil Devshatwar 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 would have to dispatch bits of a registers? We already do in some GIC 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/e4e85734-bcc5-d833-3f31-53e90c186de3%40web.de.
