Re: [Qemu-devel] [PATCH v2 6/6] hw/arm/virt: Set minimum_page_bits to 12

[Dr. David Alan Gilbert]

* Andrew Jones (address@hidden) wrote:
> On Tue, Jun 21, 2016 at 08:47:39PM +0100, Peter Maydell wrote:
> > On 21 June 2016 at 19:45, Andrew Jones <address@hidden> 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 <address@hidden>
> > >> ---
> > >>  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 / address@hidden / Manchester, UK