Re: [PATCH v2] report IRQ injection status to userspace.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 28, 2009 at 06:37:36PM +0200, Gleb Natapov wrote:
> On Tue, Jan 27, 2009 at 01:41:07PM -0200, Marcelo Tosatti wrote:
> > On Tue, Jan 27, 2009 at 03:27:39PM +0200, Gleb Natapov wrote:
> > > > -1 here ?
> > > > 
> > > I think 1 is better here. For level=0 we always want to report that interrupt
> > > was injected and for the case of edge triggered interrupt and level=1
> > > ioapic_service() will always be called. BTW it seems that expression
> > > old_irr != ioapic->irr in:
> > >             if ((!entry.fields.trig_mode && old_irr != ioapic->irr)
> > >                 || !entry.fields.remote_irr)
> > >                 ret = ioapic_service(ioapic, irq);
> > > Will always be true since for edge triggered interrupt irr is always
> > > cleared by ioapic_service(). Am I right?
> > 
> > Right, I was thinking about
> > 
> > 	if (irq >= 0 && irq < IOAPIC_NUM_PINS) {
> > 
> > Should return MASKED if irq is outside the acceptable range?
> > 
> Is this ever can be false? Should we BUG() if irq is out of range?

If qemu-kvm passes it ouf range IRQ yes. Its just a nitpicking, ignore
it.

> > That assumes guests won't mask the interrupt temporarily in the irqchip,
> > hope that is OK (as Avi noted earlier guests use CPU to mask irqs
> > temporarily, most of the time).
> And if a guest masks interrupts it can't complain that some are lost. I
> haven't seen Windows masking RTC irq.

Makes sense.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux