On Mon, 20 Jun 2022 17:24:18 +0200 Brice Goglin <brice.gog...@inria.fr> wrote:
> Le 20/06/2022 à 15:27, Igor Mammedov a écrit Machine (2966MB total) + > Package P#0 > >> NUMANode P#2 (979MB) > >> Group0 > >> NUMANode P#0 (980MB) > >> Core P#0 + PU P#0 > >> Core P#1 + PU P#1 > >> Group0 > >> NUMANode P#1 (1007MB) > >> Core P#2 + PU P#2 > >> Core P#3 + PU P#3 > > here should be a dis-assembled dump of generated HMAT table > > > Hello > > Like what I added at the end of > https://github.com/bgoglin/qemu/commit/d9b3f5cb1514adafa644afcc2a363f2dc9795a32 > > ? yep, only full version including headers. (install acpica-tools on host and then when you run your test with 'make V=1 check-qtest', it will dump diff on console for you) > > + a test case, see tests/qtest/bios-tables-test.c > > for the process (at tho top) and test examples > > > https://github.com/bgoglin/qemu/commit/643dfa2de8b3e1f5b5675825e5d1be5c93a9549c > > This passes make check V=1 but I am really not sure about what I did. > The doc is far from easy for new contributors. Only HMAT matters here, improvements to doc comment are welcome > but it looks like it wanted some other tables too. if test can't find a table with data.variant, it defaults to checking against suffix-less variant if such exists. you will need to provide all tables for your config that differ from default one (i.e. not only HMAT one). also CI runs on memory constrained systems, so limit RAM usage to possible minimum (see other numa tests) > Also I don't know > about pc vs piix4 vs q35, what "tcg" is, etc. your case is not tcg or kvm specific, so put it in generic x86 section (just like you did) and I'd pick q35 as used machine (though it should work with pc too) > > Advices appreciated. > > > How are we supposed to send patches that contain binary changes? here is a recent example of adding a new test: https://mail.gnu.org/archive/html/qemu-devel/2022-06/msg01320.html https://mail.gnu.org/archive/html/qemu-devel/2022-06/msg01320.html https://mail.gnu.org/archive/html/qemu-devel/2022-06/msg01320.html idea of splitting it on several patches is to keeps series bisect-able 1. whitelist changes/add empty files if necessary, 2. add test which will spit warnings and one can see what has been changed/added 3. update expected blobs and remove whitelisting, so any unexpected change will trigger test failure (compile after each step to make sure patches are split correctly) > > Brice > > >
