[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YhZXQOg+5/we5/1g@google.com>
Date: Wed, 23 Feb 2022 15:48:16 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Maxim Levitsky <mlevitsk@...hat.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH v2 08/18] KVM: x86/mmu: do not pass vcpu to root freeing
functions
On Wed, Feb 23, 2022, Maxim Levitsky wrote:
> On Thu, 2022-02-17 at 16:03 -0500, Paolo Bonzini wrote:
> > @@ -1156,7 +1156,7 @@ static void kvm_invalidate_pcid(struct kvm_vcpu *vcpu, unsigned long pcid)
> > if (kvm_get_pcid(vcpu, mmu->prev_roots[i].pgd) == pcid)
> > roots_to_free |= KVM_MMU_ROOT_PREVIOUS(i);
> >
> > - kvm_mmu_free_roots(vcpu, mmu, roots_to_free);
> > + kvm_mmu_free_roots(vcpu->kvm, mmu, roots_to_free);
> > }
> >
> > int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
>
> IMHO anything that is related to guest memory should work on
> VM level (that is struct kvm).
No, because there are plently of per-CPU/vCPU properties that affect physical
memory accesseses. Some of them KVM mostly punts on, e.g. MTRRs and APIC base,
but others are relevant, e.g. SMM.
> It is just ironically sad that writing to a guest page requires
> these days a vCPU due to dirty ring tracking.
I dislike (understatement) that the dirty ring code uses the currently running
vCPU instead of passing it down the stack, but fundamentally all memory accesses
that originate from the "CPU", as opposed to a device or whatever, should be tied
to a vCPU.
Powered by blists - more mailing lists