From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
George Dunlap <george.dunlap@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] tools: libxl: do not set the PoD target on ARM
Date: Tue, 28 Jan 2014 14:48:00 +0000 [thread overview]
Message-ID: <52E7C320.7080402@eu.citrix.com> (raw)
In-Reply-To: <1390919466.7753.97.camel@kazak.uk.xensource.com>
On 01/28/2014 02:31 PM, Ian Campbell wrote:
> On Tue, 2014-01-28 at 14:28 +0000, George Dunlap wrote:
>> On Tue, Jan 28, 2014 at 10:47 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> On Thu, 2014-01-16 at 15:27 +0000, Ian Campbell wrote:
>>>> ARM does not implemented PoD and so returns ENOSYS from XENMEM_set_pod_target.
>>>>
>>>> The correct solution here would be to check for ENOSYS in libxl, unfortunately
>>>> xc_domain_set_pod_target suffers from the same broken error reporting as the
>>>> rest of libxc and throws away the errno.
>>>>
>>>> So for now conditionally define xc_domain_set_pod_target to return success
>>>> (which is what PoD does if nothing needs doing). xc_domain_get_pod_target sets
>>>> errno==-1 and returns -1, which matches the broken error reporting of the
>>>> existing function. It appears to have no in tree callers in any case.
>>>>
>>>> The conditional should be removed once libxc has been fixed.
>>>>
>>>> This makes ballooning (xl mem-set) work for ARM domains.
>>>>
>>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>>> Cc: george.dunlap@citrix.com
>>>> ---
>>>> I'd be generally wary of modifying the error handling in a piecemeal way, but
>>>> certainly doing so for 4.4 now would be inapropriate.
>>>>
>>>> IIRC Ian J was planning a thorough sweep of the libxc error paths in 4.5 time
>>>> frame, at which point this conditional stuff could be dropped.
>>>>
>>>> In terms of the 4.4 release, obviously ballooning would be very nice to have
>>>> for ARM guests, on the other hand I'm aware that while the patch is fairly
>>>> small/contained and safe it is also pretty skanky and likely wouldn't be
>>>> accepted outside of the rc period.
>>>
>>> George -- what do you think of this?
>>
>> So is this actually called in the arm domain build code at the moment?
>
> It is common code in libxl which calls into it. I originally had the
> ifdef there instead.
>
> (I've just noticed that I forgot to update $subject when I moved the
> #ifdef from libxl to libxc)
Oh, right -- yes, you normally need to call set_pod_target() every time
you update the balloon target, just in case PoD mode was activated on
boot; if it wasn't (or if all the PoD entries have gone away) this will
be a noop.
The only conceptual issue with putting it here is that
xc_domain_set_pod_target() is also called during domain creation to fill
the PoD "cache" with the domain's memory, from which to populate the p2m
on-demand. So if "someone" were to try to add PoD to the ARM guest
creation, and forgot about this hack, they might spend a bit of time
figuring out why the initial call to fill the PoD cache was succeeding
but the guest was crashing with "PoD empty cache" anyway.
(xc_domain_set_target behaves differently if there are no entries in the
p2m than if there are: if the p2m is empty, it will respond to this by
filling the cache; if it's non-empty, it will ignore changes if there
are no outstanding p2m entries. That made sense at the time, but now it
looks like a bit of an interface trap for the unwary...)
Was there a reason to put this in libxc rather than libxc? We don't
expect anyone to call libxc, so having it libxc isn't a big deal, but
conceptually it would probably be safer in libxl.
-George
next prev parent reply other threads:[~2014-01-28 14:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 15:27 [PATCH] tools: libxl: do not set the PoD target on ARM Ian Campbell
2014-01-28 10:47 ` Ian Campbell
2014-01-28 14:28 ` George Dunlap
2014-01-28 14:31 ` Ian Campbell
2014-01-28 14:48 ` George Dunlap [this message]
2014-01-28 14:50 ` George Dunlap
2014-01-28 15:03 ` Ian Campbell
2014-01-28 15:24 ` George Dunlap
2014-02-04 15:04 ` Ian Jackson
2014-02-04 15:26 ` Julien Grall
2014-02-04 15:43 ` Ian Campbell
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=52E7C320.7080402@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@linaro.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).