From: George Dunlap <george.dunlap@citrix.com>
To: "Zhang, Chunyu" <zhangcy@cn.fujitsu.com>,
"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
"keir@xen.org" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] delte PAGE_ORDER_1G in pod
Date: Tue, 26 Apr 2016 12:12:41 +0100 [thread overview]
Message-ID: <571F4D29.4050501@citrix.com> (raw)
In-Reply-To: <A43879EB4A7F5F449E2CA8148EA79E51FE7FCF51@G08CNEXMBPEKD01.g08.fujitsu.local>
On 26/04/16 12:05, Zhang, Chunyu wrote:
>
>> On 26/04/16 11:49, Zhang, Chunyu wrote:
>>>
>>>> On 26/04/16 08:27, zhangcy wrote:
>>>>> PoD does not have cache list for 1GB pages.
>>>>>
>>>>> Signed-off-by: zhangcy <zhangcy@cn.fujitsu.com>
>>>>
>>>> Thanks for the patch. FYI we normally tag the area in the title in a
>>>> structured way; I probably would have used something like the following:
>>>>
>>>> xen/pod: Remove code handling PAGE_ORDER_1G from p2m_pod_cache_add
>>> got it, thanks.
>>>>
>>>> But with regards to the patch itself: The question isn't whether we have
>>>> a cache list for 1G pages; the question is whether p2m_pod_cache_add()
>>>> will ever be called with order == PAGE_ORDER_1G.
>>>>
>>>> Taking a quick glance around, it looks like in theory if a guest called
>>>> decrease_reservation with order == PAGE_ORDER_1G, you could conceivably
>>>> get to p2m_pod_cache_add() with order == PAGE_ORDER_1G.
>>> i just think like this:
>>>
>>> p2m_pod_decrease_reservation
>>> - if ( steal_for_cache && p2m_is_ram(t) )
>>> - p2m_pod_cache_add(p2m, page, cur_order)
>>> i think p2m_is_ram(t) , ram also from pod cache,
>>
>> No, that's memory from the guest's p2m table. The p2m table can have 1G
> right..
> sorry , i did not write clearly.
> i mean: ram come like this:
> - pod cache is 4K or 2M
> - ram get from pod cache
> - set ram to p2m table.
> so i think p2m table is 4K or 2M.
Oh, right, I see -- a guest booted in PoD mode would normally only have
2M or 4k entries, since that's how they get filled in.
But there's nothing preventing someone coming up with a new domain
builder that comes with some 1G entries filled in already. Nor is there
anything stopping a guest ballooning out a 1G region, then ballooning it
back in (hoping to get a full 1G entry), and then ballooning it out
again, causing Xen to potentially leak memory.
I haven't checked to see whether any of that is actually feasible or
not, but four lines of code is a small price to pay to not have to worry
about it. :-)
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-26 11:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 7:27 [PATCH] delte PAGE_ORDER_1G in pod zhangcy
2016-04-26 8:33 ` Jan Beulich
2016-04-26 8:41 ` Zhang, Chunyu
2016-04-26 10:23 ` George Dunlap
2016-04-26 10:49 ` Zhang, Chunyu
2016-04-26 10:57 ` George Dunlap
2016-04-26 11:05 ` Zhang, Chunyu
2016-04-26 11:12 ` George Dunlap [this message]
2016-04-26 11:48 ` Zhang, Chunyu
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=571F4D29.4050501@citrix.com \
--to=george.dunlap@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
--cc=zhangcy@cn.fujitsu.com \
/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.