[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] VMX: fix vmx_handle_eoi()



On Fri, Oct 12, 2018 at 03:32:59AM -0600, Jan Beulich wrote:
>In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
>emulation") I screwed up quite heavily: Instead of clearing SVI, RVI was
>cleared. Furthermore, unconditional clearing of SVI is wrong too - other
>ISR bits should be taken into account.
>
>Introduce a new helper set_svi(), split out of vmx_process_isr(), and
>use it also from vmx_handle_eoi().
>
>Following the problems in vmx_intr_assist() (see the still present big
>block of debugging code there) also warn (once) if EOI'd vector and
>original SVI don't match.
>
>Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

After correcting the description in the first paragraph

Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>

I am curious about in which case, the EOI'd vector differs from original SVI.
The sole caller of vmx_handle_eoi() is vlapic_EOI_set(), where the highest bit
of APIC_ISR is assigned to EOI'd vector. So it means the SVI isn't equal to
the highest bit in APIC_ISR. But SDM says "The processor treats this value
(SVI) as the highest priority virtual interrupt that is in service". Maybe in
some places, software or hardware (for instance, when performing virtual
interrupt delivery, SVI got updated without comparing with the current SVI)
fails to make SVI always equal to the highest bit of APIC_ISR.

Thanks
Chao

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.