It's a slightly tricky one. I was actually thinking before about adding
explicit pirq mask/unmask physdev_op hypercalls, but actually doing it with
startup/shutdown seems maybe more elegant. I need to read the code a bit
more closely and check we can't lose edge-triggered interrupts this way, or
anything like that. But I think the higher-level irq code deals with that.
-- Keir
On 15/11/07 14:10, "Chris Lalancette" <clalance@xxxxxxxxxx> wrote:
> Jiang, Yunhong wrote:
>> Not sure if the change is a bit over-kill, since enable_pirq is has void
>> return type, while startup_pirq is "int" return type, with possibility
>> to fail.
>
> Thanks for looking!
>
> This is true, startup_pirq() *could* fail; but if you notice in the code, it
> doesn't actually have anything but a "return 0", so it doesn't report errors
> currently anyway.
>
>>
>> For example, in following situation, the startup_pirq may fail : 1) when
>> startup_pirq again, fail to get free port, 2) if another domain try to
>> bind the pirq with BIND_PIRQ_WILL_SHARE cleared (like to probing, will
>> it happen?) between the shutdown_pirq/startup_pirq sequence.
>
> Yes, you are right, this can happen if another domain is probing. However,
> I'm
> not sure that it is any different from when you are calling ->startup() for
> the
> first time; you will just fail to get the event channel. Without introducing
> another event channel op (which seems like a LOT of overkill), I'm not aware
> of
> another way of asking the HV to mask out that IRQ on the IOAPIC.
>
> Chris Lalancette
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home