From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour Date: Thu, 04 Dec 2014 15:54:30 +0000 Message-ID: <548083B6.8010408@linaro.org> References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com> <1417626981-8432-5-git-send-email-vkuznets@redhat.com> <547FAFDD.8010005@linaro.org> <87wq67h2iu.fsf@vitty.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwYjm-0005oO-9v for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:54:38 +0000 Received: by mail-wi0-f169.google.com with SMTP id r20so36796600wiv.0 for ; Thu, 04 Dec 2014 07:54:36 -0800 (PST) In-Reply-To: <87wq67h2iu.fsf@vitty.brq.redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vitaly Kuznetsov Cc: Wei Liu , Andrew Jones , Keir Fraser , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 04/12/14 15:12, Vitaly Kuznetsov wrote: > Julien Grall 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 >>> --- >>> @@ -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