RE: [PATCH v5 4/9] i386: Add new property to control cache info

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

 



> -----Original Message-----
> From: Alexandr Iarygin <alexandr.iarygin@xxxxxxxxxxxxxxxx>
> Sent: Monday, April 9, 2018 12:00 PM
> To: Moger, Babu <Babu.Moger@xxxxxxx>; mst@xxxxxxxxxx;
> marcel@xxxxxxxxxx; pbonzini@xxxxxxxxxx; rth@xxxxxxxxxxx;
> ehabkost@xxxxxxxxxx; mtosatti@xxxxxxxxxx
> Cc: qemu-devel@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; kash@xxxxxxxxxxxxxx;
> Alexandr Iarygin <alexandr.iarygin@xxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH v5 4/9] i386: Add new property to control cache info
> 
> Hello,
> 
> Babu Moger <babu.moger@xxxxxxx> writes:
> 
> > This will be used to control the cache information.
> > By default new information will be displayed. If user
> > passes "-cpu legacy-cache" then older information will
> > be displayed even if the hardware supports new information.
> >
> > Signed-off-by: Babu Moger <babu.moger@xxxxxxx>
> > ---
> >  include/hw/i386/pc.h | 6 +++++-
> >  target/i386/cpu.c    | 1 +
> >  target/i386/cpu.h    | 5 +++++
> >  3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index ffee841..9cda1ab 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -327,7 +327,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *,
> uint64_t *);
> >          .driver   = "q35-pcihost",\
> >          .property = "x-pci-hole64-fix",\
> >          .value    = "off",\
> > -    },
> > +    },{\
> > +        .driver   = TYPE_X86_CPU,\
> > +        .property = "legacy-cache",\
> > +        .value    = "off",\
> > +    },\
> 
> Should be "on". Also note that this introduces extra '\' at the end.

I think, I mis-understood Eduardo's earlier comments.  It should be "on" for machine type "pc-q35-2.10".
Yes. There is an extra  '\'.  Will remove in next version. I will fix both of these in next version. Thanks
 
> 
> >
> >  #define PC_COMPAT_2_9 \
> >      HW_COMPAT_2_9 \
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 67faa53..f4fbe3a 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5132,6 +5132,7 @@ static Property x86_cpu_properties[] = {
> >                       false),
> >      DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU,
> vmware_cpuid_freq, true),
> >      DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),
> > +    DEFINE_PROP_BOOL("legacy-cache", X86CPU, legacy_cache, false),
> 
> I'm wondering the reason why Intel L1 caches aren't shared per threads,
> L2 not shared per threads/cores etc? I mean, changing that will also
> require new compat flag with very similar name.

I am not an expert on this topic. But, yes, If there is any future change in cache topology
then it would require similar change. 

> 
> >
> >      /*
> >       * From "Requirements for Implementing the Microsoft
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index 806c34b..bbe13f2 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1394,6 +1394,11 @@ struct X86CPU {
> >       */
> >      bool enable_l3_cache;
> >
> > +    /* Compatibility bits for old machine types.
> > +     * If true present the old cache topology information
> > +     */
> > +    bool legacy_cache;
> > +
> >      /* Compatibility bits for old machine types: */
> >      bool enable_cpuid_0xb;
> >
> > --
> > 1.8.3.1




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux