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. Paolo
