On Tue, Sep 12, 2017 at 05:46:48PM +0200, 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. > I'd love to see this loop closed, and I like the GTest API idea too. I'm not opposed to picking this back up myself, but it wouldn't be until after KVM Forum. Anybody who wants to start now should feel free to :-) Regarding this series: should we find a way to hack a malloc in order to use the GTest API now? x86 and s390 could just reserve some memory for malloc to use with their flat.lds files, for example. I'll go ahead and give this series a quick review too, as any comments I may have may apply to whatever followup series comes next. Thanks, drew
