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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191121144528.GB17169@local-michael-cet-test>
Date:   Thu, 21 Nov 2019 22:45:28 +0800
From:   Yang Weijiang <weijiang.yang@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Yang Weijiang <weijiang.yang@...el.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, jmattson@...gle.com,
        sean.j.christopherson@...el.com, yu.c.zhang@...ux.intel.com,
        alazar@...defender.com, edwin.zhai@...el.com
Subject: Re: [PATCH v7 4/9] mmu: spp: Add functions to create/destroy SPP
 bitmap block

On Thu, Nov 21, 2019 at 11:43:10AM +0100, Paolo Bonzini wrote:
> On 19/11/19 09:49, Yang Weijiang wrote:
> >  
> > +/*
> > + * all vcpus share the same SPPT, vcpu->arch.mmu->sppt_root points to same
> > + * SPPT root page, so any vcpu will do.
> > + */
> > +static struct kvm_vcpu *kvm_spp_get_vcpu(struct kvm *kvm)
> > +{
> > +	struct kvm_vcpu *vcpu = NULL;
> > +	int idx;
> 
> Is this true?  Perhaps you need one with
> VALID_PAGE(vcpu->arch.mmu->sppt_root) for kvm_spp_set_permission?
>
Yes, I'd like to keep single sppt_root, thank you!

> Also, since vcpu->arch.mmu->sppt_root is the same for all vCPUs, perhaps
> it should be kvm->arch.sppt_root instead?
>
Sure, make sense, will change it.

> If you can get rid of this function, it would be much better (but if you
> cannot, kvm_get_vcpu(kvm, 0) should give the same result).
>
Great, I was not sure if such usage is correct. Thanks.

> > 
> > +	if (npages > SUBPAGE_MAX_BITMAP)
> > +		return -EFAULT;
> 
> This is not needed here, the restriction only applies to the ioctl.
>
OK.
> Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ