|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/4] tools/tests: Unit test for paging mempool size
On 17.11.2022 02:08, Andrew Cooper wrote:
> Exercise some basic functionality of the new
> xc_{get,set}_paging_mempool_size() hypercalls.
>
> This passes on x86, but fails currently on ARM. ARM will be fixed up in
> future patches.
>
> This is part of XSA-409 / CVE-2022-33747.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Release-acked-by: Henry Wang <Henry.Wang@xxxxxxx>
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
(if this counts anything, since as it stands the new stuff all falls
under tool stack maintainership)
> --- /dev/null
> +++ b/tools/tests/paging-mempool/test-paging-mempool.c
> @@ -0,0 +1,181 @@
> +#include <err.h>
> +#include <errno.h>
> +#include <inttypes.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <sys/mman.h>
> +
> +#include <xenctrl.h>
> +#include <xenforeignmemory.h>
> +#include <xengnttab.h>
> +#include <xen-tools/libs.h>
> +
> +static unsigned int nr_failures;
> +#define fail(fmt, ...) \
> +({ \
> + nr_failures++; \
> + (void)printf(fmt, ##__VA_ARGS__); \
> +})
> +
> +static xc_interface *xch;
> +static uint32_t domid;
> +
> +static struct xen_domctl_createdomain create = {
> + .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
I understand that it is accepted that this test will thus fail when run
on HAP-incapable hardware (including when run with Xen itself running on
top of another hypervisor not surfacing HAP capabilities)? Oh, I notice
you're actually translating EINVAL and EOPNOTSUPP failures into "skip".
That'll probably do, albeit personally I consider skipping when EINVAL
(which we use all over the place) as a overly relaxed.
> +static void run_tests(void)
> +{
> + xen_pfn_t physmap[] = { 0 };
I have to admit that I'm uncertain whether Arm (or other architectures
that Xen is being planned to be ported to) have constraints which may
cause populating of GFN 0 to fail.
> + uint64_t size_bytes, old_size_bytes;
> + int rc;
> +
> + printf("Test default mempool size\n");
> +
> + rc = xc_get_paging_mempool_size(xch, domid, &size_bytes);
> + if ( rc )
> + return fail(" Fail: get mempool size: %d - %s\n",
> + errno, strerror(errno));
> +
> + printf("mempool size %"PRIu64" bytes (%"PRIu64"kB, %"PRIu64"MB)\n",
> + size_bytes, size_bytes >> 10, size_bytes >> 20);
> +
> +
> + /*
> + * Check that the domain has the expected default allocation size. This
> + * will fail if the logic in Xen is altered without an equivelent
Nit: equivalent
> + * adjustment here.
> + */
> + if ( size_bytes != default_mempool_size_bytes )
> + return fail(" Fail: size %"PRIu64" != expected size %"PRIu64"\n",
> + size_bytes, default_mempool_size_bytes);
> +
> +
> + printf("Test that allocate doesn't alter pool size\n");
> +
> + /*
> + * Populate the domain with some RAM. This will cause more of the
> mempool
> + * to be used.
> + */
> + old_size_bytes = size_bytes;
> +
> + rc = xc_domain_setmaxmem(xch, domid, -1);
> + if ( rc )
> + return fail(" Fail: setmaxmem: : %d - %s\n",
> + errno, strerror(errno));
> +
> + rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, physmap);
> + if ( rc )
> + return fail(" Fail: populate physmap: %d - %s\n",
> + errno, strerror(errno));
> +
> + /*
> + * Re-get the p2m size. Should not have changed as a consequence of
> + * populate physmap.
> + */
> + rc = xc_get_paging_mempool_size(xch, domid, &size_bytes);
> + if ( rc )
> + return fail(" Fail: get mempool size: %d - %s\n",
> + errno, strerror(errno));
> +
> + if ( old_size_bytes != size_bytes )
> + return fail(" Fail: mempool size changed %"PRIu64" => %"PRIu64"\n",
> + old_size_bytes, size_bytes);
> +
> +
> +
> + printf("Test bad set size\n");
> +
> + /*
> + * Check that setting a non-page size results in failure.
> + */
> + rc = xc_set_paging_mempool_size(xch, domid, size_bytes + 1);
> + if ( rc != -1 || errno != EINVAL )
> + return fail(" Fail: Bad set size: expected -1/EINVAL, got %d/%d -
> %s\n",
> + rc, errno, strerror(errno));
> +
> +
> + printf("Test very large set size\n");
Maybe drop "very", as 64M isn't all that much (and would, in particular,
not expose any 32-bit truncation issues)?
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |