<stefano.stabellini@eu.citrix.com>
2011-Aug-31 10:24 UTC
[Xen-devel] xen: fix hvm_domain_use_pirq''s behavior
hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 1515138fbd7b xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Wed Aug 24 09:33:10 2011 +0100 +++ b/xen/arch/x86/irq.c Tue Aug 30 11:56:21 2011 +0000 @@ -2024,6 +2024,5 @@ int unmap_domain_pirq_emuirq(struct doma bool_t hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq) { return is_hvm_domain(d) && pirq && - pirq->arch.hvm.emuirq != IRQ_UNBOUND && - pirq->evtchn != 0; + pirq->arch.hvm.emuirq != IRQ_UNBOUND; } diff -r 1515138fbd7b xen/arch/x86/physdev.c --- a/xen/arch/x86/physdev.c Wed Aug 24 09:33:10 2011 +0100 +++ b/xen/arch/x86/physdev.c Tue Aug 30 11:56:21 2011 +0000 @@ -196,9 +196,6 @@ int physdev_map_pirq(domid_t domid, int if ( ret == 0 ) *pirq_p = pirq; - if ( !ret && is_hvm_domain(d) ) - map_domain_emuirq_pirq(d, pirq, IRQ_PT); - done: spin_unlock(&d->event_lock); spin_unlock(&pcidevs_lock); @@ -271,7 +268,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H v->domain->arch.pv_domain.pirq_eoi_map ) evtchn_unmask(pirq->evtchn); if ( !is_hvm_domain(v->domain) || - pirq->arch.hvm.emuirq == IRQ_PT ) + domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) pirq_guest_eoi(pirq); spin_unlock(&v->domain->event_lock); ret = 0; @@ -331,7 +328,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H break; irq_status_query.flags = 0; if ( is_hvm_domain(v->domain) && - domain_pirq_to_emuirq(v->domain, irq) != IRQ_PT ) + domain_pirq_to_irq(v->domain, irq) <= 0 ) { ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; break; diff -r 1515138fbd7b xen/common/event_channel.c --- a/xen/common/event_channel.c Wed Aug 24 09:33:10 2011 +0100 +++ b/xen/common/event_channel.c Tue Aug 30 11:56:21 2011 +0000 @@ -366,6 +366,9 @@ static long evtchn_bind_pirq(evtchn_bind bind->port = port; + if ( is_hvm_domain(d) && domain_pirq_to_irq(d, pirq) > 0 ) + map_domain_emuirq_pirq(d, pirq, IRQ_PT); + out: spin_unlock(&d->event_lock); @@ -419,6 +422,8 @@ static long __evtchn_close(struct domain pirq->evtchn = 0; pirq_cleanup_check(pirq, d1); unlink_pirq_port(chn1, d1->vcpu[chn1->notify_vcpu_id]); + if ( is_hvm_domain(d1) && domain_pirq_to_irq(d1, pirq->pirq) > 0 ) + unmap_domain_pirq_emuirq(d1, pirq->pirq); break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
<stefano.stabellini@eu.citrix.com>
2011-Aug-31 10:24 UTC
[Xen-devel] xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs
If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 5814da0753df xen/arch/x86/hvm/irq.c --- a/xen/arch/x86/hvm/irq.c Tue Aug 30 11:56:22 2011 +0000 +++ b/xen/arch/x86/hvm/irq.c Tue Aug 30 11:56:37 2011 +0000 @@ -29,7 +29,7 @@ #include <asm/msi.h> /* Must be called with hvm_domain->irq_lock hold */ -static void assert_irq(struct domain *d, unsigned ioapic_gsi, unsigned pic_irq) +static void assert_gsi(struct domain *d, unsigned ioapic_gsi) { struct pirq *pirq pirq_info(d, domain_emuirq_to_pirq(d, ioapic_gsi)); @@ -40,6 +40,11 @@ static void assert_irq(struct domain *d, return; } vioapic_irq_positive_edge(d, ioapic_gsi); +} + +static void assert_irq(struct domain *d, unsigned ioapic_gsi, unsigned pic_irq) +{ + assert_gsi(d, ioapic_gsi); vpic_irq_positive_edge(d, pic_irq); } @@ -66,7 +71,7 @@ static void __hvm_pci_intx_assert( gsi = hvm_pci_intx_gsi(device, intx); if ( hvm_irq->gsi_assert_count[gsi]++ == 0 ) - vioapic_irq_positive_edge(d, gsi); + assert_gsi(d, gsi); link = hvm_pci_intx_link(device, intx); isa_irq = hvm_irq->pci_link.route[link]; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
<stefano.stabellini@eu.citrix.com>
2011-Aug-31 10:24 UTC
[Xen-devel] xen: get_free_pirq: make sure that the returned pirq is allocated
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 54845807a8ad xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Tue Aug 30 11:56:37 2011 +0000 +++ b/xen/arch/x86/irq.c Tue Aug 30 11:58:00 2011 +0000 @@ -1584,13 +1584,19 @@ int get_free_pirq(struct domain *d, int { for ( i = 16; i < nr_irqs_gsi; i++ ) if ( is_free_pirq(d, pirq_info(d, i)) ) + { + pirq_get_info(d, i); return i; + } } else { for ( i = d->nr_pirqs - 1; i >= nr_irqs_gsi; i-- ) if ( is_free_pirq(d, pirq_info(d, i)) ) + { + pirq_get_info(d, i); return i; + } } return -ENOSPC; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Aug-31 10:26 UTC
[Xen-devel] Re: xen: fix hvm_domain_use_pirq''s behavior
On Wed, 31 Aug 2011, stefano.stabellini@eu.citrix.com wrote:> hvm_domain_use_pirq should return true when the guest is using a certain > pirq, no matter if the corresponding event channel is currently enabled > or disabled. As an additional complication, qemu is going to request > pirqs for passthrough devices even for Xen unaware HVM guests, so we > need to wait for an event channel to be connected before considering the > pirq of a passthrough device as "in use". > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> >this patch should also be backported to 4.1, I am attaching the backport to this email.> diff -r 1515138fbd7b xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Wed Aug 24 09:33:10 2011 +0100 > +++ b/xen/arch/x86/irq.c Tue Aug 30 11:56:21 2011 +0000 > @@ -2024,6 +2024,5 @@ int unmap_domain_pirq_emuirq(struct doma > bool_t hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq) > { > return is_hvm_domain(d) && pirq && > - pirq->arch.hvm.emuirq != IRQ_UNBOUND && > - pirq->evtchn != 0; > + pirq->arch.hvm.emuirq != IRQ_UNBOUND; > } > diff -r 1515138fbd7b xen/arch/x86/physdev.c > --- a/xen/arch/x86/physdev.c Wed Aug 24 09:33:10 2011 +0100 > +++ b/xen/arch/x86/physdev.c Tue Aug 30 11:56:21 2011 +0000 > @@ -196,9 +196,6 @@ int physdev_map_pirq(domid_t domid, int > if ( ret == 0 ) > *pirq_p = pirq; > > - if ( !ret && is_hvm_domain(d) ) > - map_domain_emuirq_pirq(d, pirq, IRQ_PT); > - > done: > spin_unlock(&d->event_lock); > spin_unlock(&pcidevs_lock); > @@ -271,7 +268,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > v->domain->arch.pv_domain.pirq_eoi_map ) > evtchn_unmask(pirq->evtchn); > if ( !is_hvm_domain(v->domain) || > - pirq->arch.hvm.emuirq == IRQ_PT ) > + domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) > pirq_guest_eoi(pirq); > spin_unlock(&v->domain->event_lock); > ret = 0; > @@ -331,7 +328,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > break; > irq_status_query.flags = 0; > if ( is_hvm_domain(v->domain) && > - domain_pirq_to_emuirq(v->domain, irq) != IRQ_PT ) > + domain_pirq_to_irq(v->domain, irq) <= 0 ) > { > ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; > break; > diff -r 1515138fbd7b xen/common/event_channel.c > --- a/xen/common/event_channel.c Wed Aug 24 09:33:10 2011 +0100 > +++ b/xen/common/event_channel.c Tue Aug 30 11:56:21 2011 +0000 > @@ -366,6 +366,9 @@ static long evtchn_bind_pirq(evtchn_bind > > bind->port = port; > > + if ( is_hvm_domain(d) && domain_pirq_to_irq(d, pirq) > 0 ) > + map_domain_emuirq_pirq(d, pirq, IRQ_PT); > + > out: > spin_unlock(&d->event_lock); > > @@ -419,6 +422,8 @@ static long __evtchn_close(struct domain > pirq->evtchn = 0; > pirq_cleanup_check(pirq, d1); > unlink_pirq_port(chn1, d1->vcpu[chn1->notify_vcpu_id]); > + if ( is_hvm_domain(d1) && domain_pirq_to_irq(d1, pirq->pirq) > 0 ) > + unmap_domain_pirq_emuirq(d1, pirq->pirq); > break; > } > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Aug-31 10:27 UTC
[Xen-devel] Re: xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs
On Wed, 31 Aug 2011, stefano.stabellini@eu.citrix.com wrote:> If the isa irq corresponding to a particular gsi is disabled while the > gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through > the violapic, even if the gsi has been remapped onto a pirq. > This patch makes sure that even in this case we inject the notification > appropriately. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>this patch should be backported to 4.1 too> diff -r 5814da0753df xen/arch/x86/hvm/irq.c > --- a/xen/arch/x86/hvm/irq.c Tue Aug 30 11:56:22 2011 +0000 > +++ b/xen/arch/x86/hvm/irq.c Tue Aug 30 11:56:37 2011 +0000 > @@ -29,7 +29,7 @@ > #include <asm/msi.h> > > /* Must be called with hvm_domain->irq_lock hold */ > -static void assert_irq(struct domain *d, unsigned ioapic_gsi, unsigned pic_irq) > +static void assert_gsi(struct domain *d, unsigned ioapic_gsi) > { > struct pirq *pirq > pirq_info(d, domain_emuirq_to_pirq(d, ioapic_gsi)); > @@ -40,6 +40,11 @@ static void assert_irq(struct domain *d, > return; > } > vioapic_irq_positive_edge(d, ioapic_gsi); > +} > + > +static void assert_irq(struct domain *d, unsigned ioapic_gsi, unsigned pic_irq) > +{ > + assert_gsi(d, ioapic_gsi); > vpic_irq_positive_edge(d, pic_irq); > } > > @@ -66,7 +71,7 @@ static void __hvm_pci_intx_assert( > > gsi = hvm_pci_intx_gsi(device, intx); > if ( hvm_irq->gsi_assert_count[gsi]++ == 0 ) > - vioapic_irq_positive_edge(d, gsi); > + assert_gsi(d, gsi); > > link = hvm_pci_intx_link(device, intx); > isa_irq = hvm_irq->pci_link.route[link]; >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel