x86/PoD: correctly handle non-order-0 decrease-reservation requests
authorJan Beulich <jbeulich@suse.com>
Fri, 19 Jan 2018 10:14:42 +0000 (11:14 +0100)
committerJan Beulich <jbeulich@suse.com>
Fri, 19 Jan 2018 10:14:42 +0000 (11:14 +0100)
commit7867181b2ad63f0d2f1ba97598e577538b83882f
treefefdf0156d67bc5bdfe29c2857f20fc1cc773234
parent75c47ae9b63483ac404ea7e4a28cb5fb1d989ef8
x86/PoD: correctly handle non-order-0 decrease-reservation requests

p2m_pod_decrease_reservation() at the moment only returns a boolean
value: true for "nothing more to do", false for "something more to do".
If it returns false, decrease_reservation() will loop over the entire
range, calling guest_remove_page() for each page.

Unfortunately, in the case p2m_pod_decrease_reservation() succeeds
partially, some of the memory in the range will be not-present; at which
point guest_remove_page() will return an error, and the entire operation
will fail.

Fix this by:
1. Having p2m_pod_decrease_reservation() return exactly the number of
   gpfn pages it has handled (i.e., replaced with 'not present').
2. Making guest_remove_page() return -ENOENT in the case that the gpfn
   in question was already empty (and in no other cases).
3. When looping over guest_remove_page(), expect the number of -ENOENT
   failures to be no larger than the number of pages
   p2m_pod_decrease_reservation() removed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen/arch/arm/p2m.c
xen/arch/x86/mm/p2m-pod.c
xen/common/memory.c
xen/include/xen/p2m-common.h