Hi all, some thoughts:
- I vote for making the metrics as much as possible in the guest available as on the host. Allows cascading, and having in-guest-monitoring working like on bare metal. - As result, really just plain vCPU consumption would be made available in the guest as rapl-core. If the host can at some point understand guests GPU, or I/O consumption, better hand that in separately. - Having in mind that we will also need this for other architectures, at least aarch64. RAPL comes from x86, rather than extending that to also do I/O or such, we might aim at an interface which will also work for aarch64. - Bigger scope will be to look at the consumption of multiple systems, for that we will need to move the metrics to network eventually, changing from MSR or such mechanisms. - For reading the metrics in the guest, I was tempted to suggest PCP with pmda-denki to cover RAPL, but it's right now just reading /sysfs, not MSR's. pmda-lmsensors for further sensors offered on various systems, and pmda-openmetrics for covering anything appearing somewhere on /sysfs as a number. > > Not that I disagree with all you said, to the contrary, but the amount > > of change is quite significant and it would be very annoying if results > > of this work doesn't make upstream because of Y & X. > > split frontend/backend design is established pattern in QEMU, so I'm not > suggesting anything revolutionary (probability that anyone would object > to it is very low). > > sending an RFC can serve as a starting point for discussion. +1, Christian
