* [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to mod_devicetable.h
From: K. Y. Srinivasan @ 2011-07-15 17:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang
In-Reply-To: <1310752065-27895-1-git-send-email-kys@microsoft.com>
In preparation for implementing vmbus aliases for auto-loading
Hyper-V drivers, define vmbus specific device ID.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
include/linux/mod_devicetable.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index ae28e93..5a12377 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -405,6 +405,13 @@ struct virtio_device_id {
};
#define VIRTIO_DEV_ANY_ID 0xffffffff
+/*
+ * For Hyper-V devices we use the device guid as the id.
+ */
+struct hv_vmbus_device_id {
+ __u8 guid[16];
+};
+
/* i2c */
#define I2C_NAME_SIZE 20
--
1.7.4.1
^ permalink raw reply related
* [PATCH 002/117] Staging: hv: Replace struct hv_guid with the uuid type already defined in Linux
From: K. Y. Srinivasan @ 2011-07-15 17:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang
In-Reply-To: <1310752065-27895-1-git-send-email-kys@microsoft.com>
Replace struct hv_guid with the uuid type already defined in Linux.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/staging/hv/blkvsc_drv.c | 18 +++---
drivers/staging/hv/channel.c | 4 +-
drivers/staging/hv/channel_mgmt.c | 50 ++++++-------
drivers/staging/hv/hv_mouse.c | 6 +-
drivers/staging/hv/hyperv.h | 24 +++----
drivers/staging/hv/hyperv_vmbus.h | 8 +-
drivers/staging/hv/netvsc.c | 6 +-
drivers/staging/hv/storvsc_drv.c | 6 +-
drivers/staging/hv/vmbus_drv.c | 142 ++++++++++++++++++------------------
9 files changed, 129 insertions(+), 135 deletions(-)
diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
index d286b22..018b293 100644
--- a/drivers/staging/hv/blkvsc_drv.c
+++ b/drivers/staging/hv/blkvsc_drv.c
@@ -112,8 +112,8 @@ struct block_device_context {
static const char *drv_name = "blkvsc";
/* {32412632-86cb-44a2-9b5c-50d1417354f5} */
-static const struct hv_guid dev_type = {
- .data = {
+static const uuid_le dev_type = {
+ .b = {
0x32, 0x26, 0x41, 0x32, 0xcb, 0x86, 0xa2, 0x44,
0x9b, 0x5c, 0x50, 0xd1, 0x41, 0x73, 0x54, 0xf5
}
@@ -155,13 +155,13 @@ static int blkvsc_device_add(struct hv_device *device,
* id. For IDE devices, the device instance id is formatted as
* <bus id> * - <device id> - 8899 - 000000000000.
*/
- device_info->path_id = device->dev_instance.data[3] << 24 |
- device->dev_instance.data[2] << 16 |
- device->dev_instance.data[1] << 8 |
- device->dev_instance.data[0];
+ device_info->path_id = device->dev_instance.b[3] << 24 |
+ device->dev_instance.b[2] << 16 |
+ device->dev_instance.b[1] << 8 |
+ device->dev_instance.b[0];
- device_info->target_id = device->dev_instance.data[5] << 8 |
- device->dev_instance.data[4];
+ device_info->target_id = device->dev_instance.b[5] << 8 |
+ device->dev_instance.b[4];
return ret;
}
@@ -829,7 +829,7 @@ static int blkvsc_drv_init(void)
BUILD_BUG_ON(sizeof(sector_t) != 8);
- memcpy(&drv->dev_type, &dev_type, sizeof(struct hv_guid));
+ memcpy(&drv->dev_type, &dev_type, sizeof(uuid_le));
drv->driver.name = drv_name;
/* The driver belongs to vmbus */
diff --git a/drivers/staging/hv/channel.c b/drivers/staging/hv/channel.c
index 455f47a..222adcc 100644
--- a/drivers/staging/hv/channel.c
+++ b/drivers/staging/hv/channel.c
@@ -81,10 +81,10 @@ void vmbus_get_debug_info(struct vmbus_channel *channel,
debuginfo->relid = channel->offermsg.child_relid;
debuginfo->state = channel->state;
memcpy(&debuginfo->interfacetype,
- &channel->offermsg.offer.if_type, sizeof(struct hv_guid));
+ &channel->offermsg.offer.if_type, sizeof(uuid_le));
memcpy(&debuginfo->interface_instance,
&channel->offermsg.offer.if_instance,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
monitorpage = (struct hv_monitor_page *)vmbus_connection.monitor_pages;
diff --git a/drivers/staging/hv/channel_mgmt.c b/drivers/staging/hv/channel_mgmt.c
index bf011f3..11beb41 100644
--- a/drivers/staging/hv/channel_mgmt.c
+++ b/drivers/staging/hv/channel_mgmt.c
@@ -40,12 +40,12 @@ struct vmbus_channel_message_table_entry {
#define MAX_MSG_TYPES 4
#define MAX_NUM_DEVICE_CLASSES_SUPPORTED 8
-static const struct hv_guid
+static const uuid_le
supported_device_classes[MAX_NUM_DEVICE_CLASSES_SUPPORTED] = {
/* {ba6163d9-04a1-4d29-b605-72e2ffb1dc7f} */
/* Storage - SCSI */
{
- .data = {
+ .b = {
0xd9, 0x63, 0x61, 0xba, 0xa1, 0x04, 0x29, 0x4d,
0xb6, 0x05, 0x72, 0xe2, 0xff, 0xb1, 0xdc, 0x7f
}
@@ -54,7 +54,7 @@ static const struct hv_guid
/* {F8615163-DF3E-46c5-913F-F2D2F965ED0E} */
/* Network */
{
- .data = {
+ .b = {
0x63, 0x51, 0x61, 0xF8, 0x3E, 0xDF, 0xc5, 0x46,
0x91, 0x3F, 0xF2, 0xD2, 0xF9, 0x65, 0xED, 0x0E
}
@@ -63,7 +63,7 @@ static const struct hv_guid
/* {CFA8B69E-5B4A-4cc0-B98B-8BA1A1F3F95A} */
/* Input */
{
- .data = {
+ .b = {
0x9E, 0xB6, 0xA8, 0xCF, 0x4A, 0x5B, 0xc0, 0x4c,
0xB9, 0x8B, 0x8B, 0xA1, 0xA1, 0xF3, 0xF9, 0x5A
}
@@ -72,7 +72,7 @@ static const struct hv_guid
/* {32412632-86cb-44a2-9b5c-50d1417354f5} */
/* IDE */
{
- .data = {
+ .b = {
0x32, 0x26, 0x41, 0x32, 0xcb, 0x86, 0xa2, 0x44,
0x9b, 0x5c, 0x50, 0xd1, 0x41, 0x73, 0x54, 0xf5
}
@@ -80,7 +80,7 @@ static const struct hv_guid
/* 0E0B6031-5213-4934-818B-38D90CED39DB */
/* Shutdown */
{
- .data = {
+ .b = {
0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB
}
@@ -88,7 +88,7 @@ static const struct hv_guid
/* {9527E630-D0AE-497b-ADCE-E80AB0175CAF} */
/* TimeSync */
{
- .data = {
+ .b = {
0x30, 0xe6, 0x27, 0x95, 0xae, 0xd0, 0x7b, 0x49,
0xad, 0xce, 0xe8, 0x0a, 0xb0, 0x17, 0x5c, 0xaf
}
@@ -96,7 +96,7 @@ static const struct hv_guid
/* {57164f39-9115-4e78-ab55-382f3bd5422d} */
/* Heartbeat */
{
- .data = {
+ .b = {
0x39, 0x4f, 0x16, 0x57, 0x15, 0x91, 0x78, 0x4e,
0xab, 0x55, 0x38, 0x2f, 0x3b, 0xd5, 0x42, 0x2d
}
@@ -104,7 +104,7 @@ static const struct hv_guid
/* {A9A0F4E7-5A45-4d96-B827-8A841E8C03E6} */
/* KVP */
{
- .data = {
+ .b = {
0xe7, 0xf4, 0xa0, 0xa9, 0x45, 0x5a, 0x96, 0x4d,
0xb8, 0x27, 0x8a, 0x84, 0x1e, 0x8c, 0x3, 0xe6
}
@@ -231,7 +231,7 @@ struct hyperv_service_callback hv_cb_utils[MAX_MSG_TYPES] = {
/* Shutdown */
{
.msg_type = HV_SHUTDOWN_MSG,
- .data = {
+ .data.b = {
0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB
},
@@ -242,7 +242,7 @@ struct hyperv_service_callback hv_cb_utils[MAX_MSG_TYPES] = {
/* TimeSync */
{
.msg_type = HV_TIMESYNC_MSG,
- .data = {
+ .data.b = {
0x30, 0xe6, 0x27, 0x95, 0xae, 0xd0, 0x7b, 0x49,
0xad, 0xce, 0xe8, 0x0a, 0xb0, 0x17, 0x5c, 0xaf
},
@@ -252,7 +252,7 @@ struct hyperv_service_callback hv_cb_utils[MAX_MSG_TYPES] = {
/* Heartbeat */
{
.msg_type = HV_HEARTBEAT_MSG,
- .data = {
+ .data.b = {
0x39, 0x4f, 0x16, 0x57, 0x15, 0x91, 0x78, 0x4e,
0xab, 0x55, 0x38, 0x2f, 0x3b, 0xd5, 0x42, 0x2d
},
@@ -261,7 +261,7 @@ struct hyperv_service_callback hv_cb_utils[MAX_MSG_TYPES] = {
/* {A9A0F4E7-5A45-4d96-B827-8A841E8C03E6} */
/* KVP */
{
- .data = {
+ .data.b = {
0xe7, 0xf4, 0xa0, 0xa9, 0x45, 0x5a, 0x96, 0x4d,
0xb8, 0x27, 0x8a, 0x84, 0x1e, 0x8c, 0x3, 0xe6
},
@@ -358,12 +358,10 @@ static void vmbus_process_offer(struct work_struct *work)
spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
- if (!memcmp(&channel->offermsg.offer.if_type,
- &newchannel->offermsg.offer.if_type,
- sizeof(struct hv_guid)) &&
- !memcmp(&channel->offermsg.offer.if_instance,
- &newchannel->offermsg.offer.if_instance,
- sizeof(struct hv_guid))) {
+ if (!uuid_le_cmp(channel->offermsg.offer.if_type,
+ newchannel->offermsg.offer.if_type) &&
+ !uuid_le_cmp(channel->offermsg.offer.if_instance,
+ newchannel->offermsg.offer.if_instance)) {
fnew = false;
break;
}
@@ -416,9 +414,8 @@ static void vmbus_process_offer(struct work_struct *work)
/* Open IC channels */
for (cnt = 0; cnt < MAX_MSG_TYPES; cnt++) {
- if (memcmp(&newchannel->offermsg.offer.if_type,
- &hv_cb_utils[cnt].data,
- sizeof(struct hv_guid)) == 0 &&
+ if (!uuid_le_cmp(newchannel->offermsg.offer.if_type,
+ hv_cb_utils[cnt].data) &&
vmbus_open(newchannel, 2 * PAGE_SIZE,
2 * PAGE_SIZE, NULL, 0,
chn_cb_negotiate,
@@ -444,16 +441,15 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
{
struct vmbus_channel_offer_channel *offer;
struct vmbus_channel *newchannel;
- struct hv_guid *guidtype;
- struct hv_guid *guidinstance;
+ uuid_le *guidtype;
+ uuid_le *guidinstance;
int i;
int fsupported = 0;
offer = (struct vmbus_channel_offer_channel *)hdr;
for (i = 0; i < MAX_NUM_DEVICE_CLASSES_SUPPORTED; i++) {
- if (memcmp(&offer->offer.if_type,
- &supported_device_classes[i],
- sizeof(struct hv_guid)) == 0) {
+ if (!uuid_le_cmp(offer->offer.if_type,
+ supported_device_classes[i])) {
fsupported = 1;
break;
}
diff --git a/drivers/staging/hv/hv_mouse.c b/drivers/staging/hv/hv_mouse.c
index b191810..6f0992a 100644
--- a/drivers/staging/hv/hv_mouse.c
+++ b/drivers/staging/hv/hv_mouse.c
@@ -180,8 +180,8 @@ struct mousevsc_dev {
static const char *driver_name = "mousevsc";
/* {CFA8B69E-5B4A-4cc0-B98B-8BA1A1F3F95A} */
-static const struct hv_guid mouse_guid = {
- .data = {0x9E, 0xB6, 0xA8, 0xCF, 0x4A, 0x5B, 0xc0, 0x4c,
+static const uuid_le mouse_guid = {
+ .b = {0x9E, 0xB6, 0xA8, 0xCF, 0x4A, 0x5B, 0xc0, 0x4c,
0xB9, 0x8B, 0x8B, 0xA1, 0xA1, 0xF3, 0xF9, 0x5A}
};
@@ -933,7 +933,7 @@ static int __init mousevsc_init(void)
DPRINT_INFO(INPUTVSC_DRV, "Hyper-V Mouse driver initializing.");
memcpy(&drv->dev_type, &mouse_guid,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
drv->driver.name = driver_name;
diff --git a/drivers/staging/hv/hyperv.h b/drivers/staging/hv/hyperv.h
index 1747a24..399d9fe 100644
--- a/drivers/staging/hv/hyperv.h
+++ b/drivers/staging/hv/hyperv.h
@@ -27,6 +27,7 @@
#include <linux/scatterlist.h>
#include <linux/list.h>
+#include <linux/uuid.h>
#include <linux/timer.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
@@ -35,9 +36,6 @@
#include <asm/hyperv.h>
-struct hv_guid {
- unsigned char data[16];
-};
#define MAX_PAGE_BUFFER_COUNT 16
#define MAX_MULTIPAGE_BUFFER_COUNT 32 /* 128K */
@@ -156,8 +154,8 @@ struct hv_ring_buffer_debug_info {
* struct contains the fundamental information about an offer.
*/
struct vmbus_channel_offer {
- struct hv_guid if_type;
- struct hv_guid if_instance;
+ uuid_le if_type;
+ uuid_le if_instance;
u64 int_latency; /* in 100ns units */
u32 if_revision;
u32 server_ctx_size; /* in bytes */
@@ -526,8 +524,8 @@ enum vmbus_channel_state {
struct vmbus_channel_debug_info {
u32 relid;
enum vmbus_channel_state state;
- struct hv_guid interfacetype;
- struct hv_guid interface_instance;
+ uuid_le interfacetype;
+ uuid_le interface_instance;
u32 monitorid;
u32 servermonitor_pending;
u32 servermonitor_latency;
@@ -786,8 +784,8 @@ struct hv_dev_port_info {
struct hv_device_info {
u32 chn_id;
u32 chn_state;
- struct hv_guid chn_type;
- struct hv_guid chn_instance;
+ uuid_le chn_type;
+ uuid_le chn_instance;
u32 monitor_id;
u32 server_monitor_pending;
@@ -806,7 +804,7 @@ struct hv_driver {
const char *name;
/* the device type supported by this driver */
- struct hv_guid dev_type;
+ uuid_le dev_type;
struct device_driver driver;
@@ -819,10 +817,10 @@ struct hv_driver {
/* Base device object */
struct hv_device {
/* the device type id of this device */
- struct hv_guid dev_type;
+ uuid_le dev_type;
/* the device instance id of this device */
- struct hv_guid dev_instance;
+ uuid_le dev_instance;
struct device device;
@@ -935,7 +933,7 @@ struct ictimesync_data {
struct hyperv_service_callback {
u8 msg_type;
char *log_msg;
- unsigned char data[16];
+ uuid_le data;
struct vmbus_channel *channel;
void (*callback) (void *context);
};
diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/staging/hv/hyperv_vmbus.h
index 349ad80..16ca90d 100644
--- a/drivers/staging/hv/hyperv_vmbus.h
+++ b/drivers/staging/hv/hyperv_vmbus.h
@@ -451,8 +451,8 @@ enum {
/* #define VMBUS_PORT_ID 11 */
/* 628180B8-308D-4c5e-B7DB-1BEB62E62EF4 */
-static const struct hv_guid VMBUS_SERVICE_ID = {
- .data = {
+static const uuid_le VMBUS_SERVICE_ID = {
+ .b = {
0xb8, 0x80, 0x81, 0x62, 0x8d, 0x30, 0x5e, 0x4c,
0xb7, 0xdb, 0x1b, 0xeb, 0x62, 0xe6, 0x2e, 0xf4
},
@@ -601,8 +601,8 @@ extern struct vmbus_connection vmbus_connection;
/* General vmbus interface */
-struct hv_device *vmbus_child_device_create(struct hv_guid *type,
- struct hv_guid *instance,
+struct hv_device *vmbus_child_device_create(uuid_le *type,
+ uuid_le *instance,
struct vmbus_channel *channel);
int vmbus_child_device_register(struct hv_device *child_device_obj);
diff --git a/drivers/staging/hv/netvsc.c b/drivers/staging/hv/netvsc.c
index dc5e5c4..1506b53 100644
--- a/drivers/staging/hv/netvsc.c
+++ b/drivers/staging/hv/netvsc.c
@@ -36,8 +36,8 @@
static const char *driver_name = "netvsc";
/* {F8615163-DF3E-46c5-913F-F2D2F965ED0E} */
-static const struct hv_guid netvsc_device_type = {
- .data = {
+static const uuid_le netvsc_device_type = {
+ .b = {
0x63, 0x51, 0x61, 0xF8, 0x3E, 0xDF, 0xc5, 0x46,
0x91, 0x3F, 0xF2, 0xD2, 0xF9, 0x65, 0xED, 0x0E
}
@@ -1009,7 +1009,7 @@ int netvsc_initialize(struct hv_driver *drv)
{
drv->name = driver_name;
- memcpy(&drv->dev_type, &netvsc_device_type, sizeof(struct hv_guid));
+ memcpy(&drv->dev_type, &netvsc_device_type, sizeof(uuid_le));
return 0;
}
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 7effaf3..e4cdbc5 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -45,8 +45,8 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)");
static const char *driver_name = "storvsc";
/* {ba6163d9-04a1-4d29-b605-72e2ffb1dc7f} */
-static const struct hv_guid stor_vsci_device_type = {
- .data = {
+static const uuid_le stor_vsci_device_type = {
+ .b = {
0xd9, 0x63, 0x61, 0xba, 0xa1, 0x04, 0x29, 0x4d,
0xb6, 0x05, 0x72, 0xe2, 0xff, 0xb1, 0xdc, 0x7f
}
@@ -765,7 +765,7 @@ static int __init storvsc_drv_init(void)
sizeof(u64)));
memcpy(&drv->dev_type, &stor_vsci_device_type,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
if (max_outstanding_req_per_channel <
STORVSC_MAX_IO_REQUESTS)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 559353d..291b4e0 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -64,9 +64,9 @@ static void get_channel_info(struct hv_device *device,
info->chn_id = debug_info.relid;
info->chn_state = debug_info.state;
memcpy(&info->chn_type, &debug_info.interfacetype,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
memcpy(&info->chn_instance, &debug_info.interface_instance,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
info->monitor_id = debug_info.monitorid;
@@ -116,41 +116,41 @@ static ssize_t vmbus_show_device_attr(struct device *dev,
if (!strcmp(dev_attr->attr.name, "class_id")) {
return sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
"%02x%02x%02x%02x%02x%02x%02x%02x}\n",
- device_info.chn_type.data[3],
- device_info.chn_type.data[2],
- device_info.chn_type.data[1],
- device_info.chn_type.data[0],
- device_info.chn_type.data[5],
- device_info.chn_type.data[4],
- device_info.chn_type.data[7],
- device_info.chn_type.data[6],
- device_info.chn_type.data[8],
- device_info.chn_type.data[9],
- device_info.chn_type.data[10],
- device_info.chn_type.data[11],
- device_info.chn_type.data[12],
- device_info.chn_type.data[13],
- device_info.chn_type.data[14],
- device_info.chn_type.data[15]);
+ device_info.chn_type.b[3],
+ device_info.chn_type.b[2],
+ device_info.chn_type.b[1],
+ device_info.chn_type.b[0],
+ device_info.chn_type.b[5],
+ device_info.chn_type.b[4],
+ device_info.chn_type.b[7],
+ device_info.chn_type.b[6],
+ device_info.chn_type.b[8],
+ device_info.chn_type.b[9],
+ device_info.chn_type.b[10],
+ device_info.chn_type.b[11],
+ device_info.chn_type.b[12],
+ device_info.chn_type.b[13],
+ device_info.chn_type.b[14],
+ device_info.chn_type.b[15]);
} else if (!strcmp(dev_attr->attr.name, "device_id")) {
return sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
"%02x%02x%02x%02x%02x%02x%02x%02x}\n",
- device_info.chn_instance.data[3],
- device_info.chn_instance.data[2],
- device_info.chn_instance.data[1],
- device_info.chn_instance.data[0],
- device_info.chn_instance.data[5],
- device_info.chn_instance.data[4],
- device_info.chn_instance.data[7],
- device_info.chn_instance.data[6],
- device_info.chn_instance.data[8],
- device_info.chn_instance.data[9],
- device_info.chn_instance.data[10],
- device_info.chn_instance.data[11],
- device_info.chn_instance.data[12],
- device_info.chn_instance.data[13],
- device_info.chn_instance.data[14],
- device_info.chn_instance.data[15]);
+ device_info.chn_instance.b[3],
+ device_info.chn_instance.b[2],
+ device_info.chn_instance.b[1],
+ device_info.chn_instance.b[0],
+ device_info.chn_instance.b[5],
+ device_info.chn_instance.b[4],
+ device_info.chn_instance.b[7],
+ device_info.chn_instance.b[6],
+ device_info.chn_instance.b[8],
+ device_info.chn_instance.b[9],
+ device_info.chn_instance.b[10],
+ device_info.chn_instance.b[11],
+ device_info.chn_instance.b[12],
+ device_info.chn_instance.b[13],
+ device_info.chn_instance.b[14],
+ device_info.chn_instance.b[15]);
} else if (!strcmp(dev_attr->attr.name, "state")) {
return sprintf(buf, "%d\n", device_info.chn_state);
} else if (!strcmp(dev_attr->attr.name, "id")) {
@@ -246,22 +246,22 @@ static int vmbus_uevent(struct device *device, struct kobj_uevent_env *env)
ret = add_uevent_var(env, "VMBUS_DEVICE_CLASS_GUID={"
"%02x%02x%02x%02x-%02x%02x-%02x%02x-"
"%02x%02x%02x%02x%02x%02x%02x%02x}",
- dev->dev_type.data[3],
- dev->dev_type.data[2],
- dev->dev_type.data[1],
- dev->dev_type.data[0],
- dev->dev_type.data[5],
- dev->dev_type.data[4],
- dev->dev_type.data[7],
- dev->dev_type.data[6],
- dev->dev_type.data[8],
- dev->dev_type.data[9],
- dev->dev_type.data[10],
- dev->dev_type.data[11],
- dev->dev_type.data[12],
- dev->dev_type.data[13],
- dev->dev_type.data[14],
- dev->dev_type.data[15]);
+ dev->dev_type.b[3],
+ dev->dev_type.b[2],
+ dev->dev_type.b[1],
+ dev->dev_type.b[0],
+ dev->dev_type.b[5],
+ dev->dev_type.b[4],
+ dev->dev_type.b[7],
+ dev->dev_type.b[6],
+ dev->dev_type.b[8],
+ dev->dev_type.b[9],
+ dev->dev_type.b[10],
+ dev->dev_type.b[11],
+ dev->dev_type.b[12],
+ dev->dev_type.b[13],
+ dev->dev_type.b[14],
+ dev->dev_type.b[15]);
if (ret)
return ret;
@@ -269,22 +269,22 @@ static int vmbus_uevent(struct device *device, struct kobj_uevent_env *env)
ret = add_uevent_var(env, "VMBUS_DEVICE_DEVICE_GUID={"
"%02x%02x%02x%02x-%02x%02x-%02x%02x-"
"%02x%02x%02x%02x%02x%02x%02x%02x}",
- dev->dev_instance.data[3],
- dev->dev_instance.data[2],
- dev->dev_instance.data[1],
- dev->dev_instance.data[0],
- dev->dev_instance.data[5],
- dev->dev_instance.data[4],
- dev->dev_instance.data[7],
- dev->dev_instance.data[6],
- dev->dev_instance.data[8],
- dev->dev_instance.data[9],
- dev->dev_instance.data[10],
- dev->dev_instance.data[11],
- dev->dev_instance.data[12],
- dev->dev_instance.data[13],
- dev->dev_instance.data[14],
- dev->dev_instance.data[15]);
+ dev->dev_instance.b[3],
+ dev->dev_instance.b[2],
+ dev->dev_instance.b[1],
+ dev->dev_instance.b[0],
+ dev->dev_instance.b[5],
+ dev->dev_instance.b[4],
+ dev->dev_instance.b[7],
+ dev->dev_instance.b[6],
+ dev->dev_instance.b[8],
+ dev->dev_instance.b[9],
+ dev->dev_instance.b[10],
+ dev->dev_instance.b[11],
+ dev->dev_instance.b[12],
+ dev->dev_instance.b[13],
+ dev->dev_instance.b[14],
+ dev->dev_instance.b[15]);
if (ret)
return ret;
@@ -303,7 +303,7 @@ static int vmbus_match(struct device *device, struct device_driver *driver)
/* We found our driver ? */
if (memcmp(&hv_dev->dev_type, &drv->dev_type,
- sizeof(struct hv_guid)) == 0)
+ sizeof(uuid_le)) == 0)
match = 1;
return match;
@@ -630,8 +630,8 @@ EXPORT_SYMBOL(vmbus_child_driver_unregister);
* vmbus_child_device_create - Creates and registers a new child device
* on the vmbus.
*/
-struct hv_device *vmbus_child_device_create(struct hv_guid *type,
- struct hv_guid *instance,
+struct hv_device *vmbus_child_device_create(uuid_le *type,
+ uuid_le *instance,
struct vmbus_channel *channel)
{
struct hv_device *child_device_obj;
@@ -644,9 +644,9 @@ struct hv_device *vmbus_child_device_create(struct hv_guid *type,
}
child_device_obj->channel = channel;
- memcpy(&child_device_obj->dev_type, type, sizeof(struct hv_guid));
+ memcpy(&child_device_obj->dev_type, type, sizeof(uuid_le));
memcpy(&child_device_obj->dev_instance, instance,
- sizeof(struct hv_guid));
+ sizeof(uuid_le));
return child_device_obj;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 001/117] Staging: hv: vmbus: VMBUS is an ACPI enumerated device, get rid of the PCI signature
From: K. Y. Srinivasan @ 2011-07-15 17:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang
In-Reply-To: <1310752024-27854-1-git-send-email-kys@microsoft.com>
VMBUS is an ACPI enumerated device, get rid of the PCI signature.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 1c949f5..559353d 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -28,7 +28,6 @@
#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/sysctl.h>
-#include <linux/pci.h>
#include <linux/dmi.h>
#include <linux/slab.h>
#include <linux/acpi.h>
@@ -754,18 +753,6 @@ static struct acpi_driver vmbus_acpi_driver = {
},
};
-/*
- * We use a PCI table to determine if we should autoload this driver This is
- * needed by distro tools to determine if the hyperv drivers should be
- * installed and/or configured. We don't do anything else with the table, but
- * it needs to be present.
- */
-static const struct pci_device_id microsoft_hv_pci_table[] = {
- { PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
- { 0 }
-};
-MODULE_DEVICE_TABLE(pci, microsoft_hv_pci_table);
-
static int __init hv_acpi_init(void)
{
int ret;
--
1.7.4.1
^ permalink raw reply related
* virtio drivers for Solaris 10 guests?
From: Harald Dunkel @ 2011-07-15 7:41 UTC (permalink / raw)
To: virtualization
Hi folks,
Hopefully its not too much OT on this list:
I am looking for virtio drivers (net and block) for Solaris10.
AFAICS Oracle provides some virtio support for Solaris10
in the Virtualbox guest additions, but this seems to be bound
to Virtualbox on the host. I would like to keep KVM.
Are there other options you would recommend? Any helpful
comment would be highly appreciated.
Regards
Harri
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-07-14 19:38 UTC (permalink / raw)
To: Michael S. Tsirkin, Tom Lendacky
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <20110629084206.GA14627@redhat.com>
On 6/29/11 1:42 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Jun 28, 2011 at 11:08:07AM -0500, Tom Lendacky wrote:
>> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
>>> OK, different people seem to test different trees. In the hope to get
>>> everyone on the same page, I created several variants of this patch so
>>> they can be compared. Whoever's interested, please check out the
>>> following, and tell me how these compare:
>>>
>>> kernel:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>>>
>>> virtio-net-limit-xmit-polling/base - this is net-next baseline to test
>>> against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
>>> virtio-net-limit-xmit-polling/v1 - previous revision of the patch
>>> this does xmit,free,xmit,2*free,free
>>> virtio-net-limit-xmit-polling/v2 - new revision of the patch
>>> this does free,xmit,2*free,free
>>>
>>
>> Here's a summary of the results. I've also attached an ODS format
>> spreadsheet
>> (30 KB in size) that might be easier to analyze and also has some pinned VM
>> results data. I broke the tests down into a local guest-to-guest scenario
>> and a remote host-to-guest scenario.
>>
>> Within the local guest-to-guest scenario I ran:
>> - TCP_RR tests using two different messsage sizes and four different
>> instance counts among 1 pair of VMs and 2 pairs of VMs.
>> - TCP_STREAM tests using four different message sizes and two different
>> instance counts among 1 pair of VMs and 2 pairs of VMs.
>>
>> Within the remote host-to-guest scenario I ran:
>> - TCP_RR tests using two different messsage sizes and four different
>> instance counts to 1 VM and 4 VMs.
>> - TCP_STREAM and TCP_MAERTS tests using four different message sizes and
>> two different instance counts to 1 VM and 4 VMs.
>> over a 10GbE link.
>
> roprabhu, Tom,
>
> Thanks very much for the testing. So on the first glance
> one seems to see a significant performance gain in V0 here,
> and a slightly less significant in V2, with V1
> being worse than base. But I'm afraid that's not the
> whole story, and we'll need to work some more to
> know what really goes on, please see below.
>
>
> Some comments on the results: I found out that V0 because of mistake
> on my part was actually almost identical to base.
> I pushed out virtio-net-limit-xmit-polling/v1a instead that
> actually does what I intended to check. However,
> the fact we get such a huge distribution in the results by Tom
> most likely means that the noise factor is very large.
>
>
> From my experience one way to get stable results is to
> divide the throughput by the host CPU utilization
> (measured by something like mpstat).
> Sometimes throughput doesn't increase (e.g. guest-host)
> by CPU utilization does decrease. So it's interesting.
>
>
> Another issue is that we are trying to improve the latency
> of a busy queue here. However STREAM/MAERTS tests ignore the latency
> (more or less) while TCP_RR by default runs a single packet per queue.
> Without arguing about whether these are practically interesting
> workloads, these results are thus unlikely to be significantly affected
> by the optimization in question.
>
> What we are interested in, thus, is either TCP_RR with a -b flag
> (configure with --enable-burst) or multiple concurrent
> TCP_RRs.
>
>
>
Michael, below are some numbers I got from one round of runs.
Thanks,
Roopa
256byte req/response.
Vcpus and irqs were pinned to 4 cores and the cpu utilization is
Avg across 4 cores.
base:
Numof concurrent TCP_RRs Num of transactions/sec host cpu-util(%)
1 7982.93 15.72
25 67873 28.84
50 112534 52.25
100 192057 86.54
v1
Numof concurrent TCP_RRs Num of transactions/sec host cpu-util(%)
1 7970.94 10.8
25 65496.8 28
50 109858 53.22
100 190155 87.5
v1a
Numof concurrent TCP_RRs Num of transactions/sec host cpu-util (%)
1 7979.81 9.5
25 66786.1 28
50 109552 51
100 190876 88
v2
Numof concurrent TCP_RRs Num of transactions/sec host cpu-util (%)
1 7969.87 16.5
25 67780.1 28.44
50 114966 54.29
100 177982 79.9
^ permalink raw reply
* CFP: 12th IEEE/ACM Int. Symp. on Cluster, Grid and Cloud,Computing (CCGrid) 2012
From: Ioan Raicu @ 2011-07-13 6:21 UTC (permalink / raw)
To: virtualization
12th IEEE/ACM International Symposium on Cluster, Grid and Cloud
Computing (CCGrid 2012) Ottawa, Canada
May 13-16, 2012
http://www.cloudbus.org/ccgrid2012
CALL FOR PAPERS
Rapid advances in processing, communication and systems/middleware
technologies are leading to new paradigms and platforms for computing,
ranging from computing Clusters to widely distributed Grid and
emerging Clouds. CCGrid is a series of very successful conferences,
sponsored by the IEEE Computer Society Technical Committee on Scalable
Computing (TCSC) and ACM, with the overarching goal of bringing
together international researchers, developers, and users and to
provide an international forum to present leading research activities
and results on a broad range of topics related to these platforms and
paradigms and their applications. The conference features keynotes,
technical presentations, posters and research demos, workshops,
tutorials, as well as the SCALE challenges featuring live
demonstrations.
In 2012, CCGrid will come to Canada for the first time and will be
held in Ottawa, the capital city. CCGrid 2012 will have a focus on
important and immediate issues that are significantly influencing all
aspects of cluster, cloud and grid computing. Topics of interest
include, but are not limited to:
* Applications and Experiences: Applications to real and complex
problems in science, engineering, business and society; User
studies; Experiences with large-scale deployments systems or
applications.
* Architecture: System architectures, Design and deployment.
* Autonomic Computing and Cyberinfrastructure: Self managed behavior,
models and technologies; Autonomic paradigms and approaches
(control-based, bio-inspired, emergent, etc.); Bio-inspired
approaches to management; SLA definition and enforcement;
* Performance Modeling and Evaluation: Performance models; Monitoring
and evaluation tools, Analysis of system/application performance;
Benchmarks and testbeds.
* Programming Models, Systems, and Fault-Tolerant Computing:
Programming models for cluster, clouds and grid computing; fault
tolerant infrastructure and algorithms; systems software to enable
efficient computing.
* Multicore and Accelerator-based Computing: Software and application
techniques to utilize multicore architectures and
accelerators/heterogeneous computing systems.
* Scheduling and Resource Management: Techniques to schedule jobs and
resources on clusters, clouds and grid computing platforms.
* Cloud Computing: Cloud architectures; Software tools and techniques
for clouds.
PAPER SUBMISSION
Authors are invited to submit papers electronically. Submitted
manuscripts should be structured as technical papers and may not
exceed 8 letter size (8.5 x 11) pages including figures, tables and
references using the IEEE format for conference proceedings (print
area of 6-1/2 inches (16.51 cm) wide by 8-7/8 inches (22.51 cm) high,
two-column format with columns 3-1/16 inches (7.85 cm) wide with a 3/8
inch (0.81 cm) space between them, single-spaced 10-point Times fully
justified text). Submissions not conforming to these guidelines may be
returned without review. Authors should submit the manuscript in PDF
format and make sure that the file will print on a printer that uses
letter size (8.5 x 11) paper. The official language of the meeting is
English. All manuscripts will be reviewed and will be judged on
correctness, originality, technical strength, significance, quality of
presentation, and interest and relevance to the conference attendees.
Submitted papers must represent original unpublished research that is
not currently under review for any other conference or journal. Papers
not following these guidelines will be rejected without review and
further action may be taken, including (but not limited to)
notifications sent to the heads of the institutions of the authors and
sponsors of the conference. Submissions received after the due date,
exceeding the page limit, or not appropriately structured may not be
considered. Authors may contact the conference chairs for more
information. The proceedings will be published through the IEEE
Computer Society Press, USA and will be made available online through
the IEEE Digital Library.
Submission Link:
https://www.easychair.org/account/signin.cgi?conf=ccgrid2012
CHAIRS
General Chair
* Shikharesh Majumdar, Carleton University, Canada
Program Committee Co-Chairs
* Rajkumar Buyya, University of Melbourne, Australia
* Pavan Balaji, Argonne National Laboratory, USA
Program Committee Vice-chairs
* Daniel S. Katz (Applications and Experiences)
* Dhabaleswar K. Panda (Architecture)
* Manish Parashar (Middleware, Autonomic Computing, and
Cyberinfrastructure)
* Ahmad Afsahi (Performance Modeling and Analysis)
* Xian-He Sun (Performance Measurement and Evaluation)
* William Gropp (Programming Models, Systems, and Fault-Tolerant
computing)
* David Bader (Multicore and Accelerator-based Computing)
* Thomas Fahringer (Scheduling and Resource Management)
* Ignacio Martin Llorente and Madhusudhan Govindaraju (Cloud Computing)
Honorary Chair
* Geoffrey Fox, Indiana University, USA
IMPORTANT DATES
Papers Due: 25 November 2011
Notification of Acceptance: 30 January 2012
Camera Ready Papers Due: 27 February 2012
Sponsors: IEEE Computer Society (TCSE) & ACM SIGARCH (approval pending)
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* CFP: The 21st Int. ACM Symp. on High-Performance Parallel and Distributed Computing (HPDC'12) 2012
From: Ioan Raicu @ 2011-07-12 20:51 UTC (permalink / raw)
To: virtualization
**** CALL FOR PAPERS ****
**** CALL FOR WORKSHOP PROPOSALS ****
The 21st International ACM Symposium on
High-Performance Parallel and Distributed Computing
(HPDC'12)
Delft University of Technology, Delft, the Netherlands
June 18-22, 2012
http://www.hpdc.org/2012
The ACM International Symposium on High-Performance Parallel and Distributed Computing (HPDC)
is the premier annual conference on the design, the implementation, the evaluation, and
the use of parallel and distributed systems for high-end computing. HPDC'12 will take place
in Delft, the Netherlands, a historical, picturesque city that is less than one hour away
from Amsterdam-Schiphol airport. The conference will be held on June 20-22 (Wednesday to
Friday), with affiliated workshops taking place on June 18-19 (Monday and Tuesday).
**** SUBMISSION DEADLINES ****
Abstracts: 16 January 2012
Papers: 23 January 2012 (No extensions!)
**** HPDC'12 GENERAL CHAIR ****
Dick Epema, Delft University of Technology, Delft, the Netherlands
**** HPDC'12 PROGRAM CO-CHAIRS ****
Thilo Kielmann, Vrije Universiteit, Amsterdam, the Netherlands
Matei Ripeanu, The University of British Columbia, Vancouver, Canada
**** HPDC'12 WORKSHOPS CHAIR ****
Alexandru Iosup, Delft University of Technology, Delft, the Netherlands
**** SCOPE AND TOPICS ****
Submissions are welcomed on all forms of high-performance parallel and distributed computing,
including but not limited to clusters, clouds, grids, utility computing, data-intensive
computing, and massively multicore systems. Submissions that explore solutions to estimate
and reduce the energy footprint of such systems are particularly encouraged. All papers
will be evaluated for their originality, potential impact, correctness, quality of
presentation, appropriate presentation of related work, and relevance to the conference,
with a strong preference for rigorous results obtained in operational parallel and
distributed systems.
The topics of interest of the conference include, but are not limited to, the following,
in the context of high-performance parallel and distributed computing:
- Systems, networks, and architectures for high-end computing
- Massively multicore systems
- Virtualization of machines, networks, and storage
- Programming languages and environments
- I/O, storage systems, and data management
- Resource management, energy and cost minimizations
- Performance modeling and analysis
- Fault tolerance, reliability, and availability
- Data-intensive computing
- Applications of parallel and distributed computing
**** PAPER SUBMISSION GUIDELINES ****
Authors are invited to submit technical papers of at most 12 pages in PDF format, including
figures and references. Papers should be formatted in the ACM Proceedings Style and
submitted via the conference web site. No changes to the margins, spacing, or font sizes as
specified by the style file are allowed. Accepted papers will appear in the conference
proceedings, and will be incorporated into the ACM Digital Library. A limited number of
papers will be accepted as posters.
Papers must be self-contained and provide the technical substance required for the program
committee to evaluate their contributions. Submitted papers must be original work that has
not appeared in and is not under consideration for another conference or a journal. See the
ACM Prior Publication Policy for more details.
**** IMPORTANT DATES ****
Workshop Proposals Due: 3 October 2011
Abstracts Due: 16 January 2012
Papers Due: 23 January 2012 (No extensions!)
Reviews Released to Authors: 8 March 2012
Author Rebuttals Due: 12 March 2012
Author Notifications: 19 March 2012
Final Papers Due: 16 April 2012
Conference Dates: 18-22 June 2012
**** CALL FOR WORKSHOP PROPOSALS ****
Workshops affiliated with HPDC will be held on June 18-19 (Monday and Tuesday). For more
information on the workshops and for the complete Call for Workshop Proposals, see the
workshops page on the conference website.
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* CFP: The 12th IEEE/ACM International Conference on Grid Computing (Grid2011)
From: Ioan Raicu @ 2011-07-11 14:24 UTC (permalink / raw)
To: virtualization
Call for Papers
The 12th IEEE/ACM International Conference on Grid Computing (Grid2011)
Lyon, France
Sep 21 - Sep 23, 2011
http://grid2011.mnm-team.org/
Co-located with the EGI Technical Forum and OGF
Sponsored by:
- The IEEE Computer Society Technical Committee on Scalable Computing (pending)
- Association for Computing Machinery Special Interest Group on Computer Architecture (pending)
Grid computing enables the sharing of distributed computing and data
resources such as processing, network bandwidth and storage capacity
to create a cohesive resource environment for executing distributed
applications. The Grid conference series is an annual international
meeting that brings together a community of researchers, developers,
practitioners, and users involved with Grid technology. The objective
of the meeting is to serve as both the premier venue for presenting
foremost research results in the area and as a forum for introducing
and exploring new concepts. The conference will feature invited talks,
workshops, and refereed paper presentations.
Grid 2011 welcomes paper and poster submissions on innovative work
from researchers in academia, industry and government describing
original research work in grid computing. Previous events in this
series have been successful in attracting high quality papers and a
wide international participation. This event will be co-located with
the EGI Technical Forum.
SCOPE
Grid 2011 topics of interest include, but are not limited to:
- Applications, including eScience and eBusiness Applications
- Architectures and Fabrics
- Authentication, Authorization, Auditing and Accounting
- Autonomic and Utility Computing on Global Grids
- Cloud computing
- Cloud, Cluster and Grid Integration
- Creation and Management of Virtual Enterprises and Organizations
- Critical surveys or reflections on the past decade on grid and distributed computing
- Dynamic, Distributed, Data-Intensive Access, Management and Processing
- Energy Efficiency and Grid
- Grid Economy and Business Models
- Infrastructure and Practise of Distributed Computing
- Metadata, Ontologies, and Provenance
- Middleware and Toolkits
- Monitoring, Management and Organization Tools
- Networking
- Performance Measurement and Modelling
- Problem Solving Environments
- Programming Models, Tools and Environments
- Production Cyberinfrastructure
- QoS and SLA Negotiation
- Resource Management, Scheduling, and Runtime Environments
- Scientific, Industrial and Social Implications
- Semantic Grid
- Standardization efforts in Grid
- Virtualization and grid computing
TECHNICAL PAPERS
Grid 2011 invites authors to submit original papers (not published or
under review elsewhere). Papers should be no more than 8 pages in
length (including diagrams and references) and be submitted as a PDF
file by using the submission system: URL
Submission implies the willingness of at least one of the authors to
register and present the paper. A separate conference proceedings will
be published and will also be a part of the IEEE Xplore and the CS
digital library. For author instructions visit www.grid2011.org.
IMPORTANT DATES
15 July 2011 Technical Paper Submission Due
17 August 2011 Paper Acceptance Notifications
24 August 2011 Full and Revised papers due
15 August 2011 Poster submissions Due
25 August 2011 Poster Acceptance Notifications
CONFERENCE ORGANISATION
General Chair: Nils gentschen Felde, MNM, Munich
Program Chair: Shantenu Jha, Rutgers, USA and Edinburgh, UK
Local Chair: Frederic Suter, IN2P3, Lyon
Workshop Chair& Poster Chair: Gilles Fedak, INRIA, Lyon
Proceedings and Publications Chair: Rajkumar Buyya, The University of
Melbourne and Manjrasoft, Australia
Program Vice Chairs:
Clouds and Virtualisation: Roger Barga, Microsoft Research, US
Distributed Production Cyberinfrastructure and Middleware: Andrew Grimshaw, Univ. of Virginia, US
e-Research and Applications: Daniel S. Katz, Univ. of Chicago and Argonne National Lab, US
Tools& Services, Resource Management& Runtime Environments: Ramin Yahyapour, Dortmund
Distributed Data-Intensive Science and Systems: Erwin Laure, KTH, Sweeden
Publicity Chairs:
Suraj Pandey, Univ of Melbourne, Australia
Yoshiyuki Watase, KEK, Japan
Cameron Kiddle, Calgary, Canada
Ioan Raicu, Illinois Institute of Technology and Argonne National Laboratory, USA
Adam Barker, St. Andrew's, UK
CONFERENCE ORGANISATION
General Chair: Nils gentschen Felde, MNM, Munich
Program Chair: Shantenu Jha, Rutgers, USA and Edinburgh, UK
Local Chair: Frederic Suter, IN2P3, Lyon
Workshop Chair& Poster Chair: Gilles Fedak, INRIA, Lyon
Proceedings and Publications Chair: Rajkumar Buyya, The University of
Melbourne and Manjrasoft, Australia
Program Vice Chairs:
Clouds and Virtualisation: Roger Barga, Microsoft Research, US
Distributed Production Cyberinfrastructure and Middleware: Andrew Grimshaw, Univ. of Virginia, US
e-Research and Applications: Daniel S. Katz, Univ. of Chicago and Argonne National Lab, US
Tools& Services, Resource Management& Runtime Environments: Ramin Yahyapour, Dortmund
Distributed Data-Intensive Science and Systems: Erwin Laure, KTH, Sweeden
Publicity Chairs:
Suraj Pandey, Univ of Melbourne, Australia
Yoshiyuki Watase, KEK, Japan
Cameron Kiddle, Calgary, Canada
Ioan Raicu, Illinois Institute of Technology and Argonne National Laboratory, USA
Adam Barker, St. Andrew's, UK
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix (for platform-pci-unplug.c)
From: Stefano Stabellini @ 2011-07-11 10:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xensource.com, Stefano Stabellini,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Raghavendra D Prabhu,
Jeremy Fitzhardinge, Ian Campbell
In-Reply-To: <20110708202628.GA25998@dumpdata.com>
On Fri, 8 Jul 2011, Konrad Rzeszutek Wilk wrote:
> > >>Also,
> > >>I had sent another change (oneline) for the file
> > >>arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
> > >>the pull request for Linus.
> > >
> > >Oh, I didn't see it. Did you CC me on it? Can you bounce it to me please?
> > >
> > =========================
> > diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
> > index 25c52f9..ffcf261 100644
> > --- a/arch/x86/xen/platform-pci-unplug.c
> > +++ b/arch/x86/xen/platform-pci-unplug.c
> > @@ -35,7 +35,7 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
> > #ifdef CONFIG_XEN_PVHVM
> > static int xen_emul_unplug;
> >
> > -static int __init check_platform_magic(void)
> > +static int check_platform_magic(void)
> > {
> > short magic;
> > char protocol;
> > --
> >
>
> Yeah, that would cause an issue during suspend/resume by PVonHVM. How
> we didn't trip over this I've no idea..
>
> Anyhow, can you provide me with your Signed-off-by please and I will queue
> it right up.
>
> Stefano, you OK with this patch?
>
It is fine by me
^ permalink raw reply
* Re: [TOME] Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix (for platform-pci-unplug.c)
From: Raghavendra D Prabhu @ 2011-07-09 16:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, Stefano Stabellini, linux-kernel, virtualization,
jeremy.fitzhardinge, Ian Campbell
In-Reply-To: <20110708202628.GA25998@dumpdata.com>
* On Fri, Jul 08, 2011 at 04:26:28PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >>Also,
>> >>I had sent another change (oneline) for the file
>> >>arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
>> >>the pull request for Linus.
>> >Oh, I didn't see it. Did you CC me on it? Can you bounce it to me please?
>> =========================
>> diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
>> index 25c52f9..ffcf261 100644
>> --- a/arch/x86/xen/platform-pci-unplug.c
>> +++ b/arch/x86/xen/platform-pci-unplug.c
>> @@ -35,7 +35,7 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>> #ifdef CONFIG_XEN_PVHVM
>> static int xen_emul_unplug;
>> -static int __init check_platform_magic(void)
>> +static int check_platform_magic(void)
>> {
>> short magic;
>> char protocol;
>> --
>
>Yeah, that would cause an issue during suspend/resume by PVonHVM. How
>we didn't trip over this I've no idea..
>
>Anyhow, can you provide me with your Signed-off-by please and I will queue
>it right up.
Sorry for missing the Signed-off thing (was there in original one I had sent).
===========================================================
Removing __init from check_platform_magic since it is called by
xen_unplug_emulated_devices in non-init contexts (It probably gets inlined
because of -finline-functions-called-once, removing __init is more to avoid
mismatch being reported).
Signed-off-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
---
arch/x86/xen/platform-pci-unplug.c | 2 +-
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index fe00830..fb5eeb0 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -327,7 +327,7 @@ int __init pci_xen_hvm_init(void)
}
#ifdef CONFIG_XEN_DOM0
-static int xen_register_pirq(u32 gsi, int triggering)
+static __refdata int xen_register_pirq(u32 gsi, int triggering)
{
int rc, pirq, irq = -1;
struct physdev_map_pirq map_irq;
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index 25c52f9..ffcf261 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -35,7 +35,7 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
#ifdef CONFIG_XEN_PVHVM
static int xen_emul_unplug;
-static int __init check_platform_magic(void)
+static int check_platform_magic(void)
{
short magic;
char protocol;
--
>
>Stefano, you OK with this patch?
>
--------------------------
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix (for platform-pci-unplug.c)
From: Konrad Rzeszutek Wilk @ 2011-07-08 20:26 UTC (permalink / raw)
To: Raghavendra D Prabhu, Stefano Stabellini
Cc: xen-devel, virtualization, linux-kernel, jeremy.fitzhardinge,
Ian Campbell
In-Reply-To: <20110707210429.GD4394@Xye>
> >>Also,
> >>I had sent another change (oneline) for the file
> >>arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
> >>the pull request for Linus.
> >
> >Oh, I didn't see it. Did you CC me on it? Can you bounce it to me please?
> >
> =========================
> diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
> index 25c52f9..ffcf261 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -35,7 +35,7 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
> #ifdef CONFIG_XEN_PVHVM
> static int xen_emul_unplug;
>
> -static int __init check_platform_magic(void)
> +static int check_platform_magic(void)
> {
> short magic;
> char protocol;
> --
>
Yeah, that would cause an issue during suspend/resume by PVonHVM. How
we didn't trip over this I've no idea..
Anyhow, can you provide me with your Signed-off-by please and I will queue
it right up.
Stefano, you OK with this patch?
^ permalink raw reply
* Re: [PATCH 2/2] vhost: set log when updating used flags or avail event
From: Jason Wang @ 2011-07-08 10:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20110707125728.GA2469@redhat.com>
On 07/07/2011 08:57 PM, Michael S. Tsirkin wrote:
> Subject: vhost: used ring logging cleanup
>
> remove extra log bit setting for used ring updates: it's no longer
> necessary. Also, use vhost_avail_event instead of duplicating offset
> math.
>
> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
> ---
>
>> We need set log when updating used flags and avail event. Otherwise guest may
>> see stale values after migration and then do not exit or exit unexpectedly.
>>
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> OK but this means we set the log twice now.
> Also, hardcording offset is not as nice as using
> vhost_avail_event. So I think the below is needed
> on top. Comments?
>
Right, thanks for the cleanup.
> drivers/vhost/vhost.c | 29 +++++++++--------------------
> 1 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 540591b..c5f96ba 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -946,14 +946,16 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
>
> static int vhost_update_used_flags(struct vhost_virtqueue *vq)
> {
> + void __user *used;
> if (put_user(vq->used_flags,&vq->used->flags)< 0)
> return -EFAULT;
> if (unlikely(vq->log_used)) {
> /* Make sure the flag is seen before log. */
> smp_wmb();
> /* Log used flag write. */
> - log_write(vq->log_base,
> - vq->log_addr + offsetof(struct vring_used, flags),
> + used =&vq->used->flags;
> + log_write(vq->log_base, vq->log_addr +
> + (used - (void __user *)vq->used),
> sizeof vq->used->flags);
> if (vq->log_ctx)
> eventfd_signal(vq->log_ctx, 1);
> @@ -966,13 +968,14 @@ static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16 avail_event)
> if (put_user(vq->avail_idx, vhost_avail_event(vq)))
> return -EFAULT;
> if (unlikely(vq->log_used)) {
> + void __user *used;
> /* Make sure the event is seen before log. */
> smp_wmb();
> /* Log avail event write */
> - log_write(vq->log_base,
> - vq->log_addr + offsetof(struct vring_used,
> - ring[vq->num]),
> - sizeof avail_event);
> + used = vhost_avail_event(vq);
> + log_write(vq->log_base, vq->log_addr +
> + (used - (void __user *)vq->used),
> + sizeof *vhost_avail_event(vq));
> if (vq->log_ctx)
> eventfd_signal(vq->log_ctx, 1);
> }
> @@ -1474,20 +1477,6 @@ bool vhost_enable_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> return false;
> }
> }
> - if (unlikely(vq->log_used)) {
> - void __user *used;
> - /* Make sure data is seen before log. */
> - smp_wmb();
> - used = vhost_has_feature(dev, VIRTIO_RING_F_EVENT_IDX) ?
> - &vq->used->flags : vhost_avail_event(vq);
> - /* Log used flags or event index entry write. Both are 16 bit
> - * fields. */
> - log_write(vq->log_base, vq->log_addr +
> - (used - (void __user *)vq->used),
> - sizeof(u16));
> - if (vq->log_ctx)
> - eventfd_signal(vq->log_ctx, 1);
> - }
> /* They could have slipped one in as we were doing that: make
> * sure it's written, then check again. */
> smp_mb();
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix
From: Raghavendra D Prabhu @ 2011-07-07 21:04 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-kernel, Ian Campbell, xen-devel, jeremy.fitzhardinge,
virtualization
In-Reply-To: <20110707200949.GA25216@dumpdata.com>
* On Thu, Jul 07, 2011 at 04:09:49PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>On Fri, Jul 08, 2011 at 01:18:51AM +0530, Raghavendra D Prabhu wrote:
>> * On Thu, Jul 07, 2011 at 12:24:54PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >>Tested it. Works now.
>> >Ok, Stuck Tested-by on the patch. Hopefully Linus hasn't pulled it yet.
>> Ok.
>> >>Reviewed-by: Raghavendra Prabhu <rprabhu@wnohang.net>
>> >>Also,
>> >>The condition for acpi_gsi_to_irq can be removed since it always returns zero.
>> >The function might in the future return something that is non-zero
>> >and we should guard for it. Also you make 'irq' be unsigned which is not
>> >good as the IRQ 0 is a valid value - and with making it unsigned if it is
>> >set to -1 (the -1 is the invalid IRQ value) the check for 'irq != gsi'
>> >will be true and and we will pass in -1 casted to unsigned. That is a
>> >large value and not the right thing we want to pass to xen_register_gsi.
>> My rationale for the unsigned part was that acpi_gsi_to_irq always
>> assigns a positive value (>= 0) to the irq passed (as unsigned
>> argument). But even otherwise that shouldn't make much of difference I guess.
>> Also,
>> I had sent another change (oneline) for the file
>> arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
>> the pull request for Linus.
>
>Oh, I didn't see it. Did you CC me on it? Can you bounce it to me please?
>
=========================
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index 25c52f9..ffcf261 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -35,7 +35,7 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
#ifdef CONFIG_XEN_PVHVM
static int xen_emul_unplug;
-static int __init check_platform_magic(void)
+static int check_platform_magic(void)
{
short magic;
char protocol;
--
--------------------------
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix
From: Konrad Rzeszutek Wilk @ 2011-07-07 20:09 UTC (permalink / raw)
To: Raghavendra D Prabhu
Cc: linux-kernel, Ian Campbell, xen-devel, jeremy.fitzhardinge,
virtualization
In-Reply-To: <20110707194851.GB4394@Xye>
On Fri, Jul 08, 2011 at 01:18:51AM +0530, Raghavendra D Prabhu wrote:
> * On Thu, Jul 07, 2011 at 12:24:54PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >>Tested it. Works now.
> >
> >Ok, Stuck Tested-by on the patch. Hopefully Linus hasn't pulled it yet.
> Ok.
> >
> >>Reviewed-by: Raghavendra Prabhu <rprabhu@wnohang.net>
>
> >>Also,
> >>The condition for acpi_gsi_to_irq can be removed since it always returns zero.
> >
> >The function might in the future return something that is non-zero
> >and we should guard for it. Also you make 'irq' be unsigned which is not
> >good as the IRQ 0 is a valid value - and with making it unsigned if it is
> >set to -1 (the -1 is the invalid IRQ value) the check for 'irq != gsi'
> >will be true and and we will pass in -1 casted to unsigned. That is a
> >large value and not the right thing we want to pass to xen_register_gsi.
>
> My rationale for the unsigned part was that acpi_gsi_to_irq always
> assigns a positive value (>= 0) to the irq passed (as unsigned
> argument). But even otherwise that shouldn't make much of difference I guess.
>
> Also,
> I had sent another change (oneline) for the file
> arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
> the pull request for Linus.
Oh, I didn't see it. Did you CC me on it? Can you bounce it to me please?
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix
From: Raghavendra D Prabhu @ 2011-07-07 19:48 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-kernel, Ian Campbell, xen-devel, jeremy.fitzhardinge,
virtualization
In-Reply-To: <20110707162454.GA8164@dumpdata.com>
[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]
* On Thu, Jul 07, 2011 at 12:24:54PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> Tested it. Works now.
>
>Ok, Stuck Tested-by on the patch. Hopefully Linus hasn't pulled it yet.
Ok.
>
>> Reviewed-by: Raghavendra Prabhu <rprabhu@wnohang.net>
>> Also,
>> The condition for acpi_gsi_to_irq can be removed since it always returns zero.
>
>The function might in the future return something that is non-zero
>and we should guard for it. Also you make 'irq' be unsigned which is not
>good as the IRQ 0 is a valid value - and with making it unsigned if it is
>set to -1 (the -1 is the invalid IRQ value) the check for 'irq != gsi'
>will be true and and we will pass in -1 casted to unsigned. That is a
>large value and not the right thing we want to pass to xen_register_gsi.
My rationale for the unsigned part was that acpi_gsi_to_irq always
assigns a positive value (>= 0) to the irq passed (as unsigned
argument). But even otherwise that shouldn't make much of difference I guess.
Also,
I had sent another change (oneline) for the file
arch/x86/xen/platform-pci-unplug.c for check_platform_magic, looks like that has not gone into
the pull request for Linus.
>
>
>> ============================================
>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> index f567965..3faa55b 100644
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
>> @@ -405,7 +405,7 @@ static __init void xen_setup_acpi_sci(void)
>> int rc;
>> int trigger, polarity;
>> int gsi = acpi_sci_override_gsi;
>> - int irq = -1;
>> + unsigned int irq = 0u;
>> int gsi_override = -1;
>> if (!gsi)
>> @@ -435,11 +435,10 @@ static __init void xen_setup_acpi_sci(void)
>> * setup as we had setup IRQ 20 for it).
>> */
>> /* Check whether the GSI != IRQ */
>> - if (acpi_gsi_to_irq(gsi, &irq) == 0) {
>> - if (irq >= 0 && irq != gsi)
>> - /* Bugger, we MUST have that IRQ. */
>> - gsi_override = irq;
>> - }
>> + acpi_gsi_to_irq(gsi, &irq);
>> + if (irq != gsi)
>> + /* Bugger, we MUST have that IRQ. */
>> + gsi_override = irq;
>> gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
>> printk(KERN_INFO "xen: acpi sci %d\n", gsi);
>> --------------------------
>> Raghavendra Prabhu
>> GPG Id : 0xD72BE977
>> Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
>> www: wnohang.net
>
>
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
--------------------------
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net
[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] Modpost section mismatch fix
From: Konrad Rzeszutek Wilk @ 2011-07-07 16:24 UTC (permalink / raw)
To: Raghavendra D Prabhu
Cc: linux-kernel, Ian Campbell, xen-devel, jeremy.fitzhardinge,
virtualization
In-Reply-To: <20110707154648.GA4394@Xye>
> Tested it. Works now.
Ok, Stuck Tested-by on the patch. Hopefully Linus hasn't pulled it yet.
> Reviewed-by: Raghavendra Prabhu <rprabhu@wnohang.net>
>
> Also,
> The condition for acpi_gsi_to_irq can be removed since it always returns zero.
The function might in the future return something that is non-zero
and we should guard for it. Also you make 'irq' be unsigned which is not
good as the IRQ 0 is a valid value - and with making it unsigned if it is
set to -1 (the -1 is the invalid IRQ value) the check for 'irq != gsi'
will be true and and we will pass in -1 casted to unsigned. That is a
large value and not the right thing we want to pass to xen_register_gsi.
> ============================================
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index f567965..3faa55b 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -405,7 +405,7 @@ static __init void xen_setup_acpi_sci(void)
> int rc;
> int trigger, polarity;
> int gsi = acpi_sci_override_gsi;
> - int irq = -1;
> + unsigned int irq = 0u;
> int gsi_override = -1;
>
> if (!gsi)
> @@ -435,11 +435,10 @@ static __init void xen_setup_acpi_sci(void)
> * setup as we had setup IRQ 20 for it).
> */
> /* Check whether the GSI != IRQ */
> - if (acpi_gsi_to_irq(gsi, &irq) == 0) {
> - if (irq >= 0 && irq != gsi)
> - /* Bugger, we MUST have that IRQ. */
> - gsi_override = irq;
> - }
> + acpi_gsi_to_irq(gsi, &irq);
> + if (irq != gsi)
> + /* Bugger, we MUST have that IRQ. */
> + gsi_override = irq;
>
> gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
> printk(KERN_INFO "xen: acpi sci %d\n", gsi);
>
>
> --------------------------
> Raghavendra Prabhu
> GPG Id : 0xD72BE977
> Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
> www: wnohang.net
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] Modpost section mismatch fix
From: Raghavendra D Prabhu @ 2011-07-07 15:46 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, jeremy.fitzhardinge, virtualization, linux-kernel,
Ian Campbell
In-Reply-To: <20110705213243.GA3647@dumpdata.com>
[-- Attachment #1.1: Type: text/plain, Size: 6959 bytes --]
* On Tue, Jul 05, 2011 at 05:32:43PM -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>On Tue, Jul 05, 2011 at 10:48:46AM -0400, Konrad Rzeszutek Wilk wrote:
>> > >>xen_register_gsi and hence, xen_register_pirq are called from
>> > >>init (with xen_setup_acpi_sci) and non-init (with
>> > >>acpi_register_gsi_xen); since xen_set_acpi_sci calls it with gsi ==
>> > >>acpi_sci_override_gsi and is marked __init, the best way would be to
>> > >>call xen_register_gsi and xen_register_pirq with a boolean argument like
>> > >>sci_override to obviate the need to use acpi_sci_override_gsi in
>> > >>register_pirq. I will send the patch with this change if it looks good.
>> > >Hold on, let me rebase #stable/pci.cleanups and see if the issue
>> > >here disappears.
>> > Thanks, will wait until the rebase and test after that.
>> Hm, it actually looks like it wont do the trick. Why don't you send
>> a patch against 3.0-rc6 with the outlined mechanism mentioned above.
>
>Or this patch (against 3.0-rc6) might do the trick:
>
>diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>index fe00830..f567965 100644
>--- a/arch/x86/pci/xen.c
>+++ b/arch/x86/pci/xen.c
>@@ -327,13 +327,12 @@ int __init pci_xen_hvm_init(void)
> }
>
> #ifdef CONFIG_XEN_DOM0
>-static int xen_register_pirq(u32 gsi, int triggering)
>+static int xen_register_pirq(u32 gsi, int gsi_override, int triggering)
> {
> int rc, pirq, irq = -1;
> struct physdev_map_pirq map_irq;
> int shareable = 0;
> char *name;
>- bool gsi_override = false;
>
> if (!xen_pv_domain())
> return -1;
>@@ -345,31 +344,12 @@ static int xen_register_pirq(u32 gsi, int triggering)
> shareable = 1;
> name = "ioapic-level";
> }
>-
> pirq = xen_allocate_pirq_gsi(gsi);
> if (pirq < 0)
> goto out;
>
>- /* Before we bind the GSI to a Linux IRQ, check whether
>- * we need to override it with bus_irq (IRQ) value. Usually for
>- * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
>- * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
>- * but there are oddballs where the IRQ != GSI:
>- * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
>- * which ends up being: gsi_to_irq[9] == 20
>- * (which is what acpi_gsi_to_irq ends up calling when starting the
>- * the ACPI interpreter and keels over since IRQ 9 has not been
>- * setup as we had setup IRQ 20 for it).
>- */
>- if (gsi == acpi_sci_override_gsi) {
>- /* Check whether the GSI != IRQ */
>- acpi_gsi_to_irq(gsi, &irq);
>- if (irq != gsi)
>- /* Bugger, we MUST have that IRQ. */
>- gsi_override = true;
>- }
>- if (gsi_override)
>- irq = xen_bind_pirq_gsi_to_irq(irq, pirq, shareable, name);
>+ if (gsi_override >= 0)
>+ irq = xen_bind_pirq_gsi_to_irq(gsi_override, pirq, shareable, name);
> else
> irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name);
> if (irq < 0)
>@@ -392,7 +372,7 @@ out:
> return irq;
> }
>
>-static int xen_register_gsi(u32 gsi, int triggering, int polarity)
>+static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
> {
> int rc, irq;
> struct physdev_setup_gsi setup_gsi;
>@@ -403,7 +383,7 @@ static int xen_register_gsi(u32 gsi, int triggering, int polarity)
> printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
> gsi, triggering, polarity);
>
>- irq = xen_register_pirq(gsi, triggering);
>+ irq = xen_register_pirq(gsi, gsi_override, triggering);
>
> setup_gsi.gsi = gsi;
> setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
>@@ -425,6 +405,8 @@ static __init void xen_setup_acpi_sci(void)
> int rc;
> int trigger, polarity;
> int gsi = acpi_sci_override_gsi;
>+ int irq = -1;
>+ int gsi_override = -1;
>
> if (!gsi)
> return;
>@@ -441,7 +423,25 @@ static __init void xen_setup_acpi_sci(void)
> printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
> "polarity=%d\n", gsi, trigger, polarity);
>
>- gsi = xen_register_gsi(gsi, trigger, polarity);
>+ /* Before we bind the GSI to a Linux IRQ, check whether
>+ * we need to override it with bus_irq (IRQ) value. Usually for
>+ * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
>+ * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
>+ * but there are oddballs where the IRQ != GSI:
>+ * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
>+ * which ends up being: gsi_to_irq[9] == 20
>+ * (which is what acpi_gsi_to_irq ends up calling when starting the
>+ * the ACPI interpreter and keels over since IRQ 9 has not been
>+ * setup as we had setup IRQ 20 for it).
>+ */
>+ /* Check whether the GSI != IRQ */
>+ if (acpi_gsi_to_irq(gsi, &irq) == 0) {
>+ if (irq >= 0 && irq != gsi)
>+ /* Bugger, we MUST have that IRQ. */
>+ gsi_override = irq;
>+ }
>+
>+ gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
> printk(KERN_INFO "xen: acpi sci %d\n", gsi);
>
> return;
>@@ -450,7 +450,7 @@ static __init void xen_setup_acpi_sci(void)
> static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
> int trigger, int polarity)
> {
>- return xen_register_gsi(gsi, trigger, polarity);
>+ return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
> }
>
> static int __init pci_xen_initial_domain(void)
>@@ -489,7 +489,7 @@ void __init xen_setup_pirqs(void)
> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
> continue;
>
>- xen_register_pirq(irq,
>+ xen_register_pirq(irq, -1 /* no GSI override */,
> trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE);
> }
> }
>
Tested it. Works now.
Reviewed-by: Raghavendra Prabhu <rprabhu@wnohang.net>
Also,
The condition for acpi_gsi_to_irq can be removed since it always returns zero.
============================================
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index f567965..3faa55b 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -405,7 +405,7 @@ static __init void xen_setup_acpi_sci(void)
int rc;
int trigger, polarity;
int gsi = acpi_sci_override_gsi;
- int irq = -1;
+ unsigned int irq = 0u;
int gsi_override = -1;
if (!gsi)
@@ -435,11 +435,10 @@ static __init void xen_setup_acpi_sci(void)
* setup as we had setup IRQ 20 for it).
*/
/* Check whether the GSI != IRQ */
- if (acpi_gsi_to_irq(gsi, &irq) == 0) {
- if (irq >= 0 && irq != gsi)
- /* Bugger, we MUST have that IRQ. */
- gsi_override = irq;
- }
+ acpi_gsi_to_irq(gsi, &irq);
+ if (irq != gsi)
+ /* Bugger, we MUST have that IRQ. */
+ gsi_override = irq;
gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
printk(KERN_INFO "xen: acpi sci %d\n", gsi);
--------------------------
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net
[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-07-07 13:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Tom Lendacky
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <20110629084206.GA14627@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]
On 6/29/11 1:42 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> >roprabhu, Tom,
>> >
>> >Thanks very much for the testing. So on the first glance
>> >one seems to see a significant performance gain in V0 here,
>> >and a slightly less significant in V2, with V1
>> >being worse than base. But I'm afraid that's not the
>> >whole story, and we'll need to work some more to
>> >know what really goes on, please see below.
>> >
>> >
>> >Some comments on the results: I found out that V0 because of mistake
>> >on my part was actually almost identical to base.
>> >I pushed out virtio-net-limit-xmit-polling/v1a instead that
>> >actually does what I intended to check. However,
>> >the fact we get such a huge distribution in the results by Tom
>> >most likely means that the noise factor is very large.
>> >
>> >
>> >From my experience one way to get stable results is to
>> >divide the throughput by the host CPU utilization
>> >(measured by something like mpstat).
>> >Sometimes throughput doesn't increase (e.g. guest-host)
>> >by CPU utilization does decrease. So it's interesting.
>> >
>> >
>> >Another issue is that we are trying to improve the latency
>> >of a busy queue here. However STREAM/MAERTS tests ignore the latency
>> >(more or less) while TCP_RR by default runs a single packet per queue.
>> >Without arguing about whether these are practically interesting
>> >workloads, these results are thus unlikely to be significantly affected
>> >by the optimization in question.
>> >
>> >What we are interested in, thus, is either TCP_RR with a -b flag
>> >(configure with --enable-burst) or multiple concurrent
>> >TCP_RRs.
>
> ok sounds good. I am testing your v1a patch. Will try to get some results out
> end of this week. Thanks.
>
[-- Attachment #1.2: Type: text/html, Size: 2328 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 2/2] vhost: set log when updating used flags or avail event
From: Michael S. Tsirkin @ 2011-07-07 12:57 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20110621100438.6777.20695.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
Subject: vhost: used ring logging cleanup
remove extra log bit setting for used ring updates: it's no longer
necessary. Also, use vhost_avail_event instead of duplicating offset
math.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
> We need set log when updating used flags and avail event. Otherwise guest may
> see stale values after migration and then do not exit or exit unexpectedly.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
OK but this means we set the log twice now.
Also, hardcording offset is not as nice as using
vhost_avail_event. So I think the below is needed
on top. Comments?
drivers/vhost/vhost.c | 29 +++++++++--------------------
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 540591b..c5f96ba 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -946,14 +946,16 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
static int vhost_update_used_flags(struct vhost_virtqueue *vq)
{
+ void __user *used;
if (put_user(vq->used_flags, &vq->used->flags) < 0)
return -EFAULT;
if (unlikely(vq->log_used)) {
/* Make sure the flag is seen before log. */
smp_wmb();
/* Log used flag write. */
- log_write(vq->log_base,
- vq->log_addr + offsetof(struct vring_used, flags),
+ used = &vq->used->flags;
+ log_write(vq->log_base, vq->log_addr +
+ (used - (void __user *)vq->used),
sizeof vq->used->flags);
if (vq->log_ctx)
eventfd_signal(vq->log_ctx, 1);
@@ -966,13 +968,14 @@ static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16 avail_event)
if (put_user(vq->avail_idx, vhost_avail_event(vq)))
return -EFAULT;
if (unlikely(vq->log_used)) {
+ void __user *used;
/* Make sure the event is seen before log. */
smp_wmb();
/* Log avail event write */
- log_write(vq->log_base,
- vq->log_addr + offsetof(struct vring_used,
- ring[vq->num]),
- sizeof avail_event);
+ used = vhost_avail_event(vq);
+ log_write(vq->log_base, vq->log_addr +
+ (used - (void __user *)vq->used),
+ sizeof *vhost_avail_event(vq));
if (vq->log_ctx)
eventfd_signal(vq->log_ctx, 1);
}
@@ -1474,20 +1477,6 @@ bool vhost_enable_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
return false;
}
}
- if (unlikely(vq->log_used)) {
- void __user *used;
- /* Make sure data is seen before log. */
- smp_wmb();
- used = vhost_has_feature(dev, VIRTIO_RING_F_EVENT_IDX) ?
- &vq->used->flags : vhost_avail_event(vq);
- /* Log used flags or event index entry write. Both are 16 bit
- * fields. */
- log_write(vq->log_base, vq->log_addr +
- (used - (void __user *)vq->used),
- sizeof(u16));
- if (vq->log_ctx)
- eventfd_signal(vq->log_ctx, 1);
- }
/* They could have slipped one in as we were doing that: make
* sure it's written, then check again. */
smp_mb();
--
1.7.5.53.gc233e
^ permalink raw reply related
* RE: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate MODULE_ALIAS() line
From: KY Srinivasan @ 2011-07-06 15:47 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Hank Janssen
In-Reply-To: <20110706152916.GB30350@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, July 06, 2011 11:29 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang; Hank
> Janssen
> Subject: Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate
> MODULE_ALIAS() line
>
> On Wed, Jul 06, 2011 at 03:17:37PM +0000, KY Srinivasan wrote:
> > It is certainly easier to deal with a small integer than with 128bit giud and there
> is
> > no added benefit dealing with guids since the number of drivers we will support
> > under vmbus will never exceed a very small number. Having said that, I will go
> ahead
> > and embed full guids as you have suggested. So, the aliases for these drivers
> will be:
> > vmbus:device guid.
>
> Wait, no, you will never be typing "MODULE_ALIAS()" in your driver at
> all, it will be created automatically for you by the proper macro fun
> with the MODULE_DEVICE_TABLE() line. The same variable you use in that
> macro will be used to register the driver with the vmbus core.
I was referring to the name that would be generated by the parsing code
In file2alias.c. I have an id_table field in the struct hv_driver and this will point
to the table that will setup. This table will be used in the vmbus match function
as well as to generate hotplug events.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate MODULE_ALIAS() line
From: Greg KH @ 2011-07-06 15:29 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Hank Janssen
In-Reply-To: <6E21E5352C11B742B20C142EB499E0480816D432@TK5EX14MBXC126.redmond.corp.microsoft.com>
On Wed, Jul 06, 2011 at 03:17:37PM +0000, KY Srinivasan wrote:
> It is certainly easier to deal with a small integer than with 128bit giud and there is
> no added benefit dealing with guids since the number of drivers we will support
> under vmbus will never exceed a very small number. Having said that, I will go ahead
> and embed full guids as you have suggested. So, the aliases for these drivers will be:
> vmbus:device guid.
Wait, no, you will never be typing "MODULE_ALIAS()" in your driver at
all, it will be created automatically for you by the proper macro fun
with the MODULE_DEVICE_TABLE() line. The same variable you use in that
macro will be used to register the driver with the vmbus core.
No one ever sees module aliases in the "raw" anymore, except for the
platform legacy crud.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate MODULE_ALIAS() line
From: KY Srinivasan @ 2011-07-06 15:17 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Hank Janssen
In-Reply-To: <20110706150202.GA3353@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, July 06, 2011 11:02 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang; Hank
> Janssen
> Subject: Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate
> MODULE_ALIAS() line
>
> On Wed, Jul 06, 2011 at 02:55:12PM +0000, KY Srinivasan wrote:
> > > > I think you mean MODULE_DEVICE_TABLE()?
> > >
> > > Yes, sorry for the typo.
> > >
> > > > I actually went down that path first
> > > > adding code to file2alias.c for parsing the vmbus ID table. Given that this
> > > approach
> > > > would make it impossible to support auto-loading of these drivers
> > > > on many of the released kernels,
> > >
> > > Wait, what? What is a "released kernel"? We are working on the
> > > in-kernel patch, we don't care about older distros/releases for this
> > > work at all. Also, it doesn't make sense at all, why would the change I
> > > asked for make any difference on older distros/kernels?
> >
> > I understand we don't care here about older kernels and I will do what you
> > have suggested. I just wanted to give you the rationale for choices I made:
> > We are currently supporting older distros/kernels using these upstream bits.
> > With the MODULE_ALIAS() approach, since I did not have to change any code
> > outside the hv directory, this was possible. I was mostly concerned about
> > having to make changes to code outside the hv directory and figuring out
> > how to build and propagate these changes (file2alias.c) in older kernels.
>
> You create a patch like any other patch and give it to the people who
> are stuck with those older kernels. It shouldn't be that hard, and it
> also shouldn't be something that matters for this mainline work either.
>
> > > > I chose to go with the MODULE_ALIAS() macro that did not need any
> > > > changes outside our drivers. In both methods, the formatting of the
> > > > name is bus specific since I would be writing the code to parse the
> > > > table in file2alias.c.
> > >
> > > Yes, that is what is needed to be done.
> > >
> > > > Granted, I have been quite unimaginative in my alias names, but I
> > > > thought they were reasonably descriptive. If at all possible, for the
> > > > reasons listed above, I would prefer to use the MODULE_ALIAS() macro
> > > > (I could embed all or part of the guid in the alias). Let me know.
> > >
> > > Please do the correct thing and use MODULE_DEVICE_TABLE().
> >
> > We have four drivers now excluding vmbus and soon we will have only three
> > drivers with the merge of block and stor drivers. Would you still recommend I
> use the
> > full guid to name these drivers.
>
> Yes, why not?
>
> > Rather than embedding the entire 128bit guid in module aliases, I was
> > thinking of setting up a more reasonable namespace for these drivers
> > (like what virtio has done for instance). Let me know if this is ok
> > with you if I took that route (mapping the guid to small integers and
> > having these integers be used in alias strings).
>
> What's the big deal of having a large number as an alias? Is there some
> constraint here that I am not aware of?
It is certainly easier to deal with a small integer than with 128bit giud and there is
no added benefit dealing with guids since the number of drivers we will support
under vmbus will never exceed a very small number. Having said that, I will go ahead
and embed full guids as you have suggested. So, the aliases for these drivers will be:
vmbus:device guid.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate MODULE_ALIAS() line
From: Greg KH @ 2011-07-06 15:02 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Hank Janssen
In-Reply-To: <6E21E5352C11B742B20C142EB499E0480816D414@TK5EX14MBXC126.redmond.corp.microsoft.com>
On Wed, Jul 06, 2011 at 02:55:12PM +0000, KY Srinivasan wrote:
> > > I think you mean MODULE_DEVICE_TABLE()?
> >
> > Yes, sorry for the typo.
> >
> > > I actually went down that path first
> > > adding code to file2alias.c for parsing the vmbus ID table. Given that this
> > approach
> > > would make it impossible to support auto-loading of these drivers
> > > on many of the released kernels,
> >
> > Wait, what? What is a "released kernel"? We are working on the
> > in-kernel patch, we don't care about older distros/releases for this
> > work at all. Also, it doesn't make sense at all, why would the change I
> > asked for make any difference on older distros/kernels?
>
> I understand we don't care here about older kernels and I will do what you
> have suggested. I just wanted to give you the rationale for choices I made:
> We are currently supporting older distros/kernels using these upstream bits.
> With the MODULE_ALIAS() approach, since I did not have to change any code
> outside the hv directory, this was possible. I was mostly concerned about
> having to make changes to code outside the hv directory and figuring out
> how to build and propagate these changes (file2alias.c) in older kernels.
You create a patch like any other patch and give it to the people who
are stuck with those older kernels. It shouldn't be that hard, and it
also shouldn't be something that matters for this mainline work either.
> > > I chose to go with the MODULE_ALIAS() macro that did not need any
> > > changes outside our drivers. In both methods, the formatting of the
> > > name is bus specific since I would be writing the code to parse the
> > > table in file2alias.c.
> >
> > Yes, that is what is needed to be done.
> >
> > > Granted, I have been quite unimaginative in my alias names, but I
> > > thought they were reasonably descriptive. If at all possible, for the
> > > reasons listed above, I would prefer to use the MODULE_ALIAS() macro
> > > (I could embed all or part of the guid in the alias). Let me know.
> >
> > Please do the correct thing and use MODULE_DEVICE_TABLE().
>
> We have four drivers now excluding vmbus and soon we will have only three
> drivers with the merge of block and stor drivers. Would you still recommend I use the
> full guid to name these drivers.
Yes, why not?
> Rather than embedding the entire 128bit guid in module aliases, I was
> thinking of setting up a more reasonable namespace for these drivers
> (like what virtio has done for instance). Let me know if this is ok
> with you if I took that route (mapping the guid to small integers and
> having these integers be used in alias strings).
What's the big deal of having a large number as an alias? Is there some
constraint here that I am not aware of?
greg k-h
^ permalink raw reply
* RE: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate MODULE_ALIAS() line
From: KY Srinivasan @ 2011-07-06 14:55 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Hank Janssen
In-Reply-To: <20110706034228.GA4291@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, July 05, 2011 11:42 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang; Hank
> Janssen
> Subject: Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate
> MODULE_ALIAS() line
>
> On Wed, Jul 06, 2011 at 12:40:42AM +0000, KY Srinivasan wrote:
> > > > diff --git a/drivers/staging/hv/blkvsc_drv.c
> b/drivers/staging/hv/blkvsc_drv.c
> > > > index 5842db8..9496abe 100644
> > > > --- a/drivers/staging/hv/blkvsc_drv.c
> > > > +++ b/drivers/staging/hv/blkvsc_drv.c
> > > > @@ -1027,5 +1027,6 @@ static void __exit blkvsc_exit(void)
> > > > MODULE_LICENSE("GPL");
> > > > MODULE_VERSION(HV_DRV_VERSION);
> > > > MODULE_DESCRIPTION("Microsoft Hyper-V virtual block driver");
> > > > +MODULE_ALIAS("vmbus:hv_block");
> > >
> > > No, these should be automagically generated with the MODULE_DEVICE_ID()
> > > macro that you use in the module with the GUID there, instead of this.
> >
> > I think you mean MODULE_DEVICE_TABLE()?
>
> Yes, sorry for the typo.
>
> > I actually went down that path first
> > adding code to file2alias.c for parsing the vmbus ID table. Given that this
> approach
> > would make it impossible to support auto-loading of these drivers
> > on many of the released kernels,
>
> Wait, what? What is a "released kernel"? We are working on the
> in-kernel patch, we don't care about older distros/releases for this
> work at all. Also, it doesn't make sense at all, why would the change I
> asked for make any difference on older distros/kernels?
I understand we don't care here about older kernels and I will do what you
have suggested. I just wanted to give you the rationale for choices I made:
We are currently supporting older distros/kernels using these upstream bits.
With the MODULE_ALIAS() approach, since I did not have to change any code
outside the hv directory, this was possible. I was mostly concerned about
having to make changes to code outside the hv directory and figuring out
how to build and propagate these changes (file2alias.c) in older kernels.
>
> > I chose to go with the MODULE_ALIAS() macro that did not need any
> > changes outside our drivers. In both methods, the formatting of the
> > name is bus specific since I would be writing the code to parse the
> > table in file2alias.c.
>
> Yes, that is what is needed to be done.
>
> > Granted, I have been quite unimaginative in my alias names, but I
> > thought they were reasonably descriptive. If at all possible, for the
> > reasons listed above, I would prefer to use the MODULE_ALIAS() macro
> > (I could embed all or part of the guid in the alias). Let me know.
>
> Please do the correct thing and use MODULE_DEVICE_TABLE().
We have four drivers now excluding vmbus and soon we will have only three
drivers with the merge of block and stor drivers. Would you still recommend I use the
full guid to name these drivers. Rather than embedding the entire 128bit guid in module
aliases, I was thinking of setting up a more reasonable namespace for these drivers
(like what virtio has done for instance). Let me know if this is ok with you if I took that
route (mapping the guid to small integers and having these integers be used in alias strings).
Regards,
K. Y
^ permalink raw reply
* Re: [Xen-devel] Re: [TOME] Re: [PATCH] Modpost section mismatch fix
From: Ian Campbell @ 2011-07-06 8:30 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-kernel@vger.kernel.org, Raghavendra D Prabhu,
xen-devel@lists.xensource.com, Jeremy Fitzhardinge,
virtualization@lists.linux-foundation.org
In-Reply-To: <20110705213243.GA3647@dumpdata.com>
On Tue, 2011-07-05 at 22:32 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 05, 2011 at 10:48:46AM -0400, Konrad Rzeszutek Wilk wrote:
> > > >>xen_register_gsi and hence, xen_register_pirq are called from
> > > >>init (with xen_setup_acpi_sci) and non-init (with
> > > >>acpi_register_gsi_xen); since xen_set_acpi_sci calls it with gsi ==
> > > >>acpi_sci_override_gsi and is marked __init, the best way would be to
> > > >>call xen_register_gsi and xen_register_pirq with a boolean argument like
> > > >>sci_override to obviate the need to use acpi_sci_override_gsi in
> > > >>register_pirq. I will send the patch with this change if it looks good.
> > > >
> > > >Hold on, let me rebase #stable/pci.cleanups and see if the issue
> > > >here disappears.
> > > Thanks, will wait until the rebase and test after that.
> >
> > Hm, it actually looks like it wont do the trick. Why don't you send
> > a patch against 3.0-rc6 with the outlined mechanism mentioned above.
>
> Or this patch (against 3.0-rc6) might do the trick:
Based on my limited understanding it looks like it would to me.
But is there some downside to always unconditionally calling
acpi_gsi_to_irq in xen_register_pirq? It seems like it returns the
expected mapping except where explicit overrides (such as this SCI
thing) exist?
Ian.
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index fe00830..f567965 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -327,13 +327,12 @@ int __init pci_xen_hvm_init(void)
> }
>
> #ifdef CONFIG_XEN_DOM0
> -static int xen_register_pirq(u32 gsi, int triggering)
> +static int xen_register_pirq(u32 gsi, int gsi_override, int triggering)
> {
> int rc, pirq, irq = -1;
> struct physdev_map_pirq map_irq;
> int shareable = 0;
> char *name;
> - bool gsi_override = false;
>
> if (!xen_pv_domain())
> return -1;
> @@ -345,31 +344,12 @@ static int xen_register_pirq(u32 gsi, int triggering)
> shareable = 1;
> name = "ioapic-level";
> }
> -
> pirq = xen_allocate_pirq_gsi(gsi);
> if (pirq < 0)
> goto out;
>
> - /* Before we bind the GSI to a Linux IRQ, check whether
> - * we need to override it with bus_irq (IRQ) value. Usually for
> - * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
> - * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> - * but there are oddballs where the IRQ != GSI:
> - * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
> - * which ends up being: gsi_to_irq[9] == 20
> - * (which is what acpi_gsi_to_irq ends up calling when starting the
> - * the ACPI interpreter and keels over since IRQ 9 has not been
> - * setup as we had setup IRQ 20 for it).
> - */
> - if (gsi == acpi_sci_override_gsi) {
> - /* Check whether the GSI != IRQ */
> - acpi_gsi_to_irq(gsi, &irq);
> - if (irq != gsi)
> - /* Bugger, we MUST have that IRQ. */
> - gsi_override = true;
> - }
> - if (gsi_override)
> - irq = xen_bind_pirq_gsi_to_irq(irq, pirq, shareable, name);
> + if (gsi_override >= 0)
> + irq = xen_bind_pirq_gsi_to_irq(gsi_override, pirq, shareable, name);
> else
> irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name);
> if (irq < 0)
> @@ -392,7 +372,7 @@ out:
> return irq;
> }
>
> -static int xen_register_gsi(u32 gsi, int triggering, int polarity)
> +static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
> {
> int rc, irq;
> struct physdev_setup_gsi setup_gsi;
> @@ -403,7 +383,7 @@ static int xen_register_gsi(u32 gsi, int triggering, int polarity)
> printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
> gsi, triggering, polarity);
>
> - irq = xen_register_pirq(gsi, triggering);
> + irq = xen_register_pirq(gsi, gsi_override, triggering);
>
> setup_gsi.gsi = gsi;
> setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
> @@ -425,6 +405,8 @@ static __init void xen_setup_acpi_sci(void)
> int rc;
> int trigger, polarity;
> int gsi = acpi_sci_override_gsi;
> + int irq = -1;
> + int gsi_override = -1;
>
> if (!gsi)
> return;
> @@ -441,7 +423,25 @@ static __init void xen_setup_acpi_sci(void)
> printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
> "polarity=%d\n", gsi, trigger, polarity);
>
> - gsi = xen_register_gsi(gsi, trigger, polarity);
> + /* Before we bind the GSI to a Linux IRQ, check whether
> + * we need to override it with bus_irq (IRQ) value. Usually for
> + * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
> + * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> + * but there are oddballs where the IRQ != GSI:
> + * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
> + * which ends up being: gsi_to_irq[9] == 20
> + * (which is what acpi_gsi_to_irq ends up calling when starting the
> + * the ACPI interpreter and keels over since IRQ 9 has not been
> + * setup as we had setup IRQ 20 for it).
> + */
> + /* Check whether the GSI != IRQ */
> + if (acpi_gsi_to_irq(gsi, &irq) == 0) {
> + if (irq >= 0 && irq != gsi)
> + /* Bugger, we MUST have that IRQ. */
> + gsi_override = irq;
> + }
> +
> + gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
> printk(KERN_INFO "xen: acpi sci %d\n", gsi);
>
> return;
> @@ -450,7 +450,7 @@ static __init void xen_setup_acpi_sci(void)
> static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
> int trigger, int polarity)
> {
> - return xen_register_gsi(gsi, trigger, polarity);
> + return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
> }
>
> static int __init pci_xen_initial_domain(void)
> @@ -489,7 +489,7 @@ void __init xen_setup_pirqs(void)
> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
> continue;
>
> - xen_register_pirq(irq,
> + xen_register_pirq(irq, -1 /* no GSI override */,
> trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE);
> }
> }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
--
Ian Campbell
While having never invented a sin, I'm trying to perfect several.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox