On Fri, Jun 24, 2022 at 12:28:38PM +0800, Zeng Guang wrote: > >On 6/23/2022 6:33 PM, Gao, Chao wrote: >> On Thu, Jun 23, 2022 at 05:45:11PM +0800, Zeng Guang wrote: >> >> > + ASSERT_EQ(icr & ~APIC_ICR_BUSY, val & ~APIC_ICR_BUSY); >> Probably add a comment for it would be better. E.g., >> >> APIC_ICR_BUSY is removed and not used when CPU is in x2APIC mode. >> It is undefined whether write 1 to this bit will be preserved. So, >> even KVM keeps this bit cleared in some cases even in x2apic mode, >> no guarantee that hardware (specifically, CPU ucode when Intel IPI >> virtualization enabled) will clear the bit. So, skip checking this >> bit. >Hardware won't touch APIC_ICR_BUSY in x2apic mode. IMO, SDM doesn't say how the processor deals with this bit in x2apic mode. Even if SPR behaves like this, the behavior isn't architectural. Otherwise, KVM shouldn't touch this bit and we can add a test to verify that the bit won't be changed by CPU (or KVM) in x2apic mode. >It totally depends on KVM to clear it or not if set for test purpose. >While in Intel IPI virtualization case, KVM doesn't take care of this >bit in vICR writes. I don't think KVM behavior is the key problem here. If an IPI is virtualized by ucode, KVM isn't involved in processing the IPI. It means KVM has no chance to clear the APIC_ICR_BUSY bit.
