linux-kernel - [RFC PATCH 0/5] Documentation: kvm: cleanup and introduce "VM planes"

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241023124507.280382-1-pbonzini@redhat.com>
Date: Wed, 23 Oct 2024 14:45:02 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Cc: roy.hopkins@...e.com,
	seanjc@...gle.com,
	michael.roth@....com,
	ashish.kalra@....com,
	jroedel@...e.de,
	thomas.lendacky@....com,
	nsaenz@...zon.com,
	anelkz@...zon.de,
	oliver.upton@...ux.dev,
	isaku.yamahata@...el.com,
	maz@...nel.org,
	steven.price@....com,
	kai.huang@...el.com,
	rick.p.edgecombe@...el.com,
	James.Bottomley@...senPartnership.com
Subject: [RFC PATCH 0/5] Documentation: kvm: cleanup and introduce "VM planes"

As discussed at KVM Forum, this series introduces documentation for the
"VM planes" concept that can be used to implement at least AMD VMPLs
and Microsoft VTLs.

I didn't include Intel TDX and Arm CCA, because people expressed doubts
on whether KVM could deal with {firm,hard}ware that magically enters the
vCPU in one privilege level and leave at another.  This however may not
be a blocker, especially considering that we decided to have only one
mutex for all planes.

Compared to the notes from the KVM Forum BoF, the main change is in the
kvm_run fields.  The design at the BoF had fields masked_planes and
runnable_planes, and a userspace exit would happen if the value of
runnable_planes & ~masked_planes became nonzero.

Here instead I have:

- req_exit_planes which is similar to ~masked_planes.  The difference comes
  from the Hyper-V VINA feature ("Virtual Interrupt Notification Assist"),
  which requires userspace to know about _all_ interrupts, even those for
  lower VTLs

- suspended_planes, which is not used yet but needs to be there for future
  in-kernel accelerations, because interrupts can "skip" VTLs/VMPLs and need
  to return to the last suspended level.

  I am not sure that this needs to be in kvm_run though.  It definitely has
  to be migrated once KVM supports in-kernel switch, but I am not sure that
  userspace needs it "enough" to put it in kvm_run.  It could be accessed
  with KVM_GET_ONE_REG/KVM_SET_ONE_REG or similar, perhaps.

- pending_event_planes (same as runnable_planes) is in the KVM_EXIT_PLANE_EVENT
  data, kvm_run->exit.plane.  It seems that it is not used in any other case
  by userspace (KVM probably needs to keep it up to date at all time; but
  it cannot trust anyway what is in kvm_run and needs to have its own copy).

Another difference is in whether FPU is shared.  We had it as shared,
but for SEV-ES the contents of the x87 and AVX registers are stored in
the VMSA and therefore each VMPL has its own copy.  The solution I have
(KVM_CAP_PLANE_FPU) is a bit of a cop out though.

In order to add the relevant text, there are a few cleanups that can be applied
separately.

Paolo Bonzini (5):
  KVM: powerpc: remove remaining traces of KVM_CAP_PPC_RMA
  Documentation: kvm: fix a few mistakes
  Documentation: kvm: replace section numbers with links
  Documentation: kvm: reorganize introduction
  Documentation: kvm: introduce "VM plane" concept

 Documentation/virt/kvm/api.rst           | 357 ++++++++++++++++-------
 Documentation/virt/kvm/vcpu-requests.rst |   7 +
 arch/powerpc/kvm/powerpc.c               |   3 -
 3 files changed, 266 insertions(+), 101 deletions(-)

-- 
2.46.2