[RFC 1/2] linux-headers: update
This patch updates the Linux headers to include the in-progress user
space ARM timer patches. It is explicitly RFC, as the patches are not
merged yet.
---
linux-headers/asm-arm/kvm.h | 1 +
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 6 ++
3 files changed, 8 insertions(+)
diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..5d58ec2 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -105,6 +105,7 @@ struct kvm_debug_exit_arch {
};
struct kvm_sync_regs {
+ __u8 timer_irq_level;
};
struct kvm_arch_memory_slot {
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index fd5a276..0e1cbd1 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -143,6 +143,7 @@ struct kvm_debug_exit_arch {
#define KVM_GUESTDBG_USE_HW(1 << 17)
struct kvm_sync_regs {
+ __u8 timer_irq_level;
};
struct kvm_arch_memory_slot {
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 4806e06..737113c 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -870,6 +870,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_S390_USER_INSTR0 130
#define KVM_CAP_MSI_DEVID 131
#define KVM_CAP_PPC_HTM 132
+#define KVM_CAP_ARM_TIMER 133
#ifdef KVM_CAP_IRQ_ROUTING
@@ -1327,4 +1328,9 @@ struct kvm_assigned_msix_entry {
#define KVM_X2APIC_API_USE_32BIT_IDS(1ULL << 0)
#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
+/* Available with KVM_CAP_ARM_TIMER */
+
+/* Bits for run->arm_timer.timesource */
+#define KVM_ARM_TIMER_VTIMER (1 << 0)
+
#endif /* __LINUX_KVM_H */
--
1.8.5.6
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[RFC 2/2] ARM: KVM: Enable in-kernel timers with user space gic
When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.
Unfortunately when running in user mode gic emulation, we miss out on
timer events which are only available from kernel space. This patch leverages
the new kernel/user space pending line synchronization for those timer events.
Signed-off-by: Alexander Graf
---
hw/arm/virt.c| 10 ++
target-arm/cpu.h | 3 +++
target-arm/kvm.c | 19 +++
3 files changed, 32 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 070bbf8..8ac81e3 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -622,6 +622,16 @@ static void create_gic(VirtBoardInfo *vbi, qemu_irq *pic,
int type,
} else if (type == 2) {
create_v2m(vbi, pic);
}
+
+#ifdef CONFIG_KVM
+if (kvm_enabled() && !kvm_irqchip_in_kernel()) {
+if (!kvm_check_extension(kvm_state, KVM_CAP_ARM_TIMER)) {
+error_report("KVM with user space irqchip only works when the "
+ "host kernel supports KVM_CAP_ARM_TIMER");
+exit(1);
+}
+}
+#endif
}
static void create_uart(const VirtBoardInfo *vbi, qemu_irq *pic, int uart,
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 19d967b..7686082 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -659,6 +659,9 @@ struct ARMCPU {
ARMELChangeHook *el_change_hook;
void *el_change_hook_opaque;
+
+/* Used to synchronize KVM and QEMU timer levels */
+uint8_t timer_irq_level;
};
static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index c00b94e..0d8b642 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -527,6 +527,25 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
MemTxAttrs kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
{
+ARMCPU *cpu;
+
+if (kvm_irqchip_in_kernel()) {
+/*
+ * We only need to sync timer states with user-space interrupt
+ * controllers, so return early and save cycles if we don't.
+ */
+return MEMTXATTRS_UNSPECIFIED;
+}
+
+cpu = ARM_CPU(cs);
+
+/* Synchronize our internal vtimer irq line with the kvm one */
+if (run->s.regs.timer_irq_level != cpu->timer_irq_level) {
+qemu_set_irq(ARM_CPU(cs)->gt_timer_outputs[GTIMER_VIRT],
+ run->s.regs.timer_irq_level & KVM_ARM_TIMER_VTIMER);
+cpu->timer_irq_level = run->s.regs.timer_irq_level;
+}
+
return MEMTXATTRS_UNSPECIFIED;
}
--
1.8.5.6
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 0/3] Support userspace irqchip with arch timers
> On 29 Oct 2016, at 15:19, Paolo Bonzini wrote: > > What the status of userspace for this thing? Are QEMU patches being > posted and reviewed? I didn't see a notification that the patches were merged. Are they in Linus' tree yet? Then I can post enablement to qemu-devel. >>> >>> I think you got it backward. I have no intention of merging them until I >>> see a vague consensus on the userspace API, and a set of patches ready >>> to be merged in QEMU. >> >> That's not how kvm apis are made. > > Actually I think it's always been like this, depending on what Marc meant for > "ready to be merged in QEMU". It doesn't make sense to merge KVM APIs without > having userspace patches at least posted as RFC to qemu-devel, and without > having at least a positive response from the QEMU architecture maintainer. I halfway agree. I do agree that there needs to be a reference implementation that proves the API to make sense. That bit is referenced in the cover letter of the patch set. Peter as the QEMU architecture maintainer has been part of the review process and involved from the beginning. In fact, the current approach was his idea. Do we need to fly the loop over qemu-devel? I doubt it, but if it makes you happy I can post an RFC there too. > ARM does require a bit more care because there's no overlap between kernel > and userspace maintainers, so perhaps that's the source of the confusion? > > Now, of course merging the patches in QEMU may take a month or two depending > on the timing (because you have to wait for the patches to be merged into > Linus's tree and for the KVM headers to be updated in QEMU---which is not > going to happen during freeze of course). So of course the KVM patch thus > can be committed even if QEMU is in freeze, as long as the QEMU architecture > maintainer gives an overall green light. Right. My plan was to make sure that people agree on the KVM interface. Then directly send non-RFC patches to qemu-devel, which can only happen when the KVM patches are merged. I didn’t see any reason why that approach would be controversial, since everyone who really cared was involved. But again, I don’t care strongly enough to make a fuss. If people are happier with RFC patches on the ML rather than a github link to RFC patches, I’ll send them. Alex ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 0/3] Support userspace irqchip with arch timers
> > > > What the status of userspace for this thing? Are QEMU patches being > > > > posted and reviewed? > > > > > > I didn't see a notification that the patches were merged. Are they in > > > Linus' tree yet? Then I can post enablement to qemu-devel. > > > > I think you got it backward. I have no intention of merging them until I > > see a vague consensus on the userspace API, and a set of patches ready > > to be merged in QEMU. > > That's not how kvm apis are made. Actually I think it's always been like this, depending on what Marc meant for "ready to be merged in QEMU". It doesn't make sense to merge KVM APIs without having userspace patches at least posted as RFC to qemu-devel, and without having at least a positive response from the QEMU architecture maintainer. ARM does require a bit more care because there's no overlap between kernel and userspace maintainers, so perhaps that's the source of the confusion? Now, of course merging the patches in QEMU may take a month or two depending on the timing (because you have to wait for the patches to be merged into Linus's tree and for the KVM headers to be updated in QEMU---which is not going to happen during freeze of course). So of course the KVM patch thus can be committed even if QEMU is in freeze, as long as the QEMU architecture maintainer gives an overall green light. In fact a couple weeks from now would be the perfect time to post the patches to QEMU. Then you can get a review from Peter once he's back from vacation (beginning of December), the KVM patches can easily make it for the 4.10 merge window (end of December), and the userspace patches will hopefully be merged in QEMU 2.9 in January 2017. Thanks, Paolo ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH] KVM: arm/arm64: vgic: Prevent VGIC_ADDR_TO_INTID from emiting divisions
Using non-constant number of bits for VGIC_ADDR_TO_INTID() leads
to gcc 6.1 emiting calls to __aeabi_uldivmod, which the kernel
does not implement.
As we really don't want to implement complex division in the kernel,
the only other option is to prove to the compiler that there is only
a few values that are possible for the number of bits per IRQ, and
that they are all power of 2.
We turn the VGIC_ADDR_TO_INTID macro into a switch that looks for
the supported set of values (1, 2, 8, 64), and perform the computation
accordingly. When "bits" is a constant, the compiler optimizes
away the other cases. If not, we end-up with a small number of cases
that GCC optimises reasonably well. Out of range values are detected
both at build time (constants) and at run time (variables).
Signed-off-by: Marc Zyngier
---
This should be applied *before* Andre's patch fixing out of bound SPIs.
virt/kvm/arm/vgic/vgic-mmio.h | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 4c34d39..a457282 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -57,10 +57,41 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
* multiplication with the inverted fraction, and scale up both the
* numerator and denominator with 8 to support at most 64 bits per IRQ:
*/
-#define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) *
\
+#define __VGIC_ADDR_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
64 / (bits) / 8)
/*
+ * Perform the same computation, but also handle non-constant number
+ * of bits. We only care about the few cases that are required by
+ * GICv2/v3.
+ */
+#define VGIC_ADDR_TO_INTID(addr, bits) \
+ ({ \
+ u32 __v;\
+ switch((bits)) {\
+ case 1: \
+ __v = __VGIC_ADDR_INTID((addr), 1); \
+ break; \
+ case 2: \
+ __v = __VGIC_ADDR_INTID((addr), 2); \
+ break; \
+ case 8: \
+ __v = __VGIC_ADDR_INTID((addr), 8); \
+ break; \
+ case 64:\
+ __v = __VGIC_ADDR_INTID((addr), 64);\
+ break; \
+ default:\
+ if (__builtin_constant_p((bits))) \
+ BUILD_BUG();\
+ else\
+ BUG(); \
+ } \
+ \
+ __v;\
+ })
+
+/*
* Some VGIC registers store per-IRQ information, with a different number
* of bits per IRQ. For those registers this macro is used.
* The _WITH_LENGTH version instantiates registers with a fixed length
--
2.9.3
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
