On 25/03/21 23:25, Sean Christopherson wrote:
On Thu, Mar 25, 2021, Ben Gardon wrote:
On Thu, Mar 25, 2021 at 1:01 PM Sean Christopherson wrote:
+static inline bool kvm_tdp_mmu_zap_gfn_range(struct kvm *kvm, gfn_t start,
+gfn_t end)
+{
+
On 25/03/21 23:45, Ben Gardon wrote:
I think in an earlier version of the TDP that I sent out, NX reclaim
was a seperate thread for the two MMUs, sidestepping the balance
issue.
I think the TDP MMU also had a seperate NX reclaim list.
That would also make it easier to do something under the read
On 25/03/21 23:25, Sean Christopherson wrote:
I don't have a super strong preference. One thought would be to
assert that mmu_lock is held for write, and then it largely come
future person's problem:-)
Well that is what I was going to suggest. Let's keep things as simple
as possible for the
On Thu, Mar 25, 2021 at 3:25 PM Sean Christopherson wrote:
>
> On Thu, Mar 25, 2021, Ben Gardon wrote:
> > On Thu, Mar 25, 2021 at 1:01 PM Sean Christopherson
> > wrote:
> > > +static inline bool kvm_tdp_mmu_zap_gfn_range(struct kvm *kvm, gfn_t
> > > start,
> > > +
On Thu, Mar 25, 2021, Ben Gardon wrote:
> On Thu, Mar 25, 2021 at 1:01 PM Sean Christopherson wrote:
> > +static inline bool kvm_tdp_mmu_zap_gfn_range(struct kvm *kvm, gfn_t start,
> > +gfn_t end)
> > +{
> > + return
On Thu, Mar 25, 2021 at 1:01 PM Sean Christopherson wrote:
>
> Prevent the TDP MMU from yielding when zapping a gfn range during NX
> page recovery. If a flush is pending from a previous invocation of the
> zapping helper, either in the TDP MMU or the legacy MMU, but the TDP MMU
> has not
Prevent the TDP MMU from yielding when zapping a gfn range during NX
page recovery. If a flush is pending from a previous invocation of the
zapping helper, either in the TDP MMU or the legacy MMU, but the TDP MMU
has not accumulated a flush for the current invocation, then yielding
will release
7 matches
Mail list logo
