Re: Why trap interrupts with GIC v3 on arm64?
On 22.10.18 17:53, posk.de...@gmail.com wrote: On Sunday, October 21, 2018 at 4:57:58 AM UTC-7, J. Kiszka wrote: 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"). But GICv3 can route interrupts to specific physical CPUs, so JH can program it to route specific interrupts to specific cells. What am I missing here? The challenge we have to solve is fulling both of these two requirements: - provide an interrupt that is trapping into hyp mode to implement hypervisor-internal IPIs - pass all other interrupts directly through to the guest We solved that on x86 by intercepting NMIs (and effectively blocking their use for the guests) while passing regular interrupts directly through. I failed to find something equivalent on ARM GICv2/3 so far. v4 should have that, but I didn't study details yet. I'm surely all ears if you should find a solution for v3 already! 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: Why trap interrupts with GIC v3 on arm64?
On Sunday, October 21, 2018 at 4:57:58 AM UTC-7, J. Kiszka wrote: > 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"). > But GICv3 can route interrupts to specific physical CPUs, so JH can program it to route specific interrupts to specific cells. What am I missing here? -- 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: 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.
