WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

<Prev in Thread] Current Thread [Next in Thread>