qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH v2 6/6] hw/arm/virt: Set minimum_page_bits to 12
Date: Wed, 22 Jun 2016 10:02:34 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

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)

Thanks,
drew



reply via email to

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