But when I weigh the benefit of truly transparent system-wide perfIts not a transformation, its an extension. The current per-process
integration for users who don't use libvirt but do use perf, versus
the cost of transforming kvm from a single-process API to a
system-wide API with all the complications that I've listed, it comes
out in favour of not adding the API.
/dev/kvm stays mostly untouched. Its all about having something like
this:
$ cd /sys/kvm/guest0
$ ls -l
-r-------- 1 root root 0 2009-08-17 12:05 name
dr-x------ 1 root root 0 2009-08-17 12:05 fs
$ cat name
guest0
$ # ...
The fs/ directory is used as the mount point for the guest root fs.
What I meant was: perf-kernel puts the guest-name into every sample andThe samples will be tagged with the guest-name (and some additionalI take that as a yes? So we need a virtio-serial client in the kernel
information perf needs). Perf userspace can access the symbols then
through /sys/kvm/guest0/fs/...
(which might be exploitable by a malicious guest if buggy) and a
fs-over-virtio-serial client in the kernel (also exploitable).
perf-userspace accesses /sys/kvm/guest_name/fs/ later to resolve the
symbols. I leave the question of how the guest-fs is exposed to the host
out of this discussion. We should discuss this seperatly.
If a vm breaks into qemu it can access the host file system which is theAn approach like: "The files are owned and only readable by the sameThat's not how sVirt works. sVirt isolates a user's VMs from each
user that started the vm." might be a good start. So a user can measure
its own guests and root can measure all of them.
other, so if a guest breaks into qemu it can't break into other guests
owned by the same user.
bigger problem. In this case there is no isolation anymore. From that
context it can even kill other VMs of the same user independent of a
hypothetical /sys/kvm/.
Yes, but its different from the implementation point-of-view. For theYeah that would be interesting information. But it is more related toIt's all related. You start with perf, see a problem with mmio, call up
tracing than to pmu measurements. The information which you
mentioned above are probably better captured by an extension of
trace-events to userspace.
a histogram of mmio or interrupts or whatever, then zoom in on the
misbehaving device.
user it surely all plays together.