Ballooning inside PV shim is currently very broken.
From an instrumented Xen and 32bit PV XTF test:
(d3) (d3) --- Xen Test Framework ---
(d3) (d3) Ballooning: PV 32bit (PAE 3 levels)
(d3) (d3) mr { 0010a940, 1024, 0x7ff0 }
(d3) (d3) About to decrease
(d3) (XEN) *** D { ffff820080000020, nr 1020, done 0 }
(d3) (XEN) d3v0 failed to reserve 267 extents of order 0 for offlining
(d3) (XEN) *** D { ffff82007fffe040, nr 1024, done 1020 }
(d3) (XEN) d3v0 failed to reserve 1024 extents of order 0 for offlining
(d3) (d3) => got 1024
This test takes 1024 frames and calls decrease reservation on them,
before unmapping. i.e. the decrease reservation should fail. Shim
successfully offlines 753 pages (nothing to do with the frames the guest
selected), and fails to offline 1291, and despite this, returns success.
First of all, the "failed to reserve" is in pv_shim_offline_memory()
which is a void function that has a semantically relevant failure case.
This obviously isn't ok.
Second, the way the compat code loops over the translated data is
incompatible with how args.nr_done is used for the call into
pv_shim_offline_memory().
Why is pv_shim_offline_memory() not in decrease_reservation() to begin with?
Furthermore, there is a fundamental difference in ballooning behaviour
between PV and HVM guests, which I don't think we can compensate for.
PV guests need to call decrease reservation once to release the frames,
and unmap the frames (in any order). HVM guests calling decrease
reservation automatically make the frame unusable no matter how many
outstanding references exist.
Shim can't decrease reservation (HVM with L0 Xen) on any frame who's
reference count didn't drop to 0 from the PV guests' call, and there is
nothing presently to check this condition.
Short of a PGC bit and extra shim logic in free_domheap_page(), I can't
see any way to reconcile the behaviour, except to change the semantics
of decrease reservation for PV guests. In practice, this would be far
more sensible behaviour, but we have no idea if existing PV guests would
manage.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
