Re: [libvirt] [PATCH 5/5] tests: add qemuxml2argv memfd-memory-numa test

Hi On Tue, Sep 11, 2018 at 5:21 PM, John Ferlan <jferlan(a)redhat.com&gt; wrote: > > [...] > >>>> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c >>>> index 35df63b2ac..76008a8d07 100644 >>>> --- a/tests/qemuxml2argvtest.c >>>> +++ b/tests/qemuxml2argvtest.c >>>> @@ -2928,6 +2928,11 @@ mymain(void) >>>> DO_TEST("fd-memory-no-numa-topology", QEMU_CAPS_OBJECT_MEMORY_FILE, >>>> QEMU_CAPS_KVM); >>>> >>>> + DO_TEST("memfd-memory-numa", >>>> + QEMU_CAPS_OBJECT_MEMORY_MEMFD, >>>> + QEMU_CAPS_OBJECT_MEMORY_MEMFD_HUGETLB, >>>> + QEMU_CAPS_KVM); >>>> + >>> >>> Theoretically, if we have 3.1 capabilties to test against, then this >>> would use a DO_TEST_CAPS_LATEST, while a "pre-3.1" would still be using >>> -ramfd, right? That is, using DO_TEST_CAPS_VER w/ "3.0.0" would >>> generate different results. >>> >>> I'm conflicted if we should wait for someone to generate the 3.1 caps or >>> not. For whatever reason, when I post them they're not quite right for >>> someone else's tastes... >>> >>> Let's see if anyone else has strong feelings one way or another. >>> >> >> -memfd is available since 2.12. After patch 1 & 2 are applied, we >> should probably switch to use DO_TEST_CAPS_LATEST. >> > > Theoretically patches 3, 4, and 5 could be one patch, but having > separate also works well for review purposes! > > While MEMFD is there is the HUGETLB and comment in page 2 about QEMU 3.1 > that is what I was concerned with, especially since 2.12 and 3.0 find > the value... > > Looking at the QEMU sources, I see you added the field in commit > dbb9e0f40, which is 2.12 based. It's added in 2.12: git describe --contains --match=v2* dbb9e0f40 v2.12.0-rc0~107^2~8 However, only with upcoming patch for 3.1 (queued by Paolo today) will the hugetlb properties be run-time checked/exposed. > Still reading deeper into the comments in patch 2, it just seems that > @hugetlbsize has some sort run-time issue that gets fixed by 3.1. Harder It's not an issue, but it will help libvirt to figure out before starting qemu if anonymous memfd hugetlb is supported. > for libvirt to detect that an issue exists unless something was added in > 3.1 that libvirt could test on for a capability. I'm not sure what the > issue is, but maybe that's something document-able at least with respect > to what values are provided in the XML for memoryBacking. If you request anonymous memory & hugetlb today, you have a libvirt error. With the series, if the host/qemu doesn't support it, you will get an error.

https://libvirt.org/formatdomain.html#elementsMemoryBacking There is no documentation about the file memory backing requirement today (it seems). We could explain it and add that a memfd-hugetlb-capable doesn't need it (when there is no numa assignment). Is this what you are asking?

> > > John > >> Before 2.12 (or if the capabilities are not exposed by the host qemu) >> the argv will use -file. This is already covered by existing tests, >> like hugepages-shared. >> >> thanks >> >>> John >>> >>>> DO_TEST("cpu-check-none", QEMU_CAPS_KVM); >>>> DO_TEST("cpu-check-partial", QEMU_CAPS_KVM); >>>> DO_TEST("cpu-check-full", QEMU_CAPS_KVM); >>>>