| Message ID | 20210331103303.79705-3-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/intr: introduce EOI callbacks and fix vPT | expand |
On 31.03.2021 12:32, Roger Pau Monne wrote: > EOIs are always executed in guest vCPU context, so there's no reason to > pass a domain parameter around as can be fetched from current->domain. > > No functional change intended. > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > Reviewed-by: Paul Durrant <paul@xen.org> > --- > Changes since v1: > - New in this version. Just to make it explicit - possibly same thing as with patch 1, depending on how exactly the issue there gets taken care of. Jan
On Wed, Mar 31, 2021 at 06:04:43PM +0200, Jan Beulich wrote: > On 31.03.2021 12:32, Roger Pau Monne wrote: > > EOIs are always executed in guest vCPU context, so there's no reason to > > pass a domain parameter around as can be fetched from current->domain. > > > > No functional change intended. > > > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > > Reviewed-by: Paul Durrant <paul@xen.org> > > --- > > Changes since v1: > > - New in this version. > > Just to make it explicit - possibly same thing as with patch 1, > depending on how exactly the issue there gets taken care of. I don't think we have any scenario ATM where we allow EOI'ing of interrupts from a different vCPU context, neither I can see us allowing such in the future, but I don't want this discussion to block the series, hence I'm going to drop this patch together with patch 1. Roger.
On 01.04.2021 11:15, Roger Pau Monné wrote: > On Wed, Mar 31, 2021 at 06:04:43PM +0200, Jan Beulich wrote: >> On 31.03.2021 12:32, Roger Pau Monne wrote: >>> EOIs are always executed in guest vCPU context, so there's no reason to >>> pass a domain parameter around as can be fetched from current->domain. >>> >>> No functional change intended. >>> >>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >>> Reviewed-by: Paul Durrant <paul@xen.org> >>> --- >>> Changes since v1: >>> - New in this version. >> >> Just to make it explicit - possibly same thing as with patch 1, >> depending on how exactly the issue there gets taken care of. > > I don't think we have any scenario ATM where we allow EOI'ing of > interrupts from a different vCPU context, neither I can see us > allowing such in the future, but I don't want this discussion to block > the series, hence I'm going to drop this patch together with patch 1. Well, having seen also your reply to Andrew wrt patch 1, I just wanted to clarify that dropping the two patches isn't the only option. Making Viridian code resilient in this regard might be another one. Jan
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index 91e5f892787..dcc2de76489 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -284,7 +284,7 @@ static void vioapic_write_redirent( */ ASSERT(prev_level); ASSERT(!top_word); - hvm_dpci_eoi(d, gsi); + hvm_dpci_eoi(gsi); } if ( is_hardware_domain(d) && unmasked ) @@ -541,7 +541,7 @@ void vioapic_update_EOI(unsigned int vector) if ( is_iommu_enabled(d) ) { spin_unlock(&d->arch.hvm.irq_lock); - hvm_dpci_eoi(d, vioapic->base_gsi + pin); + hvm_dpci_eoi(vioapic->base_gsi + pin); spin_lock(&d->arch.hvm.irq_lock); } diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c index f465b7f9979..a69aecad912 100644 --- a/xen/arch/x86/hvm/vpic.c +++ b/xen/arch/x86/hvm/vpic.c @@ -235,8 +235,7 @@ static void vpic_ioport_write( unsigned int pin = __scanbit(pending, 8); ASSERT(pin < 8); - hvm_dpci_eoi(current->domain, - hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin)); + hvm_dpci_eoi(hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin)); __clear_bit(pin, &pending); } return; @@ -285,8 +284,7 @@ static void vpic_ioport_write( /* Release lock and EOI the physical interrupt (if any). */ vpic_update_int_output(vpic); vpic_unlock(vpic); - hvm_dpci_eoi(current->domain, - hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin)); + hvm_dpci_eoi(hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin)); return; /* bail immediately */ case 6: /* Set Priority */ vpic->priority_add = (val + 1) & 7; diff --git a/xen/drivers/passthrough/x86/hvm.c b/xen/drivers/passthrough/x86/hvm.c index 2f6c81b1e2c..a9256e7ef51 100644 --- a/xen/drivers/passthrough/x86/hvm.c +++ b/xen/drivers/passthrough/x86/hvm.c @@ -911,8 +911,9 @@ static void hvm_gsi_eoi(struct domain *d, unsigned int gsi) hvm_pirq_eoi(pirq); } -void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi) +void hvm_dpci_eoi(unsigned int guest_gsi) { + struct domain *d = current->domain; const struct hvm_irq_dpci *hvm_irq_dpci; const struct hvm_girq_dpci_mapping *girq; diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h index 8b8392ec59e..4f294232fb7 100644 --- a/xen/include/asm-x86/hvm/io.h +++ b/xen/include/asm-x86/hvm/io.h @@ -101,7 +101,7 @@ bool handle_mmio_with_translation(unsigned long gla, unsigned long gpfn, struct npfec); bool handle_pio(uint16_t port, unsigned int size, int dir); void hvm_interrupt_post(struct vcpu *v, int vector, int type); -void hvm_dpci_eoi(struct domain *d, unsigned int guest_irq); +void hvm_dpci_eoi(unsigned int guest_irq); void msix_write_completion(struct vcpu *); #ifdef CONFIG_HVM