From: "Anthony Harivel" <aharivel@redhat.com>
To: <pbonzini@redhat.com>
Cc: <berrange@redhat.com>, <mtosatti@redhat.com>,
<qemu-devel@nongnu.org>, <vchundur@redhat.com>,
<rjarry@redhat.com>, <zhao1.liu@intel.com>
Subject: Re: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
Date: Fri, 26 Apr 2024 10:36:00 +0200 [thread overview]
Message-ID: <D0TX0YRGY14M.3FU05839TNR56@redhat.com> (raw)
In-Reply-To: <Zip57XYKiIVgf2qz@redhat.com>
Hi Paolo,
Daniel P. Berrangé, Apr 25, 2024 at 17:42:
> On Thu, Apr 25, 2024 at 05:34:52PM +0200, Anthony Harivel wrote:
> > Hi Daniel,
> >
> > Daniel P. Berrangé, Apr 18, 2024 at 18:42:
> >
> > > > + if (kvm_is_rapl_feat_enable(cs)) {
> > > > + if (!IS_INTEL_CPU(env)) {
> > > > + error_setg(errp, "RAPL feature can only be\
> > > > + enabled with Intel CPU models");
> > > > + return false;
> > > > + }
> > > > + }
> > >
> > > I see a crash in kvm_is_rapl_feat_enable() from this caller,
> > > when I run with this kind of command line:
> > >
> > > $ qemu-system-x86_64 \
> > > -kernel /lib/modules/6.6.9-100.fc38.x86_64/vmlinuz \
> > > -initrd tiny-initrd.img -m 2000 -serial stdio -nodefaults \
> > > -display none -accel kvm -append "console=ttyS0 quiet"
> > >
> > >
> > > #0 0x0000555555bc14b7 in kvm_is_rapl_feat_enable (cs=cs@entry=0x555557b83470) at ../target/i386/kvm/kvm.c:2531
> > > #1 0x0000555555bc7534 in kvm_cpu_realizefn (cs=0x555557b83470, errp=0x7fffffffd2a0) at ../target/i386/kvm/kvm-cpu.c:54
> > > #2 0x0000555555d2432a in accel_cpu_common_realize (cpu=0x555557b83470, errp=0x7fffffffd2a0) at ../accel/accel-target.c:130
> > > #3 0x0000555555cdd955 in cpu_exec_realizefn (cpu=cpu@entry=0x555557b83470, errp=errp@entry=0x7fffffffd2a0) at ../cpu-target.c:137
> > > #4 0x0000555555c14b89 in x86_cpu_realizefn (dev=0x555557b83470, errp=0x7fffffffd310) at ../target/i386/cpu.c:7320
> > > #5 0x0000555555d58f4b in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffd390) at ../hw/core/qdev.c:510
> > > #6 0x0000555555d5d78d in property_set_bool (obj=0x555557b83470, v=<optimized out>, name=<optimized out>, opaque=0x5555578558e0, errp=0x7fffffffd390)
> > > at ../qom/object.c:2358
> > > #7 0x0000555555d60b0b in object_property_set (obj=obj@entry=0x555557b83470, name=name@entry=0x55555607c799 "realized", v=v@entry=0x555557b8ccb0, errp=0x7fffffffd390,
> > > errp@entry=0x555556e210d8 <error_fatal>) at ../qom/object.c:1472
> > > #8 0x0000555555d6444f in object_property_set_qobject
> > > (obj=obj@entry=0x555557b83470, name=name@entry=0x55555607c799 "realized", value=value@entry=0x555557854800, errp=errp@entry=0x555556e210d8 <error_fatal>)
> > > at ../qom/qom-qobject.c:28
> > > #9 0x0000555555d61174 in object_property_set_bool
> > > (obj=0x555557b83470, name=name@entry=0x55555607c799 "realized", value=value@entry=true, errp=errp@entry=0x555556e210d8 <error_fatal>) at ../qom/object.c:1541
> > > #10 0x0000555555d59a3c in qdev_realize (dev=<optimized out>, bus=bus@entry=0x0, errp=errp@entry=0x555556e210d8 <error_fatal>) at ../hw/core/qdev.c:292
> > > #11 0x0000555555bd51e0 in x86_cpu_new (x86ms=<optimized out>, apic_id=0, errp=0x555556e210d8 <error_fatal>) at ../hw/i386/x86.c:105
> > > #12 0x0000555555bd52ce in x86_cpus_init (x86ms=x86ms@entry=0x555557aaed30, default_cpu_version=<optimized out>) at ../hw/i386/x86.c:156
> > > #13 0x0000555555bdc1a7 in pc_init1 (machine=0x555557aaed30, pci_type=0x55555604aa61 "i440FX") at ../hw/i386/pc_piix.c:185
> > > #14 0x0000555555947a11 in machine_run_board_init (machine=0x555557aaed30, mem_path=<optimized out>, errp=<optimized out>, errp@entry=0x555556e210d8 <error_fatal>)
> > > at ../hw/core/machine.c:1547
> > > #15 0x0000555555b020ed in qemu_init_board () at ../system/vl.c:2613
> > > #16 qmp_x_exit_preconfig (errp=0x555556e210d8 <error_fatal>) at ../system/vl.c:2705
> > > #17 0x0000555555b0611e in qemu_init (argc=<optimized out>, argv=<optimized out>) at ../system/vl.c:3739
> > > #18 0x0000555555897ca9 in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:47
> > >
> > > The problem is that 'cs->kvm_state' is NULL here
> > >
> >
> > After some investigation it seems that kvm_state is not yet committed
> > at this point. Shame, because GDB showed me that we have already pass
> > the kvm_accel_instance_init() in accel/kvm/kvm-all.c that sets the
> > value "msr_energy.enable" in kvm_state...
> >
> > So should I dig more to still do the sanity check in kvm_cpu_realizefn()
> > or should I already move the RAPL feature from -kvm to -cpu
> > like suggested by Zhao from Intel and then access it from the CPUState ?
>
> I'm not so sure about that question. I think Paolo is best placed
> to suggest which is better, as the KVM maintainer.
>
I'm facing an issue that either require a simple change or a more
complex one depending on the decision.
TL;DR: Should I move from -kvm to -cpu the rapl feature ?
Zhao from Intel suggested me that enabling the rapl feature looks more
natural than through -kvm feature because it is indeed a cpu feature.
From the point of view of the QEMU architecture, it's more easier to
enable the feature with -kvm because it is kvm dependent; but maybe from
the point of view of the user, it's more natural to enable this at -cpu
level.
The issue I'm facing above is from a suggestion from Daniel to do the
sanity check at kvm_cpu_realizefn() level. However GDB showed me that
kvm_state is not yet populated, even if we have passed the init instance
kvm_accel_instance_init().
So either I'm moving from -kvm to -cpu and change the location of the
sanity check (checking if rapl feat is activated on Host / if Intel CPU)
or I keep the feature on -kvm and either find a solution of the above
issue or change the location of the sanity check.
Thanks in advance for your guidance.
Regards,
Anthony
next prev parent reply other threads:[~2024-04-26 8:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 12:14 [PATCH v5 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-04-11 12:14 ` [PATCH v5 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-04-12 10:58 ` Paolo Bonzini
2024-04-11 12:14 ` [PATCH v5 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-04-11 12:14 ` [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-04-17 10:07 ` Zhao Liu
2024-04-17 12:27 ` Daniel P. Berrangé
2024-04-17 15:13 ` Zhao Liu
2024-04-18 8:33 ` Anthony Harivel
2024-04-18 10:52 ` Anthony Harivel
2024-04-19 15:47 ` Zhao Liu
2024-04-17 17:55 ` Daniel P. Berrangé
2024-04-18 16:42 ` Daniel P. Berrangé
2024-04-18 16:57 ` Anthony Harivel
2024-04-25 15:34 ` Anthony Harivel
2024-04-25 15:42 ` Daniel P. Berrangé
2024-04-26 8:36 ` Anthony Harivel [this message]
2024-05-06 9:41 ` Anthony Harivel
2024-04-12 10:57 ` [PATCH v5 0/3] Add support for the RAPL MSRs series Paolo Bonzini
2024-04-17 17:58 ` Daniel P. Berrangé
2024-04-19 17:30 ` Paolo Bonzini
2024-04-17 17:23 ` Daniel P. Berrangé
2024-04-18 8:08 ` Anthony Harivel
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=D0TX0YRGY14M.3FU05839TNR56@redhat.com \
--to=aharivel@redhat.com \
--cc=berrange@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjarry@redhat.com \
--cc=vchundur@redhat.com \
--cc=zhao1.liu@intel.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.