Re: [PATCH] hmat acpi: Don't require initiator value in -numa when hmat=on

[Igor Mammedov]

On Mon, 20 Jun 2022 17:24:18 +0200
Brice Goglin <Brice.Goglin@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
> 
> 
>