| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home