Re: [PATCH v2 1/10] KVM MMU: fix for calculating gpa in invlpg code

[Avi Kivity]

On 04/26/2010 06:10 AM, Xiao Guangrong wrote:
> Avi Kivity wrote:
>    
> > On 04/25/2010 10:00 AM, Xiao Guangrong wrote:
> >      
> > > If the guest is 32-bit, we should use 'quadrant' to adjust gpa
> > > offset
> > >
> > > Changlog v2:
> > > - when level is PT_DIRECTORY_LEVEL, the 'offset' should be
> > >     'role.quadrant<<   8', thanks Avi for point it out
> > >
> > > Signed-off-by: Xiao Guangrong<xiaoguangrong@xxxxxxxxxxxxxx>
> > > ---
> > >    arch/x86/kvm/paging_tmpl.h |   13 +++++++++++--
> > >    1 files changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
> > > index d0cc07e..83cc72f 100644
> > > --- a/arch/x86/kvm/paging_tmpl.h
> > > +++ b/arch/x86/kvm/paging_tmpl.h
> > > @@ -478,9 +478,18 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu,
> > > gva_t gva)
> > >                ((level == PT_DIRECTORY_LEVEL&&   is_large_pte(*sptep))) ||
> > >                ((level == PT_PDPE_LEVEL&&   is_large_pte(*sptep)))) {
> > >                struct kvm_mmu_page *sp = page_header(__pa(sptep));
> > > -
> > > +            int offset = 0;
> > > +
> > > +            if (PTTYPE == 32) {
> > > +                if (level == PT_DIRECTORY_LEVEL)
> > > +                    offset = PAGE_SHIFT - 4;
> > > +                else
> > > +                    offset = PT64_LEVEL_BITS;
> > > +                offset = sp->role.quadrant<<   offset;
> > > +            }
> > >
> > >        
> > The calculation is really
> >
> >    shift = (PT32_LEVEL_BITS - PT64_LEVEL_BITS) * level;
> >
> >      
> So, the offset is q<<  (PAGE_SHIFT - (PT32_LEVEL_BITS - PT64_LEVEL_BITS) * level - 2)?
>    

Ugh, what I meant was

  shift = PAGE_SHIFT - (PT_LEVEL_BITS - PT64_LEVEL_BITS) * level;
  offset  = q << shift

so,

  pte_gpa = (sp->gfn << PAGE_SHIFT) + offset + (spte - sp->spt) * 
sizeof(pt_element_t)

No magic numbers please.  Note it could work without the 'if (PTTYPE == 
32)'.


--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/