|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [hybrid]: code review for function mapping pfn to foreign mfn
On Thu, 2012-04-19 at 00:29 +0100, Mukesh Rathor wrote:
> On Tue, 17 Apr 2012 10:05:28 +0100
> Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>
> > On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> > > On Mon, 16 Apr 2012 14:53:22 +0100
> > > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >
> > Sorry, I meant why a whole new subcall instead of a new
> > XENMAPSPACE ;-)
> >
> > e.g. On ARM I did:
> >
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 86d02c8..b2adfbe 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
> > uint16_t size;
> >
> > /* Source mapping space. */
> > -#define XENMAPSPACE_shared_info 0 /* shared info page */
> > -#define XENMAPSPACE_grant_table 1 /* grant table page */
> > -#define XENMAPSPACE_gmfn 2 /* GMFN */
> > -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */
> > - unsigned int space;
> > +#define XENMAPSPACE_shared_info 0 /* shared info page */
> > +#define XENMAPSPACE_grant_table 1 /* grant table page */
> > +#define XENMAPSPACE_gmfn 2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > + uint16_t space;
> > + domid_t foreign_domid; /* IFF gmfn_foreign */
>
>
> Well, for several reasons, I didn't use it, mainly, it doesn't allow
> for count. So requests have to come in one frame at a time.
I've got it that way on ARM too at the moment but I was planning to make
it behave like gmfn_range and use the size parameter to map multiple at
a time (unless I've misunderstood what the gmfn_range variant does).
> Second, none of the common code can be used by my new request,
I don't think that's an impediment to the API, XENMAPSPACE_gmfn_foreign
is in pretty much the same position.
> because:
> - frame is not removed from foreign domain in my case
> - i don't want to update the m2p with new info.
>
> Anyways, I put it there for now. With ballooning change in dom0, I'm
> now doing the hcall one frame at a time anyways. We can always enhance
> in the future.
>
> case XENMAPSPACE_gmfn_foreign:
> {
> rc = _add_foreign_to_pmap_batch(&xatp);
> rcu_unlock_domain(d);
> return rc;
> }
>
>
> >> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
> >> arg)
>
> >Can't XENMEM_remove_from_physmap be used here?
>
> Well, that calls guest_physmap_remove_page() which calls
> p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
> i just need to remove from the dom0 p2m and leave M2P as is (mfn to
> domU gmfn). I could add a flag to the struct causing it to just call
> set_p2m_entry() directly?
Would it be useful to track the fact that a p2m entry is foreign
somewhere? That would let you do the appropriate type of teardown etc
without relying on the tools to get it right.
Are there s/w bits available in the p2m entry itself on x86 or do we use
them all already?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |