* Andrew Jones (drjo...@redhat.com) wrote:
> On Tue, Jun 21, 2016 at 08:47:39PM +0100, Peter Maydell wrote:
> > On 21 June 2016 at 19:45, Andrew Jones <drjo...@redhat.com> wrote:
> > > On Tue, Jun 21, 2016 at 06:09:34PM +0100, Peter Maydell wrote:
> > >> Since the virt board model will never create a CPU which is
> > >> pre-ARMv7, we know that our minimum page size is 4K and can
> > >> set minimum_page_bits accordingly, for improved performance.
> > >>
> > >> Note that this is a migration compatibility break.
> > >>
> > >> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> > >> ---
> > >> hw/arm/virt.c | 2 ++
> > >> 1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > >> index c5c125e..f9b51aa 100644
> > >> --- a/hw/arm/virt.c
> > >> +++ b/hw/arm/virt.c
> > >> @@ -1440,6 +1440,8 @@ static void virt_machine_class_init(ObjectClass
> > >> *oc, void *data)
> > >> mc->block_default_type = IF_VIRTIO;
> > >> mc->no_cdrom = 1;
> > >> mc->pci_allow_0_address = true;
> > >> + /* We know we will never create a pre-ARMv7 CPU which needs 1K
> > >> pages */
> > >> + mc->minimum_page_bits = 12;
> > >> }
> > >
> > > As this breaks migration, then I guess we also need
> > >
> > > @@ -1507,5 +1510,6 @@ static void virt_machine_2_6_options(MachineClass
> > > *mc)
> > > {
> > > virt_machine_2_7_options(mc);
> > > SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6);
> > > + mc->minimum_page_bits = 10;
> > > }
> > > DEFINE_VIRT_MACHINE(2, 6)
> >
> > Doesn't hurt, but are we trying to claim migration
> > compat between different QEMU versions with the
> > versioned-machine names ?
>
> I'm still learning how best to approach compat/migration concerns.
> I've CC'ed David to help.
>
> Up until now my main concern has been keeping the RHEL-x.y mach-virt
> (and now upstream versioned mach-virt) type from changing as new
> features are added. In which case, I think the above makes sense
> regardless. With respect to migration I'm unsure of the claims we
> can/should make. IMO, we'd ideally be able to always migrate a
> versioned-machine (obviously running with a QEMU that supports that
> version) to a host with a later QEMU (which, being later, means it
> also supports that version)
Yes, my hope is that any versioned machine type should migrate to
a newer qemu with the same machine type set.
There are really two separate things that we state with the machine
versioning:
a) that the guest view is the same
b) that the migration format is the same
Dave
> Thanks,
> drew
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
