From: Julien Grall <julien.grall@linaro.org>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
David Vrabel <david.vrabel@citrix.com>,
Jan Beulich <jbeulich@suse.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
Date: Thu, 04 Dec 2014 15:54:30 +0000 [thread overview]
Message-ID: <548083B6.8010408@linaro.org> (raw)
In-Reply-To: <87wq67h2iu.fsf@vitty.brq.redhat.com>
On 04/12/14 15:12, Vitaly Kuznetsov wrote:
> Julien Grall <julien.grall@linaro.org> 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@redhat.com>
>>> ---
>>> @@ -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
next prev parent reply other threads:[~2014-12-04 15:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 17:16 [PATCH v4 0/9] toolstack-based approach to pvhvm guest kexec Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 1/9] xen: introduce DOMDYING_locked state Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 2/9] xen: introduce SHUTDOWN_soft_reset shutdown reason Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 3/9] libxl: support " Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour Vitaly Kuznetsov
2014-12-04 0:50 ` Julien Grall
2014-12-04 10:19 ` David Vrabel
2014-12-04 10:52 ` Julien Grall
2014-12-04 15:12 ` Vitaly Kuznetsov
2014-12-04 15:54 ` Julien Grall [this message]
2014-12-04 11:01 ` Julien Grall
2014-12-04 14:48 ` Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 5/9] libxc: support XEN_DOMCTL_devour Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 6/9] libxl: add libxl__domain_soft_reset_destroy_old() Vitaly Kuznetsov
2014-12-04 16:20 ` Wei Liu
2014-12-03 17:16 ` [PATCH v4 7/9] libxc: introduce soft reset for HVM domains Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 8/9] libxl: soft reset support Vitaly Kuznetsov
2014-12-04 16:01 ` Wei Liu
2014-12-05 10:45 ` Vitaly Kuznetsov
2014-12-03 17:16 ` [PATCH v4 9/9] xsm: add XEN_DOMCTL_devour support Vitaly Kuznetsov
2014-12-04 11:17 ` [PATCH v4 0/9] toolstack-based approach to pvhvm guest kexec Olaf Hering
2014-12-04 14:29 ` Vitaly Kuznetsov
2014-12-04 11:55 ` Wei Liu
2014-12-04 14:46 ` Vitaly Kuznetsov
2014-12-04 15:08 ` Wei Liu
2014-12-11 14:24 ` Olaf Hering
2014-12-11 15:24 ` David Vrabel
2014-12-11 15:30 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=548083B6.8010408@linaro.org \
--to=julien.grall@linaro.org \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=drjones@redhat.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=vkuznets@redhat.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.