Re: [Xen-devel] [PATCH] x86: expose XENMEM_get_pod_target to subject domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.02.14 at 18:24, George Dunlap <dunlapg@xxxxxxxxx> wrote:
> On Mon, Feb 24, 2014 at 1:31 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> Not having got any satisfactory suggestions on the inquiry on how to
>> determine the amount a PoD guest needs to balloon down by (see
>> http://lists.xenproject.org/archives/html/xen-devel/2014-01/msg01524.html 
>> and the thread following it), expose XENMEM_get_pod_target such that
>> the guest can use it for this purpose.
> 
> So in theory the bug you're seeing has nothing to do with PoD -- it
> just has to do with a different interpretation that the balloon driver
> and Xen may have as to what "target" means.  Is that right?  The only
> difference is that in the PoD case, not ballooning down enough can be
> deadly to the domain; whereas in the non-PoD case, the worst that can
> happen is that the toolstack has less memory left over on the host
> than it may have expected.

To me this is very much a dependency on whether PoD is in use,
precisely because of the deadliness of ballooning out too little in
that case.

> I don't like the idea of exposing specific PoD information to the
> guest -- PoD should be completely transparent to the guest.  If we
> make it PoD-specific, we may end up with a different sized domain
> depending on whether we booted with PoD mode or not.
> 
> Is the real problem that there's no way to determine the number of
> potentially non-empty pfn ranges?  If we exposed the number of
> non-empty p2m ranges (either ram or PoD), then the guest could compare
> that to the target and balloon down as necessary, no?

The only thing the guest really cares about from this hypercall is
the result of

.tot_pages + .pod_entries - .pod_cache_pages

so exposing anything to the guest that allows it to calculate this
value would be sufficient. It just seems odd to me to invent
something new if we already have what we need, as long as
exposing that information as individual pieces (instead of the
accumulated result) is not a security risk.

Anyway, I also consider it odd to complain about this now when
the referenced discussion has happened weeks ago, with no
useful result.

>> Also leverage some cleanup potential resulting from this change.
> 
> Cleanup should generally be done in separate patches, so that one
> change can be reviewed at a time.

Honestly I think that's a matter of taste - I personally dislike leaving
unclean code in place when the cleanup isn't harmful to the actual
change's understandability. Of course larger cleanup actions should
go by themselves.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel