[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.