On Wed, Dec 18, 2024 at 4:44 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > Changing our legacy BIOS is not an option so in order to support Windows VMs
> > with the legacy BIOS with decent performance we would either need to add support
> > for remote reads of the APIC ID register to KVM or support CR8 accesses w/o
> > exiting w/o the in-kernel APIC in order. Do you have a preference?
>
> I didn't quite follow the CR8 access thing. If the choice is between emulating
> Remote Read IPIs and using a userspace local APIC, then I vote with both hands
> for emulating Remote Reads, especially if we can do a half-assed version that
> provides only what your crazy BIOS needs :-)
Absolutely. Not quite userspace local APIC - VMware only needs
userspace traps on CR8 access but yeah, it would not be great to have
that. Remote read support is totally acceptable and hopefully win-win
for VMware too.
> The biggest wrinkle I can think of is that KVM uses the Remote Read IPI encoding
> for a paravirt vCPU kick feature, but I doubt that's used by Windows guests and
> so can be sacrificed on the Altar of Ancient BIOS.
That's easy, the existing code can be wrapped with
if (guest_pv_has(vcpu, KVM_FEATURE_PV_UNHALT))
The remote-read hack is not even supposed to be used by the guest
(it's used internally by kvm_pv_kick_cpu_op).
Paolo
