On Thu, Oct 19, 2017 at 10:16:23AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@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 <pet...@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.
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 :|
