Xen devel - Feb 2008 - x86: clear_IO_APIC_pin() and SMI delivery mode

clear_IO_APIC_pin() ignores entries that are set to delivery mode SMI.
While this seems reasonable if the entry was unmasked, I consider it
dubious for masked entries.

In Linux, such behavior is benign since when the entry later is being
used for some normal interrupt, the old setting is simply overwritten.
In Xen, however, ioapic_guest_write() uses the vector field to
determine the previous associated IRQ and possibly call
remove_pin_at_irq() - this is where we got a report of a hypervisor
crash - the BUG() in the first loop of this function triggers.

Since I see two ways of fixing this (and perhaps there are more),
before creating a patch I''d like to understand which of the
approaches seems more reasonable (or whether both should be
combined):

a) Only ignore un-masked SMI delivery mode entries in
clear_IO_APIC_pin().

b) Ignore the vector information in ioapic_guest_write() for all
delivery modes (at least in old_rte, new_rte is currently not allowed
to have anything but fixed or lowest priority) that don''t allow a
vector.

Jan


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

On 6/2/08 13:00, "Jan Beulich" <jbeulich@novell.com> wrote:
> b) Ignore the vector information in ioapic_guest_write() for all
> delivery modes (at least in old_rte, new_rte is currently not allowed
> to have anything but fixed or lowest priority) that don''t allow a
> vector.
That''s what we''ve done since Xen 3.1.1. See xen-unstable c/s
15270 (15184 in
3.1-testing).

 -- Keir



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

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.02.08 14:21
>>>
>On 6/2/08 13:00, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> b) Ignore the vector information in ioapic_guest_write() for all
>> delivery modes (at least in old_rte, new_rte is currently not allowed
>> to have anything but fixed or lowest priority) that don''t
allow a
>> vector.
>
>That''s what we''ve done since Xen 3.1.1. See xen-unstable
c/s 15270 (15184 in
>3.1-testing).
Hmm, I admit I again failed to look at the -unstable code, but isn''t
the
WARN_BOGUS_WRITE() itself a little bogus, especially if the entry is
masked?

Jan


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

On 6/2/08 13:55, "Jan Beulich" <jbeulich@novell.com> wrote:
>> That''s what we''ve done since Xen 3.1.1. See
xen-unstable c/s 15270 (15184 in
>> 3.1-testing).
> 
> Hmm, I admit I again failed to look at the -unstable code, but
isn''t the
> WARN_BOGUS_WRITE() itself a little bogus, especially if the entry is
> masked?
It''s nice to know if we take that path. Actually most dom0 boots will
get
one or two WARN_BOGUS_WRITE() outputs (modifying IO-APIC pin for in-use
IRQ), of course they''re almost always benign, and hence it''s
rather up to
you if you want to quieten that down for use in your product. But the
messages aren''t too scary-looking, I think.

 -- Keir



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