lkml.org 
[lkml]   [2010]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project
    On Wed, Mar 24, 2010 at 02:08:17PM +0200, Avi Kivity wrote:
    > On 03/24/2010 01:59 PM, Joerg Roedel wrote:

    > You can always provide the kernel and module paths as command line
    > parameters. It just won't be transparently usable, but if you're using
    > qemu from the command line, presumably you can live with that.

    I don't want the tool for myself only. A typical perf user expects that
    it works transparent.

    >> Could be easily done using notifier chains already in the kernel.
    >> Probably implemented with much less than 100 lines of additional code.
    >
    > And a userspace interface for that.

    Not necessarily. The perf event is configured to measure systemwide kvm
    by userspace. The kernel side of perf takes care that it stays
    system-wide even with added vm instances. So in this case the consumer
    for the notifier would be the perf kernel part. No userspace interface
    required.

    > If we make an API, I'd like it to be generally useful.

    Thats hard to do at this point since we don't know what people will use
    it for. We should keep it simple in the beginning and add new features
    as they are requested and make sense in this context.

    > It's a total headache. For example, we'd need security module hooks to
    > determine access permissions. So far we managed to avoid that since kvm
    > doesn't allow you to access any information beyond what you provided it
    > directly.

    Depends on how it is designed. A filesystem approach was already
    mentioned. We could create /sys/kvm/ for example to expose information
    about virtual machines to userspace. This would not require any new
    security hooks.

    > Copying the objects is a one time cost. If you run perf for more than a
    > second or two, it would fetch and cache all of the data. It's really
    > the same problem with non-guest profiling, only magnified a bit.

    I don't think we can cache filesystem data of a running guest on the
    host. It is too hard to keep such a cache coherent.

    >>> Other userspaces can also provide this functionality, like they have to
    >>> provide disk, network, and display emulation. The kernel is not a huge
    >>> library.

    If two userspaces run in parallel what is the single instance where perf
    can get a list of guests from?

    > kvm.ko has only a small subset of the information that is used to define
    > a guest.

    The subset is not small. It contains all guest vcpus, the complete
    interrupt routing hardware emulation and manages event the guests
    memory.

    Joerg



    \
     
     \ /
      Last update: 2010-03-24 13:53    [W:2.438 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site