[PATCH] Sysfs Interface for balloon driver

[PATCH] Sysfs Interface for balloon driver

[Satoshi Uchida]

[-- Attachment #1.1.1: Type: text/plain, Size: 2401 bytes --]

 
Hi.

This patch provides a sysfs interface for the balloon driver.

Currently, the interface for the balloon driver is provided by procfs.
However, I was suggested by Kier and Anthony that procfs should handle  only process information and other information should be located in sysfs,  when I made the interface for virtual block devices.

The information for the balloon driver also should be moved to sysfs.
So, I have made a sysfs interface for the balloon driver.

The information for balloon driver is placed in /sys/bus/xen/driver/balloon.
I thought of other locations for the information, such as /sys/class/mem or /sys/devices/xen, but I finally selected the place because the balloon driver is similar to the front-end driver.
Please comments about that location.


Example outputs of the sysfs interface of the balloon driver are as follows:

 Example 1.  Show each information

    [root@Dom0 ~]# ls /sys/bus/xen/drivers/
    balloon/  pcifront/ vbd/
    [root@Dom0 ~]# ls /sys/bus/xen/drivers/balloon/
    bind  statistics  unbind
    [root@Dom0 ~]# ls /sys/bus/xen/drivers/balloon/statistics/
    balloon_high  current_pages  hard_limit
    balloon_low   driver_pages   target_pages
    [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_high
          0 kB
    [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_low
       510976 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/current_pages
       262144 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/driver_pages
       1024 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/hard_limit
       ??? kB


 Example 2. Set memory size of a domain

   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/target_pages
     262144 kB
   [root@Dom0 ~]# echo 1024M > /sys/bus/xen/drivers/balloon/statistics/target_pages
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/target_pages
    1048576 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/current_pages
     758192 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/hard_limit
     758192 kB


The information for VMs should be located one place.
I want to propose a new location for the information of VMs, for example:
  /sys/virtualization -+--- domain
                               +--- hypervisor


Regards
Satoshi UCHIDA 
   NEC Corporation, Japan

[-- Attachment #1.1.2: balloon_sysfs.patch --]
[-- Type: application/octet-stream, Size: 3294 bytes --]

# HG changeset patch
# User root@noir.spf.cl.nec.co.jp
# Node ID 09a04601f89a1652b0d86d1764d02ebe89e7ecde
# Parent  10b05c2e79475f90330fa061b46d6df7e71a41c5
[Balloon]Add sysfs interface.

  This patch provides sysfs interface for balloon driver.
  Information is located under /sys/bus/xen/driver/balloon.

    Signed-off-by: Satoshi UCHIDA <s-uchida@ap.jp.nec.com>

diff -r 10b05c2e7947 -r 09a04601f89a linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c
--- a/linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c	Tue Aug 01 18:08:01 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c	Fri Sep 15 13:08:48 2006 +0900
@@ -460,6 +460,76 @@ static int balloon_read(char *page, char
 }
 #endif
 
+/*****************************************************
+ *  sysfs interface for balloon driver.
+ */
+static struct xenbus_driver balloon = {
+	.name = "balloon",
+	.owner = THIS_MODULE,
+};
+
+#define BALLOON_SHOW(name, format, args...)			\
+	static ssize_t show_##name(struct device_driver *dri,	\
+				   char *buf)			\
+	{							\
+		return sprintf(buf, format, ##args);		\
+	}							\
+  	static DRIVER_ATTR(name, S_IRUGO, show_##name, NULL)
+
+BALLOON_SHOW(current_pages, "%8lu kB\n", PAGES2KB(current_pages));
+BALLOON_SHOW(balloon_low, "%8lu kB\n", PAGES2KB(balloon_low));
+BALLOON_SHOW(balloon_high, "%8lu kB\n", PAGES2KB(balloon_high));
+BALLOON_SHOW(hard_limit,
+	     (hard_limit!=~0UL)?"%8lu kB\n":"??? kB\n" ,
+	     (hard_limit!=~0UL)?PAGES2KB(hard_limit):0);
+BALLOON_SHOW(driver_pages, "%8lu kB\n", PAGES2KB(driver_pages));
+
+static ssize_t show_target_pages(struct device_driver *dri,  
+				 char *buf)
+{							       
+	return sprintf(buf, "%8lu kB\n", PAGES2KB(target_pages));		       
+}							       
+
+static ssize_t store_target_pages(struct device_driver *dri,
+				  const char *buf,
+				  size_t count)
+{
+	char memstring[64], *endchar;
+	unsigned long long target_bytes;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+	
+	if (count <= 1)
+		return -EBADMSG; /* runt */
+	if (count > sizeof(memstring))
+		return -EFBIG;   /* too long */
+	printk("Balloon: size OK\n");
+	
+	target_bytes = memparse(buf, &endchar);
+	set_new_target(target_bytes >> PAGE_SHIFT);
+	
+	return count;
+}
+
+static DRIVER_ATTR(target_pages, S_IRUGO | S_IWUSR,
+	    show_target_pages, store_target_pages);
+
+static struct attribute *balloon_attrs[] = {
+	&driver_attr_current_pages.attr,
+	&driver_attr_target_pages.attr,
+	&driver_attr_balloon_low.attr,
+	&driver_attr_balloon_high.attr,
+	&driver_attr_hard_limit.attr,
+	&driver_attr_driver_pages.attr,
+	NULL
+};
+
+static struct attribute_group balloon_group = {
+	.name = "statistics",
+	.attrs = balloon_attrs,
+};
+
 static struct notifier_block xenstore_notifier;
 
 static int __init balloon_init(void)
@@ -493,7 +563,9 @@ static int __init balloon_init(void)
 	balloon_pde->read_proc  = balloon_read;
 	balloon_pde->write_proc = balloon_write;
 #endif
-    
+	xenbus_register_frontend(&balloon);
+	sysfs_create_group(&balloon.driver.kobj , &balloon_group);
+	
 	/* Initialise the balloon with excess memory space. */
 	for (pfn = xen_start_info->nr_pages; pfn < max_pfn; pfn++) {
 		page = pfn_to_page(pfn);

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] Sysfs Interface for balloon driver

[John Levon]

On Wed, Sep 20, 2006 at 09:26:43AM +0900, Satoshi Uchida wrote:

>     [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_high
>           0 kB

It's very unusual to have units in a sysfs node. I believe this should
just be the number, and documented elsewhere what the units are.

I also don't quite get the location. I don't quite think of balloon as a
real "driver" as such, it's core kernel functionality rather. Wouldn't
/sys/hypervisor/properties/balloon/ be a more sensible place?

regards,
john

RE: [PATCH] Sysfs Interface for balloon driver

[Satoshi Uchida]

Thanks John.

> >     [root@Dom0 ~]# cat 
> /sys/bus/xen/drivers/balloon/statistics/balloon_high
> >           0 kB
> 
> It's very unusual to have units in a sysfs node. I believe 
> this should just be the number, and documented elsewhere what 
> the units are.

I also hesitated that there give units or not.
First, units are not given.
However, I myself didn't understand units which is byte? or pages?.
In procfs, It is easy to understand because there have units.
So, in this time, I take them units.

As you say, it should be remove.


> I also don't quite get the location. I don't quite think of 
> balloon as a real "driver" as such, it's core kernel 
> functionality rather. Wouldn't 
> /sys/hypervisor/properties/balloon/ be a more sensible place?

In this time, it locate by following reason.
  A balloon driver is similar to front-end driver.
   1. It does not handle real device.
       Namely, by virtualization technology,
       it feign to handle computer elements. 
   2. Its computer elements is handled in 
       Domain (VM).
       Namely, it does not handle the whole real environments,
       and Its information is valid for VM.

I feel that the term "hypervisor" means VMM in general.
And a balloon exists for VM, and not for VMM.
Therefore, I think that such information should not be located to /sys/hypervisor.

Should new location make for storing such (VM's) information ?
For example, as following.
  /sys/virtualization -+--- domain
                             +--- hypervisor

Tnaks your reply.

Regards
Satoshi UCHIDA 
   NEC Corporation, Japan



> -----Original Message-----
> From: John Levon [mailto:levon@movementarian.org] 
> Sent: Wednesday, September 20, 2006 10:13 AM
> To: Satoshi Uchida
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Sysfs Interface for balloon driver
> 
> On Wed, Sep 20, 2006 at 09:26:43AM +0900, Satoshi Uchida wrote:
> 
> >     [root@Dom0 ~]# cat 
> /sys/bus/xen/drivers/balloon/statistics/balloon_high
> >           0 kB
> 
> It's very unusual to have units in a sysfs node. I believe 
> this should just be the number, and documented elsewhere what 
> the units are.
> 
> I also don't quite get the location. I don't quite think of 
> balloon as a real "driver" as such, it's core kernel 
> functionality rather. Wouldn't 
> /sys/hypervisor/properties/balloon/ be a more sensible place?
> 
> regards,
> john
> 

Re: [PATCH] Sysfs Interface for balloon driver

[John Levon]

On Wed, Sep 20, 2006 at 12:00:36PM +0900, Satoshi Uchida wrote:

> In this time, it locate by following reason.
>   A balloon driver is similar to front-end driver.

Not really. Front-end drivers are real drivers, thus it makes sense for
them to appear to be attached to a bus, even if that bus is virtual.

> I feel that the term "hypervisor" means VMM in general.
> And a balloon exists for VM, and not for VMM.

I don't understand what you mean here.

> Therefore, I think that such information should not be located to /sys/hypervisor.

Anyone else have an opinion?

> Should new location make for storing such (VM's) information ?
> For example, as following.
>   /sys/virtualization -+--- domain
>                              +--- hypervisor

Why would we need this? We already have xenstore for representing other
domain's information, and /sys/ is always specific to that particular
operating system instantiation.

regards
john

Re: [PATCH] Sysfs Interface for balloon driver

[Anthony Liguori]

John Levon wrote:
>> Therefore, I think that such information should not be located to /sys/hypervisor.
>>     
>
> Anyone else have an opinion?
>   

I *always* have an opinion :-)

Personally, I think the ballooning information ought to be exposed as a 
module parameter and appear in the sysfs module path.  I've always 
thought /sys/hypervisor ought to expose information from the hypervisor.

Regards,

Anthony Liguori

>> Should new location make for storing such (VM's) information ?
>> For example, as following.
>>   /sys/virtualization -+--- domain
>>                              +--- hypervisor
>>     
>
> Why would we need this? We already have xenstore for representing other
> domain's information, and /sys/ is always specific to that particular
> operating system instantiation.
>
> regards
> john
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>   

RE: [PATCH] Sysfs Interface for balloon driver

[Ian Pratt]

> John Levon wrote:
> >> Therefore, I think that such information should not be located to
> /sys/hypervisor.
> >>
> >
> > Anyone else have an opinion?
> >
> 
> I *always* have an opinion :-)
> 
> Personally, I think the ballooning information ought to be exposed as
a
> module parameter and appear in the sysfs module path.  I've always
> thought /sys/hypervisor ought to expose information from the
hypervisor.

I don't think the memory target stuff is a driver. 'balloon' should not
appear in the name anyhow -- this stuff is getting ever more closely
integrated with Linux's core memory management anyhow, it's definitely
not a driver.

I sort of slightly buy Anthony's argument that /sys/hypervisor should
just expose information about the hypervisor.

/sys/devices/system/memory/{target,current,max,..} ?

Ian

Re: [PATCH] Sysfs Interface for balloon driver

[John Levon]

On Thu, Sep 21, 2006 at 12:23:34AM +0100, Ian Pratt wrote:

> /sys/devices/system/memory/{target,current,max,..} ?

Sounds pretty good to me.

regards
john

Re: [PATCH] Sysfs Interface for balloon driver

[Anthony Liguori]

Ian Pratt wrote:
>> Personally, I think the ballooning information ought to be exposed as
>>     
> a
>   
>> module parameter and appear in the sysfs module path.  I've always
>> thought /sys/hypervisor ought to expose information from the
>>     
> hypervisor.
>
> I don't think the memory target stuff is a driver. 'balloon' should not
> appear in the name anyhow -- this stuff is getting ever more closely
> integrated with Linux's core memory management anyhow, it's definitely
> not a driver.
>
> I sort of slightly buy Anthony's argument that /sys/hypervisor should
> just expose information about the hypervisor.
>
> /sys/devices/system/memory/{target,current,max,..} ?
>   

Works for me.

Regards,

Anthony Liguori

> Ian
>
>
>
>   

RE: [PATCH] Sysfs Interface for balloon driver

[Satoshi Uchida]

[-- Attachment #1.1: Type: text/plain, Size: 1069 bytes --]

Thanks Ian, Anthony, John.

> I don't think the memory target stuff is a driver. 'balloon' 
> should not appear in the name anyhow -- this stuff is getting 
> ever more closely integrated with Linux's core memory 
> management anyhow, it's definitely not a driver.

> /sys/devices/system/memory/{target,current,max,..} ?

OK.


> I sort of slightly buy Anthony's argument that 
> /sys/hypervisor should just expose information about the hypervisor.

I also think such.

However, where should VM (domain) information is located?
Such location will be probably appeared in future.
And, will a reader (or developer) be perplexed at location which needed information is stored?
Currently, information about virtualization stored sparsely.
Should make a location for gathering such information?

It is important not to make the user conscious which native or VM.
It might be better to store information in general location and to use symlink for gathering location.
By such reason, balloon information may be better to locate under /sys/class/mem.


Regards,
Satoshi UCHIDA

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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