[lkml]   [2006]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ PATCH 2.6.16-rc3-xen 3/3] sysfs: export Xen hypervisor attributes to sysfs
    On Wed, 2006-02-22 at 22:26 -0600, Anthony Liguori wrote:
    > Arjan van de Ven wrote:
    > > On Wed, 2006-02-22 at 08:43 -0500, Mike D. Day wrote:
    > >
    > >> Heiko Carstens wrote:
    > >>
    > >>> On Wed, Feb 22, 2006 at 08:06:12AM -0500, Mike D. Day wrote:
    > >>>
    > >>> If it's not needed, why include it at all?
    > >>>
    > >> Sorry for not being clear. It *is* needed for control tools and agents
    > >> running in the privileged domain.
    > >>
    > >
    > > but again those tools and agents *already* have a way of talking to the
    > > hypervisor themselves. Why can't they just first ask this info? Why does
    > > that need to be in the kernel, in unswappable memory?
    > >
    > Hypercalls have to be done in ring 0 for security reasons) There has to
    > be some kernel interface for making hypercalls.

    sure but you need that ANYWAY; the management tools will want a generic
    "THIS hypercall" thing

    > The current interface is a ioctl() on a /proc file (which is awful).
    > The ioctl just pretty much passes 5 word arguments to the hypervisor.
    > It was suggested previously here that a hypercall pass-through interface
    > isn't the right approach. One suggestion that came up was a syscall
    > interface.

    yeah a syscall sounds right for this

    > Also, there are some kernel-level drivers, like the memory ballooning
    > driver, that only exist in the kernel. Controlling the balloon driver
    > requires some sort of interface. That was the original point of this
    > effort (since it's currently exposed as a /proc file). I think it's
    > quite clear that the balloon driver should expose itself through sysfs
    > but I'm not personally convinced that this information (hypervisor
    > version information) ought to be exposed in sysfs.

    that's a different thing; the ballooning driver obviously has to be in
    kernel due to how it interacts with the VM, and having it's 1 or 2
    controls in sysfs (hint: make it writable module parameters, so that the
    defaults can be set at module load time, and you'll also get the rest
    for free ;)

    pure hypervisor info... no. "only" 8Kb of code + all data structures..
    for something just as easily done in the management layer. In fact I
    suspect the management layer will do the hypercalls anyway just because
    it's easier to do than parsing sysfs !

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-23 09:27    [W:0.026 / U:3.188 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site