Re: Run Linux in non-root cell on NUC
On Monday, October 22, 2018 at 9:46:30 AM UTC+8, minskey guo wrote: > On Sunday, October 21, 2018 at 7:34:12 PM UTC+8, J. Kiszka wrote: > > On 19.10.18 11:19, Jan Kiszka wrote: > > > On 19.10.18 09:42, minskey guo wrote: > > >> > > > > to get a bzImage for non-root cell. Now, the COM1 has output now > > during > > booting non-root-cell linux , but I run into another issue: > > > > 1.797742] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, > > 655360 > > ms ovfl timer > > [ 1.805696] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules > > [ 1.811470] RAPL PMU: hw unit of domain package 2^-14 Joules > > [ 1.817155] RAPL PMU: hw unit of domain dram 2^-14 Joules > > [ 1.822574] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules > > [ 1.828254] RAPL PMU: hw unit of domain psys 2^-14 Joules > > [ 1.833679] clocksource: tsc: mask: 0x max_cycles: > > 0x2717868ea45, max_idle_s > > [ 1.843722] clocksource: Switched to clocksource tsc > > FATAL: Invalid PIO read, port: 87 size: 1 > > >>> > > >>> That's a legacy resources, and that indicates your kernel lacks > > >>> Jailhouse > > >>> awareness (CONFIG_JAILHOUSE_GUEST). There kernel will also report > > >>> during boot if > > >>> it detected (and is aware of) Jailhouse. > > >> > > >> My kconfig has CONFIG_JAILHOUSE_GUEST. Just realized that 87 is hex, so > > >> it is > > >> DMA page register port. Currently, I set pio_bitmap[] for that port to > > >> 1 in > > >> both root and non-root cell. What else should I do ? > > >> > > > > > > You should not (have to) hand this over. I thought to remember it was > > > disabled > > > by one of the platform hooks in x86 that we have for Jailhouse, but maybe > > > it was > > > some driver that should rather be turned off. > > > > > > Try deriving your config from the one we using in jailhouse-images. > > > > Actually, we have the issue in jailhouse-image as well. Will send out a > > patch > > these days, but the trick to resolve it is simple: disable > > CONFIG_ISA_DMA_API > > (requires CONFIG_EXPERT). The issue started with 4.18 > > > > Jan > > > > -- > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > Corporate Competence Center Embedded Linux > > Can u send me the patch for a try ? > > thanks, > -Minskey I tried to disable ISA/DMA & DMA_ZONE in kconfig, the issue is still there. Should I disable all ATA/SATA driver as well ? The attachment is my kconfig. -- 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. For more options, visit https://groups.google.com/d/optout. kconfig-linux Description: Binary data
Re: Run Linux in non-root cell on NUC
On Sunday, October 21, 2018 at 7:34:12 PM UTC+8, J. Kiszka wrote: > On 19.10.18 11:19, Jan Kiszka wrote: > > On 19.10.18 09:42, minskey guo wrote: > >> > > to get a bzImage for non-root cell. Now, the COM1 has output now during > booting non-root-cell linux , but I run into another issue: > > 1.797742] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, > 655360 > ms ovfl timer > [ 1.805696] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules > [ 1.811470] RAPL PMU: hw unit of domain package 2^-14 Joules > [ 1.817155] RAPL PMU: hw unit of domain dram 2^-14 Joules > [ 1.822574] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules > [ 1.828254] RAPL PMU: hw unit of domain psys 2^-14 Joules > [ 1.833679] clocksource: tsc: mask: 0x max_cycles: > 0x2717868ea45, max_idle_s > [ 1.843722] clocksource: Switched to clocksource tsc > FATAL: Invalid PIO read, port: 87 size: 1 > >>> > >>> That's a legacy resources, and that indicates your kernel lacks Jailhouse > >>> awareness (CONFIG_JAILHOUSE_GUEST). There kernel will also report during > >>> boot if > >>> it detected (and is aware of) Jailhouse. > >> > >> My kconfig has CONFIG_JAILHOUSE_GUEST. Just realized that 87 is hex, so > >> it is > >> DMA page register port. Currently, I set pio_bitmap[] for that port to 1 > >> in > >> both root and non-root cell. What else should I do ? > >> > > > > You should not (have to) hand this over. I thought to remember it was > > disabled > > by one of the platform hooks in x86 that we have for Jailhouse, but maybe > > it was > > some driver that should rather be turned off. > > > > Try deriving your config from the one we using in jailhouse-images. > > Actually, we have the issue in jailhouse-image as well. Will send out a patch > these days, but the trick to resolve it is simple: disable CONFIG_ISA_DMA_API > (requires CONFIG_EXPERT). The issue started with 4.18 > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux Can u send me the patch for a try ? thanks, -Minskey -- 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. For more options, visit https://groups.google.com/d/optout.
[siemens/jailhouse] 0ef181: arm-common: account for SMC exits
Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: 0ef181543fcc3ff47f5f6f502ff88d351304feca
https://github.com/siemens/jailhouse/commit/0ef181543fcc3ff47f5f6f502ff88d351304feca
Author: Ralf Ramsauer
Date: 2018-10-21 (Sun, 21 Oct 2018)
Changed paths:
M driver/sysfs.c
M hypervisor/arch/arm-common/smccc.c
M include/arch/arm/asm/jailhouse_hypercall.h
M include/arch/arm64/asm/jailhouse_hypercall.h
Log Message:
---
arm-common: account for SMC exits
Statistics on ARM currently has some imbalances: the total number of
exits doesn't equal the sum of the fine granular exit counters: we
aren't accounting for SMCCC exits.
Fix this by adding a new statistic counter for SMCCC.
PSCI exits are already accounted inside psci_dispatch(), move SMCCC
accounting to the dispatcher routine handle_smc().
Fixes: 7688e96c815b ("arm-common: Rework handling of SMC")
Signed-off-by: Ralf Ramsauer
Signed-off-by: Jan Kiszka
**NOTE:** This service has been marked for deprecation:
https://developer.github.com/changes/2018-04-25-github-services-deprecation/
Functionality will be removed from GitHub.com on January 31st, 2019.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v2] arm-common: account for SMC exits
On 18.10.18 15:36, Ralf Ramsauer wrote:
Statistics on ARM currently has some imbalances: the total number of
exits doesn't equal the sum of the fine granular exit counters: we
aren't accounting for SMCCC exits.
Fix this by adding a new statistic counter for SMCCC.
PSCI exits are already accounted inside psci_dispatch(), move SMCCC
accounting to the dispatcher routine handle_smc().
Fixes: 7688e96c815b ("arm-common: Rework handling of SMC")
Signed-off-by: Ralf Ramsauer
---
since v1:
- amend author email
- add Fixes tag
- don't account unhandled traps
driver/sysfs.c | 3 +++
hypervisor/arch/arm-common/smccc.c | 3 +++
include/arch/arm/asm/jailhouse_hypercall.h | 5 +++--
include/arch/arm64/asm/jailhouse_hypercall.h | 3 ++-
4 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/driver/sysfs.c b/driver/sysfs.c
index 8648cfeb..a272ef4c 100644
--- a/driver/sysfs.c
+++ b/driver/sysfs.c
@@ -148,6 +148,7 @@ JAILHOUSE_CPU_STATS_ATTR(vmexits_maintenance,
JAILHOUSE_CPU_STATS_ATTR(vmexits_virt_irq, JAILHOUSE_CPU_STAT_VMEXITS_VIRQ);
JAILHOUSE_CPU_STATS_ATTR(vmexits_virt_sgi, JAILHOUSE_CPU_STAT_VMEXITS_VSGI);
JAILHOUSE_CPU_STATS_ATTR(vmexits_psci, JAILHOUSE_CPU_STAT_VMEXITS_PSCI);
+JAILHOUSE_CPU_STATS_ATTR(vmexits_smccc, JAILHOUSE_CPU_STAT_VMEXITS_SMCCC);
#ifdef CONFIG_ARM
JAILHOUSE_CPU_STATS_ATTR(vmexits_cp15, JAILHOUSE_CPU_STAT_VMEXITS_CP15);
#endif
@@ -172,6 +173,7 @@ static struct attribute *cell_stats_attrs[] = {
_virt_irq_cell_attr.kattr.attr,
_virt_sgi_cell_attr.kattr.attr,
_psci_cell_attr.kattr.attr,
+ _smccc_cell_attr.kattr.attr,
#ifdef CONFIG_ARM
_cp15_cell_attr.kattr.attr,
#endif
@@ -203,6 +205,7 @@ static struct attribute *cpu_stats_attrs[] = {
_virt_irq_cpu_attr.kattr.attr,
_virt_sgi_cpu_attr.kattr.attr,
_psci_cpu_attr.kattr.attr,
+ _smccc_cpu_attr.kattr.attr,
#ifdef CONFIG_ARM
_cp15_cpu_attr.kattr.attr,
#endif
diff --git a/hypervisor/arch/arm-common/smccc.c
b/hypervisor/arch/arm-common/smccc.c
index b525ef25..463a0133 100644
--- a/hypervisor/arch/arm-common/smccc.c
+++ b/hypervisor/arch/arm-common/smccc.c
@@ -33,13 +33,16 @@ static long handle_arch(struct trap_context *ctx)
int handle_smc(struct trap_context *ctx)
{
unsigned long *regs = ctx->regs;
+ u32 *stats = this_cpu_public()->stats;
switch (SMCCC_GET_OWNER(regs[0])) {
case ARM_SMCCC_OWNER_ARCH:
+ stats[JAILHOUSE_CPU_STAT_VMEXITS_SMCCC]++;
regs[0] = handle_arch(ctx);
break;
case ARM_SMCCC_OWNER_SIP:
+ stats[JAILHOUSE_CPU_STAT_VMEXITS_SMCCC]++;
regs[0] = ARM_SMCCC_NOT_SUPPORTED;
break;
diff --git a/include/arch/arm/asm/jailhouse_hypercall.h b/include/arch/arm/asm/jailhouse_hypercall.h
index 7b00f873..c5c1d45a 100644
--- a/include/arch/arm/asm/jailhouse_hypercall.h
+++ b/include/arch/arm/asm/jailhouse_hypercall.h
@@ -51,8 +51,9 @@
#define JAILHOUSE_CPU_STAT_VMEXITS_VIRQ
JAILHOUSE_GENERIC_CPU_STATS + 1
#define JAILHOUSE_CPU_STAT_VMEXITS_VSGI
JAILHOUSE_GENERIC_CPU_STATS + 2
#define JAILHOUSE_CPU_STAT_VMEXITS_PSCI
JAILHOUSE_GENERIC_CPU_STATS + 3
-#define JAILHOUSE_CPU_STAT_VMEXITS_CP15
JAILHOUSE_GENERIC_CPU_STATS + 4
-#define JAILHOUSE_NUM_CPU_STATS
JAILHOUSE_GENERIC_CPU_STATS + 5
+#define JAILHOUSE_CPU_STAT_VMEXITS_SMCCC JAILHOUSE_GENERIC_CPU_STATS + 4
+#define JAILHOUSE_CPU_STAT_VMEXITS_CP15
JAILHOUSE_GENERIC_CPU_STATS + 5
+#define JAILHOUSE_NUM_CPU_STATS
JAILHOUSE_GENERIC_CPU_STATS + 6
#ifndef __ASSEMBLY__
diff --git a/include/arch/arm64/asm/jailhouse_hypercall.h b/include/arch/arm64/asm/jailhouse_hypercall.h
index 5994e1a0..497ba504 100644
--- a/include/arch/arm64/asm/jailhouse_hypercall.h
+++ b/include/arch/arm64/asm/jailhouse_hypercall.h
@@ -50,7 +50,8 @@
#define JAILHOUSE_CPU_STAT_VMEXITS_VIRQ
JAILHOUSE_GENERIC_CPU_STATS + 1
#define JAILHOUSE_CPU_STAT_VMEXITS_VSGI
JAILHOUSE_GENERIC_CPU_STATS + 2
#define JAILHOUSE_CPU_STAT_VMEXITS_PSCI
JAILHOUSE_GENERIC_CPU_STATS + 3
-#define JAILHOUSE_NUM_CPU_STATS
JAILHOUSE_GENERIC_CPU_STATS + 4
+#define JAILHOUSE_CPU_STAT_VMEXITS_SMCCC JAILHOUSE_GENERIC_CPU_STATS + 4
+#define JAILHOUSE_NUM_CPU_STATS
JAILHOUSE_GENERIC_CPU_STATS + 5
#ifndef __ASSEMBLY__
Thanks, applied to next.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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.
For more options, visit
Re: Why trap interrupts with GIC v3 on arm64?
On 19.10.18 17:18, posk.de...@gmail.com wrote: Hello! GICv3 on ARM provides the ability to route interrupts to specific cores, see e.g. "Affinity routing and assignment" here: https://static.docs.arm.com/100336/0002/corelink_gic600_generic_interrupt_controller_technical_reference_manual_100336_0002_01_en.pdf A paper on Jailhouse (https://arxiv.org/abs/1705.06932) measures interrupt delays introduced by trapping them in hypervisor and re-injecting into cells/VMs. Why can't GIC be programmed by the hypervisor to route interrupts directly to CPUs controlled by a cell, thus eliminating the extra hop to the hypervisor? Only GICv4 introduces a way to inject a physical interrupt directly into the virtual CPU. I'm sure we will eventually support that, but I'm not yet aware of any physical hardware implementing GICv4 (GICv3 adoption is still "in process"). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Give an inmate a PCI Bridge device
On 19.10.18 13:47, Robert Davis wrote: On Friday, October 19, 2018 at 2:11:20 AM UTC-4, J. Kiszka wrote: On 18.10.18 22:40, Robert Davis wrote: Good afternoon, I am currently trying to get a device onto an inmate that shares memory with a PCI bridge. Enclosed is a copy of my "lspci -vv", my inmate config, and my rootcell config. The respective device is a RTC card (07:04), which operates only on PCI and uses a PCI-E chip (06:00). The inmate will boot properly if I only have the RTC device; memregion, PCI_DEVICE, and PCI_CAPS. The device will not work properly without the corresponding PCI Bridge (06:00) however. When I place the PCI Bridge device within the inmate config with it's corresponding memregion and PCI Caps I receive the following error: FATAL: Invalid PCI config write, port: cfc, size 4, address port: 80060010 This is device 06:00.0, but it's PCI config register 0x10. That's BAR0, and while we support minimal emulation of the BARs of devices for size discovery, we don't do that for bridges because of. Do you mind elaborating on why you don't do this for bridges? I don't remember all details anymore, but if it should be only about emulating size discovery also for bridge BARs, that would not be an issue. I believe to remember, though, that Linux as non-root cell will try to move that window around, and that is nothing we can permit (like we can't for individual devices). Try it out, maybe first with a hack that removes the type != JAILHOUSE_PCI_TYPE_BRIDGE check from the code. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Run Linux in non-root cell on NUC
On 19.10.18 11:19, Jan Kiszka wrote: On 19.10.18 09:42, minskey guo wrote: to get a bzImage for non-root cell. Now, the COM1 has output now during booting non-root-cell linux , but I run into another issue: 1.797742] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer [ 1.805696] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [ 1.811470] RAPL PMU: hw unit of domain package 2^-14 Joules [ 1.817155] RAPL PMU: hw unit of domain dram 2^-14 Joules [ 1.822574] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules [ 1.828254] RAPL PMU: hw unit of domain psys 2^-14 Joules [ 1.833679] clocksource: tsc: mask: 0x max_cycles: 0x2717868ea45, max_idle_s [ 1.843722] clocksource: Switched to clocksource tsc FATAL: Invalid PIO read, port: 87 size: 1 That's a legacy resources, and that indicates your kernel lacks Jailhouse awareness (CONFIG_JAILHOUSE_GUEST). There kernel will also report during boot if it detected (and is aware of) Jailhouse. My kconfig has CONFIG_JAILHOUSE_GUEST. Just realized that 87 is hex, so it is DMA page register port. Currently, I set pio_bitmap[] for that port to 1 in both root and non-root cell. What else should I do ? You should not (have to) hand this over. I thought to remember it was disabled by one of the platform hooks in x86 that we have for Jailhouse, but maybe it was some driver that should rather be turned off. Try deriving your config from the one we using in jailhouse-images. Actually, we have the issue in jailhouse-image as well. Will send out a patch these days, but the trick to resolve it is simple: disable CONFIG_ISA_DMA_API (requires CONFIG_EXPERT). The issue started with 4.18 Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- 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. For more options, visit https://groups.google.com/d/optout.
