On Tue, 8 Dec 2020 04:48:09 -0800 Nadav Amit <nadav.amit@xxxxxxxxx> wrote: [...] > >> And other VM-entry failures, which are not easy to debug, > >> especially on bare-metal. > > > > so you are running the test on bare metal? > > > > that is something I had not tested > > Base-metal / VMware. > > > > >> Note that the failing test is not new, and unfortunately these > >> kind of errors (wrong assumption that memory is zeroed) are not > >> rare, since KVM indeed zeroes the memory (unlike other hypervisors > >> and bare-metal). > >> > >> The previous allocator had the behavior of zeroing the memory to > > > > I don't remember such behaviour, but I'll have a look > > See https://www.spinics.net/lists/kvm/msg186474.html hmmm it seems I had completely missed it, oops > > > >> avoid such problems. I would argue that zeroing should be the > >> default behavior, and if someone wants to have the memory > >> “untouched” for a specific test (which one?) he should use an > >> alternative function for this matter. > > > > probably we need some commandline switches to change the behaviour > > of the allocator according to the specific needs of each testcase > > > > > > I'll see what I can do > > I do not think commandline switches are the right way. I think that > reproducibility requires the memory to always be on a given state there are some bugs that are only exposed when the memory has never been touched. zeroing the memory on allocation guarantees that we will __never__ be able to detect those bugs. > before the tests begin. There are latent bugs in kvm-unit-tests that then maybe it's the case to fix those bugs? :) > are not apparent when the memory is zeroed. I do not think anyone > wants to waste time on resolving these bugs. I disagree. if a unit test has a bug, it should be fixed. some tests apparently need the allocator to clear the memory, while other tests depend on the memory being untouched. this is clearly impossible to solve without some kind of switch I would like to know what the others think about this issue too Claudio
