[RFC,v2,3/6] irq: bypass: Extend skeleton for ARM forwarding control
diff mbox

Message ID E959C4978C3B6342920538CF579893F0025F3568@SHSMSX104.ccr.corp.intel.com
State New
Headers show

Commit Message

Wu, Feng July 7, 2015, 11:18 a.m. UTC
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Tuesday, July 07, 2015 7:14 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:13, Wu, Feng wrote:
> >> > You can use container_of to add it to your own struct, e.g.
> >> >
> >> > 	struct irq_bypass_consumer cons;
> >> > 	struct irq_bypass_producer *prod;
> > Do you mean this:
> >
> > struct kvm_kernel_irqfd {
> >
> > 	......
> >
> > 	struct irq_bypass_consumer cons;
> > 	struct irq_bypass_producer *prod;
> > };
> 
> Yes.

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. My original though is as below:


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

Comments

Paolo Bonzini July 7, 2015, 11:21 a.m. UTC | #1
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
Wu, Feng July 7, 2015, 11:24 a.m. UTC | #2
> -----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
Wu, Feng July 7, 2015, 11:33 a.m. UTC | #3
> -----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
Paolo Bonzini July 7, 2015, 1:22 p.m. UTC | #4
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

Patch
diff mbox

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;
                }