On Tue, Jun 14, 2022 at 02:41:30PM +0000, Sean Christopherson wrote: >> PVIPI is mainly [*] for sending multi-cast IPIs. Intel IPI virtualization >> can virtualize only uni-cast IPIs. Their use cases don't overlap. So, I >> don't think it makes sense to disable PVIPI if intel IPI virtualization >> is supported. >> >> The question actually is how to deal with the exceptional case below. >> Considering the migration case Sean said below, it is hard to let VM >> always work in the ideal way unless KVM notifies VM of migration and VM >> changes its behavior on receiving such notifications. But since x2apic >> has better performance than xapic, if VM cares about performance, it can >> simply switch to x2apic mode. All things considered, I think the >> performance gain isn't worth the complexity added. So, I prefer to leave >> it as is. >> >> [*]: when linux guest is in *xapic* mode, it uses PVIPI to send uni-case IPI. > >Hmm, there are definitely guests that run xAPIC though, even if x2apic is supported. > >That said, I tend to agree that trying to handle this in KVM and/or the guest kernel >is going to get messy. The easiest solution is for VMMs to not advertise PV IPIs >when the VM is going to predominately run on hosts with IPIv. But it will hurt multi-cast IPIs in VMs. IMO, a feasible solution is to add a new hint to indicate IPI virtualization is enabled and VM uses native interface (writes to ICR) to send uni-cast IPIs in xapic mode if it sees the new hint.
