Re: [Xen-devel] [PATCH] x86/apic: fix disabling LVT0 in disconnect_bsp_APIC

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
> On 17.01.2020 16:09, Roger Pau Monne wrote:
> > The Intel SDM states:
> > 
> > "When an illegal vector value (0 to 15) is written to a LVT entry and
> > the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
> > illegal vector error, without regard to whether the mask bit is set or
> > whether an interrupt is actually seen on the input."
> > 
> > And that's exactly what's currently done in disconnect_bsp_APIC when
> > virt_wire_setup is true and LVT LINT0 is being masked. By writing only
> > APIC_LVT_MASKED Xen is actually setting the vector to 0 and the
> > delivery mode to Fixed (0), and hence it triggers an APIC error even
> > when the LVT entry is masked.
> 
> But there are many more instances where we (have a risk to) do so,
> most notably in clear_local_APIC(). The two step logic there is
> anyway somewhat in conflict with the citation above.

clear_local_APIC masks the error vector before doing any write, and
clears ESR afterwards, there's a comment at the top:

"Masking an LVT entry on a P6 can trigger a local APIC error
if the vector is zero. Mask LVTERR first to prevent this."

We could do the same (ie: mask LVTERR first and clear ESR afterwards)
if that seems preferable. There's a maxlvt check in clear_local_APIC,
but the sdm doesn't specify anyway to check if the lapic will accept a
masked vector 0 write or not, so not sure whether we should replicate
that check or just do it unconditionally on both disconnect_bsp_APIC
and clear_local_APIC.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel