On 12/09/2017 18:17, David Hildenbrand wrote: > On 12.09.2017 17:46, Paolo Bonzini wrote: >> On 12/09/2017 17:15, David Hildenbrand wrote: >>> On 12.09.2017 17:01, Paolo Bonzini wrote: >>>> On 12/09/2017 16:16, David Hildenbrand wrote: >>>>> I want to use this in another file, so instead of replicating, factoring >>>>> it out feels like the right thing to do. >>>>> >>>>> Let's directly provide it for all architectures, they just have >>>>> to implement get_time_ms() in asm/time.h to use it. >>>>> >>>>> Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> >>>>> --- >>>>> >>>>> The next step would be allowing to add custom parameters to a test. >>>>> (defining them similar to the test cases). >>>>> >>>>> Any other requests/nice to have? Does this make sense? >>>> >>>> It does, but we have at least this, vmx.c (v1 and v2) and vmexit.c, with >>>> not exactly overlapping usecases and command-line syntax. Would it make >>> >>> Yes, the ultimate goal would be to combine all into one. I only had a >>> look at some ARM tests yet. Will have a look at these. >>> >>>> sense to have an API that is not home-grown, e.g. a subset of GTest? >>>> The command-line arguments could be globs (like GTest's "-p"). >>> >>> I'll have a look. Any experts around? >> >> Take a look at https://developer.gnome.org/glib/stable/glib-Testing.html. >> >> But... one obstacle is probably the lack of malloc in x86, so this would >> be a prerequisite. Andrew first proposed it last year, and there was >> some discussion on the design and how to abstract giving more memory to >> malloc. You can find the result here: >> https://patchwork.kernel.org/patch/9409843/ -- it's a longish thread, >> but it should be fun to implement. :) >> >> The idea is to have four allocator APIs: >> >> - "phys" (phys_alloc) provides contiguous physical addresses and is used >> in early allocations or for tests that do not enable the MMU. It need >> not be able to free anything. It also provides an arch-dependent >> interface to register the available memory. >> >> - "page" (alloc_page) is initialized after the MMU is started. It picks >> whatever memory wasn't allocated by phys, and slices it in pages. Like >> "phys", it provides contiguous physical addresses. >> >> - "virt" (alloc_vpages) is also initialized after the MMU is started, >> and it allocates virtual address space. It also provides an >> arch-dependent interface to install PTEs. It provides contiguous >> virtual addresses. >> >> - "malloc" is the API we all love :) and it uses a pluggable allocator >> underneath, called "morecore" in the thread, with the prototype >> >> void *(*morecore)(size_t size, size_t align_min); >> >> In the beginning "morecore" simply uses "phys", later it is switched >> (when the MMU is started) to use both "page" and "virt". That is it >> takes not necessarily consecutive physical memory at page >> granularity from "page", it assigning consecutive virtual address (from >> "virt") to it, and if needed it also slices pages into smaller allocations. >> >> Of course each could be arbitrarily complicated, but it need not be. >> >> "page" could be a buddy system, but really in practice it need not even >> support reusing freed pages, except for 1-page allocations. This makes >> it enough to use a simple free list of pages, plus a separately-tracked >> huge block of consecutive free physical addresses at the top. >> >> Likewise, "malloc" could be Doug Lea's malloc, but really in practice it >> will just be a small veneer over morecore, with a dummy free. Like the >> testing thing, the important part is avoiding under-engineering. >> >> Quoting from the thread, you can choose separately at each layer whether >> to implement freeing or not. "phys", "virt" and "morecore" do not need >> it. See in particular the Nov. 3, 2016, 5:34 p.m. message for a plan to >> transform Drew's v2 series >> (https://www.spinics.net/lists/kvm/msg139685.html) into the design >> envisioned above. > > Holy cow, that sounds like a lot of work, especially as malloc is also > not expected to work on s390x - guess because of which architecture I > started to factor out ;) > > phys_alloc_init() yields only arm and powerpc. > > ... so while having GTest would be the optimal solution, I wonder if it > is worth the trouble right now. (sure, malloc for x86 and s390x would > also be nice, but already getting that implemented sounds like it could > take quite a while). > > Hmm.... probably have too look into the details of the malloc discussion... It's really less work than it sounds. I'm not wed to GTest, but I think the ability to define test cases programmatically is useful (vmexit.c for example has a case where the testcase list is actually in QEMU!) and it pretty much requires malloc. Paolo
