Re: [kvm-unit-tests PATCH v2 4/7] lib/alloc_page: complete rewrite of the page allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 08, 2020 at 02:41:39PM +0100, Claudio Imbrenda wrote:
> 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
>

If the allocator supports memory being returned and then reallocated, then
the generic allocation API cannot guarantee that the memory is untouched
anyway. So, if a test requires untouched memory, it should use a specific
API. I think setup() should probably just set some physical memory regions
aside for that purpose, exposing them somehow to unit tests. The unit
tests can then do anything they want with them. The generic API might
as well continue zeroing memory by default.

I never got around to finishing my review of the memory areas. Maybe that
can be modified to support this "untouched" area simply by labeling an
area as such and by not accepting returned pages to that area.

Thanks,
drew





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux