From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Anthony Harivel <aharivel@redhat.com>
Cc: pbonzini@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org,
vchundur@redhat.com
Subject: Re: [PATCH v3 3/3] Add support for RAPL MSRs in KVM/Qemu
Date: Tue, 5 Mar 2024 13:57:46 +0000 [thread overview]
Message-ID: <Zeck2gcPLe3NdmD_@redhat.com> (raw)
In-Reply-To: <CZLUM0L9G5U3.1UOBP5UFKY1AA@fedora>
On Tue, Mar 05, 2024 at 02:25:09PM +0100, Anthony Harivel wrote:
> Daniel P. Berrangé, Mar 04, 2024 at 15:48:
> > On Mon, Mar 04, 2024 at 03:41:02PM +0100, Anthony Harivel wrote:
> > >
> > > Hi Daniel,
> > >
> > > > > + if (s->msr_energy.enable == true) {
> > > >
> > > > This looks to be where we need to check that both the host CPU
> > > > vendor is intel, and the guest CPU vendor is intel, and that
> > > > the host CPU has the RAPL feature we're using.
> > >
> > > Checking for the host cpu and RAPL enable is fine and done.
> > >
> > > But checking for guest CPU is confusing me.
> > > The RAPL feature is enable only with KVM enable.
> > > This means "-cpu" can only be "host" or its derivative that essentially
> > > copy the host CPU definition, no?
> >
> > KVM can use any named CPU.
> >
> > > That means if we are already checking the host cpu we don't need to do
> > > anything for the guest, do we ?
> >
> > When I first wrote this I though it would be as simple as checknig a
> > CPUID feature flag. That appears to not be the case, however, as Linux
> > is just checking for various CPU models directly. With that in mind
> > perhaps we should just check of the guest CPU model vendor
> > == CPUID_VENDOR_INTEL and leave it at that.
> >
> > eg, create an error if running an AMD CPU such as $QEMU -cpu EPYC
>
> The idea looks good to me. Now the hiccups of this solution is that
> I cannot find a way to reach CPUArchState at this level of code (i.e
> kvm_arch_init() ) with only the MachineState or the KVMState.
> I can only reach the topology with x86_possible_cpu_arch_ids().
>
> CPUArchState struct is holding the cpuid_vendor variables where we can
> use IS_INTEL_CPU() for checking.
>
> Maybe you know the trick that I miss ?
I think perhaps you can do a check in kvm_cpu_realizefn() from
target/i386/kvm/kvm-cpu.c, as you have CPUX86State state which
is what IS_INTEL_CPU wants.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-03-05 13:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 7:22 [PATCH v3 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-01-25 7:22 ` [PATCH v3 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-01-25 16:37 ` Daniel P. Berrangé
2024-01-29 19:25 ` Paolo Bonzini
2024-01-29 19:30 ` Daniel P. Berrangé
2024-01-25 7:22 ` [PATCH v3 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-01-29 18:53 ` Daniel P. Berrangé
2024-01-29 19:33 ` Paolo Bonzini
2024-01-29 19:45 ` Daniel P. Berrangé
2024-01-29 19:53 ` Daniel P. Berrangé
2024-01-29 20:21 ` Paolo Bonzini
2024-02-21 13:19 ` Anthony Harivel
2024-02-21 13:47 ` Daniel P. Berrangé
2024-02-21 13:52 ` Anthony Harivel
2024-03-01 11:08 ` Anthony Harivel
2024-01-25 7:22 ` [PATCH v3 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-01-29 19:29 ` Daniel P. Berrangé
2024-02-20 14:00 ` Anthony Harivel
2024-02-20 15:00 ` Daniel P. Berrangé
2024-03-05 14:58 ` Anthony Harivel
2024-01-30 9:13 ` Daniel P. Berrangé
2024-03-04 14:41 ` Anthony Harivel
2024-03-04 14:48 ` Daniel P. Berrangé
2024-03-05 13:25 ` Anthony Harivel
2024-03-05 13:57 ` Daniel P. Berrangé [this message]
2024-01-30 9:39 ` Daniel P. Berrangé
2024-03-12 11:21 ` Anthony Harivel
2024-03-12 15:49 ` Daniel P. Berrangé
2024-03-13 10:48 ` Anthony Harivel
2024-03-13 11:04 ` Daniel P. Berrangé
2024-03-14 8:26 ` Anthony Harivel
2024-03-14 8:55 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zeck2gcPLe3NdmD_@redhat.com \
--to=berrange@redhat.com \
--cc=aharivel@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vchundur@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.