Xen devel - Apr 2006 - [PATCH] linux: mor assign_irq_vector() adjustments

Instead of adding locking to also protect irq_vector[] in xenlinux, this patch
adds verification that the vector passed
up from Xen for a certain IRQ is matching a potential previously obtained value.
Besides that, two minor cleanup hunks.

Jan


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

On 25 Apr 2006, at 13:38, Jan Beulich wrote:
> Instead of adding locking to also protect irq_vector[] in xenlinux, 
> this patch adds verification that the vector passed
> up from Xen for a certain IRQ is matching a potential previously 
> obtained value. Besides that, two minor cleanup hunks.
I think the extra checking here adds pointless complexity. If the check 
fails then you are totally screwed -- you''re just going to have to 
trust Xen here.

  -- Keir


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

>From: Jan Beulich
>Sent: 2006年4月25日 20:39
>
>Instead of adding locking to also protect irq_vector[] in xenlinux, this
>patch adds verification that the vector passed
>up from Xen for a certain IRQ is matching a potential previously obtained
>value. Besides that, two minor cleanup hunks.
>
>Jan
Is it useful to add that type of detect in xenlinux? Since lock has 
been added into xen, it''s always the first one holding lock to trigger 
allocation process while the latter one getting cached vector returned
directly. In this case, xen promises the consistence and it''s always 
safe even two paths are writing irq_vector table simultaneously since 
two paths see same value...

Thanks,
Kevin

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