x86/hvm/ioreq: use ref-counted target-assigned shared pages
authorPaul Durrant <paul.durrant@citrix.com>
Tue, 20 Nov 2018 14:31:48 +0000 (15:31 +0100)
committerJan Beulich <jbeulich@suse.com>
Tue, 20 Nov 2018 14:31:48 +0000 (15:31 +0100)
commitb88ccb3ae79decfa495ae965c02aeedc8fda2bcb
tree419d3b7292feb870c3c6ad15c4c664d2ef866793
parent3b2a779ccb9fd3c02ab2a68cb95a9628f0837029
x86/hvm/ioreq: use ref-counted target-assigned shared pages

Passing MEMF_no_refcount to alloc_domheap_pages() will allocate, as
expected, a page that is assigned to the specified domain but is not
accounted for in tot_pages. Unfortunately there is no logic for tracking
such allocations and avoiding any adjustment to tot_pages when the page
is freed.

The only caller of alloc_domheap_pages() that passes MEMF_no_refcount is
hvm_alloc_ioreq_mfn() so this patch removes use of the flag from that
call-site to avoid the possibility of a domain using an ioreq server as
a means to adjust its tot_pages and hence allocate more memory than it
should be able to.

However, the reason for using the flag in the first place was to avoid
the allocation failing if the emulator domain is already at its maximum
memory limit. Hence this patch switches to allocating memory from the
target domain instead of the emulator domain. There is already an extra
memory allowance of 2MB (LIBXL_HVM_EXTRA_MEMORY) applied to HVM guests,
which is sufficient to cover the pages required by the supported
configuration of a single IOREQ server for QEMU. (Stub-domains do not,
so far, use resource mapping). It also also the case the QEMU will have
mapped the IOREQ server pages before the guest boots, hence it is not
possible for the guest to inflate its balloon to consume these pages.

Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
master commit: e862e6ceb1fd971d755a0c57d6a0f3b8065187dc
master date: 2018-11-20 14:57:38 +0100
xen/arch/x86/hvm/ioreq.c
xen/arch/x86/mm.c