[libvirt] [PATCH 0/8] Add perf and Intel CMT feature support

[Jiri Denemark]

On Wed, Nov 25, 2015 at 13:16:34 +0000, Ren, Qiaowei wrote:
> 
> > -----Original Message-----
> > From: Daniel P. Berrange [mailto:berrange at redhat.com]
> > Sent: Tuesday, November 24, 2015 9:29 PM
> > To: Ren, Qiaowei; libvir-list at redhat.com
> > Subject: Re: [libvirt] [PATCH 0/8] Add perf and Intel CMT feature support
> > 
> > On Tue, Nov 24, 2015 at 02:24:22PM +0100, Jiri Denemark wrote:
> > > On Tue, Nov 17, 2015 at 16:00:40 +0800, Qiaowei Ren wrote:
> > > > The series mainly adds Intel CMT feature support into libvirt. CMT
> > > > is new introduced PQos (Platform Qos) feature to monitor the usage
> > > > of cache by applications running on the platform.
> > > >
> > > > Currently CMT patches has been merged into Linux kernel mainline.
> > > > The CMT implementation in Linux kernel is based on perf mechanism
> > > > and there is no support for perf in libvirt, and so this series
> > > > firstly add perf support into libvirt, including two public API and
> > > > a set of util interfaces. And based on these APIs and interfaces,
> > > > thie series implements CMT perf event support.
> > > >
> > > > TODO:
> > > > 1. This series relys on keeping an open file descriptor for the guest.
> > > > We should add one patch to call sys_perf_event_open again iff
> > > > libvirtd is restarted.
> > >
> > > Yes, we should reenable perf events when reconnecting to running
> > > domains. Will we need to remember what events were enabled (in domain
> > > status XML) or is it something we can read back from the kernel?
> > 
> > We need to record it somewhere. I guess this raises the question of whether we
> > should hide it in status XML, or persist the list of desired perf events in the real
> > domain XML, so we can have the option of also having them enabled
> > immediately at startup, without requiring separate API call.
> > 
> 
> I checked the kernel perf interface and could not find the way to read
> back whether events were enabled from the kernel. So we have to record
> it somewhere according to Daniel.
> 
> If we just persist the list of desired perf events in the real domain
> XML, users can have the option of having them enabled at startup. But
> it is also possible that users enable more events  at runtime through
> API call for perf event. So should we record it in both real domain
> XML and status XML?

The status XML always contains full domain XML of the running domain.
Thus if you add to code to handle all this in domain XML, you don't need
to do anything extra to store the info in status XML. However, you'll
need to update live domain definition from the APIs which enable/disable
the perf events.

Jirka