[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 12/21] hw/arm: Let the machine be the owner of the system mem
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH 12/21] hw/arm: Let the machine be the owner of the system memory |
Date: |
Mon, 21 Oct 2019 15:57:29 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
* Philippe Mathieu-Daudé (address@hidden) wrote:
> Cc'ing Paolo/David.
>
> On 10/21/19 11:39 AM, Peter Maydell wrote:
> > On Mon, 21 Oct 2019 at 10:34, Philippe Mathieu-Daudé <address@hidden> wrote:
> > >
> > > On 10/21/19 11:22 AM, Peter Maydell wrote:
> > > > On Mon, 21 Oct 2019 at 00:01, Philippe Mathieu-Daudé <address@hidden>
> > > > wrote:
> > > > >
> > > > > Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
> > > > > ---
> > > >
> > > > > hw/arm/virt.c | 2 +-
> > > >
> > > > I think from a quick code scan that this is ok, but did
> > > > you test that migration compat from old to new still works?
> > > > I vaguely recall that there are some cases when adding an
> > > > owner to a memory region changes the name string used for
> > > > identifying the ramblock in migration.
> > >
> > > It seems to still works:
> > >
> > > $ make check-qtest-aarch64 V=1
> >
> > > This test migrate the virt machine.
> > >
> > > Is this enough?
> >
> > No, you need to test migration from a QEMU binary without
> > this patchset to a QEMU binary that has it. Otherwise you're
> > only checking that the new version can migrate from itself
> > to itself. I find the easiest way to test this is just to
> > use the 'savevm' command to save a state snapshot to a
> > qcow2 disk image while running the old binary, and then run
> > 'loadvm' with the new binary and check it restored OK.
>
> I did not think if this case.
>
> I followed your blog post [*] and tested the migration works OK.
>
> Paolo, now thinking about regular testing, we should add this testing to
> patchew too. Something like:
>
> - when mainstream/master is updated, patchew build QEMU (it should be
> already mostly ccached) and generate some vm dumps with 'savevm'.
>
> - build/test the series
>
> - if series succeeded testing, run 'loadvm' tests
>
> [*]
> https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/
Avocado certainly already has an option for specifying source and
destination qemu separately; I've used that for testing
cross version in the past.
The challenge is finding a command line/set of devices for each
architecture that's expected to be stable.
You want a command line with as big a set of devices as possible (for
coverage) yet really is tied to machine type.
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
[PATCH 13/21] hw/cris: Let the machine be the owner of the system memory, Philippe Mathieu-Daudé, 2019/10/20
[PATCH 14/21] hw/hppa: Let the machine be the owner of the system memory, Philippe Mathieu-Daudé, 2019/10/20
[PATCH 15/21] hw/i386: Let the machine be the owner of the system memory, Philippe Mathieu-Daudé, 2019/10/20
[PATCH 16/21] hw/lm32: Let the machine be the owner of the system memory, Philippe Mathieu-Daudé, 2019/10/20