| Message ID | E959C4978C3B6342920538CF579893F0025F3568@SHSMSX104.ccr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/07/2015 13:18, Wu, Feng wrote: > Then I still need assign prod and de-assign prod in > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right? > Would you please share why this is better. The need to store the consumer->producer link seems to be unique to posted interrupts. It is difficult to say without seeing the PI code, but I prefer to keep the bypass manager as small as possible. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > Sent: Tuesday, July 07, 2015 7:22 PM > To: Wu, Feng; Eric Auger; eric.auger@st.com; > linux-arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > kvm@vger.kernel.org; christoffer.dall@linaro.org; marc.zyngier@arm.com; > alex.williamson@redhat.com; avi.kivity@gmail.com; mtosatti@redhat.com; > joro@8bytes.org; b.reynal@virtualopensystems.com > Cc: linux-kernel@vger.kernel.org; patches@linaro.org > Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding > control > > > > On 07/07/2015 13:18, Wu, Feng wrote: > > Then I still need assign prod and de-assign prod in > > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right? > > Would you please share why this is better. > > The need to store the consumer->producer link seems to be unique to > posted interrupts. It is difficult to say without seeing the PI code, > but I prefer to keep the bypass manager as small as possible. Fine. I will follow your suggestion! Thanks, Feng > > Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Wu, Feng > Sent: Tuesday, July 07, 2015 7:24 PM > To: Paolo Bonzini; Eric Auger; eric.auger@st.com; > linux-arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > kvm@vger.kernel.org; christoffer.dall@linaro.org; marc.zyngier@arm.com; > alex.williamson@redhat.com; avi.kivity@gmail.com; mtosatti@redhat.com; > joro@8bytes.org; b.reynal@virtualopensystems.com > Cc: linux-kernel@vger.kernel.org; patches@linaro.org; Wu, Feng > Subject: RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding > control > > > > > -----Original Message----- > > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > > Sent: Tuesday, July 07, 2015 7:22 PM > > To: Wu, Feng; Eric Auger; eric.auger@st.com; > > linux-arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > > kvm@vger.kernel.org; christoffer.dall@linaro.org; marc.zyngier@arm.com; > > alex.williamson@redhat.com; avi.kivity@gmail.com; mtosatti@redhat.com; > > joro@8bytes.org; b.reynal@virtualopensystems.com > > Cc: linux-kernel@vger.kernel.org; patches@linaro.org > > Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding > > control > > > > > > > > On 07/07/2015 13:18, Wu, Feng wrote: > > > Then I still need assign prod and de-assign prod in > > > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right? > > > Would you please share why this is better. > > > > The need to store the consumer->producer link seems to be unique to > > posted interrupts. It is difficult to say without seeing the PI code, > > but I prefer to keep the bypass manager as small as possible. > > Fine. I will follow your suggestion! If using the following changes, how can we assign 'prod', we need to use container_of to get struct kvm_kernel_irqfd and then refer to 'prod', but we cannot do this in irq_bypass_register_consumer(), right? It is a common API. But we can only get the associated producer info inside bypass manager, right? Thanks, Feng struct kvm_kernel_irqfd { ...... struct irq_bypass_consumer cons; struct irq_bypass_producer *prod; }; > > Thanks, > Feng > > > > > Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/07/2015 13:33, Wu, Feng wrote: >>> > > The need to store the consumer->producer link seems to be unique to >>> > > posted interrupts. It is difficult to say without seeing the PI code, >>> > > but I prefer to keep the bypass manager as small as possible. >> > >> > Fine. I will follow your suggestion! > If using the following changes, how can we assign 'prod', we need to use > container_of to get struct kvm_kernel_irqfd and then refer to 'prod', but > we cannot do this in irq_bypass_register_consumer(), right? It is a > common API. But we can only get the associated producer info inside > bypass manager, right? KVM's add_producer and del_producer callbacks do have a pointer to the producer. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h index 8f62235..11930c1 100644 --- a/include/linux/irqbypass.h +++ b/include/linux/irqbypass.h @@ -20,6 +20,7 @@ struct irq_bypass_producer { struct irq_bypass_consumer { struct list_head node; void *token; + struct irq_bypass_producer *producer; void (*stop)(struct irq_bypass_consumer *); void (*resume)(struct irq_bypass_consumer *); void (*add_producer)(struct irq_bypass_consumer *, diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c index efadbe5..be2da25 100644 --- a/kernel/irq/bypass.c +++ b/kernel/irq/bypass.c @@ -122,6 +122,7 @@ int irq_bypass_register_consumer(struct irq_bypass_consumer *consumer) list_for_each_entry(producer, &producers, node) { if (producer->token == consumer->token) { + consumer->producer = producer; connect(producer, consumer); break; } @@ -140,6 +141,7 @@ void irq_bypass_unregister_consumer(struct irq_bypass_consumer *consumer) list_for_each_entry(producer, &producers, node) { if (producer->token == consumer->token) { + consumer->producer = NULL; disconnect(producer, consumer); break; }