lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABgObfadZZ5sXYB0xR5OcLDw_eVUmXTOTFSWkVpkgiCJmNnFRQ@mail.gmail.com>
Date: Tue, 7 Jan 2025 18:09:54 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Doug Covelli <doug.covelli@...adcom.com>, Zack Rusin <zack.rusin@...adcom.com>, 
	kvm <kvm@...r.kernel.org>, Jonathan Corbet <corbet@....net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "the arch/x86 maintainers" <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, Shuah Khan <shuah@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Arnaldo Carvalho de Melo <acme@...hat.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Joel Stanley <joel@....id.au>, Linux Doc Mailing List <linux-doc@...r.kernel.org>, linux-kernel@...r.kernel.org, 
	linux-kselftest <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

On Wed, Dec 18, 2024 at 4:44 AM Sean Christopherson <seanjc@...gle.com> 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ