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. > > Paolo > 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... -- Thanks, David
