All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
@ 2021-01-05 18:31 Roger Pau Monne
  2021-01-06 11:22 ` Jan Beulich
  2021-01-06 21:04 ` Wei Liu
  0 siblings, 2 replies; 4+ messages in thread
From: Roger Pau Monne @ 2021-01-05 18:31 UTC (permalink / raw)
  To: xen-devel
  Cc: Roger Pau Monne, Jan Beulich, Andrew Cooper, Wei Liu, Paul Durrant

Modify hvm_pirq_eoi to always EOI the interrupt if required, instead
of not doing such EOI if the interrupt is routed through the vIO-APIC
and the entry is masked at the time the EOI is performed.

Further unmask of the vIO-APIC pin won't EOI the interrupt, and thus
the guest OS has to wait for the timeout to expire and the automatic
EOI to be performed.

This allows to simplify the helpers and drop the vioapic_redir_entry
parameter from all of them.

Fixes: ccfe4e08455 ('Intel vt-d specific changes in arch/x86/hvm/vmx/vtd.')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Kind of RFC, I've been trying to figure out how this was supposed to
work, and couldn't find any reason why the EOI is not performed if the
interrupt is masked on the emulated IO-APIC. I might be missing
something, but relying on the EOI timeout in that case seems wrong.
---
 xen/arch/x86/hvm/vioapic.c        |  2 +-
 xen/arch/x86/hvm/vpic.c           |  3 +--
 xen/drivers/passthrough/x86/hvm.c | 21 ++++++++-------------
 xen/include/asm-x86/hvm/io.h      |  3 +--
 4 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 7c462a44d4..eb6c143f74 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -521,7 +521,7 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
             if ( is_iommu_enabled(d) )
             {
                 spin_unlock(&d->arch.hvm.irq_lock);
-                hvm_dpci_eoi(d, vioapic->base_gsi + pin, ent);
+                hvm_dpci_eoi(d, 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 3cf12581e9..c1c1de7fd0 100644
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -263,8 +263,7 @@ static void vpic_ioport_write(
                 vpic_update_int_output(vpic);
                 vpic_unlock(vpic);
                 hvm_dpci_eoi(current->domain,
-                             hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin),
-                             NULL);
+                             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 41cfa2e200..edc8059518 100644
--- a/xen/drivers/passthrough/x86/hvm.c
+++ b/xen/drivers/passthrough/x86/hvm.c
@@ -950,8 +950,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_pirq_eoi(struct pirq *pirq,
-                         const union vioapic_redir_entry *ent)
+static void hvm_pirq_eoi(struct pirq *pirq)
 {
     struct hvm_pirq_dpci *pirq_dpci;
 
@@ -968,7 +967,6 @@ static void hvm_pirq_eoi(struct pirq *pirq,
      * since interrupt is still not EOIed
      */
     if ( --pirq_dpci->pending ||
-         (ent && ent->fields.mask) ||
          !pt_irq_need_timer(pirq_dpci->flags) )
         return;
 
@@ -977,19 +975,17 @@ static void hvm_pirq_eoi(struct pirq *pirq,
 }
 
 static void __hvm_dpci_eoi(struct domain *d,
-                           const struct hvm_girq_dpci_mapping *girq,
-                           const union vioapic_redir_entry *ent)
+                           const struct hvm_girq_dpci_mapping *girq)
 {
     struct pirq *pirq = pirq_info(d, girq->machine_gsi);
 
     if ( !hvm_domain_use_pirq(d, pirq) )
         hvm_pci_intx_deassert(d, girq->device, girq->intx);
 
-    hvm_pirq_eoi(pirq, ent);
+    hvm_pirq_eoi(pirq);
 }
 
-static void hvm_gsi_eoi(struct domain *d, unsigned int gsi,
-                        const union vioapic_redir_entry *ent)
+static void hvm_gsi_eoi(struct domain *d, unsigned int gsi)
 {
     struct pirq *pirq = pirq_info(d, gsi);
 
@@ -998,11 +994,10 @@ static void hvm_gsi_eoi(struct domain *d, unsigned int gsi,
         return;
 
     hvm_gsi_deassert(d, gsi);
-    hvm_pirq_eoi(pirq, ent);
+    hvm_pirq_eoi(pirq);
 }
 
-void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
-                  const union vioapic_redir_entry *ent)
+void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi)
 {
     const struct hvm_irq_dpci *hvm_irq_dpci;
     const struct hvm_girq_dpci_mapping *girq;
@@ -1013,7 +1008,7 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
     if ( is_hardware_domain(d) )
     {
         spin_lock(&d->event_lock);
-        hvm_gsi_eoi(d, guest_gsi, ent);
+        hvm_gsi_eoi(d, guest_gsi);
         goto unlock;
     }
 
@@ -1030,7 +1025,7 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
         goto unlock;
 
     list_for_each_entry ( girq, &hvm_irq_dpci->girq[guest_gsi], list )
-        __hvm_dpci_eoi(d, girq, ent);
+        __hvm_dpci_eoi(d, girq);
 
 unlock:
     spin_unlock(&d->event_lock);
diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h
index 558426b772..9453b9b2b7 100644
--- a/xen/include/asm-x86/hvm/io.h
+++ b/xen/include/asm-x86/hvm/io.h
@@ -118,8 +118,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,
-                  const union vioapic_redir_entry *ent);
+void hvm_dpci_eoi(struct domain *d, unsigned int guest_irq);
 void msix_write_completion(struct vcpu *);
 
 #ifdef CONFIG_HVM
-- 
2.29.2



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
  2021-01-05 18:31 [PATCH] x86/dpci: EOI interrupt regardless of it's masking status Roger Pau Monne
@ 2021-01-06 11:22 ` Jan Beulich
  2021-01-06 21:04 ` Wei Liu
  1 sibling, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2021-01-06 11:22 UTC (permalink / raw)
  To: Roger Pau Monne; +Cc: Andrew Cooper, Wei Liu, Paul Durrant, xen-devel

On 05.01.2021 19:31, Roger Pau Monne wrote:
> Modify hvm_pirq_eoi to always EOI the interrupt if required, instead
> of not doing such EOI if the interrupt is routed through the vIO-APIC
> and the entry is masked at the time the EOI is performed.
> 
> Further unmask of the vIO-APIC pin won't EOI the interrupt, and thus
> the guest OS has to wait for the timeout to expire and the automatic
> EOI to be performed.
> 
> This allows to simplify the helpers and drop the vioapic_redir_entry
> parameter from all of them.
> 
> Fixes: ccfe4e08455 ('Intel vt-d specific changes in arch/x86/hvm/vmx/vtd.')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> ---
> Kind of RFC, I've been trying to figure out how this was supposed to
> work, and couldn't find any reason why the EOI is not performed if the
> interrupt is masked on the emulated IO-APIC. I might be missing
> something, but relying on the EOI timeout in that case seems wrong.

Fully agree. If archeology didn't surface an explanation, I'd
assume the dependency was put in mistakenly, perhaps because
most other operations need to respect the mask bit.

Jan


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
  2021-01-05 18:31 [PATCH] x86/dpci: EOI interrupt regardless of it's masking status Roger Pau Monne
  2021-01-06 11:22 ` Jan Beulich
@ 2021-01-06 21:04 ` Wei Liu
  2021-01-07  9:41   ` Roger Pau Monné
  1 sibling, 1 reply; 4+ messages in thread
From: Wei Liu @ 2021-01-06 21:04 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: xen-devel, Jan Beulich, Andrew Cooper, Wei Liu, Paul Durrant

Typo in subject line ("it's").


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
  2021-01-06 21:04 ` Wei Liu
@ 2021-01-07  9:41   ` Roger Pau Monné
  0 siblings, 0 replies; 4+ messages in thread
From: Roger Pau Monné @ 2021-01-07  9:41 UTC (permalink / raw)
  To: Wei Liu; +Cc: xen-devel, Jan Beulich, Andrew Cooper, Paul Durrant

On Wed, Jan 06, 2021 at 09:04:16PM +0000, Wei Liu wrote:
> Typo in subject line ("it's").

Ouch yes. To whoever ends up committing this: can you please fix the
subject line?

Thanks, Roger.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-07  9:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-05 18:31 [PATCH] x86/dpci: EOI interrupt regardless of it's masking status Roger Pau Monne
2021-01-06 11:22 ` Jan Beulich
2021-01-06 21:04 ` Wei Liu
2021-01-07  9:41   ` Roger Pau Monné

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.