qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add a subsection for migrat


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add a subsection for migrating vcpu's TSC rate
Date: Fri, 13 Nov 2015 13:21:35 -0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Nov 13, 2015 at 10:23:54AM +0800, Haozhong Zhang wrote:
> On 11/11/15 22:27, Haozhong Zhang wrote:
> > On 11/11/15 12:16, Eduardo Habkost wrote:
> [...]
> > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > > > index 2f8f396..858ed69 100644
> > > > --- a/hw/i386/pc_q35.c
> > > > +++ b/hw/i386/pc_q35.c
> > > > @@ -385,6 +385,7 @@ static void pc_q35_2_4_machine_options(MachineClass 
> > > > *m)
> > > >      pc_q35_2_5_machine_options(m);
> > > >      m->alias = NULL;
> > > >      pcmc->broken_reserved_end = true;
> > > > +    pcmc->save_tsc_khz = false;
> > > 
> > > I had suggested the PCMachineClass field, but now I've been thinking:
> > > all other fields related to tsc_khz are in X86CPU, so I believe this
> > > belongs to X86CPU too. It could be a simple X86CPU property set by
> > > PC_COMPAT_2_4.
> > >
> > 
> > Reasonable, will update in the next version.
> 
> Or maybe no ...
> 
> I think there is still a problem to set a X86CPU property in
> PC_COMPAT_2_4:
> 
> if I create a property for save_tsc_khz by adding
>   DEFINE_PROP_BOOL("save-tsc-freq", X86CPU, save_tsc_khz, true)
> in x86_cpu_properties and add
>   {
>       .driver   = TYPE_X86_CPU,
>       .property = "save-tsc-freq",
>       .value    = "off",
>   }
> in PC_COMPAT_2_4, then "save-tsc-freq" will also become a
> user-visible cpu option. But we agreed on keeping it as an
> internal flag in the previous discussion.
> 
> Any other ways to set a property in PC_COMPAT_* while keeping that
> property internal?

I don't think making it internal is a requirement. It just make
things simpler because it allowed us to postpone decisions about
the user-visible parts.

...which seems to be a good reason to keep it on PCMachineClass
by now, if you prefer it that way. The subsection code is already
on machine.c and not on cpu.c, anyway.

-- 
Eduardo



reply via email to

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