Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side


* Avi Kivity <avi@xxxxxxxxxx> wrote:

On 03/16/2010 01:25 PM, Ingo Molnar wrote:

I haven't followed vmchannel closely, but I think it is. vmchannel is
terminated in qemu on the host side, not in the host kernel. So perf would
need to connect to qemu.
Hm, that sounds rather messy if we want to use it to basically expose kernel
functionality in a guest/host unified way. Is the qemu process discoverable in
some secure way?

We know its pid.

How do i get a list of all 'guest instance PIDs', and what is the way to talk
to Qemu?

Can we trust it?

No choice, it contains the guest address space.

I mean, i can trust a kernel service and i can trust /proc/kallsyms.

Can perf trust a random process claiming to be Qemu? What's the trust
mechanism here?

Is there some proper tooling available to do it, or do we have to push it
through 2-3 packages to get such a useful feature done?

libvirt manages qemu processes, but I don't think this should go through
libvirt. qemu can do this directly by opening a unix domain socket in a
well-known place.

So Qemu has never run into such problems before?

( Sounds weird - i think Qemu configuration itself should be done via a
unix domain socket driven configuration protocol as well. )

( That is the general thought process how many cross-discipline useful
desktop/server features hit the bit bucket before having had any chance of
being vetted by users, and why Linux sucks so much when it comes to feature
integration and application usability. )

You can't solve everything in the kernel, even with a well populated tools/.

Certainly not, but this is a technical problem in the kernel's domain, so it's
a fair (and natural) expectation to be able to solve this within the kernel
project.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC] Unify KVM kernel-space and user-space code into a single project
    ... The only difference is that we could ignore potential alternatives to qemu, libvirt, and RHEV-M. ... But that's not how kernel ABIs are developed, we try to make them general, not suited to just one consumer that happens to be close to our heart. ... In fact kvm started out in a single repo, and it certainly made it easy to bring it up in baby steps. ... well and user-space developers can be pretty good kernel developers as well. ...
    (Linux-Kernel)
  • Re: Recommended virtualization technique for debugging/developing FreeBSD
    ... > to debug/develop FreeBSD (the kernel in particular). ... Most initial debugging was done with a super-low-level serial console, ... John Baldwin has been using qemu lately for bios/btx/loader work on x86. ...
    (freebsd-current)
  • Re: [RFC] Unify KVM kernel-space and user-space code into a single project
    ... as a kernel module where it belonged. ... qemu are similar to the skills requires to produce useful patches for ... some merging of a qemu-kvm side patch (it always happened to me so far ... creates a pure paravirt userland for kvm without full driver emulation ...
    (Linux-Kernel)
  • Re: upstream regression (IO-APIC?)
    ... or lost IRQs on ATA init... ... attempts and if there is no panic kernel boots normally. ... So the issue only affects qemu ATM. ... When host and guest are using the same HZ setting ...
    (Linux-Kernel)
  • Re: upstream regression (IO-APIC?)
    ... or lost IRQs on ATA init... ... attempts and if there is no panic kernel boots normally. ... the real hardware works fine: ... So the issue only affects qemu ATM. ...
    (Linux-Kernel)