The design of the memory populate-on-demand (PoD) system requires that
a guest's memory ballooning driver reach its memory reduction target.
The target is not entirely well-defined in terms of the information
visible to the appropriate parts of the system, so some unknown set of
guests (but probably most guests) will fail this criterion.
If the guest memory balloon driver does not free sufficient memory to
reach its target, the guest will proceed to run with a nonzero number
of outstanding PoD pages. When the guest or management toolstack
touches such a page, the hypervisor would search the guest memory for
a page containing only zeroes.
If no such page is found, the guest crashes. Prior to the patch for
XSA-150, the search might lock up the relevant physical cpu for a
while. After the patch to XSA-150, it might crash the guest even if a
suitable zero page is available.
This means that in the current arrangements toolstack software must
apply an adjustment to a guest's PoD target as supplied to Xen.
Neither xend nor libxl do this. Guests configured with PoD might be
unstable, especially under load.
Reducing the guest's memory target, after guest startup, can cause the
guest's ballon driver to eliminate the PoD discrepancy. If the guest
successfully balloons down, it will no longer be vulnerable.
Created xen tracking bugs for this issue:
Affects: fedora-all [bug 1276344]
xen-4.5.1-14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
xen-4.5.1-14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
xen-4.4.3-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.