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

Re: [Xen-devel] [PATCH, resend] replacement for noirqdebug hack




On 2 Jun 2006, at 12:01, Jan Beulich wrote:

That stickiness is clearly undesirable to me - if you bring up a domU for testing or other temporary purposes that makes use of an interrupt already in use elsewhere, all other users of the interrupt will from there on not do proper
accounting anymore.

It's hardly a core part of interrupt management. It'd just be disabling a code path that only matters for broken hardware. Now that the IOAPIC ACking is fixed we could arguably just disable that path completely again (noirqdebug). So I think all the interface changes and additions to shared_info are overkill because this is just enabling a broken-hardware workaround.

Further, how would you want to prevent doing the hypercall if by default interrupts are non-shared (I hope you didn't have other intentions) and hence the (sticky) flag wasn't set, yet.

We'd only execute the hypercall if the return code was IRQ_NONE.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.