Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: > On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: > > >> What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an > >> EOI can de-assert the irqfd source, but the line is kept high by the > >> last KVM_IRQ_LINE invocation. > > > > Exactly. So 1 ID for userspace and 1 for irqfd. > > Gaa, this mess belongs in userspace. Not sure I understand what you refer to. I meant simply #define KVM_IRQFD_IRQ_SOURCE_ID1 request it at kvm init. As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now for edge. Does this seem acceptable to you? > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: >> What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an >> EOI can de-assert the irqfd source, but the line is kept high by the >> last KVM_IRQ_LINE invocation. > > Exactly. So 1 ID for userspace and 1 for irqfd. Gaa, this mess belongs in userspace. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/16/2012 07:54 PM, Michael S. Tsirkin wrote: > On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: >> On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: >> >> >> What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an >> >> EOI can de-assert the irqfd source, but the line is kept high by the >> >> last KVM_IRQ_LINE invocation. >> > >> > Exactly. So 1 ID for userspace and 1 for irqfd. >> >> Gaa, this mess belongs in userspace. > > Not sure I understand what you refer to. > > I meant simply > #define KVM_IRQFD_IRQ_SOURCE_ID1 > request it at kvm init. > > As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now > for edge. > Does this seem acceptable to you? I meant the pic/ioapic, not this particular bit. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: >> On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: >> > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: >> > > v8: >> > > >> > > Trying a new approach. Nobody seems to like the internal IRQ >> > > source ID object and the interactions it implies between irqfd >> > > and eoifd, so let's get rid of it. Instead, simply expose >> > > IRQ source IDs to userspace. This lets the user be in charge >> > > of freeing them or hanging onto a source ID for later use. >> > >> > In the end it turns out source ID is an optimization for shared >> > interrupts, isn't it? Can't we apply the optimization transparently to >> > the user? E.g. if we have some spare source IDs, allocate them, if we >> > run out, use a shared source ID? >> >> Let's think about shared source IDs a bit more. I think it's wrong that >> irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all >> irqfd users can share a source ID. We do not get the logical OR of all >> users by putting them on the same source ID, we get "last set wins". >> KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the >> logical OR happens in userspace. How would we not starve a user if we >> define KVM_IRQFD_SOURCE_ID? What am I missing? > > That all irqfds are deasserted on EOI anyway. So there's no point > to do a logical OR. > > What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:54:04PM +0300, Avi Kivity wrote: > On 08/16/2012 07:54 PM, Michael S. Tsirkin wrote: > > On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: > >> On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: > >> > >> >> What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an > >> >> EOI can de-assert the irqfd source, but the line is kept high by the > >> >> last KVM_IRQ_LINE invocation. > >> > > >> > Exactly. So 1 ID for userspace and 1 for irqfd. > >> > >> Gaa, this mess belongs in userspace. > > > > Not sure I understand what you refer to. > > > > I meant simply > > #define KVM_IRQFD_IRQ_SOURCE_ID1 > > request it at kvm init. > > > > As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now > > for edge. > > Does this seem acceptable to you? > > I meant the pic/ioapic, not this particular bit. :) > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/11/2012 01:37 AM, Alex Williamson wrote: > v8: > > Trying a new approach. Nobody seems to like the internal IRQ > source ID object and the interactions it implies between irqfd > and eoifd, so let's get rid of it. Instead, simply expose > IRQ source IDs to userspace. This lets the user be in charge > of freeing them or hanging onto a source ID for later use. They > can also detach and re-attach components at will. It also opens > up the possibility that userspace might want to use each IRQ > source ID for more than one GSI (and avoids the kernel needing > to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. > > I really wanted to add a de-assert-only option to irqfd so the > irq_ackfd could be fed directly into an irqfd, but I'm dependent > on the ordering of de-assert _then_ signal an eventfd. Keeping > that ordering doesn't seem to be possible, especially since irqfd > uses a workqueue, if I attempt to make that connection. Thanks, I can't say I'm happy with exposing irq source IDs. It's true that they correspond to a physical entity so they can't be said to be an implementation detail, but adding more ABIs has a cost and I can't say that I see another user for this. Can you provide a link to the combined irqfd+ackfd implementation? I'm inclined now to go for the simplest solution possible. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, 2012-08-16 at 19:29 +0300, Avi Kivity wrote: > On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: > > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: > >> On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > >> > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > >> > > v8: > >> > > > >> > > Trying a new approach. Nobody seems to like the internal IRQ > >> > > source ID object and the interactions it implies between irqfd > >> > > and eoifd, so let's get rid of it. Instead, simply expose > >> > > IRQ source IDs to userspace. This lets the user be in charge > >> > > of freeing them or hanging onto a source ID for later use. > >> > > >> > In the end it turns out source ID is an optimization for shared > >> > interrupts, isn't it? Can't we apply the optimization transparently to > >> > the user? E.g. if we have some spare source IDs, allocate them, if we > >> > run out, use a shared source ID? > >> > >> Let's think about shared source IDs a bit more. I think it's wrong that > >> irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all > >> irqfd users can share a source ID. We do not get the logical OR of all > >> users by putting them on the same source ID, we get "last set wins". > >> KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the > >> logical OR happens in userspace. How would we not starve a user if we > >> define KVM_IRQFD_SOURCE_ID? What am I missing? > > > > That all irqfds are deasserted on EOI anyway. So there's no point > > to do a logical OR. > > > > > > What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an > EOI can de-assert the irqfd source, but the line is kept high by the > last KVM_IRQ_LINE invocation. As I understand Michael's proposal, the shared irq source id used by level-deassert-irqfds can only be asserted via an irqfd injection and can only be de-asserted by the ack notifier. If we let any other interface have access to the irq source id it breaks. If KVM_IRQ_LINE picks up and extension to specify the irq source id, it would have to be prevented from accessing this one. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, 2012-08-16 at 19:32 +0300, Avi Kivity wrote: > On 08/11/2012 01:37 AM, Alex Williamson wrote: > > v8: > > > > Trying a new approach. Nobody seems to like the internal IRQ > > source ID object and the interactions it implies between irqfd > > and eoifd, so let's get rid of it. Instead, simply expose > > IRQ source IDs to userspace. This lets the user be in charge > > of freeing them or hanging onto a source ID for later use. They > > can also detach and re-attach components at will. It also opens > > up the possibility that userspace might want to use each IRQ > > source ID for more than one GSI (and avoids the kernel needing > > to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. > > > > I really wanted to add a de-assert-only option to irqfd so the > > irq_ackfd could be fed directly into an irqfd, but I'm dependent > > on the ordering of de-assert _then_ signal an eventfd. Keeping > > that ordering doesn't seem to be possible, especially since irqfd > > uses a workqueue, if I attempt to make that connection. Thanks, > > I can't say I'm happy with exposing irq source IDs. It's true that they > correspond to a physical entity so they can't be said to be an > implementation detail, but adding more ABIs has a cost and I can't say > that I see another user for this. > > Can you provide a link to the combined irqfd+ackfd implementation? I'm > inclined now to go for the simplest solution possible. As soon as I write it :) Keeping lists to handle the one-to-many deassert-to-notify will notch up the complexity, but it'll be interesting to see how it compares. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:29:40PM +0300, Avi Kivity wrote: > On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: > > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: > >> On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > >> > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > >> > > v8: > >> > > > >> > > Trying a new approach. Nobody seems to like the internal IRQ > >> > > source ID object and the interactions it implies between irqfd > >> > > and eoifd, so let's get rid of it. Instead, simply expose > >> > > IRQ source IDs to userspace. This lets the user be in charge > >> > > of freeing them or hanging onto a source ID for later use. > >> > > >> > In the end it turns out source ID is an optimization for shared > >> > interrupts, isn't it? Can't we apply the optimization transparently to > >> > the user? E.g. if we have some spare source IDs, allocate them, if we > >> > run out, use a shared source ID? > >> > >> Let's think about shared source IDs a bit more. I think it's wrong that > >> irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all > >> irqfd users can share a source ID. We do not get the logical OR of all > >> users by putting them on the same source ID, we get "last set wins". > >> KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the > >> logical OR happens in userspace. How would we not starve a user if we > >> define KVM_IRQFD_SOURCE_ID? What am I missing? > > > > That all irqfds are deasserted on EOI anyway. So there's no point > > to do a logical OR. > > > > > > What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an > EOI can de-assert the irqfd source, but the line is kept high by the > last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 06:34:52AM -0600, Alex Williamson wrote: > > > > So I'm inclined to say source IDs are a requirement for shared > > > > interrupts. > > > > > > Can yo show a specific example that breaks? > > > I don't think it can exist. > > > > Only the edge vs level interaction if we define the policy above for > > de-assert. > > Hmm, there is still a race w/ level. If we have a number of > level-deassert-irqfds making use of the same gsi and sourceid and we > individually de-assert and notify, a re-assert could get lost if it > happens before all of the de-asserts have finished. > We either need > separate sourceids or we need to do a single de-assert followed by > multiple notifies. Right? Thanks, > > Alex Good catch, I agree, we need a single deassert. I think I see how to implement this without reference counting and stuff. So we chain all auto-deassert irqfds for a given GSI together, and have a single ack notifier. When list becomes empty, remove the ack notifier. It's actually a good thing to do anyway, too many ack notifiers would slow unrelated GSIs down. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 13:59 -0600, Alex Williamson wrote: > On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote: > > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: > > > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > > > > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > > > > > v8: > > > > > > > > > > Trying a new approach. Nobody seems to like the internal IRQ > > > > > source ID object and the interactions it implies between irqfd > > > > > and eoifd, so let's get rid of it. Instead, simply expose > > > > > IRQ source IDs to userspace. This lets the user be in charge > > > > > of freeing them or hanging onto a source ID for later use. > > > > > > > > In the end it turns out source ID is an optimization for shared > > > > interrupts, isn't it? Can't we apply the optimization transparently to > > > > the user? E.g. if we have some spare source IDs, allocate them, if we > > > > run out, use a shared source ID? > > > > > > Let's think about shared source IDs a bit more. I think it's wrong that > > > irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all > > > irqfd users can share a source ID. We do not get the logical OR of all > > > users by putting them on the same source ID, we get "last set wins". > > > KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the > > > logical OR happens in userspace. How would we not starve a user if we > > > define KVM_IRQFD_SOURCE_ID? What am I missing? > > > > That all irqfds are deasserted on EOI anyway. So there's no point > > to do a logical OR. > > Ok, so the argument is: > > - edge irqfds (the code now) can share a source ID because there is no > state. Overlapping interrupt injects always cause one or more edge > triggers. > - your proposed level extension can only be asserted by the inject > eventfd and is only de-asserted by EOI, which de-asserts and notifies > all users. > > What prevents an edge irqfd being registered to the same GSI as a level > irqfd, resulting in a de-assert that might result in the irr not being > seen by the guest and therefore maybe not getting an EOI? (I think this > is the same problem as why we can't use the exiting irqfd to insert a > level interrupt) > > Having the de-assert only on EOI policy allows level irqfds to share a > source ID, but do they all need to share a separate source ID from edge > irqfds? > > > > So I'm inclined to say source IDs are a requirement for shared > > > interrupts. > > > > Can yo show a specific example that breaks? > > I don't think it can exist. > > Only the edge vs level interaction if we define the policy above for > de-assert. Hmm, there is still a race w/ level. If we have a number of level-deassert-irqfds making use of the same gsi and sourceid and we individually de-assert and notify, a re-assert could get lost if it happens before all of the de-asserts have finished. We either need separate sourceids or we need to do a single de-assert followed by multiple notifies. Right? Thanks, Alex > > > That means the re-use scheme becomes complicated (ex. we > > > run out of IRQ source IDs, so we start looking for sharing by re-using a > > > source ID used by a different GSI). Do we want to do that in kernel or > > > userspace? This series allows userspace to deal with that complexity. > > > Please let me know if I'm thinking incorrectly about source ID re-use. > > > Thanks, > > > > > > Alex > > > > I think there is a misunderstanding. > > All deassert on ack irqfds can share a source ID. > > This is why I am now thinking deassert on ack behaviour > > should be set when irqfd is assigned. > > Maybe you were already thinking along the lines of a separate source ID > for de-assert on ack irqfds vs normal irqfds then. I think I missed > that. Thanks, > > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 13:59 -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote: On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. Ok, so the argument is: - edge irqfds (the code now) can share a source ID because there is no state. Overlapping interrupt injects always cause one or more edge triggers. - your proposed level extension can only be asserted by the inject eventfd and is only de-asserted by EOI, which de-asserts and notifies all users. What prevents an edge irqfd being registered to the same GSI as a level irqfd, resulting in a de-assert that might result in the irr not being seen by the guest and therefore maybe not getting an EOI? (I think this is the same problem as why we can't use the exiting irqfd to insert a level interrupt) Having the de-assert only on EOI policy allows level irqfds to share a source ID, but do they all need to share a separate source ID from edge irqfds? So I'm inclined to say source IDs are a requirement for shared interrupts. Can yo show a specific example that breaks? I don't think it can exist. Only the edge vs level interaction if we define the policy above for de-assert. Hmm, there is still a race w/ level. If we have a number of level-deassert-irqfds making use of the same gsi and sourceid and we individually de-assert and notify, a re-assert could get lost if it happens before all of the de-asserts have finished. We either need separate sourceids or we need to do a single de-assert followed by multiple notifies. Right? Thanks, Alex That means the re-use scheme becomes complicated (ex. we run out of IRQ source IDs, so we start looking for sharing by re-using a source ID used by a different GSI). Do we want to do that in kernel or userspace? This series allows userspace to deal with that complexity. Please let me know if I'm thinking incorrectly about source ID re-use. Thanks, Alex I think there is a misunderstanding. All deassert on ack irqfds can share a source ID. This is why I am now thinking deassert on ack behaviour should be set when irqfd is assigned. Maybe you were already thinking along the lines of a separate source ID for de-assert on ack irqfds vs normal irqfds then. I think I missed that. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 06:34:52AM -0600, Alex Williamson wrote: So I'm inclined to say source IDs are a requirement for shared interrupts. Can yo show a specific example that breaks? I don't think it can exist. Only the edge vs level interaction if we define the policy above for de-assert. Hmm, there is still a race w/ level. If we have a number of level-deassert-irqfds making use of the same gsi and sourceid and we individually de-assert and notify, a re-assert could get lost if it happens before all of the de-asserts have finished. We either need separate sourceids or we need to do a single de-assert followed by multiple notifies. Right? Thanks, Alex Good catch, I agree, we need a single deassert. I think I see how to implement this without reference counting and stuff. So we chain all auto-deassert irqfds for a given GSI together, and have a single ack notifier. When list becomes empty, remove the ack notifier. It's actually a good thing to do anyway, too many ack notifiers would slow unrelated GSIs down. -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:29:40PM +0300, Avi Kivity wrote: On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, 2012-08-16 at 19:32 +0300, Avi Kivity wrote: On 08/11/2012 01:37 AM, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, I can't say I'm happy with exposing irq source IDs. It's true that they correspond to a physical entity so they can't be said to be an implementation detail, but adding more ABIs has a cost and I can't say that I see another user for this. Can you provide a link to the combined irqfd+ackfd implementation? I'm inclined now to go for the simplest solution possible. As soon as I write it :) Keeping lists to handle the one-to-many deassert-to-notify will notch up the complexity, but it'll be interesting to see how it compares. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, 2012-08-16 at 19:29 +0300, Avi Kivity wrote: On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. As I understand Michael's proposal, the shared irq source id used by level-deassert-irqfds can only be asserted via an irqfd injection and can only be de-asserted by the ack notifier. If we let any other interface have access to the irq source id it breaks. If KVM_IRQ_LINE picks up and extension to specify the irq source id, it would have to be prevented from accessing this one. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/11/2012 01:37 AM, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, I can't say I'm happy with exposing irq source IDs. It's true that they correspond to a physical entity so they can't be said to be an implementation detail, but adding more ABIs has a cost and I can't say that I see another user for this. Can you provide a link to the combined irqfd+ackfd implementation? I'm inclined now to go for the simplest solution possible. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:54:04PM +0300, Avi Kivity wrote: On 08/16/2012 07:54 PM, Michael S. Tsirkin wrote: On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. Gaa, this mess belongs in userspace. Not sure I understand what you refer to. I meant simply #define KVM_IRQFD_IRQ_SOURCE_ID1 request it at kvm init. As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now for edge. Does this seem acceptable to you? I meant the pic/ioapic, not this particular bit. :) -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote: On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/16/2012 07:54 PM, Michael S. Tsirkin wrote: On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. Gaa, this mess belongs in userspace. Not sure I understand what you refer to. I meant simply #define KVM_IRQFD_IRQ_SOURCE_ID1 request it at kvm init. As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now for edge. Does this seem acceptable to you? I meant the pic/ioapic, not this particular bit. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. Gaa, this mess belongs in userspace. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Thu, Aug 16, 2012 at 07:39:35PM +0300, Avi Kivity wrote: On 08/16/2012 07:36 PM, Michael S. Tsirkin wrote: What if a level irqfd shares a line with a KVM_IRQ_LINE ioctl? Then an EOI can de-assert the irqfd source, but the line is kept high by the last KVM_IRQ_LINE invocation. Exactly. So 1 ID for userspace and 1 for irqfd. Gaa, this mess belongs in userspace. Not sure I understand what you refer to. I meant simply #define KVM_IRQFD_IRQ_SOURCE_ID1 request it at kvm init. As opposed to using KVM_USERSPACE_IRQ_SOURCE_ID like we do now for edge. Does this seem acceptable to you? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote: > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: > > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > > > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > > > > v8: > > > > > > > > Trying a new approach. Nobody seems to like the internal IRQ > > > > source ID object and the interactions it implies between irqfd > > > > and eoifd, so let's get rid of it. Instead, simply expose > > > > IRQ source IDs to userspace. This lets the user be in charge > > > > of freeing them or hanging onto a source ID for later use. > > > > > > In the end it turns out source ID is an optimization for shared > > > interrupts, isn't it? Can't we apply the optimization transparently to > > > the user? E.g. if we have some spare source IDs, allocate them, if we > > > run out, use a shared source ID? > > > > Let's think about shared source IDs a bit more. I think it's wrong that > > irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all > > irqfd users can share a source ID. We do not get the logical OR of all > > users by putting them on the same source ID, we get "last set wins". > > KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the > > logical OR happens in userspace. How would we not starve a user if we > > define KVM_IRQFD_SOURCE_ID? What am I missing? > > That all irqfds are deasserted on EOI anyway. So there's no point > to do a logical OR. Ok, so the argument is: - edge irqfds (the code now) can share a source ID because there is no state. Overlapping interrupt injects always cause one or more edge triggers. - your proposed level extension can only be asserted by the inject eventfd and is only de-asserted by EOI, which de-asserts and notifies all users. What prevents an edge irqfd being registered to the same GSI as a level irqfd, resulting in a de-assert that might result in the irr not being seen by the guest and therefore maybe not getting an EOI? (I think this is the same problem as why we can't use the exiting irqfd to insert a level interrupt) Having the de-assert only on EOI policy allows level irqfds to share a source ID, but do they all need to share a separate source ID from edge irqfds? > > So I'm inclined to say source IDs are a requirement for shared > > interrupts. > > Can yo show a specific example that breaks? > I don't think it can exist. Only the edge vs level interaction if we define the policy above for de-assert. > > That means the re-use scheme becomes complicated (ex. we > > run out of IRQ source IDs, so we start looking for sharing by re-using a > > source ID used by a different GSI). Do we want to do that in kernel or > > userspace? This series allows userspace to deal with that complexity. > > Please let me know if I'm thinking incorrectly about source ID re-use. > > Thanks, > > > > Alex > > I think there is a misunderstanding. > All deassert on ack irqfds can share a source ID. > This is why I am now thinking deassert on ack behaviour > should be set when irqfd is assigned. Maybe you were already thinking along the lines of a separate source ID for de-assert on ack irqfds vs normal irqfds then. I think I missed that. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > > > v8: > > > > > > Trying a new approach. Nobody seems to like the internal IRQ > > > source ID object and the interactions it implies between irqfd > > > and eoifd, so let's get rid of it. Instead, simply expose > > > IRQ source IDs to userspace. This lets the user be in charge > > > of freeing them or hanging onto a source ID for later use. > > > > In the end it turns out source ID is an optimization for shared > > interrupts, isn't it? Can't we apply the optimization transparently to > > the user? E.g. if we have some spare source IDs, allocate them, if we > > run out, use a shared source ID? > > Let's think about shared source IDs a bit more. I think it's wrong that > irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all > irqfd users can share a source ID. We do not get the logical OR of all > users by putting them on the same source ID, we get "last set wins". > KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the > logical OR happens in userspace. How would we not starve a user if we > define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. > > So I'm inclined to say source IDs are a requirement for shared > interrupts. Can yo show a specific example that breaks? I don't think it can exist. > That means the re-use scheme becomes complicated (ex. we > run out of IRQ source IDs, so we start looking for sharing by re-using a > source ID used by a different GSI). Do we want to do that in kernel or > userspace? This series allows userspace to deal with that complexity. > Please let me know if I'm thinking incorrectly about source ID re-use. > Thanks, > > Alex I think there is a misunderstanding. All deassert on ack irqfds can share a source ID. This is why I am now thinking deassert on ack behaviour should be set when irqfd is assigned. > > > > They > > > can also detach and re-attach components at will. It also opens > > > up the possibility that userspace might want to use each IRQ > > > source ID for more than one GSI (and avoids the kernel needing > > > to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. > > > > > > I really wanted to add a de-assert-only option to irqfd so the > > > irq_ackfd could be fed directly into an irqfd, but I'm dependent > > > on the ordering of de-assert _then_ signal an eventfd. Keeping > > > that ordering doesn't seem to be possible, especially since irqfd > > > uses a workqueue, if I attempt to make that connection. Thanks, > > > > > > Alex > > > --- > > > > > > Alex Williamson (6): > > > kvm: Add de-assert option to KVM_IRQ_ACKFD > > > kvm: KVM_IRQ_ACKFD > > > kvm: Add assert-only option to KVM_IRQFD > > > kvm: Add IRQ source ID option to KVM_IRQFD > > > kvm: Expose IRQ source IDs to userspace > > > kvm: Allow filtering of acked irqs > > > > > > > > > Documentation/virtual/kvm/api.txt | 53 ++ > > > arch/x86/kvm/Kconfig |1 > > > arch/x86/kvm/i8254.c |1 > > > arch/x86/kvm/i8259.c |8 + > > > arch/x86/kvm/x86.c|8 + > > > include/linux/kvm.h | 39 - > > > include/linux/kvm_host.h | 18 ++ > > > virt/kvm/Kconfig |3 > > > virt/kvm/assigned-dev.c |1 > > > virt/kvm/eventfd.c| 315 > > > + > > > virt/kvm/ioapic.c |5 - > > > virt/kvm/irq_comm.c | 28 +++ > > > virt/kvm/kvm_main.c | 26 +++ > > > 13 files changed, 496 insertions(+), 10 deletions(-) > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > > v8: > > > > Trying a new approach. Nobody seems to like the internal IRQ > > source ID object and the interactions it implies between irqfd > > and eoifd, so let's get rid of it. Instead, simply expose > > IRQ source IDs to userspace. This lets the user be in charge > > of freeing them or hanging onto a source ID for later use. > > In the end it turns out source ID is an optimization for shared > interrupts, isn't it? Can't we apply the optimization transparently to > the user? E.g. if we have some spare source IDs, allocate them, if we > run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get "last set wins". KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? So I'm inclined to say source IDs are a requirement for shared interrupts. That means the re-use scheme becomes complicated (ex. we run out of IRQ source IDs, so we start looking for sharing by re-using a source ID used by a different GSI). Do we want to do that in kernel or userspace? This series allows userspace to deal with that complexity. Please let me know if I'm thinking incorrectly about source ID re-use. Thanks, Alex > > They > > can also detach and re-attach components at will. It also opens > > up the possibility that userspace might want to use each IRQ > > source ID for more than one GSI (and avoids the kernel needing > > to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. > > > > I really wanted to add a de-assert-only option to irqfd so the > > irq_ackfd could be fed directly into an irqfd, but I'm dependent > > on the ordering of de-assert _then_ signal an eventfd. Keeping > > that ordering doesn't seem to be possible, especially since irqfd > > uses a workqueue, if I attempt to make that connection. Thanks, > > > > Alex > > --- > > > > Alex Williamson (6): > > kvm: Add de-assert option to KVM_IRQ_ACKFD > > kvm: KVM_IRQ_ACKFD > > kvm: Add assert-only option to KVM_IRQFD > > kvm: Add IRQ source ID option to KVM_IRQFD > > kvm: Expose IRQ source IDs to userspace > > kvm: Allow filtering of acked irqs > > > > > > Documentation/virtual/kvm/api.txt | 53 ++ > > arch/x86/kvm/Kconfig |1 > > arch/x86/kvm/i8254.c |1 > > arch/x86/kvm/i8259.c |8 + > > arch/x86/kvm/x86.c|8 + > > include/linux/kvm.h | 39 - > > include/linux/kvm_host.h | 18 ++ > > virt/kvm/Kconfig |3 > > virt/kvm/assigned-dev.c |1 > > virt/kvm/eventfd.c| 315 > > + > > virt/kvm/ioapic.c |5 - > > virt/kvm/irq_comm.c | 28 +++ > > virt/kvm/kvm_main.c | 26 +++ > > 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: > v8: > > Trying a new approach. Nobody seems to like the internal IRQ > source ID object and the interactions it implies between irqfd > and eoifd, so let's get rid of it. Instead, simply expose > IRQ source IDs to userspace. This lets the user be in charge > of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? > They > can also detach and re-attach components at will. It also opens > up the possibility that userspace might want to use each IRQ > source ID for more than one GSI (and avoids the kernel needing > to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. > > I really wanted to add a de-assert-only option to irqfd so the > irq_ackfd could be fed directly into an irqfd, but I'm dependent > on the ordering of de-assert _then_ signal an eventfd. Keeping > that ordering doesn't seem to be possible, especially since irqfd > uses a workqueue, if I attempt to make that connection. Thanks, > > Alex > --- > > Alex Williamson (6): > kvm: Add de-assert option to KVM_IRQ_ACKFD > kvm: KVM_IRQ_ACKFD > kvm: Add assert-only option to KVM_IRQFD > kvm: Add IRQ source ID option to KVM_IRQFD > kvm: Expose IRQ source IDs to userspace > kvm: Allow filtering of acked irqs > > > Documentation/virtual/kvm/api.txt | 53 ++ > arch/x86/kvm/Kconfig |1 > arch/x86/kvm/i8254.c |1 > arch/x86/kvm/i8259.c |8 + > arch/x86/kvm/x86.c|8 + > include/linux/kvm.h | 39 - > include/linux/kvm_host.h | 18 ++ > virt/kvm/Kconfig |3 > virt/kvm/assigned-dev.c |1 > virt/kvm/eventfd.c| 315 > + > virt/kvm/ioapic.c |5 - > virt/kvm/irq_comm.c | 28 +++ > virt/kvm/kvm_main.c | 26 +++ > 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, Alex --- Alex Williamson (6): kvm: Add de-assert option to KVM_IRQ_ACKFD kvm: KVM_IRQ_ACKFD kvm: Add assert-only option to KVM_IRQFD kvm: Add IRQ source ID option to KVM_IRQFD kvm: Expose IRQ source IDs to userspace kvm: Allow filtering of acked irqs Documentation/virtual/kvm/api.txt | 53 ++ arch/x86/kvm/Kconfig |1 arch/x86/kvm/i8254.c |1 arch/x86/kvm/i8259.c |8 + arch/x86/kvm/x86.c|8 + include/linux/kvm.h | 39 - include/linux/kvm_host.h | 18 ++ virt/kvm/Kconfig |3 virt/kvm/assigned-dev.c |1 virt/kvm/eventfd.c| 315 + virt/kvm/ioapic.c |5 - virt/kvm/irq_comm.c | 28 +++ virt/kvm/kvm_main.c | 26 +++ 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? So I'm inclined to say source IDs are a requirement for shared interrupts. That means the re-use scheme becomes complicated (ex. we run out of IRQ source IDs, so we start looking for sharing by re-using a source ID used by a different GSI). Do we want to do that in kernel or userspace? This series allows userspace to deal with that complexity. Please let me know if I'm thinking incorrectly about source ID re-use. Thanks, Alex They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, Alex --- Alex Williamson (6): kvm: Add de-assert option to KVM_IRQ_ACKFD kvm: KVM_IRQ_ACKFD kvm: Add assert-only option to KVM_IRQFD kvm: Add IRQ source ID option to KVM_IRQFD kvm: Expose IRQ source IDs to userspace kvm: Allow filtering of acked irqs Documentation/virtual/kvm/api.txt | 53 ++ arch/x86/kvm/Kconfig |1 arch/x86/kvm/i8254.c |1 arch/x86/kvm/i8259.c |8 + arch/x86/kvm/x86.c|8 + include/linux/kvm.h | 39 - include/linux/kvm_host.h | 18 ++ virt/kvm/Kconfig |3 virt/kvm/assigned-dev.c |1 virt/kvm/eventfd.c| 315 + virt/kvm/ioapic.c |5 - virt/kvm/irq_comm.c | 28 +++ virt/kvm/kvm_main.c | 26 +++ 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. So I'm inclined to say source IDs are a requirement for shared interrupts. Can yo show a specific example that breaks? I don't think it can exist. That means the re-use scheme becomes complicated (ex. we run out of IRQ source IDs, so we start looking for sharing by re-using a source ID used by a different GSI). Do we want to do that in kernel or userspace? This series allows userspace to deal with that complexity. Please let me know if I'm thinking incorrectly about source ID re-use. Thanks, Alex I think there is a misunderstanding. All deassert on ack irqfds can share a source ID. This is why I am now thinking deassert on ack behaviour should be set when irqfd is assigned. They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, Alex --- Alex Williamson (6): kvm: Add de-assert option to KVM_IRQ_ACKFD kvm: KVM_IRQ_ACKFD kvm: Add assert-only option to KVM_IRQFD kvm: Add IRQ source ID option to KVM_IRQFD kvm: Expose IRQ source IDs to userspace kvm: Allow filtering of acked irqs Documentation/virtual/kvm/api.txt | 53 ++ arch/x86/kvm/Kconfig |1 arch/x86/kvm/i8254.c |1 arch/x86/kvm/i8259.c |8 + arch/x86/kvm/x86.c|8 + include/linux/kvm.h | 39 - include/linux/kvm_host.h | 18 ++ virt/kvm/Kconfig |3 virt/kvm/assigned-dev.c |1 virt/kvm/eventfd.c| 315 + virt/kvm/ioapic.c |5 - virt/kvm/irq_comm.c | 28 +++ virt/kvm/kvm_main.c | 26 +++ 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/6] kvm: level irqfd support
On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote: On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote: On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote: On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote: v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. In the end it turns out source ID is an optimization for shared interrupts, isn't it? Can't we apply the optimization transparently to the user? E.g. if we have some spare source IDs, allocate them, if we run out, use a shared source ID? Let's think about shared source IDs a bit more. I think it's wrong that irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all irqfd users can share a source ID. We do not get the logical OR of all users by putting them on the same source ID, we get last set wins. KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the logical OR happens in userspace. How would we not starve a user if we define KVM_IRQFD_SOURCE_ID? What am I missing? That all irqfds are deasserted on EOI anyway. So there's no point to do a logical OR. Ok, so the argument is: - edge irqfds (the code now) can share a source ID because there is no state. Overlapping interrupt injects always cause one or more edge triggers. - your proposed level extension can only be asserted by the inject eventfd and is only de-asserted by EOI, which de-asserts and notifies all users. What prevents an edge irqfd being registered to the same GSI as a level irqfd, resulting in a de-assert that might result in the irr not being seen by the guest and therefore maybe not getting an EOI? (I think this is the same problem as why we can't use the exiting irqfd to insert a level interrupt) Having the de-assert only on EOI policy allows level irqfds to share a source ID, but do they all need to share a separate source ID from edge irqfds? So I'm inclined to say source IDs are a requirement for shared interrupts. Can yo show a specific example that breaks? I don't think it can exist. Only the edge vs level interaction if we define the policy above for de-assert. That means the re-use scheme becomes complicated (ex. we run out of IRQ source IDs, so we start looking for sharing by re-using a source ID used by a different GSI). Do we want to do that in kernel or userspace? This series allows userspace to deal with that complexity. Please let me know if I'm thinking incorrectly about source ID re-use. Thanks, Alex I think there is a misunderstanding. All deassert on ack irqfds can share a source ID. This is why I am now thinking deassert on ack behaviour should be set when irqfd is assigned. Maybe you were already thinking along the lines of a separate source ID for de-assert on ack irqfds vs normal irqfds then. I think I missed that. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/6] kvm: level irqfd support
v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, Alex --- Alex Williamson (6): kvm: Add de-assert option to KVM_IRQ_ACKFD kvm: KVM_IRQ_ACKFD kvm: Add assert-only option to KVM_IRQFD kvm: Add IRQ source ID option to KVM_IRQFD kvm: Expose IRQ source IDs to userspace kvm: Allow filtering of acked irqs Documentation/virtual/kvm/api.txt | 53 ++ arch/x86/kvm/Kconfig |1 arch/x86/kvm/i8254.c |1 arch/x86/kvm/i8259.c |8 + arch/x86/kvm/x86.c|8 + include/linux/kvm.h | 39 - include/linux/kvm_host.h | 18 ++ virt/kvm/Kconfig |3 virt/kvm/assigned-dev.c |1 virt/kvm/eventfd.c| 315 + virt/kvm/ioapic.c |5 - virt/kvm/irq_comm.c | 28 +++ virt/kvm/kvm_main.c | 26 +++ 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/6] kvm: level irqfd support
v8: Trying a new approach. Nobody seems to like the internal IRQ source ID object and the interactions it implies between irqfd and eoifd, so let's get rid of it. Instead, simply expose IRQ source IDs to userspace. This lets the user be in charge of freeing them or hanging onto a source ID for later use. They can also detach and re-attach components at will. It also opens up the possibility that userspace might want to use each IRQ source ID for more than one GSI (and avoids the kernel needing to manage that). Per suggestions, EOIFD is now IRQ_ACKFD. I really wanted to add a de-assert-only option to irqfd so the irq_ackfd could be fed directly into an irqfd, but I'm dependent on the ordering of de-assert _then_ signal an eventfd. Keeping that ordering doesn't seem to be possible, especially since irqfd uses a workqueue, if I attempt to make that connection. Thanks, Alex --- Alex Williamson (6): kvm: Add de-assert option to KVM_IRQ_ACKFD kvm: KVM_IRQ_ACKFD kvm: Add assert-only option to KVM_IRQFD kvm: Add IRQ source ID option to KVM_IRQFD kvm: Expose IRQ source IDs to userspace kvm: Allow filtering of acked irqs Documentation/virtual/kvm/api.txt | 53 ++ arch/x86/kvm/Kconfig |1 arch/x86/kvm/i8254.c |1 arch/x86/kvm/i8259.c |8 + arch/x86/kvm/x86.c|8 + include/linux/kvm.h | 39 - include/linux/kvm_host.h | 18 ++ virt/kvm/Kconfig |3 virt/kvm/assigned-dev.c |1 virt/kvm/eventfd.c| 315 + virt/kvm/ioapic.c |5 - virt/kvm/irq_comm.c | 28 +++ virt/kvm/kvm_main.c | 26 +++ 13 files changed, 496 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
