| Message ID | 20200214145736.18550-17-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | irqchip/gic-v4: GICv4.1 architecture support | expand |
Hi Marc, On 2020/2/14 22:57, Marc Zyngier wrote: > In order to let a guest buy in the new, active-less SGIs, we > need to be able to switch between the two modes. > > Handle this by stopping all guest activity, transfer the state > from one mode to the other, and resume the guest. > > Signed-off-by: Marc Zyngier <maz@kernel.org> [...] > diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c > index 1bc09b523486..2c9fc13e2c59 100644 > --- a/virt/kvm/arm/vgic/vgic-v3.c > +++ b/virt/kvm/arm/vgic/vgic-v3.c > @@ -540,6 +540,8 @@ int vgic_v3_map_resources(struct kvm *kvm) > goto out; > } > > + if (kvm_vgic_global_state.has_gicv4_1) > + vgic_v4_configure_vsgis(kvm); > dist->ready = true; > > out: Is there any reason to invoke vgic_v4_configure_vsgis() here? This is called on the first VCPU run, through kvm_vgic_map_resources(). Shouldn't the vSGI configuration only driven by a GICD_CTLR.nASSGIreq writing (from guest, or from userspace maybe)? Thanks, Zenghui
Hi Zenghui, On 2020-02-20 03:55, Zenghui Yu wrote: > Hi Marc, > > On 2020/2/14 22:57, Marc Zyngier wrote: >> In order to let a guest buy in the new, active-less SGIs, we >> need to be able to switch between the two modes. >> >> Handle this by stopping all guest activity, transfer the state >> from one mode to the other, and resume the guest. >> >> Signed-off-by: Marc Zyngier <maz@kernel.org> > > [...] > >> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c >> index 1bc09b523486..2c9fc13e2c59 100644 >> --- a/virt/kvm/arm/vgic/vgic-v3.c >> +++ b/virt/kvm/arm/vgic/vgic-v3.c >> @@ -540,6 +540,8 @@ int vgic_v3_map_resources(struct kvm *kvm) >> goto out; >> } >> + if (kvm_vgic_global_state.has_gicv4_1) >> + vgic_v4_configure_vsgis(kvm); >> dist->ready = true; >> out: > > Is there any reason to invoke vgic_v4_configure_vsgis() here? > This is called on the first VCPU run, through kvm_vgic_map_resources(). > Shouldn't the vSGI configuration only driven by a GICD_CTLR.nASSGIreq > writing (from guest, or from userspace maybe)? What I'm trying to catch here is the guest that has been restored with nASSGIreq set. At the moment, we don't do anything on the userspace side, because the vmm could decide to write that particular bit multiple times, and switching between the two modes is expensive (not to mention that all the vcpus may not have been created yet). Moving it to the first run makes all these pitfalls go away (we have the final nASSSGIreq value, and all the vcpus are accounted for). Does this make sense to you? Thanks, M.
Hi Marc, On 2020/2/29 3:16, Marc Zyngier wrote: > Hi Zenghui, > > On 2020-02-20 03:55, Zenghui Yu wrote: >> Hi Marc, >> >> On 2020/2/14 22:57, Marc Zyngier wrote: >>> In order to let a guest buy in the new, active-less SGIs, we >>> need to be able to switch between the two modes. >>> >>> Handle this by stopping all guest activity, transfer the state >>> from one mode to the other, and resume the guest. >>> >>> Signed-off-by: Marc Zyngier <maz@kernel.org> >> >> [...] >> >>> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c >>> index 1bc09b523486..2c9fc13e2c59 100644 >>> --- a/virt/kvm/arm/vgic/vgic-v3.c >>> +++ b/virt/kvm/arm/vgic/vgic-v3.c >>> @@ -540,6 +540,8 @@ int vgic_v3_map_resources(struct kvm *kvm) >>> goto out; >>> } >>> + if (kvm_vgic_global_state.has_gicv4_1) >>> + vgic_v4_configure_vsgis(kvm); >>> dist->ready = true; >>> out: >> >> Is there any reason to invoke vgic_v4_configure_vsgis() here? >> This is called on the first VCPU run, through kvm_vgic_map_resources(). >> Shouldn't the vSGI configuration only driven by a GICD_CTLR.nASSGIreq >> writing (from guest, or from userspace maybe)? > > What I'm trying to catch here is the guest that has been restored with > nASSGIreq set. At the moment, we don't do anything on the userspace > side, because the vmm could decide to write that particular bit > multiple times, and switching between the two modes is expensive (not > to mention that all the vcpus may not have been created yet). > > Moving it to the first run makes all these pitfalls go away (we have the > final nASSSGIreq value, and all the vcpus are accounted for). So what will happen on restoration is (roughly): - for GICR_ISPENR0: We will restore the pending status of vSGIs into software pending_latch, just like what we've done for normal SGIs. - for GICD_CTLR.nASSGIreq: We will only record the written value. (Note to myself: No invocation of configure_vsgis() in uaccess_write callback, I previously mixed it up with the guest write callback.) - Finally, you choose the first vcpu run as the appropriate point to potentially flush the pending status to HW according to the final nASSGIreq value. > > Does this make sense to you? Yeah, it sounds like a good idea! And please ignore what I've replied to patch #15, I obviously missed your intention at that time, sorry... But can we move this hunk to some places more appropriate, for example, put it together with the GICD_CTLR's uaccess_write change? It might make things a bit clearer for other reviewers. :-) Thanks, Zenghui
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index 63457908c9c4..69f4164d6477 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -231,6 +231,9 @@ struct vgic_dist { /* distributor enabled */ bool enabled; + /* Wants SGIs without active state */ + bool nassgireq; + struct vgic_irq *spis; struct vgic_io_device dist_iodev; diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c index 1bc09b523486..2c9fc13e2c59 100644 --- a/virt/kvm/arm/vgic/vgic-v3.c +++ b/virt/kvm/arm/vgic/vgic-v3.c @@ -540,6 +540,8 @@ int vgic_v3_map_resources(struct kvm *kvm) goto out; } + if (kvm_vgic_global_state.has_gicv4_1) + vgic_v4_configure_vsgis(kvm); dist->ready = true; out: diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c index c2fcde104ea2..063785fd2dc7 100644 --- a/virt/kvm/arm/vgic/vgic-v4.c +++ b/virt/kvm/arm/vgic/vgic-v4.c @@ -97,6 +97,102 @@ static irqreturn_t vgic_v4_doorbell_handler(int irq, void *info) return IRQ_HANDLED; } +static void vgic_v4_sync_sgi_config(struct its_vpe *vpe, struct vgic_irq *irq) +{ + vpe->sgi_config[irq->intid].enabled = irq->enabled; + vpe->sgi_config[irq->intid].group = irq->group; + vpe->sgi_config[irq->intid].priority = irq->priority; +} + +static void vgic_v4_enable_vsgis(struct kvm_vcpu *vcpu) +{ + struct its_vpe *vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; + int i; + + /* + * With GICv4.1, every virtual SGI can be directly injected. So + * let's pretend that they are HW interrupts, tied to a host + * IRQ. The SGI code will do its magic. + */ + for (i = 0; i < VGIC_NR_SGIS; i++) { + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, i); + struct irq_desc *desc; + int ret; + + if (irq->hw) { + vgic_put_irq(vcpu->kvm, irq); + continue; + } + + irq->hw = true; + irq->host_irq = irq_find_mapping(vpe->sgi_domain, i); + vgic_v4_sync_sgi_config(vpe, irq); + /* + * SGIs are initialised as disabled. Enable them if + * required by the rest of the VGIC init code. + */ + desc = irq_to_desc(irq->host_irq); + ret = irq_domain_activate_irq(irq_desc_get_irq_data(desc), + false); + if (!WARN_ON(ret)) { + /* Transfer pending state */ + ret = irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch); + WARN_ON(ret); + irq->pending_latch = false; + } + + vgic_put_irq(vcpu->kvm, irq); + } +} + +static void vgic_v4_disable_vsgis(struct kvm_vcpu *vcpu) +{ + int i; + + for (i = 0; i < VGIC_NR_SGIS; i++) { + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, i); + struct irq_desc *desc; + int ret; + + if (!irq->hw) { + vgic_put_irq(vcpu->kvm, irq); + continue; + } + + irq->hw = false; + ret = irq_get_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + &irq->pending_latch); + WARN_ON(ret); + + desc = irq_to_desc(irq->host_irq); + irq_domain_deactivate_irq(irq_desc_get_irq_data(desc)); + + vgic_put_irq(vcpu->kvm, irq); + } +} + +/* Must be called with the kvm lock held */ +void vgic_v4_configure_vsgis(struct kvm *kvm) +{ + struct vgic_dist *dist = &kvm->arch.vgic; + struct kvm_vcpu *vcpu; + int i; + + kvm_arm_halt_guest(kvm); + + kvm_for_each_vcpu(i, vcpu, kvm) { + if (dist->nassgireq) + vgic_v4_enable_vsgis(vcpu); + else + vgic_v4_disable_vsgis(vcpu); + } + + kvm_arm_resume_guest(kvm); +} + /** * vgic_v4_init - Initialize the GICv4 data structures * @kvm: Pointer to the VM being initialized diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h index c7fefd6b1c80..769e4802645e 100644 --- a/virt/kvm/arm/vgic/vgic.h +++ b/virt/kvm/arm/vgic/vgic.h @@ -316,5 +316,6 @@ void vgic_its_invalidate_cache(struct kvm *kvm); bool vgic_supports_direct_msis(struct kvm *kvm); int vgic_v4_init(struct kvm *kvm); void vgic_v4_teardown(struct kvm *kvm); +void vgic_v4_configure_vsgis(struct kvm *kvm); #endif
In order to let a guest buy in the new, active-less SGIs, we need to be able to switch between the two modes. Handle this by stopping all guest activity, transfer the state from one mode to the other, and resume the guest. Signed-off-by: Marc Zyngier <maz@kernel.org> --- include/kvm/arm_vgic.h | 3 ++ virt/kvm/arm/vgic/vgic-v3.c | 2 + virt/kvm/arm/vgic/vgic-v4.c | 96 +++++++++++++++++++++++++++++++++++++ virt/kvm/arm/vgic/vgic.h | 1 + 4 files changed, 102 insertions(+)