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
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
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
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
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
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
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
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,
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,
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
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
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,
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
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
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
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
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
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?
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
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
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
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.
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:
> > > >
> > > >
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
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
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.
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
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
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
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.
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
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
32 matches
Mail list logo