Re: [Qemu-devel] [PATCH 1/6] tests: Add basic migration precopy test

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Thu, Oct 19, 2017 at 10:16:23AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berrange@redhat.com) wrote:
> > > On Thu, Oct 19, 2017 at 11:18:33AM +0800, Peter Xu wrote:
> > > > On Wed, Oct 18, 2017 at 01:10:38PM +0100, Daniel P. Berrange wrote:
> > > > > On Wed, Oct 18, 2017 at 01:36:56PM +0200, Juan Quintela wrote:
> > > > > > Peter Xu <peterx@redhat.com> wrote:
> > > > > > > On Wed, Oct 04, 2017 at 12:39:28PM +0200, Juan Quintela wrote:
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > >> +/* A simple PC boot sector that modifies memory (1-100MB) quickly
> > > > > > >> + * outputing a 'B' every so often if it's still running.
> > > > > > >> + */
> > > > > > >> +unsigned char bootsect[] = {
> > > > > > >> +  0xfa, 0x0f, 0x01, 0x16, 0x74, 0x7c, 0x66, 0xb8, 0x01, 0x00, 0x00, 0x00,
> > > > > > >> +  0x0f, 0x22, 0xc0, 0x66, 0xea, 0x20, 0x7c, 0x00, 0x00, 0x08, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe4, 0x92, 0x0c, 0x02,
> > > > > > >> +  0xe6, 0x92, 0xb8, 0x10, 0x00, 0x00, 0x00, 0x8e, 0xd8, 0x66, 0xb8, 0x41,
> > > > > > >> +  0x00, 0x66, 0xba, 0xf8, 0x03, 0xee, 0xb3, 0x00, 0xb8, 0x00, 0x00, 0x10,
> > > > > > >> +  0x00, 0xfe, 0x00, 0x05, 0x00, 0x10, 0x00, 0x00, 0x3d, 0x00, 0x00, 0x40,
> > > > > > >> +  0x06, 0x7c, 0xf2, 0xfe, 0xc3, 0x75, 0xe9, 0x66, 0xb8, 0x42, 0x00, 0x66,
> > > > > > >> +  0xba, 0xf8, 0x03, 0xee, 0xeb, 0xde, 0x66, 0x90, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0x00, 0x9a, 0xcf, 0x00,
> > > > > > >> +  0xff, 0xff, 0x00, 0x00, 0x00, 0x92, 0xcf, 0x00, 0x27, 0x00, 0x5c, 0x7c,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > > > >> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0xaa
> > > > > > >> +};
> > > > > > >
> > > > > > > Not sure whether it would be nicer to put this section as binary into
> > > > > > > QEMU's tree as shared, then other test code can use it too directly,
> > > > > > > and it would be easier if someone wants to boot a VM running this
> > > > > > > bootstrap code.  Thanks,
> > > > > > 
> > > > > > I am sharing this code now on a single place.  About getting this
> > > > > > outside ... I will wait for someone that understand how this works, I
> > > > > > have no clue neither how it works nor how to share/use/setup/....
> > > > > 
> > > > > FWIW, we already have a reusuable program that can be used to generate
> > > > > load stress for testing live migration see tests/migration/stress.c
> > > > > This gets compiled into a static binary, put into an initrd, and then
> > > > > run by booting the host OS kernel. So the caveat is that this approach
> > > > > only lets you test a QEMU emulator whose target arch matches the host.
> > > > > That isn't much different from this boot sector though which only lets
> > > > > you test the x86 system emulator.
> > > > 
> > > > Yes, if we can have some C program for all architecture then it sounds
> > > > nicer, though IIUC this program is somehow special since it should be
> > > > writting some "A"/"B" chars to console, and the test program is using
> > > > those chars during the process.
> > > 
> > > That would be easy enough to add to the current program I expect.
> > > 
> > > Oh the other difference with the program I wrote is that it is
> > > multi-threaded, so it spawns a writer thread for each vCPU that
> > > is given to the guest. This lets you generate even more extreme
> > > memory dirtying rates if desired :-)
> > > 
> > > > Maybe it would be nice to rewrite a C program to replace current
> > > > binary sector when someone wants to support postcopy migration test on
> > > > a 3rd platform besides x86 and ppc.
> > > 
> > > Booting a real Linux kernel and then running the C program as 'init'
> > > is easier to make portable since we don't need to know about special
> > > ways each arch deals with initial boot up.
> > 
> > No, it doesn't work.
> > This test reads a well defined area of physical memory; you can't
> > replace that test booting a full kernel and userland program.
> 
> Ah ok, I didn't realize this test was actually looking into guest RAM, I
> thought it just treated the guest as opaque merely needing RAM dirtying
> load.

No, it's verifying that the contents after migration are valid.
For which that's not a fixed value but matches a set of constraints;
i.e. that since the increment happens in order, that there's a single
point in the sequence where the value is lower than than the previous
page, since the increment hasn't got to that page yet.

Dave

> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK