Re: VMI Interface Proposal Documentation for I386, Part 5

[Zwane Mwaikambo <zwane@arm.linux.org.uk>]

Hello Zach,

On Tue, 14 Mar 2006, Zachary Amsden wrote:

> It could be possible to change the semantics of the interrupt masking
> interface in Linux, such that enable_interrupts() did just that - but did not
> yet deliver pending IRQs.  As did restore_interrupt_mask().  This would
> require inspection of many drivers to ensure that they don't rely on those
> actions causing immediate interrupt delivery.  And if they did, they would
> require a call, say, deliver_pending_irqs() to accomplish that.

I think we can break these down into low level and higher level interrupt 
enabling. Lower level tends to be call sites like exception entry, in that 
particular case drivers aren't aware of the interrupt enable/disable 
semantics so it's safe to enable without dispatch. Higher up is where 
dispatch makes sense and we can closer mimick hardware.

> Is this a nice interface for Linux?  Probably not.  In fact, requiring source
> inspection of all drivers just for this would be a gargantuan task, as well as
> being difficult to maintain.  Perhaps, it may have some benefit - one ideology
> is that drivers should not in general require the ability to enable and
> receive interrupts immediately.  Otherwise, they are dependent on hardware
> responses to continue operation, which means they are probably not fault
> tolerant / recoverable.  But many drivers have been written this way.

The aforementioned should allow us not to have to do a driver audit.

> The motivation here is entirely selfish.  Emulating the CPU by unquestioning
> delivery of interrupts is a fine course of action - but it does impose a
> slight overhead.  You first have to determine if there are any interrupts /
> callbacks / upcalls to be serviced.  This is not something you can do in one
> instruction, and moreover, you may have to deal with race conditions in
> determining whether or not any actions are pending.  So there is a measurable
> benefit, when running in a virtual machine, to separate the required delivery
> or interrupts with the enabling of them.
> 
> That is why I think it warrants discussion on the principles, although I am
> not sure that it is practical.

I believe it certainly is worth seperating and would help in the iret, in 
that you could enable interrupts without recursing again.

Thanks,
	Zwane

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/