qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 1/6] tests: Add basic migration precopy test
Date: Thu, 19 Oct 2017 10:16:23 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

* Daniel P. Berrange (address@hidden) 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 <address@hidden> 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.

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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]