Oops, sorry, fat fingers... second try with guest code:
==========
OK, thanks! Sorry to belabour this further, but getting
this wrong has resulted in dom0 data corruption so I'm
trying to get it right this time :-)
> Xen doesn't do pfn-to-mfn translation for PV guests...
So there's no way to do this from inside Xen then?
Then I gather I need to be passing an mfn to Xen instead
of a gpfn. To do so, it looks like I call pfn_to_mfn()
in the paravirtualized guest. But how can this work
on a 32-bit-PV-on-64-bit-Xen since pfn_to_mfn() returns
an unsigned long?
Also, once I've got an (pvguest-translated-gpfn-to-) mfn
inside of Xen, do I still do a gfn_to_mfn() on it?
(Shouldn't matter because it just returns the gfn, right?)
I've now tried various combinations of these with known
data in the page being passed by the pv guest, but the
wrong data is found on the xen side, so I'm clearly
still missing something.
BTW, all this works when passing the page as a guest
virtual address, but the virtual addresss of the page
isn't always accessible on the guest side.
Guest side:
unsigned long mfn = pfn_to_mfn(page_to_pfn(page));
void *va = PageHighMem(page) ? page_address(page) :
lowmem_page_address(page);
if (!va) return 0;
else *(uint32_t *)va == 0x12345678;
return my_hypercall(hcache_id, obj, ind, mfn);
Xen side:
if (is_pv_32on64_vcpu(current))
gpfn.p = (void *)((unsigned long)gpfn.p & 0xfffffUL);
dst_mfn = page_to_mfn(xen_page);
guest_mfn = gfn_to_mfn(current->domain,
(unsigned long)gpfn.p,&t);
if (!p2m_is_ram(t))
{
bad_addr_copies++;
printk("bad copy_from_guest: "
"gpfn=%lu mfn=%lu\n",
(unsigned long)gpfn.p,guest_mfn);
return 0;
}
dst_va = map_domain_page(dst_mfn);
guest_va = map_domain_page(guest_mfn);
i = __copy_from_user(dst_va, guest_va, PAGE_SIZE);
if (i)
printk("copy_from_guest failed:"
" gpfn=%lu mfn=%lu va=%p\n",
(unsigned long)gpfn.p,guest_mfn,guest_va);
if (*(uint32_t *)guest_va != 0x12345678)
printk("copy_from_guest bad data:"
" gpfn=%lu mfn=%lu va=%p\n"
(unsigned long)gpfn.p,guest_mfn,guest_va);
unmap_domain_page(guest_va);
unmap_domain_page(dst_va);
> > -----Original Message-----
> > From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> > Sent: Monday, September 29, 2008 2:12 PM
> > To: Dan Magenheimer; Xen-Devel (E-mail); Tian, Kevin
> > Subject: Re: [Xen-devel] guest physical to xen machine copy?
> >
> >
> > On 29/9/08 19:50, "Dan Magenheimer"
> > <dan.magenheimer@xxxxxxxxxx> wrote:
> >
> > > Hmmm... gfn_to_mfn() when used as below seems to just
> > > return the original gfn, e.g.
> > >
> > > guest_mfn = gfn_to_mfn(current->domain,gpfn,&t);
> > >
> > > Is this correct? Note that current->domain is a 32-bit
> > > paravirtualized domain and xen is 64-bit, if that matters.
> > > (Is there a better way if one knows that the domain is
> > > always pv?)
> >
> > Xen doesn't do pfn-to-mfn translation for PV guests. They do
> > it themselves
> > with their own p2m table. So, for a PV guest, gfn==mfn.
> >
> > >> Use p2m_is_ram() instead of checking individual p2m ram type
> > >
> > > In copying the other direction (e.g. copy_page_TO_guest),
> > > I think I need to check for t==p2m_ram_rw, right?
> >
> > You need to check for not p2m_ram_ro. You also should
> > page_mark_dirty()
> > (__hvm_copy() does it unconditionally on pages it modifies).
> >
> > -- Keir
> >
> > > If so, the "Not necessarily true" comment in static
> > > inline _gfn_to_mfn in include/asm-x86/p2m.h worries me.
> > > Should it?
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home