Re: [Xen-devel] Re: pv_ops & gntdev?

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>   
> > Jeremy Fitzhardinge wrote:
> >     
> > > Do you have a test program?
> > >       
>   
> > usage:
> > qemu -M xenpv -xen-create -uuid $(uuidgen) \
> >   -kernel <bzImage> -initrd <initrd> \
> >   -drive media=disk,if=xen,file=<diskimage> \
> >   -net nic,model=xen,macaddr=<addr> \
> >   -serial <yourconsolehere>
> >     
> "-m 256" is needed too.
>
>   
> > > > +    BUG_ON(pgnr >= map->count);
> > > > +    mpte  = (u64)pfn_to_mfn(page_to_pfn(token)) << PAGE_SHIFT;
> > > > +    mpte |= (unsigned long)pte & ~PAGE_MASK;
> > > >   
> > > >         
> > > (!) You're casting pte_t * to unsigned long, masking off the lower bits
> > > then oring them into your pte.  That doesn't look like it will mean very
> > > much...  I guess this explains your not-unmapping bug.
> > >
> > > This should probably be using mfn_pte() anyway:
> > >
> > >     mfn = pfn_to_mfn(page_to_pfn(token));
> > >     pgprot = __pgprot(pte->pte & PTE_FLAGS_MASK);
> > >     mpte = mfn_pte(mfn, pgprot);
> > >       
> > Looks better indeed.  Unclean stuff carried over from 2.6.18 ...
> >     
> Well, no.  mpte (bad name indeed) isn't a pte, but the *pointer*
> (machine address) to the pte.
>   
Yes, but it *looks* better ;) Yes, my "cleanup" will have screwed up the 
actual functional parts in that case.   Hiding the PAGE_MASK in a 
tactical application of PAGE_OFFSET will probably help make it clearer.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel