WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [ PATCH 2.6.16-rc3-xen 3/3] sysfs: export Xen hypervisor

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: [Xen-devel] Re: [ PATCH 2.6.16-rc3-xen 3/3] sysfs: export Xen hypervisor attributes to sysfs
From: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Date: Thu, 23 Feb 2006 09:24:25 +0100
Cc: "Mike D. Day" <ncmike@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Heiko Carstens <heiko.carstens@xxxxxxxxxx>, Dave Hansen <haveblue@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, Greg KH <greg@xxxxxxxxx>
Delivery-date: Thu, 23 Feb 2006 10:53:04 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43FD3971.7070703@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <43FB2642.7020109@xxxxxxxxxx> <1140542130.8693.18.camel@xxxxxxxxxxxxxxxxxxxxx> <20060222123250.GB9295@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <43FC5B1D.5040901@xxxxxxxxxx> <1140612969.2979.20.camel@xxxxxxxxxxxxxxxxxxxxx> <43FC61C4.30002@xxxxxxxxxx> <20060222131918.GC9295@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <43FC6A86.90901@xxxxxxxxxx> <1140616911.2979.22.camel@xxxxxxxxxxxxxxxxxxxxx> <43FD3971.7070703@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 !


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>