[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
On 04/12/14 15:12, Vitaly Kuznetsov wrote: > Julien Grall <julien.grall@xxxxxxxxxx> writes: > >> Hi Vitaly, >> >> On 03/12/2014 17:16, Vitaly Kuznetsov wrote: >>> New operation sets the 'recipient' domain which will recieve all >> >> s/recieve/receive/ >> >>> memory pages from a particular domain and kills the original domain. >>> >>> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> >>> --- >>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, >>> unsigned int order) >> >> [..] >> >>> + else >>> + { >>> + mfn = page_to_mfn(pg); >>> + gmfn = mfn_to_gmfn(d, mfn); >>> + >>> + page_set_owner(pg, NULL); >>> + if ( assign_pages(d->recipient, pg, order, 0) ) >>> + /* assign_pages reports the error by itself */ >>> + goto out; >>> + >>> + if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) ) >> >> On ARM, mfn_to_gmfn will always return the mfn. This would result to >> add a 1:1 mapping in the recipient domain. >> >> But ... only DOM0 has its memory mapped 1:1. So this code may blow up >> the P2M of the recipient domain. > > I know almost nothing about ARM so please bear with me. So, for a guest > domain the mapping is not 1:1 (so guest sees different addresses) but > mfn_to_gmfn() doesn't returs these addresses? Yes. I guess it's because this macro is not really used (see why below). Ian, Stefano: any idea why mfn_to_gfmn is not correctly implemented on ARM? > I was under an impression > it is not x86-specific and I can see its usage in e.g. getdomaininfo(), > memory_exchange(),.. I can find two places in the common code: - getdomaininfo: The return is obviously buggy. Though, it doesn't seem to be used in the toolstack side for ARM - memory_exchange: AFAIK this is not supported right now. > How can one figure out the mapping then? AFAIK, there is no way on ARM to get a GMFN from an MFN in Xen. Maybe we should implement it correctly mfn_to_gmfn on ARM? Ian, Stefano, any though? > Anyway, what I want to do here is: when this page is freed I want to > reassign it to our newly-created guest at the exact same address it was > mapped in the original domain. > BTW, what's the current state of affairs with kexec and ARM guest? AFAIK, nobody has worked on it for Xen ARM. I don't even know the status for Kexec on ARM. > I > suppose we should have similar problems: vcpu_info, event channels, > .. ARM guest is very similar to PVH guest. All the problems you will fixed now means less work when we will add support for ARM ;). Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |