Thread (133 messages) 133 messages, 11 authors, 2024-08-22

Re: [PATCH v12 00/84] KVM: Stop grabbing references to PFNMAP'd pages

From: Sean Christopherson <seanjc@google.com>
Date: 2024-07-30 22:35:21
Also in: kvm, kvm-riscv, kvmarm, linux-arm-kernel, linux-mips, linux-riscv, lkml, loongarch

On Tue, Jul 30, 2024, Paolo Bonzini wrote:
An interesting evolution of the API could be to pass a struct kvm_follow_pfn
pointer to {,__}kvm_faultin_pfn() and __gfn_to_page() (the "constructors");
and on the other side to kvm_release_faultin_page() and
kvm_release_page_*().  The struct kvm_follow_pfn could be embedded in the
(x86) kvm_page_fault and (generic) kvm_host_map structs.  But certainly not
as part of this already huge work.
For kvm_faultin_pfn(), my hope/dream is to make kvm_page_fault a common struct,
with an arch member (a la kvm_vcpu), and get to something like:

  static int arch_page_fault_handler(...)
  {
	struct kvm_page_fault fault = {
		<const common stuff>,

		.arch.xxx = <arch stuff>,
	};

	<arch code>


	r = kvm_faultin_pfn();
	
	...
  }

In theory, that would allow moving the kvm->mmu_invalidate_seq handling, memslot
lookup, etc. into kvm_faultin_pfn(), or maybe another helper that is invoked to
setup the fault structure.  I.e. it would give us a way to drive convergence for
at least some of the fault handling logic, without having to tackle gory arch
details, at least not right away.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help