]> xenbits.xensource.com Git - people/dwmw2/xen.git/commit
x86/hvm/ioreq: use ref-counted target-assigned shared pages
authorPaul Durrant <Paul.Durrant@citrix.com>
Tue, 20 Nov 2018 13:57:38 +0000 (14:57 +0100)
committerJan Beulich <jbeulich@suse.com>
Tue, 20 Nov 2018 13:57:38 +0000 (14:57 +0100)
commite862e6ceb1fd971d755a0c57d6a0f3b8065187dc
tree50ff961bb8fa4a25debc5b14397cbd8489fe53ac
parentf6b6ae78679b363ff670a9c125077c436dabd608
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>
xen/arch/x86/hvm/ioreq.c
xen/arch/x86/mm.c