[PATCH] VMCI: Check userland-provided datagram size
Ensure that the size filled in by userland in the datagram header
matches the size of the buffer passed down in the IOCTL. Note that we
account for the size of the header itself in the check.
Acked-by: Jorgen Hansen
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
Reported-by: David Ramos
---
drivers/misc/vmw_vmci/vmci_driver.c | 2 +-
drivers/misc/vmw_vmci/vmci_host.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 032d35c..cf264a1 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
-MODULE_VERSION("1.1.1.0-k");
+MODULE_VERSION("1.1.2.0-k");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/misc/vmw_vmci/vmci_host.c
b/drivers/misc/vmw_vmci/vmci_host.c
index 66fc992..a721b5d 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -395,6 +395,12 @@ static int vmci_host_do_send_datagram(struct vmci_host_dev
*vmci_host_dev,
return -EFAULT;
}
+ if (VMCI_DG_SIZE(dg) != send_info.len) {
+ vmci_ioctl_err("datagram size mismatch\n");
+ kfree(dg);
+ return -EINVAL;
+ }
+
pr_devel("Datagram dst (handle=0x%x:0x%x) src (handle=0x%x:0x%x),
payload (size=%llu bytes)\n",
dg->dst.context, dg->dst.resource,
dg->src.context, dg->src.resource,
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMCI: Check userland-provided datagram size
Ensure that the size filled in by userland in the datagram header
matches the size of the buffer passed down in the IOCTL. Note that we
account for the size of the header itself in the check.
Acked-by: Jorgen Hansen jhan...@vmware.com
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
Reported-by: David Ramos dara...@stanford.edu
---
drivers/misc/vmw_vmci/vmci_driver.c | 2 +-
drivers/misc/vmw_vmci/vmci_host.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 032d35c..cf264a1 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Machine Communication Interface.);
-MODULE_VERSION(1.1.1.0-k);
+MODULE_VERSION(1.1.2.0-k);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/misc/vmw_vmci/vmci_host.c
b/drivers/misc/vmw_vmci/vmci_host.c
index 66fc992..a721b5d 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -395,6 +395,12 @@ static int vmci_host_do_send_datagram(struct vmci_host_dev
*vmci_host_dev,
return -EFAULT;
}
+ if (VMCI_DG_SIZE(dg) != send_info.len) {
+ vmci_ioctl_err(datagram size mismatch\n);
+ kfree(dg);
+ return -EINVAL;
+ }
+
pr_devel(Datagram dst (handle=0x%x:0x%x) src (handle=0x%x:0x%x),
payload (size=%llu bytes)\n,
dg-dst.context, dg-dst.resource,
dg-src.context, dg-src.resource,
--
1.8.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
This version addresses Sergei's comments. o Fixed description and added Reported-by o Removed NULL check for kfree() -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Check for map error in vmxnet3_set_mc
We should check if the map of the table actually succeeds, and also free
resources accordingly.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
Reported-by: Tetsuo Handa
---
drivers/net/vmxnet3/vmxnet3_drv.c | 15 ---
drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..6dfcbf5 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2056,7 +2056,6 @@ vmxnet3_set_mc(struct net_device *netdev)
if (!netdev_mc_empty(netdev)) {
new_table = vmxnet3_copy_mc(netdev);
if (new_table) {
- new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
new_table_pa = dma_map_single(
@@ -2064,15 +2063,18 @@ vmxnet3_set_mc(struct net_device *netdev)
new_table,
rxConf->mfTableLen,
PCI_DMA_TODEVICE);
+ }
+
+ if (new_table_pa) {
+ new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTablePA = cpu_to_le64(new_table_pa);
} else {
- netdev_info(netdev, "failed to copy mcast list"
- ", setting ALL_MULTI\n");
+ netdev_info(netdev,
+ "failed to copy mcast list, setting
ALL_MULTI\n");
new_mode |= VMXNET3_RXM_ALL_MULTI;
}
}
-
if (!(new_mode & VMXNET3_RXM_MCAST)) {
rxConf->mfTableLen = 0;
rxConf->mfTablePA = 0;
@@ -2091,11 +2093,10 @@ vmxnet3_set_mc(struct net_device *netdev)
VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(>cmd_lock, flags);
- if (new_table) {
+ if (new_table_pa)
dma_unmap_single(>pdev->dev, new_table_pa,
rxConf->mfTableLen, PCI_DMA_TODEVICE);
- kfree(new_table);
- }
+ kfree(new_table);
}
void
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 29ee77f2..3759479 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.2.0.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.2.1.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x0102
+#define VMXNET3_DRIVER_VERSION_NUM 0x01020100
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Check for map error in vmxnet3_set_mc
We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.c | 14 --
drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..f450010 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2056,7 +2056,6 @@ vmxnet3_set_mc(struct net_device *netdev)
if (!netdev_mc_empty(netdev)) {
new_table = vmxnet3_copy_mc(netdev);
if (new_table) {
- new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
new_table_pa = dma_map_single(
@@ -2064,15 +2063,18 @@ vmxnet3_set_mc(struct net_device *netdev)
new_table,
rxConf->mfTableLen,
PCI_DMA_TODEVICE);
+ }
+
+ if (new_table_pa) {
+ new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTablePA = cpu_to_le64(new_table_pa);
} else {
- netdev_info(netdev, "failed to copy mcast list"
- ", setting ALL_MULTI\n");
+ netdev_info(netdev,
+ "failed to copy mcast list, setting
ALL_MULTI\n");
new_mode |= VMXNET3_RXM_ALL_MULTI;
}
}
-
if (!(new_mode & VMXNET3_RXM_MCAST)) {
rxConf->mfTableLen = 0;
rxConf->mfTablePA = 0;
@@ -2091,11 +2093,11 @@ vmxnet3_set_mc(struct net_device *netdev)
VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(>cmd_lock, flags);
- if (new_table) {
+ if (new_table_pa)
dma_unmap_single(>pdev->dev, new_table_pa,
rxConf->mfTableLen, PCI_DMA_TODEVICE);
+ if (new_table)
kfree(new_table);
- }
}
void
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 29ee77f2..3759479 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.2.0.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.2.1.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x0102
+#define VMXNET3_DRIVER_VERSION_NUM 0x01020100
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Check for map error in vmxnet3_set_mc
We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong shelleyg...@vmware.com
Acked-by: Bhavesh Davda bhav...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/net/vmxnet3/vmxnet3_drv.c | 14 --
drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..f450010 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2056,7 +2056,6 @@ vmxnet3_set_mc(struct net_device *netdev)
if (!netdev_mc_empty(netdev)) {
new_table = vmxnet3_copy_mc(netdev);
if (new_table) {
- new_mode |= VMXNET3_RXM_MCAST;
rxConf-mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
new_table_pa = dma_map_single(
@@ -2064,15 +2063,18 @@ vmxnet3_set_mc(struct net_device *netdev)
new_table,
rxConf-mfTableLen,
PCI_DMA_TODEVICE);
+ }
+
+ if (new_table_pa) {
+ new_mode |= VMXNET3_RXM_MCAST;
rxConf-mfTablePA = cpu_to_le64(new_table_pa);
} else {
- netdev_info(netdev, failed to copy mcast list
- , setting ALL_MULTI\n);
+ netdev_info(netdev,
+ failed to copy mcast list, setting
ALL_MULTI\n);
new_mode |= VMXNET3_RXM_ALL_MULTI;
}
}
-
if (!(new_mode VMXNET3_RXM_MCAST)) {
rxConf-mfTableLen = 0;
rxConf-mfTablePA = 0;
@@ -2091,11 +2093,11 @@ vmxnet3_set_mc(struct net_device *netdev)
VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(adapter-cmd_lock, flags);
- if (new_table) {
+ if (new_table_pa)
dma_unmap_single(adapter-pdev-dev, new_table_pa,
rxConf-mfTableLen, PCI_DMA_TODEVICE);
+ if (new_table)
kfree(new_table);
- }
}
void
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 29ee77f2..3759479 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING 1.2.0.0-k
+#define VMXNET3_DRIVER_VERSION_STRING 1.2.1.0-k
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x0102
+#define VMXNET3_DRIVER_VERSION_NUM 0x01020100
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Check for map error in vmxnet3_set_mc
We should check if the map of the table actually succeeds, and also free
resources accordingly.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong shelleyg...@vmware.com
Acked-by: Bhavesh Davda bhav...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
Reported-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
---
drivers/net/vmxnet3/vmxnet3_drv.c | 15 ---
drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..6dfcbf5 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2056,7 +2056,6 @@ vmxnet3_set_mc(struct net_device *netdev)
if (!netdev_mc_empty(netdev)) {
new_table = vmxnet3_copy_mc(netdev);
if (new_table) {
- new_mode |= VMXNET3_RXM_MCAST;
rxConf-mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
new_table_pa = dma_map_single(
@@ -2064,15 +2063,18 @@ vmxnet3_set_mc(struct net_device *netdev)
new_table,
rxConf-mfTableLen,
PCI_DMA_TODEVICE);
+ }
+
+ if (new_table_pa) {
+ new_mode |= VMXNET3_RXM_MCAST;
rxConf-mfTablePA = cpu_to_le64(new_table_pa);
} else {
- netdev_info(netdev, failed to copy mcast list
- , setting ALL_MULTI\n);
+ netdev_info(netdev,
+ failed to copy mcast list, setting
ALL_MULTI\n);
new_mode |= VMXNET3_RXM_ALL_MULTI;
}
}
-
if (!(new_mode VMXNET3_RXM_MCAST)) {
rxConf-mfTableLen = 0;
rxConf-mfTablePA = 0;
@@ -2091,11 +2093,10 @@ vmxnet3_set_mc(struct net_device *netdev)
VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(adapter-cmd_lock, flags);
- if (new_table) {
+ if (new_table_pa)
dma_unmap_single(adapter-pdev-dev, new_table_pa,
rxConf-mfTableLen, PCI_DMA_TODEVICE);
- kfree(new_table);
- }
+ kfree(new_table);
}
void
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 29ee77f2..3759479 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING 1.2.0.0-k
+#define VMXNET3_DRIVER_VERSION_STRING 1.2.1.0-k
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x0102
+#define VMXNET3_DRIVER_VERSION_NUM 0x01020100
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
This version addresses Sergei's comments. o Fixed description and added Reported-by o Removed NULL check for kfree() -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vsock: Make transport the proto owner
Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.
Includes version bump to 1.0.1.0-k
Passes checkpatch this time, I swear...
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/net/af_vsock.h |6 -
net/vmw_vsock/af_vsock.c | 47 +
2 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 7d64d36..4282778 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -155,7 +155,11 @@ struct vsock_transport {
/ CORE /
-int vsock_core_init(const struct vsock_transport *t);
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner);
+static inline int vsock_core_init(const struct vsock_transport *t)
+{
+ return __vsock_core_init(t, THIS_MODULE);
+}
void vsock_core_exit(void);
/ UTILS /
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5adfd94..85d232b 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1925,9 +1925,23 @@ static struct miscdevice vsock_device = {
.fops = _device_ops,
};
-static int __vsock_core_init(void)
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
{
- int err;
+ int err = mutex_lock_interruptible(_register_mutex);
+
+ if (err)
+ return err;
+
+ if (transport) {
+ err = -EBUSY;
+ goto err_busy;
+ }
+
+ /* Transport must be the owner of the protocol so that it can't
+* unload while there are open sockets.
+*/
+ vsock_proto.owner = owner;
+ transport = t;
vsock_init_tables();
@@ -1951,36 +1965,19 @@ static int __vsock_core_init(void)
goto err_unregister_proto;
}
+ mutex_unlock(_register_mutex);
return 0;
err_unregister_proto:
proto_unregister(_proto);
err_misc_deregister:
misc_deregister(_device);
- return err;
-}
-
-int vsock_core_init(const struct vsock_transport *t)
-{
- int retval = mutex_lock_interruptible(_register_mutex);
- if (retval)
- return retval;
-
- if (transport) {
- retval = -EBUSY;
- goto out;
- }
-
- transport = t;
- retval = __vsock_core_init();
- if (retval)
- transport = NULL;
-
-out:
+ transport = NULL;
+err_busy:
mutex_unlock(_register_mutex);
- return retval;
+ return err;
}
-EXPORT_SYMBOL_GPL(vsock_core_init);
+EXPORT_SYMBOL_GPL(__vsock_core_init);
void vsock_core_exit(void)
{
@@ -2000,5 +1997,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Socket Family");
-MODULE_VERSION("1.0.0.0-k");
+MODULE_VERSION("1.0.1.0-k");
MODULE_LICENSE("GPL v2");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vsock: Make transport the proto owner
Oh just shoot me now, doesn't even pass checkpatch *hangs head in shame*
Dave/Greg, flame away if you like...
- Andy
- Original Message -
> Right now the core vsock module is the owner of the proto family. This
> means there's nothing preventing the transport module from unloading if
> there are open sockets, which results in a panic. Fix that by allowing
> the transport to be the owner, which will refcount it properly.
>
> Includes version bump to 1.0.1.0-k
>
> Cc: sta...@vger.kernel.org
> Acked-by: Dmitry Torokhov
> Signed-off-by: Andy King
> ---
> include/net/af_vsock.h |6 +-
> net/vmw_vsock/af_vsock.c | 46
> +-
> 2 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
> index 7d64d36..8f02e5c 100644
> --- a/include/net/af_vsock.h
> +++ b/include/net/af_vsock.h
> @@ -155,7 +155,11 @@ struct vsock_transport {
>
> / CORE /
>
> -int vsock_core_init(const struct vsock_transport *t);
> +int __vsock_core_init(const struct vsock_transport *t, struct module
> *owner);
> +static inline int vsock_core_init(const struct vsock_transport *t)
> +{
> + return __vsock_core_init(t, THIS_MODULE);
> +}
> void vsock_core_exit(void);
>
> / UTILS /
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index 5adfd94..5743553 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -1925,9 +1925,22 @@ static struct miscdevice vsock_device = {
> .fops = _device_ops,
> };
>
> -static int __vsock_core_init(void)
> +int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
> {
> - int err;
> + int err = mutex_lock_interruptible(_register_mutex);
> + if (err)
> + return err;
> +
> + if (transport) {
> + err = -EBUSY;
> + goto err_busy;
> + }
> +
> + /* Transport must be the owner of the protocol so that it can't
> + * unload while there are open sockets.
> + */
> + vsock_proto.owner = owner;
> + transport = t;
>
> vsock_init_tables();
>
> @@ -1951,36 +1964,19 @@ static int __vsock_core_init(void)
> goto err_unregister_proto;
> }
>
> + mutex_unlock(_register_mutex);
> return 0;
>
> err_unregister_proto:
> proto_unregister(_proto);
> err_misc_deregister:
> misc_deregister(_device);
> - return err;
> -}
> -
> -int vsock_core_init(const struct vsock_transport *t)
> -{
> - int retval = mutex_lock_interruptible(_register_mutex);
> - if (retval)
> - return retval;
> -
> - if (transport) {
> - retval = -EBUSY;
> - goto out;
> - }
> -
> - transport = t;
> - retval = __vsock_core_init();
> - if (retval)
> - transport = NULL;
> -
> -out:
> + transport = NULL;
> +err_busy:
> mutex_unlock(_register_mutex);
> - return retval;
> + return err;
> }
> -EXPORT_SYMBOL_GPL(vsock_core_init);
> +EXPORT_SYMBOL_GPL(__vsock_core_init);
>
> void vsock_core_exit(void)
> {
> @@ -2000,5 +1996,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
>
> MODULE_AUTHOR("VMware, Inc.");
> MODULE_DESCRIPTION("VMware Virtual Socket Family");
> -MODULE_VERSION("1.0.0.0-k");
> +MODULE_VERSION("1.0.1.0-k");
> MODULE_LICENSE("GPL v2");
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vsock: Make transport the proto owner
Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.
Includes version bump to 1.0.1.0-k
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/net/af_vsock.h |6 +-
net/vmw_vsock/af_vsock.c | 46 +-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 7d64d36..8f02e5c 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -155,7 +155,11 @@ struct vsock_transport {
/ CORE /
-int vsock_core_init(const struct vsock_transport *t);
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner);
+static inline int vsock_core_init(const struct vsock_transport *t)
+{
+ return __vsock_core_init(t, THIS_MODULE);
+}
void vsock_core_exit(void);
/ UTILS /
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5adfd94..5743553 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1925,9 +1925,22 @@ static struct miscdevice vsock_device = {
.fops = _device_ops,
};
-static int __vsock_core_init(void)
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
{
- int err;
+ int err = mutex_lock_interruptible(_register_mutex);
+ if (err)
+ return err;
+
+ if (transport) {
+ err = -EBUSY;
+ goto err_busy;
+ }
+
+ /* Transport must be the owner of the protocol so that it can't
+* unload while there are open sockets.
+*/
+ vsock_proto.owner = owner;
+ transport = t;
vsock_init_tables();
@@ -1951,36 +1964,19 @@ static int __vsock_core_init(void)
goto err_unregister_proto;
}
+ mutex_unlock(_register_mutex);
return 0;
err_unregister_proto:
proto_unregister(_proto);
err_misc_deregister:
misc_deregister(_device);
- return err;
-}
-
-int vsock_core_init(const struct vsock_transport *t)
-{
- int retval = mutex_lock_interruptible(_register_mutex);
- if (retval)
- return retval;
-
- if (transport) {
- retval = -EBUSY;
- goto out;
- }
-
- transport = t;
- retval = __vsock_core_init();
- if (retval)
- transport = NULL;
-
-out:
+ transport = NULL;
+err_busy:
mutex_unlock(_register_mutex);
- return retval;
+ return err;
}
-EXPORT_SYMBOL_GPL(vsock_core_init);
+EXPORT_SYMBOL_GPL(__vsock_core_init);
void vsock_core_exit(void)
{
@@ -2000,5 +1996,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Socket Family");
-MODULE_VERSION("1.0.0.0-k");
+MODULE_VERSION("1.0.1.0-k");
MODULE_LICENSE("GPL v2");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vsock: Make transport the proto owner
Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.
Includes version bump to 1.0.1.0-k
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
include/net/af_vsock.h |6 +-
net/vmw_vsock/af_vsock.c | 46 +-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 7d64d36..8f02e5c 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -155,7 +155,11 @@ struct vsock_transport {
/ CORE /
-int vsock_core_init(const struct vsock_transport *t);
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner);
+static inline int vsock_core_init(const struct vsock_transport *t)
+{
+ return __vsock_core_init(t, THIS_MODULE);
+}
void vsock_core_exit(void);
/ UTILS /
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5adfd94..5743553 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1925,9 +1925,22 @@ static struct miscdevice vsock_device = {
.fops = vsock_device_ops,
};
-static int __vsock_core_init(void)
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
{
- int err;
+ int err = mutex_lock_interruptible(vsock_register_mutex);
+ if (err)
+ return err;
+
+ if (transport) {
+ err = -EBUSY;
+ goto err_busy;
+ }
+
+ /* Transport must be the owner of the protocol so that it can't
+* unload while there are open sockets.
+*/
+ vsock_proto.owner = owner;
+ transport = t;
vsock_init_tables();
@@ -1951,36 +1964,19 @@ static int __vsock_core_init(void)
goto err_unregister_proto;
}
+ mutex_unlock(vsock_register_mutex);
return 0;
err_unregister_proto:
proto_unregister(vsock_proto);
err_misc_deregister:
misc_deregister(vsock_device);
- return err;
-}
-
-int vsock_core_init(const struct vsock_transport *t)
-{
- int retval = mutex_lock_interruptible(vsock_register_mutex);
- if (retval)
- return retval;
-
- if (transport) {
- retval = -EBUSY;
- goto out;
- }
-
- transport = t;
- retval = __vsock_core_init();
- if (retval)
- transport = NULL;
-
-out:
+ transport = NULL;
+err_busy:
mutex_unlock(vsock_register_mutex);
- return retval;
+ return err;
}
-EXPORT_SYMBOL_GPL(vsock_core_init);
+EXPORT_SYMBOL_GPL(__vsock_core_init);
void vsock_core_exit(void)
{
@@ -2000,5 +1996,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Socket Family);
-MODULE_VERSION(1.0.0.0-k);
+MODULE_VERSION(1.0.1.0-k);
MODULE_LICENSE(GPL v2);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vsock: Make transport the proto owner
Oh just shoot me now, doesn't even pass checkpatch *hangs head in shame*
Dave/Greg, flame away if you like...
- Andy
- Original Message -
Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.
Includes version bump to 1.0.1.0-k
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
include/net/af_vsock.h |6 +-
net/vmw_vsock/af_vsock.c | 46
+-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 7d64d36..8f02e5c 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -155,7 +155,11 @@ struct vsock_transport {
/ CORE /
-int vsock_core_init(const struct vsock_transport *t);
+int __vsock_core_init(const struct vsock_transport *t, struct module
*owner);
+static inline int vsock_core_init(const struct vsock_transport *t)
+{
+ return __vsock_core_init(t, THIS_MODULE);
+}
void vsock_core_exit(void);
/ UTILS /
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5adfd94..5743553 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1925,9 +1925,22 @@ static struct miscdevice vsock_device = {
.fops = vsock_device_ops,
};
-static int __vsock_core_init(void)
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
{
- int err;
+ int err = mutex_lock_interruptible(vsock_register_mutex);
+ if (err)
+ return err;
+
+ if (transport) {
+ err = -EBUSY;
+ goto err_busy;
+ }
+
+ /* Transport must be the owner of the protocol so that it can't
+ * unload while there are open sockets.
+ */
+ vsock_proto.owner = owner;
+ transport = t;
vsock_init_tables();
@@ -1951,36 +1964,19 @@ static int __vsock_core_init(void)
goto err_unregister_proto;
}
+ mutex_unlock(vsock_register_mutex);
return 0;
err_unregister_proto:
proto_unregister(vsock_proto);
err_misc_deregister:
misc_deregister(vsock_device);
- return err;
-}
-
-int vsock_core_init(const struct vsock_transport *t)
-{
- int retval = mutex_lock_interruptible(vsock_register_mutex);
- if (retval)
- return retval;
-
- if (transport) {
- retval = -EBUSY;
- goto out;
- }
-
- transport = t;
- retval = __vsock_core_init();
- if (retval)
- transport = NULL;
-
-out:
+ transport = NULL;
+err_busy:
mutex_unlock(vsock_register_mutex);
- return retval;
+ return err;
}
-EXPORT_SYMBOL_GPL(vsock_core_init);
+EXPORT_SYMBOL_GPL(__vsock_core_init);
void vsock_core_exit(void)
{
@@ -2000,5 +1996,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Socket Family);
-MODULE_VERSION(1.0.0.0-k);
+MODULE_VERSION(1.0.1.0-k);
MODULE_LICENSE(GPL v2);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vsock: Make transport the proto owner
Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.
Includes version bump to 1.0.1.0-k
Passes checkpatch this time, I swear...
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
include/net/af_vsock.h |6 -
net/vmw_vsock/af_vsock.c | 47 +
2 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 7d64d36..4282778 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -155,7 +155,11 @@ struct vsock_transport {
/ CORE /
-int vsock_core_init(const struct vsock_transport *t);
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner);
+static inline int vsock_core_init(const struct vsock_transport *t)
+{
+ return __vsock_core_init(t, THIS_MODULE);
+}
void vsock_core_exit(void);
/ UTILS /
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5adfd94..85d232b 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1925,9 +1925,23 @@ static struct miscdevice vsock_device = {
.fops = vsock_device_ops,
};
-static int __vsock_core_init(void)
+int __vsock_core_init(const struct vsock_transport *t, struct module *owner)
{
- int err;
+ int err = mutex_lock_interruptible(vsock_register_mutex);
+
+ if (err)
+ return err;
+
+ if (transport) {
+ err = -EBUSY;
+ goto err_busy;
+ }
+
+ /* Transport must be the owner of the protocol so that it can't
+* unload while there are open sockets.
+*/
+ vsock_proto.owner = owner;
+ transport = t;
vsock_init_tables();
@@ -1951,36 +1965,19 @@ static int __vsock_core_init(void)
goto err_unregister_proto;
}
+ mutex_unlock(vsock_register_mutex);
return 0;
err_unregister_proto:
proto_unregister(vsock_proto);
err_misc_deregister:
misc_deregister(vsock_device);
- return err;
-}
-
-int vsock_core_init(const struct vsock_transport *t)
-{
- int retval = mutex_lock_interruptible(vsock_register_mutex);
- if (retval)
- return retval;
-
- if (transport) {
- retval = -EBUSY;
- goto out;
- }
-
- transport = t;
- retval = __vsock_core_init();
- if (retval)
- transport = NULL;
-
-out:
+ transport = NULL;
+err_busy:
mutex_unlock(vsock_register_mutex);
- return retval;
+ return err;
}
-EXPORT_SYMBOL_GPL(vsock_core_init);
+EXPORT_SYMBOL_GPL(__vsock_core_init);
void vsock_core_exit(void)
{
@@ -2000,5 +1997,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Socket Family);
-MODULE_VERSION(1.0.0.0-k);
+MODULE_VERSION(1.0.1.0-k);
MODULE_LICENSE(GPL v2);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VMCI: fix to pass correct device identity to free_irq()
> free_irq() expects the same device identity that was passed to > corresponding request_irq(), otherwise the IRQ is not freed. > > Signed-off-by: Wei Yongjun Acked-by: Andy King Thanks for fixing this! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VMCI: fix to pass correct device identity to free_irq()
free_irq() expects the same device identity that was passed to corresponding request_irq(), otherwise the IRQ is not freed. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Andy King ack...@vmware.com Thanks for fixing this! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Add support for virtual IOMMU
This patch adds support for virtual IOMMU to the vmxnet3 module. We
switch to DMA consistent mappings for anything we pass to the device.
There were a few places where we already did this, but using pci_blah();
these have been fixed to use dma_blah(), along with all new occurrences
where we've replaced kmalloc() and friends.
Also fix two small bugs:
1) use after free of rq->buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.c | 211 +++--
drivers/net/vmxnet3/vmxnet3_int.h | 10 ++-
2 files changed, 138 insertions(+), 83 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 55a62ca..7e2788c 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -313,10 +313,10 @@ vmxnet3_unmap_tx_buf(struct vmxnet3_tx_buf_info *tbi,
struct pci_dev *pdev)
{
if (tbi->map_type == VMXNET3_MAP_SINGLE)
- pci_unmap_single(pdev, tbi->dma_addr, tbi->len,
+ dma_unmap_single(>dev, tbi->dma_addr, tbi->len,
PCI_DMA_TODEVICE);
else if (tbi->map_type == VMXNET3_MAP_PAGE)
- pci_unmap_page(pdev, tbi->dma_addr, tbi->len,
+ dma_unmap_page(>dev, tbi->dma_addr, tbi->len,
PCI_DMA_TODEVICE);
else
BUG_ON(tbi->map_type != VMXNET3_MAP_NONE);
@@ -429,25 +429,29 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
if (tq->tx_ring.base) {
- pci_free_consistent(adapter->pdev, tq->tx_ring.size *
- sizeof(struct Vmxnet3_TxDesc),
- tq->tx_ring.base, tq->tx_ring.basePA);
+ dma_free_coherent(>pdev->dev, tq->tx_ring.size *
+ sizeof(struct Vmxnet3_TxDesc),
+ tq->tx_ring.base, tq->tx_ring.basePA);
tq->tx_ring.base = NULL;
}
if (tq->data_ring.base) {
- pci_free_consistent(adapter->pdev, tq->data_ring.size *
- sizeof(struct Vmxnet3_TxDataDesc),
- tq->data_ring.base, tq->data_ring.basePA);
+ dma_free_coherent(>pdev->dev, tq->data_ring.size *
+ sizeof(struct Vmxnet3_TxDataDesc),
+ tq->data_ring.base, tq->data_ring.basePA);
tq->data_ring.base = NULL;
}
if (tq->comp_ring.base) {
- pci_free_consistent(adapter->pdev, tq->comp_ring.size *
- sizeof(struct Vmxnet3_TxCompDesc),
- tq->comp_ring.base, tq->comp_ring.basePA);
+ dma_free_coherent(>pdev->dev, tq->comp_ring.size *
+ sizeof(struct Vmxnet3_TxCompDesc),
+ tq->comp_ring.base, tq->comp_ring.basePA);
tq->comp_ring.base = NULL;
}
- kfree(tq->buf_info);
- tq->buf_info = NULL;
+ if (tq->buf_info) {
+ dma_free_coherent(>pdev->dev,
+ tq->tx_ring.size * sizeof(tq->buf_info[0]),
+ tq->buf_info, tq->buf_info_pa);
+ tq->buf_info = NULL;
+ }
}
@@ -496,37 +500,38 @@ static int
vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
+ size_t sz;
+
BUG_ON(tq->tx_ring.base || tq->data_ring.base ||
tq->comp_ring.base || tq->buf_info);
- tq->tx_ring.base = pci_alloc_consistent(adapter->pdev, tq->tx_ring.size
- * sizeof(struct Vmxnet3_TxDesc),
- >tx_ring.basePA);
+ tq->tx_ring.base = dma_alloc_coherent(>pdev->dev,
+ tq->tx_ring.size * sizeof(struct Vmxnet3_TxDesc),
+ >tx_ring.basePA, GFP_KERNEL);
if (!tq->tx_ring.base) {
netdev_err(adapter->netdev, "failed to allocate tx ring\n");
goto err;
}
- tq->data_ring.base = pci_alloc_consistent(adapter->pdev,
-tq->data_ring.size *
-sizeof(struct Vmxnet3_TxDataDesc),
->data_ring.basePA);
+ tq->data_ring.base = dma_alloc_coherent(>pdev->dev,
+ tq->data_ring.size * sizeof(struct Vmxnet3_TxDataDesc),
+
[PATCH 0/2] VMCI: Add support for virtual IOMMU
This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c |2 +- drivers/misc/vmw_vmci/vmci_driver.h |7 + drivers/misc/vmw_vmci/vmci_guest.c | 22 ++- drivers/misc/vmw_vmci/vmci_queue_pair.c | 313 --- drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- 5 files changed, 142 insertions(+), 220 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] VMCI: Remove non-blocking/pinned queuepair support
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 149 +--
drivers/misc/vmw_vmci/vmci_queue_pair.h | 18
2 files changed, 22 insertions(+), 145 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8ff2e5e..8698e0c 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -148,12 +148,10 @@ typedef int vmci_memcpy_from_queue_func(void *dest,
size_t dest_offset,
struct vmci_queue_kern_if {
struct page **page;
struct page **header_page;
- void *va;
struct mutex __mutex; /* Protects the queue. */
struct mutex *mutex;/* Shared by producer and consumer queues. */
bool host;
size_t num_pages;
- bool mapped;
};
/*
@@ -267,11 +265,6 @@ static void qp_free_queue(void *q, u64 size)
if (queue) {
u64 i = DIV_ROUND_UP(size, PAGE_SIZE);
- if (queue->kernel_if->mapped) {
- vunmap(queue->kernel_if->va);
- queue->kernel_if->va = NULL;
- }
-
while (i)
__free_page(queue->kernel_if->page[--i]);
@@ -311,8 +304,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
queue->kernel_if->header_page = NULL; /* Unused in guest. */
queue->kernel_if->page = (struct page **)(queue->kernel_if + 1);
queue->kernel_if->host = false;
- queue->kernel_if->va = NULL;
- queue->kernel_if->mapped = false;
for (i = 0; i < num_data_pages; i++) {
queue->kernel_if->page[i] = alloc_pages(GFP_KERNEL, 0);
@@ -320,16 +311,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
goto fail;
}
- if (vmci_qp_pinned(flags)) {
- queue->kernel_if->va =
- vmap(queue->kernel_if->page, num_data_pages, VM_MAP,
-PAGE_KERNEL);
- if (!queue->kernel_if->va)
- goto fail;
-
- queue->kernel_if->mapped = true;
- }
-
return (void *)queue;
fail:
@@ -359,11 +340,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
void *va;
size_t to_copy;
- if (!kernel_if->mapped)
- va = kmap(kernel_if->page[page_index]);
- else
- va = (void *)((u8 *)kernel_if->va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if->page[page_index]);
if (size - bytes_copied > PAGE_SIZE - page_offset)
/* Enough payload to fill up from this page. */
@@ -388,8 +365,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
}
bytes_copied += to_copy;
- if (!kernel_if->mapped)
- kunmap(kernel_if->page[page_index]);
+ kunmap(kernel_if->page[page_index]);
}
return VMCI_SUCCESS;
@@ -417,11 +393,7 @@ static int __qp_memcpy_from_queue(void *dest,
void *va;
size_t to_copy;
- if (!kernel_if->mapped)
- va = kmap(kernel_if->page[page_index]);
- else
- va = (void *)((u8 *)kernel_if->va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if->page[page_index]);
if (size - bytes_copied > PAGE_SIZE - page_offset)
/* Enough payload to fill up this page. */
@@ -446,8 +418,7 @@ static int __qp_memcpy_from_queue(void *dest,
}
bytes_copied += to_copy;
- if (!kernel_if->mapped)
- kunmap(kernel_if->page[page_index]);
+ kunmap(kernel_if->page[page_index]);
}
return VMCI_SUCCESS;
@@ -634,8 +605,6 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size)
queue->kernel_if->header_page =
(struct page **)((u8 *)queue + queue_size);
queue->kernel_if->page = >kernel_if->header_page[1];
- queue->kernel_if->va = NULL;
- queue->kernel_if->mapped = false;
}
return queue;
@@ -1720,21 +1689,6 @@ static int qp_broker_attach(struct qp_broker_entry
*entry,
if (result < VMCI_SUCCESS)
r
[PATCH 2/2] VMCI: Add support for virtual IOMMU
This patch adds support for virtual IOMMU to the vmci module. We switch
to DMA consistent mappings for guest queuepair and doorbell pages that
are passed to the device. We still allocate each page individually,
since there's no guarantee that we'll get a contiguous block of physical
for an entire queuepair (especially since we allow up to 128 MiB!).
Also made the split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_driver.c |2 +-
drivers/misc/vmw_vmci/vmci_driver.h |7 ++
drivers/misc/vmw_vmci/vmci_guest.c | 22 +++-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 180 ++-
4 files changed, 128 insertions(+), 83 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 7b3fce2..3dee7ae 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
-MODULE_VERSION("1.0.0.0-k");
+MODULE_VERSION("1.1.0.0-k");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/misc/vmw_vmci/vmci_driver.h
b/drivers/misc/vmw_vmci/vmci_driver.h
index f69156a..cee9e97 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.h
+++ b/drivers/misc/vmw_vmci/vmci_driver.h
@@ -35,6 +35,13 @@ struct vmci_obj {
enum vmci_obj_type type;
};
+/*
+ * Needed by other components of this module. It's okay to have one global
+ * instance of this because there can only ever be one VMCI device. Our
+ * virtual hardware enforces this.
+ */
+extern struct pci_dev *vmci_pdev;
+
u32 vmci_get_context_id(void);
int vmci_send_datagram(struct vmci_datagram *dg);
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 60c0199..b3a2b76 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -65,9 +65,11 @@ struct vmci_guest_device {
void *data_buffer;
void *notification_bitmap;
+ dma_addr_t notification_base;
};
/* vmci_dev singleton device and supporting data*/
+struct pci_dev *vmci_pdev;
static struct vmci_guest_device *vmci_dev_g;
static DEFINE_SPINLOCK(vmci_dev_spinlock);
@@ -528,7 +530,9 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* well.
*/
if (capabilities & VMCI_CAPS_NOTIFICATIONS) {
- vmci_dev->notification_bitmap = vmalloc(PAGE_SIZE);
+ vmci_dev->notification_bitmap = dma_alloc_coherent(
+ >dev, PAGE_SIZE, _dev->notification_base,
+ GFP_KERNEL);
if (!vmci_dev->notification_bitmap) {
dev_warn(>dev,
"Unable to allocate notification bitmap\n");
@@ -546,6 +550,7 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
/* Set up global device so that we can start sending datagrams */
spin_lock_irq(_dev_spinlock);
vmci_dev_g = vmci_dev;
+ vmci_pdev = pdev;
spin_unlock_irq(_dev_spinlock);
/*
@@ -553,9 +558,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* used.
*/
if (capabilities & VMCI_CAPS_NOTIFICATIONS) {
- struct page *page =
- vmalloc_to_page(vmci_dev->notification_bitmap);
- unsigned long bitmap_ppn = page_to_pfn(page);
+ unsigned long bitmap_ppn =
+ vmci_dev->notification_base >> PAGE_SHIFT;
if (!vmci_dbell_register_notification_bitmap(bitmap_ppn)) {
dev_warn(>dev,
"VMCI device unable to register notification
bitmap with PPN 0x%x\n",
@@ -665,11 +669,14 @@ err_remove_bitmap:
if (vmci_dev->notification_bitmap) {
iowrite32(VMCI_CONTROL_RESET,
vmci_dev->iobase + VMCI_CONTROL_ADDR);
- vfree(vmci_dev->notification_bitmap);
+ dma_free_coherent(>dev, PAGE_SIZE,
+ vmci_dev->notification_bitmap,
+ vmci_dev->notification_base);
}
err_remove_vmci_dev_g:
spin_lock_irq(_dev_spinlock);
+ vmci_pdev = NULL;
vmci_dev_g = NULL;
spin_unlock_irq(_dev_spinlock);
@@ -699,6 +706,7 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
spin_lock_irq(_dev_spinlock);
vmci_dev_g = NULL;
+ vmci_pdev = NULL;
spin_unlock_irq(_dev_spinlock);
dev_dbg(>dev, "Resetting vmci device\n");
@@ -727,7 +735,9 @@ static void vmci_guest_remo
[PATCH 2/2] VMCI: Add support for virtual IOMMU
This patch adds support for virtual IOMMU to the vmci module. We switch
to DMA consistent mappings for guest queuepair and doorbell pages that
are passed to the device. We still allocate each page individually,
since there's no guarantee that we'll get a contiguous block of physical
for an entire queuepair (especially since we allow up to 128 MiB!).
Also made the split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Acked-by: George Zhang georgezh...@vmware.com
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_driver.c |2 +-
drivers/misc/vmw_vmci/vmci_driver.h |7 ++
drivers/misc/vmw_vmci/vmci_guest.c | 22 +++-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 180 ++-
4 files changed, 128 insertions(+), 83 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 7b3fce2..3dee7ae 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Machine Communication Interface.);
-MODULE_VERSION(1.0.0.0-k);
+MODULE_VERSION(1.1.0.0-k);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/misc/vmw_vmci/vmci_driver.h
b/drivers/misc/vmw_vmci/vmci_driver.h
index f69156a..cee9e97 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.h
+++ b/drivers/misc/vmw_vmci/vmci_driver.h
@@ -35,6 +35,13 @@ struct vmci_obj {
enum vmci_obj_type type;
};
+/*
+ * Needed by other components of this module. It's okay to have one global
+ * instance of this because there can only ever be one VMCI device. Our
+ * virtual hardware enforces this.
+ */
+extern struct pci_dev *vmci_pdev;
+
u32 vmci_get_context_id(void);
int vmci_send_datagram(struct vmci_datagram *dg);
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 60c0199..b3a2b76 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -65,9 +65,11 @@ struct vmci_guest_device {
void *data_buffer;
void *notification_bitmap;
+ dma_addr_t notification_base;
};
/* vmci_dev singleton device and supporting data*/
+struct pci_dev *vmci_pdev;
static struct vmci_guest_device *vmci_dev_g;
static DEFINE_SPINLOCK(vmci_dev_spinlock);
@@ -528,7 +530,9 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* well.
*/
if (capabilities VMCI_CAPS_NOTIFICATIONS) {
- vmci_dev-notification_bitmap = vmalloc(PAGE_SIZE);
+ vmci_dev-notification_bitmap = dma_alloc_coherent(
+ pdev-dev, PAGE_SIZE, vmci_dev-notification_base,
+ GFP_KERNEL);
if (!vmci_dev-notification_bitmap) {
dev_warn(pdev-dev,
Unable to allocate notification bitmap\n);
@@ -546,6 +550,7 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
/* Set up global device so that we can start sending datagrams */
spin_lock_irq(vmci_dev_spinlock);
vmci_dev_g = vmci_dev;
+ vmci_pdev = pdev;
spin_unlock_irq(vmci_dev_spinlock);
/*
@@ -553,9 +558,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* used.
*/
if (capabilities VMCI_CAPS_NOTIFICATIONS) {
- struct page *page =
- vmalloc_to_page(vmci_dev-notification_bitmap);
- unsigned long bitmap_ppn = page_to_pfn(page);
+ unsigned long bitmap_ppn =
+ vmci_dev-notification_base PAGE_SHIFT;
if (!vmci_dbell_register_notification_bitmap(bitmap_ppn)) {
dev_warn(pdev-dev,
VMCI device unable to register notification
bitmap with PPN 0x%x\n,
@@ -665,11 +669,14 @@ err_remove_bitmap:
if (vmci_dev-notification_bitmap) {
iowrite32(VMCI_CONTROL_RESET,
vmci_dev-iobase + VMCI_CONTROL_ADDR);
- vfree(vmci_dev-notification_bitmap);
+ dma_free_coherent(pdev-dev, PAGE_SIZE,
+ vmci_dev-notification_bitmap,
+ vmci_dev-notification_base);
}
err_remove_vmci_dev_g:
spin_lock_irq(vmci_dev_spinlock);
+ vmci_pdev = NULL;
vmci_dev_g = NULL;
spin_unlock_irq(vmci_dev_spinlock);
@@ -699,6 +706,7 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
spin_lock_irq(vmci_dev_spinlock);
vmci_dev_g = NULL;
+ vmci_pdev = NULL;
spin_unlock_irq(vmci_dev_spinlock);
dev_dbg(pdev-dev, Resetting vmci device\n);
@@ -727,7 +735,9 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
* device, so we can
[PATCH 0/2] VMCI: Add support for virtual IOMMU
This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c |2 +- drivers/misc/vmw_vmci/vmci_driver.h |7 + drivers/misc/vmw_vmci/vmci_guest.c | 22 ++- drivers/misc/vmw_vmci/vmci_queue_pair.c | 313 --- drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- 5 files changed, 142 insertions(+), 220 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] VMCI: Remove non-blocking/pinned queuepair support
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 149 +--
drivers/misc/vmw_vmci/vmci_queue_pair.h | 18
2 files changed, 22 insertions(+), 145 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8ff2e5e..8698e0c 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -148,12 +148,10 @@ typedef int vmci_memcpy_from_queue_func(void *dest,
size_t dest_offset,
struct vmci_queue_kern_if {
struct page **page;
struct page **header_page;
- void *va;
struct mutex __mutex; /* Protects the queue. */
struct mutex *mutex;/* Shared by producer and consumer queues. */
bool host;
size_t num_pages;
- bool mapped;
};
/*
@@ -267,11 +265,6 @@ static void qp_free_queue(void *q, u64 size)
if (queue) {
u64 i = DIV_ROUND_UP(size, PAGE_SIZE);
- if (queue-kernel_if-mapped) {
- vunmap(queue-kernel_if-va);
- queue-kernel_if-va = NULL;
- }
-
while (i)
__free_page(queue-kernel_if-page[--i]);
@@ -311,8 +304,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
queue-kernel_if-header_page = NULL; /* Unused in guest. */
queue-kernel_if-page = (struct page **)(queue-kernel_if + 1);
queue-kernel_if-host = false;
- queue-kernel_if-va = NULL;
- queue-kernel_if-mapped = false;
for (i = 0; i num_data_pages; i++) {
queue-kernel_if-page[i] = alloc_pages(GFP_KERNEL, 0);
@@ -320,16 +311,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
goto fail;
}
- if (vmci_qp_pinned(flags)) {
- queue-kernel_if-va =
- vmap(queue-kernel_if-page, num_data_pages, VM_MAP,
-PAGE_KERNEL);
- if (!queue-kernel_if-va)
- goto fail;
-
- queue-kernel_if-mapped = true;
- }
-
return (void *)queue;
fail:
@@ -359,11 +340,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
void *va;
size_t to_copy;
- if (!kernel_if-mapped)
- va = kmap(kernel_if-page[page_index]);
- else
- va = (void *)((u8 *)kernel_if-va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if-page[page_index]);
if (size - bytes_copied PAGE_SIZE - page_offset)
/* Enough payload to fill up from this page. */
@@ -388,8 +365,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
}
bytes_copied += to_copy;
- if (!kernel_if-mapped)
- kunmap(kernel_if-page[page_index]);
+ kunmap(kernel_if-page[page_index]);
}
return VMCI_SUCCESS;
@@ -417,11 +393,7 @@ static int __qp_memcpy_from_queue(void *dest,
void *va;
size_t to_copy;
- if (!kernel_if-mapped)
- va = kmap(kernel_if-page[page_index]);
- else
- va = (void *)((u8 *)kernel_if-va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if-page[page_index]);
if (size - bytes_copied PAGE_SIZE - page_offset)
/* Enough payload to fill up this page. */
@@ -446,8 +418,7 @@ static int __qp_memcpy_from_queue(void *dest,
}
bytes_copied += to_copy;
- if (!kernel_if-mapped)
- kunmap(kernel_if-page[page_index]);
+ kunmap(kernel_if-page[page_index]);
}
return VMCI_SUCCESS;
@@ -634,8 +605,6 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size)
queue-kernel_if-header_page =
(struct page **)((u8 *)queue + queue_size);
queue-kernel_if-page = queue-kernel_if-header_page[1];
- queue-kernel_if-va = NULL;
- queue-kernel_if-mapped = false;
}
return queue;
@@ -1720,21 +1689,6 @@ static int qp_broker_attach(struct qp_broker_entry
*entry,
if (result VMCI_SUCCESS)
return result;
- /*
-* Preemptively load in the headers if non-blocking to
-* prevent blocking later.
-*/
- if (entry
[PATCH] VMXNET3: Add support for virtual IOMMU
This patch adds support for virtual IOMMU to the vmxnet3 module. We
switch to DMA consistent mappings for anything we pass to the device.
There were a few places where we already did this, but using pci_blah();
these have been fixed to use dma_blah(), along with all new occurrences
where we've replaced kmalloc() and friends.
Also fix two small bugs:
1) use after free of rq-buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang georgezh...@vmware.com
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/net/vmxnet3/vmxnet3_drv.c | 211 +++--
drivers/net/vmxnet3/vmxnet3_int.h | 10 ++-
2 files changed, 138 insertions(+), 83 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 55a62ca..7e2788c 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -313,10 +313,10 @@ vmxnet3_unmap_tx_buf(struct vmxnet3_tx_buf_info *tbi,
struct pci_dev *pdev)
{
if (tbi-map_type == VMXNET3_MAP_SINGLE)
- pci_unmap_single(pdev, tbi-dma_addr, tbi-len,
+ dma_unmap_single(pdev-dev, tbi-dma_addr, tbi-len,
PCI_DMA_TODEVICE);
else if (tbi-map_type == VMXNET3_MAP_PAGE)
- pci_unmap_page(pdev, tbi-dma_addr, tbi-len,
+ dma_unmap_page(pdev-dev, tbi-dma_addr, tbi-len,
PCI_DMA_TODEVICE);
else
BUG_ON(tbi-map_type != VMXNET3_MAP_NONE);
@@ -429,25 +429,29 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
if (tq-tx_ring.base) {
- pci_free_consistent(adapter-pdev, tq-tx_ring.size *
- sizeof(struct Vmxnet3_TxDesc),
- tq-tx_ring.base, tq-tx_ring.basePA);
+ dma_free_coherent(adapter-pdev-dev, tq-tx_ring.size *
+ sizeof(struct Vmxnet3_TxDesc),
+ tq-tx_ring.base, tq-tx_ring.basePA);
tq-tx_ring.base = NULL;
}
if (tq-data_ring.base) {
- pci_free_consistent(adapter-pdev, tq-data_ring.size *
- sizeof(struct Vmxnet3_TxDataDesc),
- tq-data_ring.base, tq-data_ring.basePA);
+ dma_free_coherent(adapter-pdev-dev, tq-data_ring.size *
+ sizeof(struct Vmxnet3_TxDataDesc),
+ tq-data_ring.base, tq-data_ring.basePA);
tq-data_ring.base = NULL;
}
if (tq-comp_ring.base) {
- pci_free_consistent(adapter-pdev, tq-comp_ring.size *
- sizeof(struct Vmxnet3_TxCompDesc),
- tq-comp_ring.base, tq-comp_ring.basePA);
+ dma_free_coherent(adapter-pdev-dev, tq-comp_ring.size *
+ sizeof(struct Vmxnet3_TxCompDesc),
+ tq-comp_ring.base, tq-comp_ring.basePA);
tq-comp_ring.base = NULL;
}
- kfree(tq-buf_info);
- tq-buf_info = NULL;
+ if (tq-buf_info) {
+ dma_free_coherent(adapter-pdev-dev,
+ tq-tx_ring.size * sizeof(tq-buf_info[0]),
+ tq-buf_info, tq-buf_info_pa);
+ tq-buf_info = NULL;
+ }
}
@@ -496,37 +500,38 @@ static int
vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
+ size_t sz;
+
BUG_ON(tq-tx_ring.base || tq-data_ring.base ||
tq-comp_ring.base || tq-buf_info);
- tq-tx_ring.base = pci_alloc_consistent(adapter-pdev, tq-tx_ring.size
- * sizeof(struct Vmxnet3_TxDesc),
- tq-tx_ring.basePA);
+ tq-tx_ring.base = dma_alloc_coherent(adapter-pdev-dev,
+ tq-tx_ring.size * sizeof(struct Vmxnet3_TxDesc),
+ tq-tx_ring.basePA, GFP_KERNEL);
if (!tq-tx_ring.base) {
netdev_err(adapter-netdev, failed to allocate tx ring\n);
goto err;
}
- tq-data_ring.base = pci_alloc_consistent(adapter-pdev,
-tq-data_ring.size *
-sizeof(struct Vmxnet3_TxDataDesc),
-tq-data_ring.basePA);
+ tq-data_ring.base = dma_alloc_coherent(adapter-pdev-dev,
+ tq-data_ring.size * sizeof(struct Vmxnet3_TxDataDesc),
+ tq-data_ring.basePA, GFP_KERNEL);
if (!tq-data_ring.base) {
netdev_err(adapter-netdev, failed to allocate data ring\n);
goto err;
}
- tq-comp_ring.base
Re: [PATCH 0/2] VMCI: Add support for virtual IOMMU
Greg, I'd like to withdraw this in light of DaveM's comments on a similar patch to vmxnet3 regarding dma_alloc_coherent() vs pci_alloc_consistent(). I'll fix it and send out a new patchset. Sorry about this! Thanks! - Andy - Original Message - > This patchset adds support for virtual IOMMU to the VMCI module. We switch > to > DMA consistent mappings for queuepair and doorbell pages that are passed to > the > device, which allows the module to work in the presence of vIOMMU/VT-d. > > Andy King (2): > VMCI: Remove non-blocking/pinned queuepair support > VMCI: Add support for virtual IOMMU > > drivers/misc/vmw_vmci/vmci_driver.c |2 +- > drivers/misc/vmw_vmci/vmci_driver.h |7 + > drivers/misc/vmw_vmci/vmci_guest.c | 21 ++- > drivers/misc/vmw_vmci/vmci_queue_pair.c | 312 > --- > drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- > 5 files changed, 140 insertions(+), 220 deletions(-) > > -- > 1.7.4.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VMXNET3: Add support for virtual IOMMU
Adding Greg, since this will apply to a similar patchset I sent out for VMCI. - Original Message - > From: Andy King > Date: Tue, 20 Aug 2013 10:33:32 -0700 > > > We can't just do virt_to_phys() on memory that we pass to the device and > > expect it to work in presence of a virtual IOMMU. We need to add IOMMU > > mappings for such DMAs to work correctly. Fix that with > > pci_alloc_consistent() where possible, or pci_map_single() where the > > mapping is short-lived or we don't control the allocation (netdev). > > Please use dma_alloc_coherent() (or in fact dma_zalloc_coherent()), > dma_map_single() et al., because they are preferred and in particular > allow specification of GFP_* flags Sorry about that, I'll fix that and send out a new patch. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VMXNET3: Add support for virtual IOMMU
Adding Greg, since this will apply to a similar patchset I sent out for VMCI. - Original Message - From: Andy King ack...@vmware.com Date: Tue, 20 Aug 2013 10:33:32 -0700 We can't just do virt_to_phys() on memory that we pass to the device and expect it to work in presence of a virtual IOMMU. We need to add IOMMU mappings for such DMAs to work correctly. Fix that with pci_alloc_consistent() where possible, or pci_map_single() where the mapping is short-lived or we don't control the allocation (netdev). Please use dma_alloc_coherent() (or in fact dma_zalloc_coherent()), dma_map_single() et al., because they are preferred and in particular allow specification of GFP_* flags Sorry about that, I'll fix that and send out a new patch. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] VMCI: Add support for virtual IOMMU
Greg, I'd like to withdraw this in light of DaveM's comments on a similar patch to vmxnet3 regarding dma_alloc_coherent() vs pci_alloc_consistent(). I'll fix it and send out a new patchset. Sorry about this! Thanks! - Andy - Original Message - This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c |2 +- drivers/misc/vmw_vmci/vmci_driver.h |7 + drivers/misc/vmw_vmci/vmci_guest.c | 21 ++- drivers/misc/vmw_vmci/vmci_queue_pair.c | 312 --- drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- 5 files changed, 140 insertions(+), 220 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] VMCI: Remove non-blocking/pinned queuepair support
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 149 +--
drivers/misc/vmw_vmci/vmci_queue_pair.h | 18
2 files changed, 22 insertions(+), 145 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8ff2e5e..8698e0c 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -148,12 +148,10 @@ typedef int vmci_memcpy_from_queue_func(void *dest,
size_t dest_offset,
struct vmci_queue_kern_if {
struct page **page;
struct page **header_page;
- void *va;
struct mutex __mutex; /* Protects the queue. */
struct mutex *mutex;/* Shared by producer and consumer queues. */
bool host;
size_t num_pages;
- bool mapped;
};
/*
@@ -267,11 +265,6 @@ static void qp_free_queue(void *q, u64 size)
if (queue) {
u64 i = DIV_ROUND_UP(size, PAGE_SIZE);
- if (queue->kernel_if->mapped) {
- vunmap(queue->kernel_if->va);
- queue->kernel_if->va = NULL;
- }
-
while (i)
__free_page(queue->kernel_if->page[--i]);
@@ -311,8 +304,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
queue->kernel_if->header_page = NULL; /* Unused in guest. */
queue->kernel_if->page = (struct page **)(queue->kernel_if + 1);
queue->kernel_if->host = false;
- queue->kernel_if->va = NULL;
- queue->kernel_if->mapped = false;
for (i = 0; i < num_data_pages; i++) {
queue->kernel_if->page[i] = alloc_pages(GFP_KERNEL, 0);
@@ -320,16 +311,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
goto fail;
}
- if (vmci_qp_pinned(flags)) {
- queue->kernel_if->va =
- vmap(queue->kernel_if->page, num_data_pages, VM_MAP,
-PAGE_KERNEL);
- if (!queue->kernel_if->va)
- goto fail;
-
- queue->kernel_if->mapped = true;
- }
-
return (void *)queue;
fail:
@@ -359,11 +340,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
void *va;
size_t to_copy;
- if (!kernel_if->mapped)
- va = kmap(kernel_if->page[page_index]);
- else
- va = (void *)((u8 *)kernel_if->va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if->page[page_index]);
if (size - bytes_copied > PAGE_SIZE - page_offset)
/* Enough payload to fill up from this page. */
@@ -388,8 +365,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
}
bytes_copied += to_copy;
- if (!kernel_if->mapped)
- kunmap(kernel_if->page[page_index]);
+ kunmap(kernel_if->page[page_index]);
}
return VMCI_SUCCESS;
@@ -417,11 +393,7 @@ static int __qp_memcpy_from_queue(void *dest,
void *va;
size_t to_copy;
- if (!kernel_if->mapped)
- va = kmap(kernel_if->page[page_index]);
- else
- va = (void *)((u8 *)kernel_if->va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if->page[page_index]);
if (size - bytes_copied > PAGE_SIZE - page_offset)
/* Enough payload to fill up this page. */
@@ -446,8 +418,7 @@ static int __qp_memcpy_from_queue(void *dest,
}
bytes_copied += to_copy;
- if (!kernel_if->mapped)
- kunmap(kernel_if->page[page_index]);
+ kunmap(kernel_if->page[page_index]);
}
return VMCI_SUCCESS;
@@ -634,8 +605,6 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size)
queue->kernel_if->header_page =
(struct page **)((u8 *)queue + queue_size);
queue->kernel_if->page = >kernel_if->header_page[1];
- queue->kernel_if->va = NULL;
- queue->kernel_if->mapped = false;
}
return queue;
@@ -1720,21 +1689,6 @@ static int qp_broker_attach(struct qp_broker_entry
*entry,
if (result < VMCI_SUCCESS)
r
[PATCH] VMXNET3: Add support for virtual IOMMU
We can't just do virt_to_phys() on memory that we pass to the device and
expect it to work in presence of a virtual IOMMU. We need to add IOMMU
mappings for such DMAs to work correctly. Fix that with
pci_alloc_consistent() where possible, or pci_map_single() where the
mapping is short-lived or we don't control the allocation (netdev).
Also fix two small bugs:
1) use after free of rq->buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.c | 89 ++---
drivers/net/vmxnet3/vmxnet3_int.h | 10 +++-
2 files changed, 71 insertions(+), 28 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 55a62ca..7ca9ec9 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -446,8 +446,12 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
tq->comp_ring.base, tq->comp_ring.basePA);
tq->comp_ring.base = NULL;
}
- kfree(tq->buf_info);
- tq->buf_info = NULL;
+ if (tq->buf_info) {
+ pci_free_consistent(adapter->pdev,
+ tq->tx_ring.size * sizeof(tq->buf_info[0]),
+ tq->buf_info, tq->buf_info_pa);
+ tq->buf_info = NULL;
+ }
}
@@ -496,6 +500,8 @@ static int
vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
+ size_t sz;
+
BUG_ON(tq->tx_ring.base || tq->data_ring.base ||
tq->comp_ring.base || tq->buf_info);
@@ -525,10 +531,12 @@ vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
goto err;
}
- tq->buf_info = kcalloc(tq->tx_ring.size, sizeof(tq->buf_info[0]),
- GFP_KERNEL);
+ sz = tq->tx_ring.size * sizeof(tq->buf_info[0]);
+ tq->buf_info = pci_alloc_consistent(adapter->pdev, sz,
+ >buf_info_pa);
if (!tq->buf_info)
goto err;
+ memset(tq->buf_info, 0, sz);
return 0;
@@ -1400,8 +1408,6 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue
*rq,
}
- kfree(rq->buf_info[0]);
-
for (i = 0; i < 2; i++) {
if (rq->rx_ring[i].base) {
pci_free_consistent(adapter->pdev, rq->rx_ring[i].size
@@ -1419,6 +1425,13 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue
*rq,
rq->comp_ring.base, rq->comp_ring.basePA);
rq->comp_ring.base = NULL;
}
+
+ if (rq->buf_info[0]) {
+ size_t sz = sizeof(struct vmxnet3_rx_buf_info) *
+ (rq->rx_ring[0].size + rq->rx_ring[1].size);
+ pci_free_consistent(adapter->pdev, sz, rq->buf_info[0],
+ rq->buf_info_pa);
+ }
}
@@ -1522,10 +1535,11 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct
vmxnet3_adapter *adapter)
sz = sizeof(struct vmxnet3_rx_buf_info) * (rq->rx_ring[0].size +
rq->rx_ring[1].size);
- bi = kzalloc(sz, GFP_KERNEL);
+ bi = pci_alloc_consistent(adapter->pdev, sz, >buf_info_pa);
if (!bi)
goto err;
+ memset(bi, 0, sz);
rq->buf_info[0] = bi;
rq->buf_info[1] = bi + rq->rx_ring[0].size;
@@ -2005,6 +2019,7 @@ vmxnet3_set_mc(struct net_device *netdev)
struct Vmxnet3_RxFilterConf *rxConf =
>shared->devRead.rxFilterConf;
u8 *new_table = NULL;
+ dma_addr_t new_table_pa = 0;
u32 new_mode = VMXNET3_RXM_UCAST;
if (netdev->flags & IFF_PROMISC) {
@@ -2028,8 +2043,11 @@ vmxnet3_set_mc(struct net_device *netdev)
new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
- rxConf->mfTablePA = cpu_to_le64(virt_to_phys(
- new_table));
+ new_table_pa = pci_map_single(adapter->pdev,
+ new_table,
+ rxConf->mfTableLen,
+ PCI_DMA_TODEVICE);
+ rxConf->mfTablePA = cpu_to_le64(new_table_pa);
} else {
netdev_in
[PATCH 0/2] VMCI: Add support for virtual IOMMU
This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c |2 +- drivers/misc/vmw_vmci/vmci_driver.h |7 + drivers/misc/vmw_vmci/vmci_guest.c | 21 ++- drivers/misc/vmw_vmci/vmci_queue_pair.c | 312 --- drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- 5 files changed, 140 insertions(+), 220 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] VMCI: Add support for virtual IOMMU
Right now we use vmalloc()/alloc_page() for our guest queuepair pages
and then do a virt_to_phys() before passing them down to the device.
That's not going to work if DMA remapping is enabled, since the IOMMU
has no idea about the mappings. Switch to pci_alloc_consistent()
instead. We still allocate each page individually, since there's no
guarantee that we'll get a contiguous block of physical for an entire
queuepair (especially since we allow up to 128 MiB!).
Also made the split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_driver.c |2 +-
drivers/misc/vmw_vmci/vmci_driver.h |7 ++
drivers/misc/vmw_vmci/vmci_guest.c | 21 +++-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 179 ++-
4 files changed, 126 insertions(+), 83 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 7b3fce2..3dee7ae 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
-MODULE_VERSION("1.0.0.0-k");
+MODULE_VERSION("1.1.0.0-k");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/misc/vmw_vmci/vmci_driver.h
b/drivers/misc/vmw_vmci/vmci_driver.h
index f69156a..cee9e97 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.h
+++ b/drivers/misc/vmw_vmci/vmci_driver.h
@@ -35,6 +35,13 @@ struct vmci_obj {
enum vmci_obj_type type;
};
+/*
+ * Needed by other components of this module. It's okay to have one global
+ * instance of this because there can only ever be one VMCI device. Our
+ * virtual hardware enforces this.
+ */
+extern struct pci_dev *vmci_pdev;
+
u32 vmci_get_context_id(void);
int vmci_send_datagram(struct vmci_datagram *dg);
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 60c0199..2485c02 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -65,9 +65,11 @@ struct vmci_guest_device {
void *data_buffer;
void *notification_bitmap;
+ dma_addr_t notification_base;
};
/* vmci_dev singleton device and supporting data*/
+struct pci_dev *vmci_pdev;
static struct vmci_guest_device *vmci_dev_g;
static DEFINE_SPINLOCK(vmci_dev_spinlock);
@@ -528,7 +530,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* well.
*/
if (capabilities & VMCI_CAPS_NOTIFICATIONS) {
- vmci_dev->notification_bitmap = vmalloc(PAGE_SIZE);
+ vmci_dev->notification_bitmap = pci_alloc_consistent(
+ pdev, PAGE_SIZE, _dev->notification_base);
if (!vmci_dev->notification_bitmap) {
dev_warn(>dev,
"Unable to allocate notification bitmap\n");
@@ -546,6 +549,7 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
/* Set up global device so that we can start sending datagrams */
spin_lock_irq(_dev_spinlock);
vmci_dev_g = vmci_dev;
+ vmci_pdev = pdev;
spin_unlock_irq(_dev_spinlock);
/*
@@ -553,9 +557,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* used.
*/
if (capabilities & VMCI_CAPS_NOTIFICATIONS) {
- struct page *page =
- vmalloc_to_page(vmci_dev->notification_bitmap);
- unsigned long bitmap_ppn = page_to_pfn(page);
+ unsigned long bitmap_ppn =
+ vmci_dev->notification_base >> PAGE_SHIFT;
if (!vmci_dbell_register_notification_bitmap(bitmap_ppn)) {
dev_warn(>dev,
"VMCI device unable to register notification
bitmap with PPN 0x%x\n",
@@ -665,11 +668,14 @@ err_remove_bitmap:
if (vmci_dev->notification_bitmap) {
iowrite32(VMCI_CONTROL_RESET,
vmci_dev->iobase + VMCI_CONTROL_ADDR);
- vfree(vmci_dev->notification_bitmap);
+ pci_free_consistent(pdev, PAGE_SIZE,
+ vmci_dev->notification_bitmap,
+ vmci_dev->notification_base);
}
err_remove_vmci_dev_g:
spin_lock_irq(_dev_spinlock);
+ vmci_pdev = NULL;
vmci_dev_g = NULL;
spin_unlock_irq(_dev_spinlock);
@@ -699,6 +705,7 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
spin_lock_irq(_dev_spinlock);
vmci_dev_g = NULL;
+ vmci_pdev = NULL;
spin_unlock_irq(_dev_spinlock);
dev_dbg(>dev, "Rese
[PATCH 2/2] VMCI: Add support for virtual IOMMU
Right now we use vmalloc()/alloc_page() for our guest queuepair pages
and then do a virt_to_phys() before passing them down to the device.
That's not going to work if DMA remapping is enabled, since the IOMMU
has no idea about the mappings. Switch to pci_alloc_consistent()
instead. We still allocate each page individually, since there's no
guarantee that we'll get a contiguous block of physical for an entire
queuepair (especially since we allow up to 128 MiB!).
Also made the split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Acked-by: George Zhang georgezh...@vmware.com
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_driver.c |2 +-
drivers/misc/vmw_vmci/vmci_driver.h |7 ++
drivers/misc/vmw_vmci/vmci_guest.c | 21 +++-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 179 ++-
4 files changed, 126 insertions(+), 83 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
index 7b3fce2..3dee7ae 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Machine Communication Interface.);
-MODULE_VERSION(1.0.0.0-k);
+MODULE_VERSION(1.1.0.0-k);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/misc/vmw_vmci/vmci_driver.h
b/drivers/misc/vmw_vmci/vmci_driver.h
index f69156a..cee9e97 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.h
+++ b/drivers/misc/vmw_vmci/vmci_driver.h
@@ -35,6 +35,13 @@ struct vmci_obj {
enum vmci_obj_type type;
};
+/*
+ * Needed by other components of this module. It's okay to have one global
+ * instance of this because there can only ever be one VMCI device. Our
+ * virtual hardware enforces this.
+ */
+extern struct pci_dev *vmci_pdev;
+
u32 vmci_get_context_id(void);
int vmci_send_datagram(struct vmci_datagram *dg);
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 60c0199..2485c02 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -65,9 +65,11 @@ struct vmci_guest_device {
void *data_buffer;
void *notification_bitmap;
+ dma_addr_t notification_base;
};
/* vmci_dev singleton device and supporting data*/
+struct pci_dev *vmci_pdev;
static struct vmci_guest_device *vmci_dev_g;
static DEFINE_SPINLOCK(vmci_dev_spinlock);
@@ -528,7 +530,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* well.
*/
if (capabilities VMCI_CAPS_NOTIFICATIONS) {
- vmci_dev-notification_bitmap = vmalloc(PAGE_SIZE);
+ vmci_dev-notification_bitmap = pci_alloc_consistent(
+ pdev, PAGE_SIZE, vmci_dev-notification_base);
if (!vmci_dev-notification_bitmap) {
dev_warn(pdev-dev,
Unable to allocate notification bitmap\n);
@@ -546,6 +549,7 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
/* Set up global device so that we can start sending datagrams */
spin_lock_irq(vmci_dev_spinlock);
vmci_dev_g = vmci_dev;
+ vmci_pdev = pdev;
spin_unlock_irq(vmci_dev_spinlock);
/*
@@ -553,9 +557,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* used.
*/
if (capabilities VMCI_CAPS_NOTIFICATIONS) {
- struct page *page =
- vmalloc_to_page(vmci_dev-notification_bitmap);
- unsigned long bitmap_ppn = page_to_pfn(page);
+ unsigned long bitmap_ppn =
+ vmci_dev-notification_base PAGE_SHIFT;
if (!vmci_dbell_register_notification_bitmap(bitmap_ppn)) {
dev_warn(pdev-dev,
VMCI device unable to register notification
bitmap with PPN 0x%x\n,
@@ -665,11 +668,14 @@ err_remove_bitmap:
if (vmci_dev-notification_bitmap) {
iowrite32(VMCI_CONTROL_RESET,
vmci_dev-iobase + VMCI_CONTROL_ADDR);
- vfree(vmci_dev-notification_bitmap);
+ pci_free_consistent(pdev, PAGE_SIZE,
+ vmci_dev-notification_bitmap,
+ vmci_dev-notification_base);
}
err_remove_vmci_dev_g:
spin_lock_irq(vmci_dev_spinlock);
+ vmci_pdev = NULL;
vmci_dev_g = NULL;
spin_unlock_irq(vmci_dev_spinlock);
@@ -699,6 +705,7 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
spin_lock_irq(vmci_dev_spinlock);
vmci_dev_g = NULL;
+ vmci_pdev = NULL;
spin_unlock_irq(vmci_dev_spinlock);
dev_dbg(pdev-dev, Resetting vmci device\n);
@@ -727,7 +734,9 @@ static void
[PATCH 0/2] VMCI: Add support for virtual IOMMU
This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c |2 +- drivers/misc/vmw_vmci/vmci_driver.h |7 + drivers/misc/vmw_vmci/vmci_guest.c | 21 ++- drivers/misc/vmw_vmci/vmci_queue_pair.c | 312 --- drivers/misc/vmw_vmci/vmci_queue_pair.h | 18 -- 5 files changed, 140 insertions(+), 220 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMXNET3: Add support for virtual IOMMU
We can't just do virt_to_phys() on memory that we pass to the device and
expect it to work in presence of a virtual IOMMU. We need to add IOMMU
mappings for such DMAs to work correctly. Fix that with
pci_alloc_consistent() where possible, or pci_map_single() where the
mapping is short-lived or we don't control the allocation (netdev).
Also fix two small bugs:
1) use after free of rq-buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang georgezh...@vmware.com
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/net/vmxnet3/vmxnet3_drv.c | 89 ++---
drivers/net/vmxnet3/vmxnet3_int.h | 10 +++-
2 files changed, 71 insertions(+), 28 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 55a62ca..7ca9ec9 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -446,8 +446,12 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
tq-comp_ring.base, tq-comp_ring.basePA);
tq-comp_ring.base = NULL;
}
- kfree(tq-buf_info);
- tq-buf_info = NULL;
+ if (tq-buf_info) {
+ pci_free_consistent(adapter-pdev,
+ tq-tx_ring.size * sizeof(tq-buf_info[0]),
+ tq-buf_info, tq-buf_info_pa);
+ tq-buf_info = NULL;
+ }
}
@@ -496,6 +500,8 @@ static int
vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
+ size_t sz;
+
BUG_ON(tq-tx_ring.base || tq-data_ring.base ||
tq-comp_ring.base || tq-buf_info);
@@ -525,10 +531,12 @@ vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
goto err;
}
- tq-buf_info = kcalloc(tq-tx_ring.size, sizeof(tq-buf_info[0]),
- GFP_KERNEL);
+ sz = tq-tx_ring.size * sizeof(tq-buf_info[0]);
+ tq-buf_info = pci_alloc_consistent(adapter-pdev, sz,
+ tq-buf_info_pa);
if (!tq-buf_info)
goto err;
+ memset(tq-buf_info, 0, sz);
return 0;
@@ -1400,8 +1408,6 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue
*rq,
}
- kfree(rq-buf_info[0]);
-
for (i = 0; i 2; i++) {
if (rq-rx_ring[i].base) {
pci_free_consistent(adapter-pdev, rq-rx_ring[i].size
@@ -1419,6 +1425,13 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue
*rq,
rq-comp_ring.base, rq-comp_ring.basePA);
rq-comp_ring.base = NULL;
}
+
+ if (rq-buf_info[0]) {
+ size_t sz = sizeof(struct vmxnet3_rx_buf_info) *
+ (rq-rx_ring[0].size + rq-rx_ring[1].size);
+ pci_free_consistent(adapter-pdev, sz, rq-buf_info[0],
+ rq-buf_info_pa);
+ }
}
@@ -1522,10 +1535,11 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct
vmxnet3_adapter *adapter)
sz = sizeof(struct vmxnet3_rx_buf_info) * (rq-rx_ring[0].size +
rq-rx_ring[1].size);
- bi = kzalloc(sz, GFP_KERNEL);
+ bi = pci_alloc_consistent(adapter-pdev, sz, rq-buf_info_pa);
if (!bi)
goto err;
+ memset(bi, 0, sz);
rq-buf_info[0] = bi;
rq-buf_info[1] = bi + rq-rx_ring[0].size;
@@ -2005,6 +2019,7 @@ vmxnet3_set_mc(struct net_device *netdev)
struct Vmxnet3_RxFilterConf *rxConf =
adapter-shared-devRead.rxFilterConf;
u8 *new_table = NULL;
+ dma_addr_t new_table_pa = 0;
u32 new_mode = VMXNET3_RXM_UCAST;
if (netdev-flags IFF_PROMISC) {
@@ -2028,8 +2043,11 @@ vmxnet3_set_mc(struct net_device *netdev)
new_mode |= VMXNET3_RXM_MCAST;
rxConf-mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
- rxConf-mfTablePA = cpu_to_le64(virt_to_phys(
- new_table));
+ new_table_pa = pci_map_single(adapter-pdev,
+ new_table,
+ rxConf-mfTableLen,
+ PCI_DMA_TODEVICE);
+ rxConf-mfTablePA = cpu_to_le64(new_table_pa);
} else {
netdev_info(netdev, failed to copy mcast list
, setting ALL_MULTI\n);
@@ -2056,7 +2074,11 @@ vmxnet3_set_mc(struct net_device *netdev
[PATCH 1/2] VMCI: Remove non-blocking/pinned queuepair support
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade asarw...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 149 +--
drivers/misc/vmw_vmci/vmci_queue_pair.h | 18
2 files changed, 22 insertions(+), 145 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8ff2e5e..8698e0c 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -148,12 +148,10 @@ typedef int vmci_memcpy_from_queue_func(void *dest,
size_t dest_offset,
struct vmci_queue_kern_if {
struct page **page;
struct page **header_page;
- void *va;
struct mutex __mutex; /* Protects the queue. */
struct mutex *mutex;/* Shared by producer and consumer queues. */
bool host;
size_t num_pages;
- bool mapped;
};
/*
@@ -267,11 +265,6 @@ static void qp_free_queue(void *q, u64 size)
if (queue) {
u64 i = DIV_ROUND_UP(size, PAGE_SIZE);
- if (queue-kernel_if-mapped) {
- vunmap(queue-kernel_if-va);
- queue-kernel_if-va = NULL;
- }
-
while (i)
__free_page(queue-kernel_if-page[--i]);
@@ -311,8 +304,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
queue-kernel_if-header_page = NULL; /* Unused in guest. */
queue-kernel_if-page = (struct page **)(queue-kernel_if + 1);
queue-kernel_if-host = false;
- queue-kernel_if-va = NULL;
- queue-kernel_if-mapped = false;
for (i = 0; i num_data_pages; i++) {
queue-kernel_if-page[i] = alloc_pages(GFP_KERNEL, 0);
@@ -320,16 +311,6 @@ static void *qp_alloc_queue(u64 size, u32 flags)
goto fail;
}
- if (vmci_qp_pinned(flags)) {
- queue-kernel_if-va =
- vmap(queue-kernel_if-page, num_data_pages, VM_MAP,
-PAGE_KERNEL);
- if (!queue-kernel_if-va)
- goto fail;
-
- queue-kernel_if-mapped = true;
- }
-
return (void *)queue;
fail:
@@ -359,11 +340,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
void *va;
size_t to_copy;
- if (!kernel_if-mapped)
- va = kmap(kernel_if-page[page_index]);
- else
- va = (void *)((u8 *)kernel_if-va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if-page[page_index]);
if (size - bytes_copied PAGE_SIZE - page_offset)
/* Enough payload to fill up from this page. */
@@ -388,8 +365,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue,
}
bytes_copied += to_copy;
- if (!kernel_if-mapped)
- kunmap(kernel_if-page[page_index]);
+ kunmap(kernel_if-page[page_index]);
}
return VMCI_SUCCESS;
@@ -417,11 +393,7 @@ static int __qp_memcpy_from_queue(void *dest,
void *va;
size_t to_copy;
- if (!kernel_if-mapped)
- va = kmap(kernel_if-page[page_index]);
- else
- va = (void *)((u8 *)kernel_if-va +
- (page_index * PAGE_SIZE));
+ va = kmap(kernel_if-page[page_index]);
if (size - bytes_copied PAGE_SIZE - page_offset)
/* Enough payload to fill up this page. */
@@ -446,8 +418,7 @@ static int __qp_memcpy_from_queue(void *dest,
}
bytes_copied += to_copy;
- if (!kernel_if-mapped)
- kunmap(kernel_if-page[page_index]);
+ kunmap(kernel_if-page[page_index]);
}
return VMCI_SUCCESS;
@@ -634,8 +605,6 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size)
queue-kernel_if-header_page =
(struct page **)((u8 *)queue + queue_size);
queue-kernel_if-page = queue-kernel_if-header_page[1];
- queue-kernel_if-va = NULL;
- queue-kernel_if-mapped = false;
}
return queue;
@@ -1720,21 +1689,6 @@ static int qp_broker_attach(struct qp_broker_entry
*entry,
if (result VMCI_SUCCESS)
return result;
- /*
-* Preemptively load in the headers if non-blocking to
-* prevent blocking later.
-*/
- if (entry
[PATCH] VMCI: Fix process-to-process DRGAMs.
When sending between processes, we always schedule a work item. Our work info
struct has the message embedded in the middle, which means that we end up
overwriting subsequent fields when we copy the (variable-length) message into
it. Move it to the end of the struct.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_datagram.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
index ed5c433..f3cdd90 100644
--- a/drivers/misc/vmw_vmci/vmci_datagram.c
+++ b/drivers/misc/vmw_vmci/vmci_datagram.c
@@ -42,9 +42,11 @@ struct datagram_entry {
struct delayed_datagram_info {
struct datagram_entry *entry;
- struct vmci_datagram msg;
struct work_struct work;
bool in_dg_host_queue;
+ /* msg and msg_payload must be together. */
+ struct vmci_datagram msg;
+ u8 msg_payload[];
};
/* Number of in-flight host->host datagrams */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VSOCK: Split vm_sockets.h into kernel/uapi
Split the vSockets header into kernel and UAPI parts. The former gets the bits
that used to be in __KERNEL__ guards, while the latter gets everything that is
user-visible. Tested by compiling vsock (+transport) and a simple user-mode
vSockets application.
Reported-by: David Howells
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/linux/vm_sockets.h | 23 +++
include/uapi/linux/vm_sockets.h | 23 ---
2 files changed, 31 insertions(+), 15 deletions(-)
create mode 100644 include/linux/vm_sockets.h
diff --git a/include/linux/vm_sockets.h b/include/linux/vm_sockets.h
new file mode 100644
index 000..0805eec
--- /dev/null
+++ b/include/linux/vm_sockets.h
@@ -0,0 +1,23 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2007-2013 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _VM_SOCKETS_H
+#define _VM_SOCKETS_H
+
+#include
+
+int vm_sockets_get_local_cid(void);
+
+#endif /* _VM_SOCKETS_H */
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index df91301..b4ed5d8 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -13,12 +13,10 @@
* more details.
*/
-#ifndef _VM_SOCKETS_H_
-#define _VM_SOCKETS_H_
+#ifndef _UAPI_VM_SOCKETS_H
+#define _UAPI_VM_SOCKETS_H
-#if !defined(__KERNEL__)
-#include
-#endif
+#include
/* Option name for STREAM socket buffer size. Use as the option name in
* setsockopt(3) or getsockopt(3) to set or get an unsigned long long that
@@ -137,14 +135,13 @@
#define VM_SOCKETS_VERSION_MINOR(_v) (((_v) & 0x))
/* Address structure for vSockets. The address family should be set to
- * whatever vmci_sock_get_af_value_fd() returns. The structure members should
- * all align on their natural boundaries without resorting to compiler packing
- * directives. The total size of this structure should be exactly the same as
- * that of struct sockaddr.
+ * AF_VSOCK. The structure members should all align on their natural
+ * boundaries without resorting to compiler packing directives. The total size
+ * of this structure should be exactly the same as that of struct sockaddr.
*/
struct sockaddr_vm {
- sa_family_t svm_family;
+ __kernel_sa_family_t svm_family;
unsigned short svm_reserved1;
unsigned int svm_port;
unsigned int svm_cid;
@@ -156,8 +153,4 @@ struct sockaddr_vm {
#define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9)
-#if defined(__KERNEL__)
-int vm_sockets_get_local_cid(void);
-#endif
-
-#endif
+#endif /* _UAPI_VM_SOCKETS_H */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VSOCK: Split vm_sockets.h into kernel/uapi
Split the vSockets header into kernel and UAPI parts. The former gets the bits
that used to be in __KERNEL__ guards, while the latter gets everything that is
user-visible. Tested by compiling vsock (+transport) and a simple user-mode
vSockets application.
Reported-by: David Howells dhowe...@redhat.com
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
include/linux/vm_sockets.h | 23 +++
include/uapi/linux/vm_sockets.h | 23 ---
2 files changed, 31 insertions(+), 15 deletions(-)
create mode 100644 include/linux/vm_sockets.h
diff --git a/include/linux/vm_sockets.h b/include/linux/vm_sockets.h
new file mode 100644
index 000..0805eec
--- /dev/null
+++ b/include/linux/vm_sockets.h
@@ -0,0 +1,23 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2007-2013 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _VM_SOCKETS_H
+#define _VM_SOCKETS_H
+
+#include uapi/linux/vm_sockets.h
+
+int vm_sockets_get_local_cid(void);
+
+#endif /* _VM_SOCKETS_H */
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index df91301..b4ed5d8 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -13,12 +13,10 @@
* more details.
*/
-#ifndef _VM_SOCKETS_H_
-#define _VM_SOCKETS_H_
+#ifndef _UAPI_VM_SOCKETS_H
+#define _UAPI_VM_SOCKETS_H
-#if !defined(__KERNEL__)
-#include sys/socket.h
-#endif
+#include linux/socket.h
/* Option name for STREAM socket buffer size. Use as the option name in
* setsockopt(3) or getsockopt(3) to set or get an unsigned long long that
@@ -137,14 +135,13 @@
#define VM_SOCKETS_VERSION_MINOR(_v) (((_v) 0x))
/* Address structure for vSockets. The address family should be set to
- * whatever vmci_sock_get_af_value_fd() returns. The structure members should
- * all align on their natural boundaries without resorting to compiler packing
- * directives. The total size of this structure should be exactly the same as
- * that of struct sockaddr.
+ * AF_VSOCK. The structure members should all align on their natural
+ * boundaries without resorting to compiler packing directives. The total size
+ * of this structure should be exactly the same as that of struct sockaddr.
*/
struct sockaddr_vm {
- sa_family_t svm_family;
+ __kernel_sa_family_t svm_family;
unsigned short svm_reserved1;
unsigned int svm_port;
unsigned int svm_cid;
@@ -156,8 +153,4 @@ struct sockaddr_vm {
#define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9)
-#if defined(__KERNEL__)
-int vm_sockets_get_local_cid(void);
-#endif
-
-#endif
+#endif /* _UAPI_VM_SOCKETS_H */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMCI: Fix process-to-process DRGAMs.
When sending between processes, we always schedule a work item. Our work info
struct has the message embedded in the middle, which means that we end up
overwriting subsequent fields when we copy the (variable-length) message into
it. Move it to the end of the struct.
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_datagram.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
index ed5c433..f3cdd90 100644
--- a/drivers/misc/vmw_vmci/vmci_datagram.c
+++ b/drivers/misc/vmw_vmci/vmci_datagram.c
@@ -42,9 +42,11 @@ struct datagram_entry {
struct delayed_datagram_info {
struct datagram_entry *entry;
- struct vmci_datagram msg;
struct work_struct work;
bool in_dg_host_queue;
+ /* msg and msg_payload must be together. */
+ struct vmci_datagram msg;
+ u8 msg_payload[];
};
/* Number of in-flight host-host datagrams */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Sasha, > > + * Specifically, we initialize the vsock_bind_table array to a size of > > + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through ... > Why isn't it using the kernel's linux/hashtable.h? Gah, that's a leftover from when it was platform independent :/ I have a patch lying around to address this, once we have some more fixes batched up I'll send it out. Sorry about that! Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd, > > + written = transport->stream_enqueue( > > + vsk, msg->msg_iov, > > + len - total_written); > > Hmm, shouldn't we pass total_written to stream_enqueue here? > > In case a blocking send(big-buffer) call gets splitted into multiple > stream_enqueue calls the second (and further) stream_enqueue calls need > to know at which msg offset they should continue sending the data, no? On the client side, the iov tracks it internally; see memcpy_fromiovec(). On the socket side, VMCI uses a ring buffer, so it also knows its position internally. Or did I misunderstand the question? Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
> > + if (protocol) > > + return -EPROTONOSUPPORT; > > + > > IMO protocol == PF_VSOCK should not get rejected here. Good catch, I've sent out a patch for this. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] VSOCK: Remove hypervisor-only socket option
Remove hypervisor-only socket option. Reported-by: Gerd Hoffmann Acked-by: Dmitry Torokhov Signed-off-by: Andy King --- include/uapi/linux/vm_sockets.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index f7f2e99..df91301 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -52,14 +52,6 @@ #define SO_VM_SOCKETS_PEER_HOST_VM_ID 3 -/* Option name for socket's service label. Use as the option name in - * setsockopt(3) or getsockopt(3) to set or get the service label for a socket. - * The service label is a C-style NUL-terminated string. Only available for - * hypervisor endpoints. - */ - -#define SO_VM_SOCKETS_SERVICE_LABEL 4 - /* Option name for determining if a socket is trusted. Use as the option name * in getsockopt(3) to determine if a socket is trusted. The value is a * signed integer. -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] VSOCK: Don't reject PF_VSOCK protocol
Allow our own family as the protocol value for socket creation.
Reported-by: Gerd Hoffmann
Signed-off-by: Andy King
---
net/vmw_vsock/af_vsock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index c1b9e55..ca511c4 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1860,7 +1860,7 @@ static int vsock_create(struct net *net, struct socket
*sock,
if (!sock)
return -EINVAL;
- if (protocol)
+ if (protocol && protocol != PF_VSOCK)
return -EPROTONOSUPPORT;
switch (sock->type) {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] VSOCK: get rid of EXPORT_SYMTAB
From: Dmitry Torokhov This is the default behavior for a looong time. Acked-by: Andy King Signed-off-by: Dmitry Torokhov --- net/vmw_vsock/af_vsock.c |2 -- net/vmw_vsock/vmci_transport.c |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 54bb7bd..a8efe5a 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -76,8 +76,6 @@ */ #include - -#define EXPORT_SYMTAB #include #include #include diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index e8a87cf..a70ace8 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -14,8 +14,6 @@ */ #include - -#define EXPORT_SYMTAB #include #include #include -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] VSOCK: get rid of vsock_version.h
From: Dmitry Torokhov
There isn't really a need to have a separate file for it.
Acked-by: Andy King
Signed-off-by: Dmitry Torokhov
---
net/vmw_vsock/af_vsock.c |3 +--
net/vmw_vsock/vsock_version.h | 22 --
2 files changed, 1 insertions(+), 24 deletions(-)
delete mode 100644 net/vmw_vsock/vsock_version.h
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index a8efe5a..c1b9e55 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -98,7 +98,6 @@
#include
#include "af_vsock.h"
-#include "vsock_version.h"
static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr);
static void vsock_sk_destruct(struct sock *sk);
@@ -2009,5 +2008,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Socket Family");
-MODULE_VERSION(VSOCK_DRIVER_VERSION_STRING);
+MODULE_VERSION("1.0.0.0-k");
MODULE_LICENSE("GPL v2");
diff --git a/net/vmw_vsock/vsock_version.h b/net/vmw_vsock/vsock_version.h
deleted file mode 100644
index 4df7f5e..000
--- a/net/vmw_vsock/vsock_version.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * VMware vSockets Driver
- *
- * Copyright (C) 2011-2012 VMware, Inc. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation version 2 and no later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- */
-
-#ifndef _VSOCK_VERSION_H_
-#define _VSOCK_VERSION_H_
-
-#define VSOCK_DRIVER_VERSION_PARTS { 1, 0, 0, 0 }
-#define VSOCK_DRIVER_VERSION_STRING"1.0.0.0-k"
-
-#endif /* _VSOCK_VERSION_H_ */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Minor vSockets fixes
Minor vSockets fixes, two of which were reported on LKML. Andy King (2): VSOCK: Remove hypervisor-only socket option VSOCK: Don't reject PF_VSOCK protocol Dmitry Torokhov (2): VSOCK: get rid of EXPORT_SYMTAB VSOCK: get rid of vsock_version.h include/uapi/linux/vm_sockets.h |8 net/vmw_vsock/af_vsock.c|7 ++- net/vmw_vsock/vmci_transport.c |2 -- net/vmw_vsock/vsock_version.h | 22 -- 4 files changed, 2 insertions(+), 37 deletions(-) delete mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Minor vSockets fixes
Minor vSockets fixes, two of which were reported on LKML. Andy King (2): VSOCK: Remove hypervisor-only socket option VSOCK: Don't reject PF_VSOCK protocol Dmitry Torokhov (2): VSOCK: get rid of EXPORT_SYMTAB VSOCK: get rid of vsock_version.h include/uapi/linux/vm_sockets.h |8 net/vmw_vsock/af_vsock.c|7 ++- net/vmw_vsock/vmci_transport.c |2 -- net/vmw_vsock/vsock_version.h | 22 -- 4 files changed, 2 insertions(+), 37 deletions(-) delete mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] VSOCK: get rid of EXPORT_SYMTAB
From: Dmitry Torokhov d...@vmware.com This is the default behavior for a looong time. Acked-by: Andy King ack...@vmware.com Signed-off-by: Dmitry Torokhov d...@vmware.com --- net/vmw_vsock/af_vsock.c |2 -- net/vmw_vsock/vmci_transport.c |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 54bb7bd..a8efe5a 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -76,8 +76,6 @@ */ #include linux/types.h - -#define EXPORT_SYMTAB #include linux/bitops.h #include linux/cred.h #include linux/init.h diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index e8a87cf..a70ace8 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -14,8 +14,6 @@ */ #include linux/types.h - -#define EXPORT_SYMTAB #include linux/bitops.h #include linux/cred.h #include linux/init.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] VSOCK: get rid of vsock_version.h
From: Dmitry Torokhov d...@vmware.com
There isn't really a need to have a separate file for it.
Acked-by: Andy King ack...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
---
net/vmw_vsock/af_vsock.c |3 +--
net/vmw_vsock/vsock_version.h | 22 --
2 files changed, 1 insertions(+), 24 deletions(-)
delete mode 100644 net/vmw_vsock/vsock_version.h
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index a8efe5a..c1b9e55 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -98,7 +98,6 @@
#include net/sock.h
#include af_vsock.h
-#include vsock_version.h
static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr);
static void vsock_sk_destruct(struct sock *sk);
@@ -2009,5 +2008,5 @@ EXPORT_SYMBOL_GPL(vsock_core_exit);
MODULE_AUTHOR(VMware, Inc.);
MODULE_DESCRIPTION(VMware Virtual Socket Family);
-MODULE_VERSION(VSOCK_DRIVER_VERSION_STRING);
+MODULE_VERSION(1.0.0.0-k);
MODULE_LICENSE(GPL v2);
diff --git a/net/vmw_vsock/vsock_version.h b/net/vmw_vsock/vsock_version.h
deleted file mode 100644
index 4df7f5e..000
--- a/net/vmw_vsock/vsock_version.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * VMware vSockets Driver
- *
- * Copyright (C) 2011-2012 VMware, Inc. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation version 2 and no later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- */
-
-#ifndef _VSOCK_VERSION_H_
-#define _VSOCK_VERSION_H_
-
-#define VSOCK_DRIVER_VERSION_PARTS { 1, 0, 0, 0 }
-#define VSOCK_DRIVER_VERSION_STRING1.0.0.0-k
-
-#endif /* _VSOCK_VERSION_H_ */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] VSOCK: Don't reject PF_VSOCK protocol
Allow our own family as the protocol value for socket creation.
Reported-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Andy King ack...@vmware.com
---
net/vmw_vsock/af_vsock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index c1b9e55..ca511c4 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1860,7 +1860,7 @@ static int vsock_create(struct net *net, struct socket
*sock,
if (!sock)
return -EINVAL;
- if (protocol)
+ if (protocol protocol != PF_VSOCK)
return -EPROTONOSUPPORT;
switch (sock-type) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] VSOCK: Remove hypervisor-only socket option
Remove hypervisor-only socket option. Reported-by: Gerd Hoffmann kra...@redhat.com Acked-by: Dmitry Torokhov d...@vmware.com Signed-off-by: Andy King ack...@vmware.com --- include/uapi/linux/vm_sockets.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index f7f2e99..df91301 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -52,14 +52,6 @@ #define SO_VM_SOCKETS_PEER_HOST_VM_ID 3 -/* Option name for socket's service label. Use as the option name in - * setsockopt(3) or getsockopt(3) to set or get the service label for a socket. - * The service label is a C-style NUL-terminated string. Only available for - * hypervisor endpoints. - */ - -#define SO_VM_SOCKETS_SERVICE_LABEL 4 - /* Option name for determining if a socket is trusted. Use as the option name * in getsockopt(3) to determine if a socket is trusted. The value is a * signed integer. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
+ if (protocol) + return -EPROTONOSUPPORT; + IMO protocol == PF_VSOCK should not get rejected here. Good catch, I've sent out a patch for this. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd, + written = transport-stream_enqueue( + vsk, msg-msg_iov, + len - total_written); Hmm, shouldn't we pass total_written to stream_enqueue here? In case a blocking send(big-buffer) call gets splitted into multiple stream_enqueue calls the second (and further) stream_enqueue calls need to know at which msg offset they should continue sending the data, no? On the client side, the iov tracks it internally; see memcpy_fromiovec(). On the socket side, VMCI uses a ring buffer, so it also knows its position internally. Or did I misunderstand the question? Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Sasha, + * Specifically, we initialize the vsock_bind_table array to a size of + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through ... Why isn't it using the kernel's linux/hashtable.h? Gah, that's a leftover from when it was platform independent :/ I have a patch lying around to address this, once we have some more fixes batched up I'll send it out. Sorry about that! Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
> I've seen you have a notify_ops in the vmci bits. Do you have different > notify ops depending on socket type or something? Does it make sense to > move the notify ops ptr into "struct vsock_sock" maybe? The notify stuff only applies to STREAMs. However, we have two different notify impls, one for legacy ESX and one for newer, and we figure out at runtime which protocol we're using with the hypervisor and set the callbacks appropriately. The difference between the two is that the newer one is much smarter and knows not to signal (the peer) quite so much, i.e., it has some basic but sensible flow-control, which improves performance quite a bit. Again, that might not make any sense at all for virtio. Do you need to signal when you enqueue to a ring? And is there coalescing? Dunno... > And can we make it optional please (i.e. allow the function pointers to > be NULL)? They were originally allowed to be NULL, but I changed it in the last round of patches while moving them into the transport, since I disliked the NULL checks so much. I can put them back, but that's a bigger change, and I'm not sure we want to push large patches to Dave right now :) > Which problem you are trying to tackle with the notifications? It's to do with signaling the peer, or more appropriately, trying to avoid signaling the peer when possible. The naive impl. is to signal every time we enqueue or dequeue data (into our VMCI queuepairs). But signaling is slow, since it involves a world exit, so we prefer not to. Which means we need to keep track of rate of flow and figure out when we should and should not, and that's what all the notification stuff does. It's...ugly... > > For the VMCI transport, it indicates if the underlying queuepair is > > still around (i.e., make sure we haven't torn it down while sleeping > > in a blocking send or receive). Perhaps it's not the best name? > > How you'd hit that? Peer closing the socket while sleeping? Other > thread closing the socket wile sleeping? Both? > > I think a state field in struct vsock_sock would be a better solution here. Hrm, lemme think about this one. > > >> What is *_allow? > > > > It's very basic filtering. We have specific addresses that we don't > > allow, and we look for them in the allow() functions. You can just > > return true if you like. > > Can we make those calls optional too please? Sure. > The notify_*_init could return a opaque pointer instead. But then > you'll need a notify_*_free too. And you can't place it on the stack > and thus have a allocation in the hot path, which I guess you are trying > to avoid in the first place. Avoiding allocation is good, but at the same time, I wonder if it's not a big deal compared with the time spent copying out of the buffers, in which case it won't matter. So maybe we can do this. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
> > + if (protocol) > > + return -EPROTONOSUPPORT; > > + > > IMO protocol == PF_VSOCK should not get rejected here. Agreed, let me fix that too. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
+ if (protocol) + return -EPROTONOSUPPORT; + IMO protocol == PF_VSOCK should not get rejected here. Agreed, let me fix that too. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
I've seen you have a notify_ops in the vmci bits. Do you have different notify ops depending on socket type or something? Does it make sense to move the notify ops ptr into struct vsock_sock maybe? The notify stuff only applies to STREAMs. However, we have two different notify impls, one for legacy ESX and one for newer, and we figure out at runtime which protocol we're using with the hypervisor and set the callbacks appropriately. The difference between the two is that the newer one is much smarter and knows not to signal (the peer) quite so much, i.e., it has some basic but sensible flow-control, which improves performance quite a bit. Again, that might not make any sense at all for virtio. Do you need to signal when you enqueue to a ring? And is there coalescing? Dunno... And can we make it optional please (i.e. allow the function pointers to be NULL)? They were originally allowed to be NULL, but I changed it in the last round of patches while moving them into the transport, since I disliked the NULL checks so much. I can put them back, but that's a bigger change, and I'm not sure we want to push large patches to Dave right now :) Which problem you are trying to tackle with the notifications? It's to do with signaling the peer, or more appropriately, trying to avoid signaling the peer when possible. The naive impl. is to signal every time we enqueue or dequeue data (into our VMCI queuepairs). But signaling is slow, since it involves a world exit, so we prefer not to. Which means we need to keep track of rate of flow and figure out when we should and should not, and that's what all the notification stuff does. It's...ugly... For the VMCI transport, it indicates if the underlying queuepair is still around (i.e., make sure we haven't torn it down while sleeping in a blocking send or receive). Perhaps it's not the best name? How you'd hit that? Peer closing the socket while sleeping? Other thread closing the socket wile sleeping? Both? I think a state field in struct vsock_sock would be a better solution here. Hrm, lemme think about this one. What is *_allow? It's very basic filtering. We have specific addresses that we don't allow, and we look for them in the allow() functions. You can just return true if you like. Can we make those calls optional too please? Sure. The notify_*_init could return a opaque pointer instead. But then you'll need a notify_*_free too. And you can't place it on the stack and thus have a allocation in the hot path, which I guess you are trying to avoid in the first place. Avoiding allocation is good, but at the same time, I wonder if it's not a big deal compared with the time spent copying out of the buffers, in which case it won't matter. So maybe we can do this. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd, > > +/* Option name for socket's service label. Use as the option name in > > + * setsockopt(3) or getsockopt(3) to set or get the service label for a > > socket. > > + * The service label is a C-style NUL-terminated string. Only available > > for > > + * hypervisor endpoints. > > + */ > > + > > +#define SO_VM_SOCKETS_SERVICE_LABEL 4 > > + > > What is this and how does it work? Oops, that's specific to ESX. Thankfully it's only in the header and not in anything under net/vmw_vsock, so removing it is easy. I'll send out a patch in the morning. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 1/1] VSOCK: Introduce VM Sockets
> stream_has_data: Returns amount of data available (in bytes) in the > socket's receive buffer, or -1 if empty. > > stream_has_space: Returns amount of space available (in bytes) in the > socket's send buffer, or -1 if full. Actually, I think it's for empty/full, and -1 for an error (say, the transport closed or whatever). Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
> > +struct vsock_transport {
...
> Whoa. This has grown *alot*. Care to explain this please? Patch
> creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I removed the vmci header from the core code. You are
free to use empty functions for these if they don't make any sense
for virtio. The alternative is for us to move the entire body of
vsock_stream_recv/send into the transport, where we can hide the
notification stuff, but it seems like folks will just end up
duplicating a lot of code then.
> stream_has_data + stream_has_space + stream_rcvhiwat look like they
> are needed for buffer management. Details please (especially for
> stream_rcvhiwat).
stream_has_data: Returns amount of data available (in bytes) in the
socket's receive buffer, or -1 if empty.
stream_has_space: Returns amount of space available (in bytes) in the
socket's send buffer, or -1 if full.
stream_rcvhiwat: The upper bound on the socket's receive buffer.
Which technically is the same as the value returned by
get_buffer_size(), so perhaps we could substitute that here and
drop this one.
> What is stream_is_active?
For the VMCI transport, it indicates if the underlying queuepair is
still around (i.e., make sure we haven't torn it down while sleeping
in a blocking send or receive). Perhaps it's not the best name?
> What is *_allow?
It's very basic filtering. We have specific addresses that we don't
allow, and we look for them in the allow() functions. You can just
return true if you like.
> What are all those notify_* calls?
They're to do with signaling and flow-control. Again, they might
not make any sense at all, but it's hard to know without having
written another transport :)
> Why do you need vsock_transport_{send,recv}_notify_data structs?
> Can't this live in vsock_sock->trans?
Those have to be setup on a per-call basis (per-thread), so it's
just easier to have them on the stack of the send/recv calls. If
you think there's a better name, or a better way to allocate them,
I'm all ears.
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
+struct vsock_transport {
...
Whoa. This has grown *alot*. Care to explain this please? Patch
creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I removed the vmci header from the core code. You are
free to use empty functions for these if they don't make any sense
for virtio. The alternative is for us to move the entire body of
vsock_stream_recv/send into the transport, where we can hide the
notification stuff, but it seems like folks will just end up
duplicating a lot of code then.
stream_has_data + stream_has_space + stream_rcvhiwat look like they
are needed for buffer management. Details please (especially for
stream_rcvhiwat).
stream_has_data: Returns amount of data available (in bytes) in the
socket's receive buffer, or -1 if empty.
stream_has_space: Returns amount of space available (in bytes) in the
socket's send buffer, or -1 if full.
stream_rcvhiwat: The upper bound on the socket's receive buffer.
Which technically is the same as the value returned by
get_buffer_size(), so perhaps we could substitute that here and
drop this one.
What is stream_is_active?
For the VMCI transport, it indicates if the underlying queuepair is
still around (i.e., make sure we haven't torn it down while sleeping
in a blocking send or receive). Perhaps it's not the best name?
What is *_allow?
It's very basic filtering. We have specific addresses that we don't
allow, and we look for them in the allow() functions. You can just
return true if you like.
What are all those notify_* calls?
They're to do with signaling and flow-control. Again, they might
not make any sense at all, but it's hard to know without having
written another transport :)
Why do you need vsock_transport_{send,recv}_notify_data structs?
Can't this live in vsock_sock-trans?
Those have to be setup on a per-call basis (per-thread), so it's
just easier to have them on the stack of the send/recv calls. If
you think there's a better name, or a better way to allocate them,
I'm all ears.
Thanks!
- Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 1/1] VSOCK: Introduce VM Sockets
stream_has_data: Returns amount of data available (in bytes) in the socket's receive buffer, or -1 if empty. stream_has_space: Returns amount of space available (in bytes) in the socket's send buffer, or -1 if full. Actually, I think it's for empty/full, and -1 for an error (say, the transport closed or whatever). Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd, +/* Option name for socket's service label. Use as the option name in + * setsockopt(3) or getsockopt(3) to set or get the service label for a socket. + * The service label is a C-style NUL-terminated string. Only available for + * hypervisor endpoints. + */ + +#define SO_VM_SOCKETS_SERVICE_LABEL 4 + What is this and how does it work? Oops, that's specific to ESX. Thankfully it's only in the header and not in anything under net/vmw_vsock, so removing it is easy. I'll send out a patch in the morning. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/1] VM Sockets for Linux upstreaming
Hi Gerd, > > linux/vmw_vmci_defs.h: No such file or directory > > compilation terminated. > > make[4]: *** [net/vmw_vsock/af_vsock.o] Error 1 > > Oops, you're right, it really shouldn't need that header. Sorry > about that, let me rip that out. Fixed. The VMCI headers are now gone from the core in af_vsock.* and vsock_addr.* > > Only vmw_vsock_vmci_transport should have a vmw_vmci dependency, > > not vsock ... > > Agreed, that's not right, I'll fix that too. Fixed, lsmod now shows that only the transport has a dependency. Also, it turns out that we do need a dgram_recv(), since our transport currently enqueues skbs with VMCI DGRAMs in them, which need to be converted before copying into the user's buffer. I've added that too. Please see latest patchset (sent a few minutes ago), hope it works for you this time. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] VM Sockets for Linux upstreaming
In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vsock kernel module. Unlike previous submissions, where the new socket family was entirely reliant on VMware's VMCI PCI device (and thus VMware's hypervisor), VM Sockets is now completely[1] separated out into two parts, each in its own module: o Core socket code, which is transport-neutral and invokes transport callbacks to communicate with the hypervisor. This is vsock.ko. o A VMCI transport, which communicates over VMCI with the VMware hypervisor. This is vmw_vsock_vmci_transport.ko, and it registers with the core module as a transport. This should provide a path to introducing additional transports, for example virtio, with the ultimate goal being to make this new socket family hypervisor-neutral. [1] If Gerd tries it and determines this to be false (still), I'll ship him a keg of beer. Andy King (1): VSOCK: Introduce VM Sockets include/linux/socket.h |4 +- include/uapi/linux/vm_sockets.h | 171 ++ net/Kconfig |1 + net/Makefile |1 + net/vmw_vsock/Kconfig| 28 + net/vmw_vsock/Makefile |7 + net/vmw_vsock/af_vsock.c | 2015 net/vmw_vsock/af_vsock.h | 175 +++ net/vmw_vsock/vmci_transport.c | 2157 ++ net/vmw_vsock/vmci_transport.h | 139 ++ net/vmw_vsock/vmci_transport_notify.c| 680 net/vmw_vsock/vmci_transport_notify.h| 83 + net/vmw_vsock/vmci_transport_notify_qstate.c | 438 ++ net/vmw_vsock/vsock_addr.c | 86 + net/vmw_vsock/vsock_addr.h | 32 + net/vmw_vsock/vsock_version.h| 22 + 16 files changed, 6038 insertions(+), 1 deletions(-) create mode 100644 include/uapi/linux/vm_sockets.h create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/vmci_transport.c create mode 100644 net/vmw_vsock/vmci_transport.h create mode 100644 net/vmw_vsock/vmci_transport_notify.c create mode 100644 net/vmw_vsock/vmci_transport_notify.h create mode 100644 net/vmw_vsock/vmci_transport_notify_qstate.c create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] VM Sockets for Linux upstreaming
In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vsock kernel module. Unlike previous submissions, where the new socket family was entirely reliant on VMware's VMCI PCI device (and thus VMware's hypervisor), VM Sockets is now completely[1] separated out into two parts, each in its own module: o Core socket code, which is transport-neutral and invokes transport callbacks to communicate with the hypervisor. This is vsock.ko. o A VMCI transport, which communicates over VMCI with the VMware hypervisor. This is vmw_vsock_vmci_transport.ko, and it registers with the core module as a transport. This should provide a path to introducing additional transports, for example virtio, with the ultimate goal being to make this new socket family hypervisor-neutral. [1] If Gerd tries it and determines this to be false (still), I'll ship him a keg of beer. Andy King (1): VSOCK: Introduce VM Sockets include/linux/socket.h |4 +- include/uapi/linux/vm_sockets.h | 171 ++ net/Kconfig |1 + net/Makefile |1 + net/vmw_vsock/Kconfig| 28 + net/vmw_vsock/Makefile |7 + net/vmw_vsock/af_vsock.c | 2015 net/vmw_vsock/af_vsock.h | 175 +++ net/vmw_vsock/vmci_transport.c | 2157 ++ net/vmw_vsock/vmci_transport.h | 139 ++ net/vmw_vsock/vmci_transport_notify.c| 680 net/vmw_vsock/vmci_transport_notify.h| 83 + net/vmw_vsock/vmci_transport_notify_qstate.c | 438 ++ net/vmw_vsock/vsock_addr.c | 86 + net/vmw_vsock/vsock_addr.h | 32 + net/vmw_vsock/vsock_version.h| 22 + 16 files changed, 6038 insertions(+), 1 deletions(-) create mode 100644 include/uapi/linux/vm_sockets.h create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/vmci_transport.c create mode 100644 net/vmw_vsock/vmci_transport.h create mode 100644 net/vmw_vsock/vmci_transport_notify.c create mode 100644 net/vmw_vsock/vmci_transport_notify.h create mode 100644 net/vmw_vsock/vmci_transport_notify_qstate.c create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/1] VM Sockets for Linux upstreaming
Hi Gerd, linux/vmw_vmci_defs.h: No such file or directory compilation terminated. make[4]: *** [net/vmw_vsock/af_vsock.o] Error 1 Oops, you're right, it really shouldn't need that header. Sorry about that, let me rip that out. Fixed. The VMCI headers are now gone from the core in af_vsock.* and vsock_addr.* Only vmw_vsock_vmci_transport should have a vmw_vmci dependency, not vsock ... Agreed, that's not right, I'll fix that too. Fixed, lsmod now shows that only the transport has a dependency. Also, it turns out that we do need a dgram_recv(), since our transport currently enqueues skbs with VMCI DGRAMs in them, which need to be converted before copying into the user's buffer. I've added that too. Please see latest patchset (sent a few minutes ago), hope it works for you this time. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] VM Sockets for Linux upstreaming
Hi Gerd, > Some separation still needs to be done: > > CC [M] net/vmw_vsock/af_vsock.o > In file included from > /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.c:102:0: > /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.h:21:33: fatal > error: > linux/vmw_vmci_defs.h: No such file or directory > compilation terminated. > make[4]: *** [net/vmw_vsock/af_vsock.o] Error 1 Oops, you're right, it really shouldn't need that header. Sorry about that, let me rip that out. > Module deps are a bit bogous too: > > vmw_vsock_vmci_transport26162 0 > vsock 34481 1 vmw_vsock_vmci_transport > vmw_vmci 61602 2 vsock,vmw_vsock_vmci_transport > > Only vmw_vsock_vmci_transport should have a vmw_vmci dependency, not > vsock ... Agreed, that's not right, I'll fix that too. > Nevertheless this should be good enough to start hacking up a virtio > prototype. Great! Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] VM Sockets for Linux upstreaming
Hi Gerd, Some separation still needs to be done: CC [M] net/vmw_vsock/af_vsock.o In file included from /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.c:102:0: /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.h:21:33: fatal error: linux/vmw_vmci_defs.h: No such file or directory compilation terminated. make[4]: *** [net/vmw_vsock/af_vsock.o] Error 1 Oops, you're right, it really shouldn't need that header. Sorry about that, let me rip that out. Module deps are a bit bogous too: vmw_vsock_vmci_transport26162 0 vsock 34481 1 vmw_vsock_vmci_transport vmw_vmci 61602 2 vsock,vmw_vsock_vmci_transport Only vmw_vsock_vmci_transport should have a vmw_vmci dependency, not vsock ... Agreed, that's not right, I'll fix that too. Nevertheless this should be good enough to start hacking up a virtio prototype. Great! Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Dave, > >> Instead, what I remember doing was deferring to the feedback these > >> folks received, stating that ideas that the virtio people had > >> mentioned should be considered instead. > >> > >> http://marc.info/?l=linux-netdev=135301515818462=2 > > > > I believe Andy replied to Anthony's AF_VMCHANNEL post and the > > differences between the proposed solutions. > > I'd much rather see a hypervisor neutral solution than a hypervisor > specific one which this certainly is. We've addressed this with the latest patch series, which I sent earlier today. vSockets now has support for pluggable transports, of which VMCI happens to be the first; all transport code is separated out into its own module. So the core is now hypervisor neutral. Given that, would you be willing to re-consider it, please? If at all possible, we'd like to make the current merge window. Thanks so much! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
> From my side the minimum requirement is to have
> vsock_(un)register_transport calls available, so it is possible to
> write a virtio transport module without having to patch vsock code
> to hook it up.
We've done exactly that. It's now split into two separate modules,
with the core module offering precisely the calls you've requested.
All transport code is now its own module. So now you should be
able to add a vsock_transport_virtio module, which can register
with the core.
> >>> + struct {
> >>> + /* For DGRAMs. */
> >>> + struct vmci_handle dg_handle;
> >>
> >> Yep, should be a pointer where transports can hook in their
> >> private
> >> data.
> >
> > I'm fixing this.
>
> Yes, please, that is needed too to get started with virtio support.
Fixed: it's now a void * in the core socket structure.
I believe it's now at the point where you can start working on the
virtio transport, and we'll address API issues as they arise and
refine it as necessary. So please take one last look and let us
know what you think; hopefully we can make the current merge window :)
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] VM Sockets for Linux upstreaming
In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vsock kernel module. Unlike previous submissions, where the new socket family was entirely reliant on VMware's VMCI PCI device (and thus VMware's hypervisor), VM Sockets is now *completely* separated out into two parts, each in its own module: o Core socket code, which is transport-neutral and invokes transport callbacks to communicate with the hypervisor. This is vsock.ko. o A VMCI transport, which communicates over VMCI with the VMware hypervisor. This is vmw_vsock_vmci_transport.ko, and it registers with the core module as a transport. This should provide a path to introducing additional transports, for example virtio, with the ultimate goal being to make this new socket family hypervisor-neutral. Andy King (1): VSOCK: Introduce VM Sockets include/linux/socket.h |4 +- include/uapi/linux/vm_sockets.h | 169 +++ net/Kconfig |1 + net/Makefile |1 + net/vmw_vsock/Kconfig| 28 + net/vmw_vsock/Makefile |7 + net/vmw_vsock/af_vsock.c | 2085 ++ net/vmw_vsock/af_vsock.h | 170 +++ net/vmw_vsock/vmci_transport.c | 2050 + net/vmw_vsock/vmci_transport.h | 139 ++ net/vmw_vsock/vmci_transport_notify.c| 680 + net/vmw_vsock/vmci_transport_notify.h| 83 + net/vmw_vsock/vmci_transport_notify_qstate.c | 438 ++ net/vmw_vsock/vsock_addr.c | 128 ++ net/vmw_vsock/vsock_addr.h | 36 + net/vmw_vsock/vsock_version.h| 22 + 16 files changed, 6040 insertions(+), 1 deletions(-) create mode 100644 include/uapi/linux/vm_sockets.h create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/vmci_transport.c create mode 100644 net/vmw_vsock/vmci_transport.h create mode 100644 net/vmw_vsock/vmci_transport_notify.c create mode 100644 net/vmw_vsock/vmci_transport_notify.h create mode 100644 net/vmw_vsock/vmci_transport_notify_qstate.c create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] VM Sockets for Linux upstreaming
In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vsock kernel module. Unlike previous submissions, where the new socket family was entirely reliant on VMware's VMCI PCI device (and thus VMware's hypervisor), VM Sockets is now *completely* separated out into two parts, each in its own module: o Core socket code, which is transport-neutral and invokes transport callbacks to communicate with the hypervisor. This is vsock.ko. o A VMCI transport, which communicates over VMCI with the VMware hypervisor. This is vmw_vsock_vmci_transport.ko, and it registers with the core module as a transport. This should provide a path to introducing additional transports, for example virtio, with the ultimate goal being to make this new socket family hypervisor-neutral. Andy King (1): VSOCK: Introduce VM Sockets include/linux/socket.h |4 +- include/uapi/linux/vm_sockets.h | 169 +++ net/Kconfig |1 + net/Makefile |1 + net/vmw_vsock/Kconfig| 28 + net/vmw_vsock/Makefile |7 + net/vmw_vsock/af_vsock.c | 2085 ++ net/vmw_vsock/af_vsock.h | 170 +++ net/vmw_vsock/vmci_transport.c | 2050 + net/vmw_vsock/vmci_transport.h | 139 ++ net/vmw_vsock/vmci_transport_notify.c| 680 + net/vmw_vsock/vmci_transport_notify.h| 83 + net/vmw_vsock/vmci_transport_notify_qstate.c | 438 ++ net/vmw_vsock/vsock_addr.c | 128 ++ net/vmw_vsock/vsock_addr.h | 36 + net/vmw_vsock/vsock_version.h| 22 + 16 files changed, 6040 insertions(+), 1 deletions(-) create mode 100644 include/uapi/linux/vm_sockets.h create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/vmci_transport.c create mode 100644 net/vmw_vsock/vmci_transport.h create mode 100644 net/vmw_vsock/vmci_transport_notify.c create mode 100644 net/vmw_vsock/vmci_transport_notify.h create mode 100644 net/vmw_vsock/vmci_transport_notify_qstate.c create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_version.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
From my side the minimum requirement is to have
vsock_(un)register_transport calls available, so it is possible to
write a virtio transport module without having to patch vsock code
to hook it up.
We've done exactly that. It's now split into two separate modules,
with the core module offering precisely the calls you've requested.
All transport code is now its own module. So now you should be
able to add a vsock_transport_virtio module, which can register
with the core.
+ struct {
+ /* For DGRAMs. */
+ struct vmci_handle dg_handle;
Yep, should be a pointer where transports can hook in their
private
data.
I'm fixing this.
Yes, please, that is needed too to get started with virtio support.
Fixed: it's now a void * in the core socket structure.
I believe it's now at the point where you can start working on the
virtio transport, and we'll address API issues as they arise and
refine it as necessary. So please take one last look and let us
know what you think; hopefully we can make the current merge window :)
Thanks!
- Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Dave, Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. We've addressed this with the latest patch series, which I sent earlier today. vSockets now has support for pluggable transports, of which VMCI happens to be the first; all transport code is separated out into its own module. So the core is now hypervisor neutral. Given that, would you be willing to re-consider it, please? If at all possible, we'd like to make the current merge window. Thanks so much! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
Thanks so much for taking a look and apologies for the delay!
> > +config VMWARE_VSOCK
> > + tristate "Virtual Socket protocol"
> > + depends on VMWARE_VMCI
>
> I guess this is temporary? Cover letter says *mostly* separated ...
Yes, right now everything is still munged into one driver.
> > +vmw_vsock-y += af_vsock.o vmci_transport.o vmci_transport_notify.o
> > \
> > + vmci_transport_notify_qstate.o vsock_addr.o
>
> Likewise, I expect with the final version vmci_transport is a
> separate module (or moves into the vmci driver), correct?
When you say final, do you mean something that we have to do before
acceptance into mainline or something we can refine over time? I'm
rather hoping for the latter: it'd be nice to come to an agreement
about whether VM Sockets is the right way to go, and actually get
this in, before we go to the trouble of splitting this out, only to
find that nobody actually implements their own transport ;)
> > + switch (cmd) {
> > + case IOCTL_VMCI_SOCKETS_VERSION:
> > + version = VMCI_SOCKETS_MAKE_VERSION(parts);
> > + if (put_user(version, p) != 0)
> > + retval = -EFAULT;
> > + break;
>
> Still needed?
Cut.
> > + case IOCTL_VMCI_SOCKETS_GET_AF_VALUE:
> > + if (put_user(AF_VSOCK, p) != 0)
> > + retval = -EFAULT;
> > +
> > + break;
>
> That can go away, with the upstream merge vsock will get a fixed
> AF_VSOCK.
Cut.
> > + case IOCTL_VMCI_SOCKETS_GET_LOCAL_CID:
> > + if (put_user(vmci_get_context_id(), p) != 0)
> > + retval = -EFAULT;
>
> What is this?
A CID, or "context ID" is how we identify a VM. It's also in
the address structure (svm_cid). If you look at vm_sockets.h,
you'll see that we have definitions for various endpoints (the
host, anonymous and so forth). It's sometimes useful for VMs
to be able to query their own ID, for example, to be able to
pass it out-of-band via INET to a peer. So we'd like to keep
this, although I guess it should be transport-defined, i.e.,
we should ask the transport for this value.
> > + err = vmci_transport_register();
> > + if (err) {
> > + pr_err("Cannot register with VMCI device\n");
> > + goto err_misc_deregister;
> > + }
>
> Hmm? There should be a vsock_(un)register_transport which the vmci
> transport code can call (and likewise virtio transport some day).
Yes, it's still totally topsy-turvy. But see comment about coming
to an agreement :)
> > + struct {
> > + /* For DGRAMs. */
> > + struct vmci_handle dg_handle;
>
> Yep, should be a pointer where transports can hook in their private
> data.
I'm fixing this.
> > +struct vsock_transport {
> > + void (*init)(struct vsock_sock *, struct vsock_sock *);
> > + void (*destruct)(struct vsock_sock *);
> > + void (*release)(struct vsock_sock *);
> > + int (*connect)(struct vsock_sock *);
> > + int (*bind_dgram)(struct vsock_sock *, struct sockaddr_vm *);
> > + int (*send_dgram)(struct vsock_sock *, struct sockaddr_vm *,
> > + struct iovec *, size_t len);
> > + ssize_t (*recv_stream)(struct vsock_sock *, struct iovec *,
> > + size_t len, int flags);
> > + ssize_t (*send_stream)(struct vsock_sock *, struct iovec *,
> > + size_t len);
> > + s64 (*stream_has_data)(struct vsock_sock *);
> > + s64 (*stream_has_space)(struct vsock_sock *);
> > + int (*send_shutdown)(struct sock *sk, int mode);
> > + void (*unregister)(void);
> > +};
>
> So that is the interface transports have to implement. Looks
> reasonable to me. Some documentation would be nice, although
> most of it is self-explaining.
>
> Where is recv_dgram?
The transport just enqueues sk_buffs in the socket's buffer, so the
core socket code can just pull them off. So there's no explicit
recv_dgram.
> Also why bind_dgram? I guess binding stream sockets doesn't make
> sense for the vsock family?
Ah, for our transport, there's nothing special involved in binding a
STREAM, everything is handled by the core socket code. So I didn't
add a transport callback. This is something we can add when it
becomes necessary, if that's okay?
> I'd make the naming a bit more consistent, some stream callbacks are
> prefixed and some postfixed with "stream".
Fixed.
> I'd also name send_shutdown just shutdown (same name the system call
> has).
Fixed.
> What does unregister?
That's topsy-turvy unregistration, it drops the transport. It will go
away eventually.
I'll send out a patch soon addressing the (easy) issues above.
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Gerd,
Thanks so much for taking a look and apologies for the delay!
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on VMWARE_VMCI
I guess this is temporary? Cover letter says *mostly* separated ...
Yes, right now everything is still munged into one driver.
+vmw_vsock-y += af_vsock.o vmci_transport.o vmci_transport_notify.o
\
+ vmci_transport_notify_qstate.o vsock_addr.o
Likewise, I expect with the final version vmci_transport is a
separate module (or moves into the vmci driver), correct?
When you say final, do you mean something that we have to do before
acceptance into mainline or something we can refine over time? I'm
rather hoping for the latter: it'd be nice to come to an agreement
about whether VM Sockets is the right way to go, and actually get
this in, before we go to the trouble of splitting this out, only to
find that nobody actually implements their own transport ;)
+ switch (cmd) {
+ case IOCTL_VMCI_SOCKETS_VERSION:
+ version = VMCI_SOCKETS_MAKE_VERSION(parts);
+ if (put_user(version, p) != 0)
+ retval = -EFAULT;
+ break;
Still needed?
Cut.
+ case IOCTL_VMCI_SOCKETS_GET_AF_VALUE:
+ if (put_user(AF_VSOCK, p) != 0)
+ retval = -EFAULT;
+
+ break;
That can go away, with the upstream merge vsock will get a fixed
AF_VSOCK.
Cut.
+ case IOCTL_VMCI_SOCKETS_GET_LOCAL_CID:
+ if (put_user(vmci_get_context_id(), p) != 0)
+ retval = -EFAULT;
What is this?
A CID, or context ID is how we identify a VM. It's also in
the address structure (svm_cid). If you look at vm_sockets.h,
you'll see that we have definitions for various endpoints (the
host, anonymous and so forth). It's sometimes useful for VMs
to be able to query their own ID, for example, to be able to
pass it out-of-band via INET to a peer. So we'd like to keep
this, although I guess it should be transport-defined, i.e.,
we should ask the transport for this value.
+ err = vmci_transport_register(transport);
+ if (err) {
+ pr_err(Cannot register with VMCI device\n);
+ goto err_misc_deregister;
+ }
Hmm? There should be a vsock_(un)register_transport which the vmci
transport code can call (and likewise virtio transport some day).
Yes, it's still totally topsy-turvy. But see comment about coming
to an agreement :)
+ struct {
+ /* For DGRAMs. */
+ struct vmci_handle dg_handle;
Yep, should be a pointer where transports can hook in their private
data.
I'm fixing this.
+struct vsock_transport {
+ void (*init)(struct vsock_sock *, struct vsock_sock *);
+ void (*destruct)(struct vsock_sock *);
+ void (*release)(struct vsock_sock *);
+ int (*connect)(struct vsock_sock *);
+ int (*bind_dgram)(struct vsock_sock *, struct sockaddr_vm *);
+ int (*send_dgram)(struct vsock_sock *, struct sockaddr_vm *,
+ struct iovec *, size_t len);
+ ssize_t (*recv_stream)(struct vsock_sock *, struct iovec *,
+ size_t len, int flags);
+ ssize_t (*send_stream)(struct vsock_sock *, struct iovec *,
+ size_t len);
+ s64 (*stream_has_data)(struct vsock_sock *);
+ s64 (*stream_has_space)(struct vsock_sock *);
+ int (*send_shutdown)(struct sock *sk, int mode);
+ void (*unregister)(void);
+};
So that is the interface transports have to implement. Looks
reasonable to me. Some documentation would be nice, although
most of it is self-explaining.
Where is recv_dgram?
The transport just enqueues sk_buffs in the socket's buffer, so the
core socket code can just pull them off. So there's no explicit
recv_dgram.
Also why bind_dgram? I guess binding stream sockets doesn't make
sense for the vsock family?
Ah, for our transport, there's nothing special involved in binding a
STREAM, everything is handled by the core socket code. So I didn't
add a transport callback. This is something we can add when it
becomes necessary, if that's okay?
I'd make the naming a bit more consistent, some stream callbacks are
prefixed and some postfixed with stream.
Fixed.
I'd also name send_shutdown just shutdown (same name the system call
has).
Fixed.
What does unregister?
That's topsy-turvy unregistration, it drops the transport. It will go
away eventually.
I'll send out a patch soon addressing the (easy) issues above.
Thanks!
- Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
> > > Our position is that VSOCK feature set is more complete and that > > > it > > > should be possible to use transports other than VMCI for VSOCK > > > traffic, should interested parties implement them, > > > > Implementing other transports requires restructing vsock (and vmci) > > first as the current vsock code is not a hypervisor neutral > > service. > > I'm going to bite the bullet and spend the next couple of days doing > just that: factoring out the VMCI bits and hiding them behind a > transport layer. It'll be a bit rough, but it'll be a start. We'll > submit another patch series next week with that. I'm hoping that'll > get us over this hump, since it should by hypervisor agnostic at > that point. It'll be up to you guys to add virtio, though :) I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMCI: Fix broken context ID retrieval
I'm an idiot. The context ID can be a really large unsigned number, which
means it'll appear negative as an int. So actually the right fix here is just
to set it regardless of the returned value (but only for this particular
hypercall; normally we would check it).
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_guest.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index de1a90b..60c0199 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -81,16 +81,13 @@ bool vmci_guest_code_active(void)
u32 vmci_get_vm_context_id(void)
{
if (vm_context_id == VMCI_INVALID_ID) {
- int result;
struct vmci_datagram get_cid_msg;
get_cid_msg.dst =
vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
VMCI_GET_CONTEXT_ID);
get_cid_msg.src = VMCI_ANON_SRC_HANDLE;
get_cid_msg.payload_size = 0;
- result = vmci_send_datagram(_cid_msg);
- if (result >= 0)
- vm_context_id = result;
+ vm_context_id = vmci_send_datagram(_cid_msg);
}
return vm_context_id;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VMCI: Fix broken context ID retrieval
I'm an idiot. The context ID can be a really large unsigned number, which
means it'll appear negative as an int. So actually the right fix here is just
to set it regardless of the returned value (but only for this particular
hypercall; normally we would check it).
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_guest.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index de1a90b..60c0199 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -81,16 +81,13 @@ bool vmci_guest_code_active(void)
u32 vmci_get_vm_context_id(void)
{
if (vm_context_id == VMCI_INVALID_ID) {
- int result;
struct vmci_datagram get_cid_msg;
get_cid_msg.dst =
vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
VMCI_GET_CONTEXT_ID);
get_cid_msg.src = VMCI_ANON_SRC_HANDLE;
get_cid_msg.payload_size = 0;
- result = vmci_send_datagram(get_cid_msg);
- if (result = 0)
- vm_context_id = result;
+ vm_context_id = vmci_send_datagram(get_cid_msg);
}
return vm_context_id;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
> > Our position is that VSOCK feature set is more complete and that it > > should be possible to use transports other than VMCI for VSOCK > > traffic, should interested parties implement them, > > Implementing other transports requires restructing vsock (and vmci) > first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) And in the meantime, are there any other glaring errors that we need to address? Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) And in the meantime, are there any other glaring errors that we need to address? Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Anthony, > This was already done in a hypervisor neutral way using virtio: > > http://lists.openwall.net/netdev/2008/12/14/8 > > The concept was Nacked and that led to the abomination of > virtio-serial. If an address family for virtualization is on the > table, we should reconsider AF_VMCHANNEL. I finally had a look at your patch. Please correct me if I'm wrong, but it seems that the peer of an AF_VMCHANNEL connection is a virtio channel inside the hypervisor, i.e., the other end is _not_ sockets, right? That's quite a bit different from vSockets, where both sides use the socket interface, even within the VMX process in our hypervisor. We also intend for arbitrary host processes -- those outside the hypervisor -- to use it via the sockets interface. We have shipping applications that do just that, where communication is between a guest process and a host service, with both sides using the standard socket API but with the vSockets address family. We also encourage people to write such VM-to-host applications, and we've been shipping the vSockets header in our host-side products to allow people to do just that. So I think in that sense vSockets is somewhat more general, and we'd obviously prefer to go with our socket family and address structure if LKML is open to something like this. Thanks! - Andy PS I realize we still owe LKML a spec for the vSockets protocol. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Anthony, This was already done in a hypervisor neutral way using virtio: http://lists.openwall.net/netdev/2008/12/14/8 The concept was Nacked and that led to the abomination of virtio-serial. If an address family for virtualization is on the table, we should reconsider AF_VMCHANNEL. I finally had a look at your patch. Please correct me if I'm wrong, but it seems that the peer of an AF_VMCHANNEL connection is a virtio channel inside the hypervisor, i.e., the other end is _not_ sockets, right? That's quite a bit different from vSockets, where both sides use the socket interface, even within the VMX process in our hypervisor. We also intend for arbitrary host processes -- those outside the hypervisor -- to use it via the sockets interface. We have shipping applications that do just that, where communication is between a guest process and a host service, with both sides using the standard socket API but with the vSockets address family. We also encourage people to write such VM-to-host applications, and we've been shipping the vSockets header in our host-side products to allow people to do just that. So I think in that sense vSockets is somewhat more general, and we'd obviously prefer to go with our socket family and address structure if LKML is open to something like this. Thanks! - Andy PS I realize we still owe LKML a spec for the vSockets protocol. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] VMCI: Some header and config files.
I didn't get the resend either, so it seems our corporate mail really is eating messages. Lovely. > > > +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd > > > > I don't recall ever getting a valid answer for this (if you did, my > > appologies, can you repeat it). What in the world are you talking > > about here? Why is your driver somehow special from the thousands > > of other ones that use the in-kernel IO macros properly for an > > ioctl? Because we're morons. And unfortunately, we've shipped our product using those broken definitions: our VMX uses them to talk to the driver. So here's what we'd like to do. We will send out a patch soon that fixes the other issues you mention and also adds IOCTL definitions the proper way using _IOBLAH(). But we'd also like to retain these broken definitions for a short period, commented as such, at least until we can get out a patch release to Workstation 9, at which point we can remove them. Does that sound reasonable? Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] VMCI: Some header and config files.
I didn't get the resend either, so it seems our corporate mail really is eating messages. Lovely. +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd I don't recall ever getting a valid answer for this (if you did, my appologies, can you repeat it). What in the world are you talking about here? Why is your driver somehow special from the thousands of other ones that use the in-kernel IO macros properly for an ioctl? Because we're morons. And unfortunately, we've shipped our product using those broken definitions: our VMX uses them to talk to the driver. So here's what we'd like to do. We will send out a patch soon that fixes the other issues you mention and also adds IOCTL definitions the proper way using _IOBLAH(). But we'd also like to retain these broken definitions for a short period, commented as such, at least until we can get out a patch release to Workstation 9, at which point we can remove them. Does that sound reasonable? Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 01/12] VMCI: context implementation.
Hi Joe,
> Just some trivial notes.
Thanks for taking a look!
> > + pr_warn("Failed to allocate memory for VMCI context.\n");
>
> OOM logging messages aren't necessary as alloc failures
> are already logged with a stack trace.
Noted, we'll remove all such occurrences.
> Maybe just use
> struct vmci_event_msg e_msg;
> struct vmci_event_payld_ctx ev_payload;
> and change the addressing or use a cast as appropriate?
It does seem inelegant, we'll take a look.
> You also have some inconsistency in whether or not your
> logging messages use a terminating period. I suggest
> you just delete all the periods.
> s/\.\\n"/\\n"/g
Gah, that's ugly. We'll remove all of them as you suggest.
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 01/12] VMCI: context implementation.
Hi Joe, Just some trivial notes. Thanks for taking a look! + pr_warn(Failed to allocate memory for VMCI context.\n); OOM logging messages aren't necessary as alloc failures are already logged with a stack trace. Noted, we'll remove all such occurrences. Maybe just use struct vmci_event_msg e_msg; struct vmci_event_payld_ctx ev_payload; and change the addressing or use a cast as appropriate? It does seem inelegant, we'll take a look. You also have some inconsistency in whether or not your logging messages use a terminating period. I suggest you just delete all the periods. s/\.\\n/\\n/g Gah, that's ugly. We'll remove all of them as you suggest. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Sasha, Thanks for taking a look. > So all the documentation I see in the VMCI Socket Programming Guide > is about userspace programming, and the documentation in af_vsock.c > is all around implementation considerations. Agreed, we're sorely lacking in proper documentation for the internal protocol. We're in the process of writing such a specification and will post it to LKML next week at the latest. > example, whats the deal with REQUEST/REQUEST2? it appears like > something to deal with legacy code, but I'd really like to have it > documented somewhere instead of trying to figure how everything Correct, we have a legacy protocol and a v2, the latter now being the default. This particular packet is sent by the client when initiating a STREAM connection. The sequence is REQUEST(2)-> NEGOTIATE(2)->OFFER->ACCEPT. It will be properly documented in the specification we post next week. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Sasha, Thanks for taking a look. So all the documentation I see in the VMCI Socket Programming Guide is about userspace programming, and the documentation in af_vsock.c is all around implementation considerations. Agreed, we're sorely lacking in proper documentation for the internal protocol. We're in the process of writing such a specification and will post it to LKML next week at the latest. example, whats the deal with REQUEST/REQUEST2? it appears like something to deal with legacy code, but I'd really like to have it documented somewhere instead of trying to figure how everything Correct, we have a legacy protocol and a v2, the latter now being the default. This particular packet is sent by the client when initiating a STREAM connection. The sequence is REQUEST(2)- NEGOTIATE(2)-OFFER-ACCEPT. It will be properly documented in the specification we post next week. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Gerd, >> Also, there was some interest from RedHat into using vSockets as >> a unified interface, routed over a hypervisor-specific transport >> (virtio or otherwise, although for now VMCI is the only one >> implemented). > > Can you outline how this can be done? From a quick look over the > code it seems like vsock has a hard dependency on vmci, is that > correct? That's correct, VMCI is wired into vSockets and we don't currently provide any way to insert another transport. > When making vsock a generic, reusable kernel service it should be > the other way around: vsock should provide the core implementation > and an interface where hypervisor-specific transports (vmci, > virtio, xenbus, ...) can register themself. Sorry, that was a bad explanation on my part. You're absolutely correct as to how it _should_ work. But it's up to Red Hat or others to get the ball rolling and motivate the necessary work on vSockets to make this happen. As Greg says, "everyone is lazy and just wants their code accepted" ;) Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Gerd, Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Can you outline how this can be done? From a quick look over the code it seems like vsock has a hard dependency on vmci, is that correct? That's correct, VMCI is wired into vSockets and we don't currently provide any way to insert another transport. When making vsock a generic, reusable kernel service it should be the other way around: vsock should provide the core implementation and an interface where hypervisor-specific transports (vmci, virtio, xenbus, ...) can register themself. Sorry, that was a bad explanation on my part. You're absolutely correct as to how it _should_ work. But it's up to Red Hat or others to get the ball rolling and motivate the necessary work on vSockets to make this happen. As Greg says, everyone is lazy and just wants their code accepted ;) Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 1/6] VSOCK: vsock protocol implementation.
Hi Stephen, > You did some scrubbing of the macro's to support multiple kernel > versions, but there are still some leftovers. > This code seems to have a lot of "this added in version xxx" > type comments. These are probably not a good idea to include > in the mainline kernel code. Thanks so much for taking a look. Sorry about that, we'll remove all such occurrences and send out a new series of patches in a bit. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 1/6] VSOCK: vsock protocol implementation.
Hi Stephen, You did some scrubbing of the macro's to support multiple kernel versions, but there are still some leftovers. This code seems to have a lot of this added in version xxx type comments. These are probably not a good idea to include in the mainline kernel code. Thanks so much for taking a look. Sorry about that, we'll remove all such occurrences and send out a new series of patches in a bit. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi David, > The big and only question is whether anyone can actually use any of > this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is actively reviewing that code and we are addressing feedback. Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi David, The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is actively reviewing that code and we are addressing feedback. Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
