[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang Acked-by: Andy king Acked-by: Dmitry Torokhov --- drivers/misc/Kconfig |1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 include/linux/vmw_vmci_api.h | 82 include/linux/vmw_vmci_defs.h | 880 6 files changed, 985 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b151b7c..264e647 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -507,4 +507,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 2129377..5c99726 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,3 +49,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..023430e --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include +#include + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define VMCI_KERNEL_API_VERSION_2 2 +#define VMCI_KERNEL_API_VERSION VMCI_KERNEL_API_VERSION_2 + +typedef void (vmci_device_shutdown_fn) (void *device_registration, + void *user_data); + +int vmci_datagram_create_handle(u32 resource_id, u32 flags, + vmci_datagram_recv_cb recv_cb, + void *client_data, + struct vmci_handle *out_handle); +int vmci_datagram_create_handle_priv(u32 resource_id, u32 flags, u32 priv_flags, +vmci_datagram_recv_cb recv_cb, +void *client_data, +struct vmci_handle *out_handle); +int vmci_datagram_destroy_handle(struct vmci_handle handle); +int vmci_datagram_send(struct vmci_datagram *msg); +int vmci_doorbell_create(struct vmci_handle *handle, u32 flags, +u32 priv_flags, +vmci_callback notify_cb, void *client_data); +int vmci_doorbell_destroy(struct vmci_handle handle); +int vmci_doorbell_notify(struct vmci_handle handle, u32 priv_flags); +u32 vmci_get_context_id(void); +bool vmci_is_context_owner(u32 context_id, kuid_t uid); + +int vmci_event_subscribe(u32 event, +vmci_event_cb callback, void *callback_data, +
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com Acked-by: Andy king ack...@vmware.com Acked-by: Dmitry Torokhov d...@vmware.com --- drivers/misc/Kconfig |1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 include/linux/vmw_vmci_api.h | 82 include/linux/vmw_vmci_defs.h | 880 6 files changed, 985 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b151b7c..264e647 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -507,4 +507,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 2129377..5c99726 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,3 +49,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..023430e --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include linux/uidgid.h +#include linux/vmw_vmci_defs.h + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define VMCI_KERNEL_API_VERSION_2 2 +#define VMCI_KERNEL_API_VERSION VMCI_KERNEL_API_VERSION_2 + +typedef void (vmci_device_shutdown_fn) (void *device_registration, + void *user_data); + +int vmci_datagram_create_handle(u32 resource_id, u32 flags, + vmci_datagram_recv_cb recv_cb, + void *client_data, + struct vmci_handle *out_handle); +int vmci_datagram_create_handle_priv(u32 resource_id, u32 flags, u32 priv_flags, +vmci_datagram_recv_cb recv_cb, +void *client_data, +struct vmci_handle *out_handle); +int vmci_datagram_destroy_handle(struct vmci_handle handle); +int vmci_datagram_send(struct vmci_datagram *msg); +int vmci_doorbell_create(struct vmci_handle *handle, u32 flags, +u32 priv_flags, +vmci_callback notify_cb, void *client_data); +int vmci_doorbell_destroy(struct vmci_handle handle); +int vmci_doorbell_notify(struct vmci_handle handle, u32 priv_flags); +u32 vmci_get_context_id(void); +bool vmci_is_context_owner(u32 context_id, kuid_t uid); + +int vmci_event_subscribe(u32 event, +
Re: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:58:25PM -0800, Dmitry Torokhov wrote: > On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: > > On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > > > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > > > However you snipped the rest of my reply: do we really need to > > > > > renumber > > > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > > > not parse the numbers into components. > > > > > > > > I don't know if you need to renumber, I really don't understand what you > > > > were trying to do with this code, and as it was acting differently from > > > > all other kernel ioctl declarations, I asked for some clarity. > > > > > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > > > fine with me. > > > > > > OK, it looks like we can redo them as: > > > > > > #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ > > > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > > > > > Is this acceptable? > > > > Sure, that's better. You also got lucky, '7' happens to be unused right > > now. > > Excellent. You said you want the next drop after -rc1, right? Yes please, I will be ignoring patches until then. greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: > On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > > However you snipped the rest of my reply: do we really need to > > > > renumber > > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > > not parse the numbers into components. > > > > > > I don't know if you need to renumber, I really don't understand what you > > > were trying to do with this code, and as it was acting differently from > > > all other kernel ioctl declarations, I asked for some clarity. > > > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > > fine with me. > > > > OK, it looks like we can redo them as: > > > > #define IOCTL_VMCI_VERSION _IO(7, 0x9f)/* 1951 */ > > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > > > Is this acceptable? > > Sure, that's better. You also got lucky, '7' happens to be unused right > now. Excellent. You said you want the next drop after -rc1, right? -- Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > However you snipped the rest of my reply: do we really need to renumber > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > not parse the numbers into components. > > > > I don't know if you need to renumber, I really don't understand what you > > were trying to do with this code, and as it was acting differently from > > all other kernel ioctl declarations, I asked for some clarity. > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > fine with me. > > OK, it looks like we can redo them as: > > #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > Is this acceptable? Sure, that's better. You also got lucky, '7' happens to be unused right now. greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > However you snipped the rest of my reply: do we really need to renumber > > ioctls? There is no benefit for the driver as its ioctl handler does > > not parse the numbers into components. > > I don't know if you need to renumber, I really don't understand what you > were trying to do with this code, and as it was acting differently from > all other kernel ioctl declarations, I asked for some clarity. > > If you can rewrite it to look sane, and keep the same numbers, that's > fine with me. OK, it looks like we can redo them as: #define IOCTL_VMCI_VERSION _IO(7, 0x9f)/* 1951 */ #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ Is this acceptable? Thanks, Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > However you snipped the rest of my reply: do we really need to renumber > ioctls? There is no benefit for the driver as its ioctl handler does > not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. thanks, greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 10:39:18 AM Greg KH wrote: > On Fri, Nov 30, 2012 at 09:20:41AM -0800, Dmitry Torokhov wrote: > > On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: > > > On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: > > > > 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? > > > > > > It has been my experience, that when people say "We will remove that api > > > sometime in the future", it never happens. So why not just do it now? > > > > > > Especially given that this code will be coming out in 3.9 at the > > > earliest, and that is 6 months away, so that should be plenty of time to > > > get this fixed up. > > > > Our schedule for releasing hosted products is not necessarily aligned > > with mainline kernel releases. > > And kernel developers don't really care about company schedules, nor > should they, you know this :) > That is why we are offering a compromise so that older installations have a chance to work and nobody has to care about schedules too much. However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. Thanks, Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 09:20:41AM -0800, Dmitry Torokhov wrote: > On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: > > On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: > > > 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? > > > > It has been my experience, that when people say "We will remove that api > > sometime in the future", it never happens. So why not just do it now? > > > > Especially given that this code will be coming out in 3.9 at the > > earliest, and that is 6 months away, so that should be plenty of time to > > get this fixed up. > > Our schedule for releasing hosted products is not necessarily aligned > with mainline kernel releases. And kernel developers don't really care about company schedules, nor should they, you know this :) thanks, greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: > On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: > > 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? > > It has been my experience, that when people say "We will remove that api > sometime in the future", it never happens. So why not just do it now? > > Especially given that this code will be coming out in 3.9 at the > earliest, and that is 6 months away, so that should be plenty of time to > get this fixed up. Our schedule for releasing hosted products is not necessarily aligned with mainline kernel releases. Also, thinking about it some more, maybe we should simply keep the old ioctls as is? Yes, they would not use the standard kernel style encoding for direction, etc, but the encoding only important if ioctl handler wants to parse and use it. Since we do not flat ioctl number is fine with us. That said we 'll clean up comments and numbers to remove stuff not applicable to mainline. Thanks, Dmitry -- 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.
On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: > 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? It has been my experience, that when people say "We will remove that api sometime in the future", it never happens. So why not just do it now? Especially given that this code will be coming out in 3.9 at the earliest, and that is 6 months away, so that should be plenty of time to get this fixed up. thanks, greg k-h -- 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: [PATCH 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: 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? It has been my experience, that when people say We will remove that api sometime in the future, it never happens. So why not just do it now? Especially given that this code will be coming out in 3.9 at the earliest, and that is 6 months away, so that should be plenty of time to get this fixed up. thanks, greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: 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? It has been my experience, that when people say We will remove that api sometime in the future, it never happens. So why not just do it now? Especially given that this code will be coming out in 3.9 at the earliest, and that is 6 months away, so that should be plenty of time to get this fixed up. Our schedule for releasing hosted products is not necessarily aligned with mainline kernel releases. Also, thinking about it some more, maybe we should simply keep the old ioctls as is? Yes, they would not use the standard kernel style encoding for direction, etc, but the encoding only important if ioctl handler wants to parse and use it. Since we do not flat ioctl number is fine with us. That said we 'll clean up comments and numbers to remove stuff not applicable to mainline. Thanks, Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 09:20:41AM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: 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? It has been my experience, that when people say We will remove that api sometime in the future, it never happens. So why not just do it now? Especially given that this code will be coming out in 3.9 at the earliest, and that is 6 months away, so that should be plenty of time to get this fixed up. Our schedule for releasing hosted products is not necessarily aligned with mainline kernel releases. And kernel developers don't really care about company schedules, nor should they, you know this :) thanks, greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 10:39:18 AM Greg KH wrote: On Fri, Nov 30, 2012 at 09:20:41AM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 09:09:21 AM Greg KH wrote: On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote: 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? It has been my experience, that when people say We will remove that api sometime in the future, it never happens. So why not just do it now? Especially given that this code will be coming out in 3.9 at the earliest, and that is 6 months away, so that should be plenty of time to get this fixed up. Our schedule for releasing hosted products is not necessarily aligned with mainline kernel releases. And kernel developers don't really care about company schedules, nor should they, you know this :) That is why we are offering a compromise so that older installations have a chance to work and nobody has to care about schedules too much. However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. Thanks, Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. thanks, greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. OK, it looks like we can redo them as: #define IOCTL_VMCI_VERSION _IO(7, 0x9f)/* 1951 */ #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ Is this acceptable? Thanks, Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. OK, it looks like we can redo them as: #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ Is this acceptable? Sure, that's better. You also got lucky, '7' happens to be unused right now. greg k-h -- 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 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. OK, it looks like we can redo them as: #define IOCTL_VMCI_VERSION _IO(7, 0x9f)/* 1951 */ #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ Is this acceptable? Sure, that's better. You also got lucky, '7' happens to be unused right now. Excellent. You said you want the next drop after -rc1, right? -- Dmitry -- 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 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:58:25PM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: However you snipped the rest of my reply: do we really need to renumber ioctls? There is no benefit for the driver as its ioctl handler does not parse the numbers into components. I don't know if you need to renumber, I really don't understand what you were trying to do with this code, and as it was acting differently from all other kernel ioctl declarations, I asked for some clarity. If you can rewrite it to look sane, and keep the same numbers, that's fine with me. OK, it looks like we can redo them as: #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ Is this acceptable? Sure, that's better. You also got lucky, '7' happens to be unused right now. Excellent. You said you want the next drop after -rc1, right? Yes please, I will be ignoring patches until then. greg k-h -- 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 12/12] VMCI: Some header and config files.
On Monday, November 26, 2012 04:32:39 PM Greg KH wrote:
> On Mon, Nov 26, 2012 at 04:23:57PM -0800, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > For some reason it still didn't go through to our corporate mail server
> > but I see it on LKML.
>
> Good.
>
> > On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
> > > On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
> > > > +static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid,
> > > > vmci_id rid) +{
> > > > + struct vmci_handle h;
> > > > + h.context = cid;
> > > > + h.resource = rid;
> > > > + return h;
> > > > +}
> > >
> > > You return a structure on the stack that just went away? Yeah, I know
> > > it's an inline, but come on, that's not ok.
> >
> > This is certainly OK even if it is not inline, we return the _value_,
> > not the pointer to the stacki memory. And yes, the structure is 64 bit
> > value so it is returned in registers.
>
> Even on a 32bit processor?
I thought it would, but it looks like it won't. Maybe we'll just switch it
to a macro with C99 style initializators to keep the same semantic but
avoid the question.
> Also, you already have another function that
> does this same thing, so having 2 functions in the same patch seems odd,
> right?
Yes, you can say that it is probably a bit excessive.
OK, now that we are on the same page we'll go and fix the issues.
Thanks,
Dmitry
--
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.
On Mon, Nov 26, 2012 at 04:23:57PM -0800, Dmitry Torokhov wrote:
> Hi Greg,
>
> For some reason it still didn't go through to our corporate mail server
> but I see it on LKML.
Good.
> On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
> > On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
> >
> > > +static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id
> > > rid)
> > > +{
> > > + struct vmci_handle h;
> > > + h.context = cid;
> > > + h.resource = rid;
> > > + return h;
> > > +}
> >
> > You return a structure on the stack that just went away? Yeah, I know
> > it's an inline, but come on, that's not ok.
>
> This is certainly OK even if it is not inline, we return the _value_,
> not the pointer to the stacki memory. And yes, the structure is 64 bit
> value so it is returned in registers.
Even on a 32bit processor? Also, you already have another function that
does this same thing, so having 2 functions in the same patch seems odd,
right?
greg k-h
--
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.
Hi Greg,
For some reason it still didn't go through to our corporate mail server
but I see it on LKML.
On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
> On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
>
> > +static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
> > +{
> > + struct vmci_handle h;
> > + h.context = cid;
> > + h.resource = rid;
> > + return h;
> > +}
>
> You return a structure on the stack that just went away? Yeah, I know
> it's an inline, but come on, that's not ok.
This is certainly OK even if it is not inline, we return the _value_,
not the pointer to the stacki memory. And yes, the structure is 64 bit
value so it is returned in registers.
>
> > +#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
> > +#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
>
> It's longer to write the macro out than to just do .context or
> .resource, just use them instead.
We really want vmci_handle to be opaque where possible and use proper
accessors.
>
> > +#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context &&
> > \
> > +(_h1).resource == (_h2).resource)
>
> Inline function instead? How often do you really need this?
OK, makes sense.
>
> > +#define VMCI_INVALID_ID ~0
> > +static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
> > + VMCI_INVALID_ID
> > +};
>
> C99 initializers please.
OK.
>
> > +
> > +#define VMCI_HANDLE_INVALID(_handle)
> > \
> > + VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
>
> Gotta love magic values :(
?
>
> > +/*
> > + * The below defines can be used to send anonymous requests.
> > + * This also indicates that no response is expected.
> > + */
> > +#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
> > +#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
> > +#define VMCI_ANON_SRC_HANDLE
> > vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
> > + VMCI_ANON_SRC_RESOURCE_ID)
>
> So you just created an invalid message?
Anonymous one, yes.
>
> > +/* The lowest 16 context ids are reserved for internal use. */
> > +#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
> > +
> > +/*
> > + * Hypervisor context id, used for calling into hypervisor
> > + * supplied services from the VM.
> > + */
> > +#define VMCI_HYPERVISOR_CONTEXT_ID 0
> > +
> > +/*
> > + * Well-known context id, a logical context that contains a set of
> > + * well-known services. This context ID is now obsolete.
> > + */
> > +#define VMCI_WELL_KNOWN_CONTEXT_ID 1
> > +
> > +/*
> > + * Context ID used by host endpoints.
> > + */
> > +#define VMCI_HOST_CONTEXT_ID 2
> > +
> > +#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid) &&
> > \
> > + (_cid) > VMCI_HOST_CONTEXT_ID)
> > +
>
> Are you sure all of this stuff needs to be in a .h file that lives in
> include/linux/?
Probably not. We'll rebase to 3.7 and split as needed.
>
> > +/*
> > + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> > + * ioctl value. It is up to individual drivers to decode the value (for
> > + * example to look at the size of a structure to determine which version
> > + * of a specific command should be used) or not (which is what we
> > + * currently do, so right now the ioctl value for a given command is the
> > + * command itself).
> > + *
> > + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> > + * intermediate IOCTLCMD_ representation.
> > + */
> > +#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?
Hmm, not sure, we'll review ioctl definitions and fix as needed.
Thanks!
--
Dmitry
--
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.
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
> +#ifndef _VMCI_COMMONINT_H_
> +#define _VMCI_COMMONINT_H_
> +
> +#include
Why printk from a .h file?
> +
> +#define ASSERT(cond) BUG_ON(!(cond))
No, please no.
> +
> +#define PCI_VENDOR_ID_VMWARE 0x15AD
> +#define PCI_DEVICE_ID_VMWARE_VMCI0x0740
Align these properly? Why do they need to be in a .h file?
> +#define VMCI_DRIVER_VERSION_STRING "1.0.0.0-k"
Is this needed at all anymore?
> +#define MODULE_NAME "vmw_vmci"
This isn't needed, use the built-in macro instead.
> +/* Print magic... whee! */
> +#ifdef pr_fmt
> +#undef pr_fmt
> +#define pr_fmt(fmt) MODULE_NAME ": " fmt
> +#endif
That's not how you do this, sorry. Please do it like the rest of the
kernel.
> --- /dev/null
> +++ b/include/linux/vmw_vmci_api.h
With the new uapi rework, should this file still be here? What about
the other .h files?
> +typedef u32 vmci_id;
> +typedef u32 vmci_privilege_flags;
> +typedef u32 vmci_event;
Ick, no typdefs please.
> +static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
> +{
> + struct vmci_handle h;
> + h.context = cid;
> + h.resource = rid;
> + return h;
> +}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
> +#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
> +#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
It's longer to write the macro out than to just do .context or
.resource, just use them instead.
> +#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context &&
> \
> + (_h1).resource == (_h2).resource)
Inline function instead? How often do you really need this?
> +#define VMCI_INVALID_ID ~0
> +static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
> + VMCI_INVALID_ID
> +};
C99 initializers please.
> +
> +#define VMCI_HANDLE_INVALID(_handle) \
> + VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
Gotta love magic values :(
> +/*
> + * The below defines can be used to send anonymous requests.
> + * This also indicates that no response is expected.
> + */
> +#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
> +#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
> +#define VMCI_ANON_SRC_HANDLE
> vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
> + VMCI_ANON_SRC_RESOURCE_ID)
So you just created an invalid message?
> +/* The lowest 16 context ids are reserved for internal use. */
> +#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
> +
> +/*
> + * Hypervisor context id, used for calling into hypervisor
> + * supplied services from the VM.
> + */
> +#define VMCI_HYPERVISOR_CONTEXT_ID 0
> +
> +/*
> + * Well-known context id, a logical context that contains a set of
> + * well-known services. This context ID is now obsolete.
> + */
> +#define VMCI_WELL_KNOWN_CONTEXT_ID 1
> +
> +/*
> + * Context ID used by host endpoints.
> + */
> +#define VMCI_HOST_CONTEXT_ID 2
> +
> +#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid) &&
> \
> + (_cid) > VMCI_HOST_CONTEXT_ID)
> +
Are you sure all of this stuff needs to be in a .h file that lives in
include/linux/?
> +/*
> + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> + * ioctl value. It is up to individual drivers to decode the value (for
> + * example to look at the size of a structure to determine which version
> + * of a specific command should be used) or not (which is what we
> + * currently do, so right now the ioctl value for a given command is the
> + * command itself).
> + *
> + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> + * intermediate IOCTLCMD_ representation.
> + */
> +#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?
> +enum {
> + /*
> + * We need to bracket the range of values used for ioctls,
> + * because x86_64 Linux forces us to explicitly register ioctl
> + * handlers by value for handling 32 bit ioctl syscalls.
> + * Hence FIRST and LAST. Pick something for FIRST that
> + * doesn't collide with vmmon (2001+).
> + */
What do you mean here? What are you trying to work around? And why?
> + IOCTLCMD(FIRST) = 1951,
> + IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
Huh?
> +
> + /* BEGIN VMCI */
> + IOCTLCMD(INIT_CONTEXT),
> +
> + /*
> + * The following two were used for process and datagram
> + * process creation. They are not used anymore and reserved
> + * for future use. They will fail if issued.
> + */
> +
Re: [PATCH 12/12] VMCI: Some header and config files.
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
+#ifndef _VMCI_COMMONINT_H_
+#define _VMCI_COMMONINT_H_
+
+#include linux/printk.h
Why printk from a .h file?
+
+#define ASSERT(cond) BUG_ON(!(cond))
No, please no.
+
+#define PCI_VENDOR_ID_VMWARE 0x15AD
+#define PCI_DEVICE_ID_VMWARE_VMCI0x0740
Align these properly? Why do they need to be in a .h file?
+#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k
Is this needed at all anymore?
+#define MODULE_NAME vmw_vmci
This isn't needed, use the built-in macro instead.
+/* Print magic... whee! */
+#ifdef pr_fmt
+#undef pr_fmt
+#define pr_fmt(fmt) MODULE_NAME : fmt
+#endif
That's not how you do this, sorry. Please do it like the rest of the
kernel.
--- /dev/null
+++ b/include/linux/vmw_vmci_api.h
With the new uapi rework, should this file still be here? What about
the other .h files?
+typedef u32 vmci_id;
+typedef u32 vmci_privilege_flags;
+typedef u32 vmci_event;
Ick, no typdefs please.
+static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
+{
+ struct vmci_handle h;
+ h.context = cid;
+ h.resource = rid;
+ return h;
+}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
+#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
+#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
It's longer to write the macro out than to just do .context or
.resource, just use them instead.
+#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context
\
+ (_h1).resource == (_h2).resource)
Inline function instead? How often do you really need this?
+#define VMCI_INVALID_ID ~0
+static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
+ VMCI_INVALID_ID
+};
C99 initializers please.
+
+#define VMCI_HANDLE_INVALID(_handle) \
+ VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
Gotta love magic values :(
+/*
+ * The below defines can be used to send anonymous requests.
+ * This also indicates that no response is expected.
+ */
+#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_HANDLE
vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
+ VMCI_ANON_SRC_RESOURCE_ID)
So you just created an invalid message?
+/* The lowest 16 context ids are reserved for internal use. */
+#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
+
+/*
+ * Hypervisor context id, used for calling into hypervisor
+ * supplied services from the VM.
+ */
+#define VMCI_HYPERVISOR_CONTEXT_ID 0
+
+/*
+ * Well-known context id, a logical context that contains a set of
+ * well-known services. This context ID is now obsolete.
+ */
+#define VMCI_WELL_KNOWN_CONTEXT_ID 1
+
+/*
+ * Context ID used by host endpoints.
+ */
+#define VMCI_HOST_CONTEXT_ID 2
+
+#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid)
\
+ (_cid) VMCI_HOST_CONTEXT_ID)
+
Are you sure all of this stuff needs to be in a .h file that lives in
include/linux/?
+/*
+ * Linux defines _IO* macros, but the core kernel code ignore the encoded
+ * ioctl value. It is up to individual drivers to decode the value (for
+ * example to look at the size of a structure to determine which version
+ * of a specific command should be used) or not (which is what we
+ * currently do, so right now the ioctl value for a given command is the
+ * command itself).
+ *
+ * Hence, we just define the IOCTL_VMCI_foo values directly, with no
+ * intermediate IOCTLCMD_ representation.
+ */
+#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?
+enum {
+ /*
+ * We need to bracket the range of values used for ioctls,
+ * because x86_64 Linux forces us to explicitly register ioctl
+ * handlers by value for handling 32 bit ioctl syscalls.
+ * Hence FIRST and LAST. Pick something for FIRST that
+ * doesn't collide with vmmon (2001+).
+ */
What do you mean here? What are you trying to work around? And why?
+ IOCTLCMD(FIRST) = 1951,
+ IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
Huh?
+
+ /* BEGIN VMCI */
+ IOCTLCMD(INIT_CONTEXT),
+
+ /*
+ * The following two were used for process and datagram
+ * process creation. They are not used anymore and reserved
+ * for future use. They will fail if issued.
+ */
+ IOCTLCMD(RESERVED1),
+ IOCTLCMD(RESERVED2),
Who's reserving them? If they aren't in the driver, no need to list
Re: [PATCH 12/12] VMCI: Some header and config files.
Hi Greg,
For some reason it still didn't go through to our corporate mail server
but I see it on LKML.
On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
+static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
+{
+ struct vmci_handle h;
+ h.context = cid;
+ h.resource = rid;
+ return h;
+}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
This is certainly OK even if it is not inline, we return the _value_,
not the pointer to the stacki memory. And yes, the structure is 64 bit
value so it is returned in registers.
+#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
+#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
It's longer to write the macro out than to just do .context or
.resource, just use them instead.
We really want vmci_handle to be opaque where possible and use proper
accessors.
+#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context
\
+(_h1).resource == (_h2).resource)
Inline function instead? How often do you really need this?
OK, makes sense.
+#define VMCI_INVALID_ID ~0
+static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
+ VMCI_INVALID_ID
+};
C99 initializers please.
OK.
+
+#define VMCI_HANDLE_INVALID(_handle)
\
+ VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
Gotta love magic values :(
?
+/*
+ * The below defines can be used to send anonymous requests.
+ * This also indicates that no response is expected.
+ */
+#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_HANDLE
vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
+ VMCI_ANON_SRC_RESOURCE_ID)
So you just created an invalid message?
Anonymous one, yes.
+/* The lowest 16 context ids are reserved for internal use. */
+#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
+
+/*
+ * Hypervisor context id, used for calling into hypervisor
+ * supplied services from the VM.
+ */
+#define VMCI_HYPERVISOR_CONTEXT_ID 0
+
+/*
+ * Well-known context id, a logical context that contains a set of
+ * well-known services. This context ID is now obsolete.
+ */
+#define VMCI_WELL_KNOWN_CONTEXT_ID 1
+
+/*
+ * Context ID used by host endpoints.
+ */
+#define VMCI_HOST_CONTEXT_ID 2
+
+#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid)
\
+ (_cid) VMCI_HOST_CONTEXT_ID)
+
Are you sure all of this stuff needs to be in a .h file that lives in
include/linux/?
Probably not. We'll rebase to 3.7 and split as needed.
+/*
+ * Linux defines _IO* macros, but the core kernel code ignore the encoded
+ * ioctl value. It is up to individual drivers to decode the value (for
+ * example to look at the size of a structure to determine which version
+ * of a specific command should be used) or not (which is what we
+ * currently do, so right now the ioctl value for a given command is the
+ * command itself).
+ *
+ * Hence, we just define the IOCTL_VMCI_foo values directly, with no
+ * intermediate IOCTLCMD_ representation.
+ */
+#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?
Hmm, not sure, we'll review ioctl definitions and fix as needed.
Thanks!
--
Dmitry
--
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.
On Mon, Nov 26, 2012 at 04:23:57PM -0800, Dmitry Torokhov wrote:
Hi Greg,
For some reason it still didn't go through to our corporate mail server
but I see it on LKML.
Good.
On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
+static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id
rid)
+{
+ struct vmci_handle h;
+ h.context = cid;
+ h.resource = rid;
+ return h;
+}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
This is certainly OK even if it is not inline, we return the _value_,
not the pointer to the stacki memory. And yes, the structure is 64 bit
value so it is returned in registers.
Even on a 32bit processor? Also, you already have another function that
does this same thing, so having 2 functions in the same patch seems odd,
right?
greg k-h
--
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 12/12] VMCI: Some header and config files.
On Monday, November 26, 2012 04:32:39 PM Greg KH wrote:
On Mon, Nov 26, 2012 at 04:23:57PM -0800, Dmitry Torokhov wrote:
Hi Greg,
For some reason it still didn't go through to our corporate mail server
but I see it on LKML.
Good.
On Mon, Nov 26, 2012 at 04:03:04PM -0800, Greg KH wrote:
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
+static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid,
vmci_id rid) +{
+ struct vmci_handle h;
+ h.context = cid;
+ h.resource = rid;
+ return h;
+}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
This is certainly OK even if it is not inline, we return the _value_,
not the pointer to the stacki memory. And yes, the structure is 64 bit
value so it is returned in registers.
Even on a 32bit processor?
I thought it would, but it looks like it won't. Maybe we'll just switch it
to a macro with C99 style initializators to keep the same semantic but
avoid the question.
Also, you already have another function that
does this same thing, so having 2 functions in the same patch seems odd,
right?
Yes, you can say that it is probably a bit excessive.
OK, now that we are on the same page we'll go and fix the issues.
Thanks,
Dmitry
--
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 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang Signed-off-by: Dmitry Torokhov Signed-off-by: Andy King --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 32 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1110 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..81a268a --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,32 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING "1.0.0.0-k" +#define MODULE_NAME "vmw_vmci" + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME ": " fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include +#include + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define VMCI_KERNEL_API_VERSION_2 2 +#define
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com Signed-off-by: Dmitry Torokhov d...@vmware.com Signed-off-by: Andy King ack...@vmware.com --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 32 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1110 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..81a268a --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,32 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k +#define MODULE_NAME vmw_vmci + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME : fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include linux/uidgid.h +#include linux/vmw_vmci_defs.h + +#undef VMCI_KERNEL_API_VERSION
Re: [PATCH 12/12] VMCI: Some header and config files.
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
> +#ifndef _VMCI_COMMONINT_H_
> +#define _VMCI_COMMONINT_H_
> +
> +#include
Why printk from a .h file?
> +
> +#define ASSERT(cond) BUG_ON(!(cond))
No, please no.
> +
> +#define PCI_VENDOR_ID_VMWARE 0x15AD
> +#define PCI_DEVICE_ID_VMWARE_VMCI0x0740
Align these properly? Why do they need to be in a .h file?
> +#define VMCI_DRIVER_VERSION_STRING "1.0.0.0-k"
Is this needed at all anymore?
> +#define MODULE_NAME "vmw_vmci"
This isn't needed, use the built-in macro instead.
> +/* Print magic... whee! */
> +#ifdef pr_fmt
> +#undef pr_fmt
> +#define pr_fmt(fmt) MODULE_NAME ": " fmt
> +#endif
That's not how you do this, sorry. Please do it like the rest of the
kernel.
> --- /dev/null
> +++ b/include/linux/vmw_vmci_api.h
With the new uapi rework, should this file still be here? What about
the other .h files?
> +typedef u32 vmci_id;
> +typedef u32 vmci_privilege_flags;
> +typedef u32 vmci_event;
Ick, no typdefs please.
> +static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
> +{
> + struct vmci_handle h;
> + h.context = cid;
> + h.resource = rid;
> + return h;
> +}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
> +#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
> +#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
It's longer to write the macro out than to just do .context or
.resource, just use them instead.
> +#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context &&
> \
> + (_h1).resource == (_h2).resource)
Inline function instead? How often do you really need this?
> +#define VMCI_INVALID_ID ~0
> +static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
> + VMCI_INVALID_ID
> +};
C99 initializers please.
> +
> +#define VMCI_HANDLE_INVALID(_handle) \
> + VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
Gotta love magic values :(
> +/*
> + * The below defines can be used to send anonymous requests.
> + * This also indicates that no response is expected.
> + */
> +#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
> +#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
> +#define VMCI_ANON_SRC_HANDLE
> vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
> + VMCI_ANON_SRC_RESOURCE_ID)
So you just created an invalid message?
> +/* The lowest 16 context ids are reserved for internal use. */
> +#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
> +
> +/*
> + * Hypervisor context id, used for calling into hypervisor
> + * supplied services from the VM.
> + */
> +#define VMCI_HYPERVISOR_CONTEXT_ID 0
> +
> +/*
> + * Well-known context id, a logical context that contains a set of
> + * well-known services. This context ID is now obsolete.
> + */
> +#define VMCI_WELL_KNOWN_CONTEXT_ID 1
> +
> +/*
> + * Context ID used by host endpoints.
> + */
> +#define VMCI_HOST_CONTEXT_ID 2
> +
> +#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid) &&
> \
> + (_cid) > VMCI_HOST_CONTEXT_ID)
> +
Are you sure all of this stuff needs to be in a .h file that lives in
include/linux/?
> +/*
> + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> + * ioctl value. It is up to individual drivers to decode the value (for
> + * example to look at the size of a structure to determine which version
> + * of a specific command should be used) or not (which is what we
> + * currently do, so right now the ioctl value for a given command is the
> + * command itself).
> + *
> + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> + * intermediate IOCTLCMD_ representation.
> + */
> +#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?
> +enum {
> + /*
> + * We need to bracket the range of values used for ioctls,
> + * because x86_64 Linux forces us to explicitly register ioctl
> + * handlers by value for handling 32 bit ioctl syscalls.
> + * Hence FIRST and LAST. Pick something for FIRST that
> + * doesn't collide with vmmon (2001+).
> + */
What do you mean here? What are you trying to work around? And why?
> + IOCTLCMD(FIRST) = 1951,
> + IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
Huh?
> +
> + /* BEGIN VMCI */
> + IOCTLCMD(INIT_CONTEXT),
> +
> + /*
> + * The following two were used for process and datagram
> + * process creation. They are not used anymore and reserved
> + * for future use. They will fail if issued.
> + */
> +
Re: [PATCH 12/12] VMCI: Some header and config files.
On Wed, Nov 07, 2012 at 10:43:03AM -0800, George Zhang wrote:
+#ifndef _VMCI_COMMONINT_H_
+#define _VMCI_COMMONINT_H_
+
+#include linux/printk.h
Why printk from a .h file?
+
+#define ASSERT(cond) BUG_ON(!(cond))
No, please no.
+
+#define PCI_VENDOR_ID_VMWARE 0x15AD
+#define PCI_DEVICE_ID_VMWARE_VMCI0x0740
Align these properly? Why do they need to be in a .h file?
+#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k
Is this needed at all anymore?
+#define MODULE_NAME vmw_vmci
This isn't needed, use the built-in macro instead.
+/* Print magic... whee! */
+#ifdef pr_fmt
+#undef pr_fmt
+#define pr_fmt(fmt) MODULE_NAME : fmt
+#endif
That's not how you do this, sorry. Please do it like the rest of the
kernel.
--- /dev/null
+++ b/include/linux/vmw_vmci_api.h
With the new uapi rework, should this file still be here? What about
the other .h files?
+typedef u32 vmci_id;
+typedef u32 vmci_privilege_flags;
+typedef u32 vmci_event;
Ick, no typdefs please.
+static inline struct vmci_handle VMCI_MAKE_HANDLE(vmci_id cid, vmci_id rid)
+{
+ struct vmci_handle h;
+ h.context = cid;
+ h.resource = rid;
+ return h;
+}
You return a structure on the stack that just went away? Yeah, I know
it's an inline, but come on, that's not ok.
+#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
+#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
It's longer to write the macro out than to just do .context or
.resource, just use them instead.
+#define VMCI_HANDLE_EQUAL(_h1, _h2) ((_h1).context == (_h2).context
\
+ (_h1).resource == (_h2).resource)
Inline function instead? How often do you really need this?
+#define VMCI_INVALID_ID ~0
+static const struct vmci_handle VMCI_INVALID_HANDLE = { VMCI_INVALID_ID,
+ VMCI_INVALID_ID
+};
C99 initializers please.
+
+#define VMCI_HANDLE_INVALID(_handle) \
+ VMCI_HANDLE_EQUAL((_handle), VMCI_INVALID_HANDLE)
Gotta love magic values :(
+/*
+ * The below defines can be used to send anonymous requests.
+ * This also indicates that no response is expected.
+ */
+#define VMCI_ANON_SRC_CONTEXT_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_RESOURCE_ID VMCI_INVALID_ID
+#define VMCI_ANON_SRC_HANDLE
vmci_make_handle(VMCI_ANON_SRC_CONTEXT_ID, \
+ VMCI_ANON_SRC_RESOURCE_ID)
So you just created an invalid message?
+/* The lowest 16 context ids are reserved for internal use. */
+#define VMCI_RESERVED_CID_LIMIT ((u32) 16)
+
+/*
+ * Hypervisor context id, used for calling into hypervisor
+ * supplied services from the VM.
+ */
+#define VMCI_HYPERVISOR_CONTEXT_ID 0
+
+/*
+ * Well-known context id, a logical context that contains a set of
+ * well-known services. This context ID is now obsolete.
+ */
+#define VMCI_WELL_KNOWN_CONTEXT_ID 1
+
+/*
+ * Context ID used by host endpoints.
+ */
+#define VMCI_HOST_CONTEXT_ID 2
+
+#define VMCI_CONTEXT_IS_VM(_cid) (VMCI_INVALID_ID != (_cid)
\
+ (_cid) VMCI_HOST_CONTEXT_ID)
+
Are you sure all of this stuff needs to be in a .h file that lives in
include/linux/?
+/*
+ * Linux defines _IO* macros, but the core kernel code ignore the encoded
+ * ioctl value. It is up to individual drivers to decode the value (for
+ * example to look at the size of a structure to determine which version
+ * of a specific command should be used) or not (which is what we
+ * currently do, so right now the ioctl value for a given command is the
+ * command itself).
+ *
+ * Hence, we just define the IOCTL_VMCI_foo values directly, with no
+ * intermediate IOCTLCMD_ representation.
+ */
+#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?
+enum {
+ /*
+ * We need to bracket the range of values used for ioctls,
+ * because x86_64 Linux forces us to explicitly register ioctl
+ * handlers by value for handling 32 bit ioctl syscalls.
+ * Hence FIRST and LAST. Pick something for FIRST that
+ * doesn't collide with vmmon (2001+).
+ */
What do you mean here? What are you trying to work around? And why?
+ IOCTLCMD(FIRST) = 1951,
+ IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
Huh?
+
+ /* BEGIN VMCI */
+ IOCTLCMD(INIT_CONTEXT),
+
+ /*
+ * The following two were used for process and datagram
+ * process creation. They are not used anymore and reserved
+ * for future use. They will fail if issued.
+ */
+ IOCTLCMD(RESERVED1),
+ IOCTLCMD(RESERVED2),
Who's reserving them? If they aren't in the driver, no need to list
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1112 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING "1.0.0.0-k" +#define MODULE_NAME "vmw_vmci" + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME ": " fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include +#include + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define VMCI_KERNEL_API_VERSION_2 2 +#define
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1112 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k +#define MODULE_NAME vmw_vmci + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME : fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include linux/uidgid.h +#include linux/vmw_vmci_defs.h + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1112 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING "1.0.0.0-k" +#define MODULE_NAME "vmw_vmci" + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME ": " fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include +#include + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define VMCI_KERNEL_API_VERSION_2 2 +#define
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1112 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k +#define MODULE_NAME vmw_vmci + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME : fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include linux/uidgid.h +#include linux/vmw_vmci_defs.h + +#undef VMCI_KERNEL_API_VERSION +#define VMCI_KERNEL_API_VERSION_1 1 +#define
Re: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 07:32:55PM -0700, Greg KH wrote: > On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: > > --- /dev/null > > +++ b/drivers/misc/vmw_vmci/Makefile > > @@ -0,0 +1,43 @@ > > + > > +# > > +# Linux driver for VMware's VMCI device. > > +# > > +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or > > +# NON INFRINGEMENT. See the GNU General Public License for more > > +# details. > > +# > > +# Maintained by: Andrew Stiegmann > > +# > > + > > That's a big boiler-plate for a makefile :) > > Wait, what's Andrew's name doing here, and yet it isn't on any of the > signed-off-by: or From: lines of the driver? Surely you aren't the only > contributor here? > > > +# > > +# Makefile for the VMware VMCI > > +# > > That's the only needed comment for this file, if even that. > > > + > > +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o > > + > > +vmw_vmci-y += vmci_context.o > > +vmw_vmci-y += vmci_datagram.o > > +vmw_vmci-y += vmci_doorbell.o > > +vmw_vmci-y += vmci_driver.o > > +vmw_vmci-y += vmci_event.o > > +vmw_vmci-y += vmci_guest.o > > +vmw_vmci-y += vmci_handle_array.o > > +vmw_vmci-y += vmci_host.o > > +vmw_vmci-y += vmci_queue_pair.o > > +vmw_vmci-y += vmci_resource.o > > +vmw_vmci-y += vmci_route.o > > You can do this cleaner with multiple .o objects on the same line... > > > +vmci: > > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules > > + > > +clean: > > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean > > What are these two last targets for? I'm guessing this is from when you > ported it from a stand-along module? Please remove them. We'll clean it all up. Thanks for going over the code. -- Dmitry -- 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.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote:
> +/*
> + * Driver version.
> + *
> + * Increment major version when you make an incompatible change.
> + * Compatibility goes both ways (old driver with new executable
> + * as well as new driver with old executable).
> + */
> +
> +/* Never change VMCI_VERSION_SHIFT_WIDTH */
> +#define VMCI_VERSION_SHIFT_WIDTH 16
> +#define VMCI_MAKE_VERSION(_major, _minor)\
> + ((_major) << VMCI_VERSION_SHIFT_WIDTH | (u16) (_minor))
> +
> +#define VMCI_VERSION_MAJOR(v) ((u32) (v) >> VMCI_VERSION_SHIFT_WIDTH)
> +#define VMCI_VERSION_MINOR(v) ((u16) (v))
> +
> +/*
> + * VMCI_VERSION is always the current version. Subsequently listed
> + * versions are ways of detecting previous versions of the connecting
> + * application (i.e., VMX).
> + *
> + * VMCI_VERSION_NOVMVM: This version removed support for VM to VM
> + * communication.
> + *
> + * VMCI_VERSION_NOTIFY: This version introduced doorbell notification
> + * support.
> + *
> + * VMCI_VERSION_HOSTQP: This version introduced host end point support
> + * for hosted products.
> + *
> + * VMCI_VERSION_PREHOSTQP: This is the version prior to the adoption of
> + * support for host end-points.
> + *
> + * VMCI_VERSION_PREVERS2: This fictional version number is intended to
> + * represent the version of a VMX which doesn't call into the driver
> + * with ioctl VERSION2 and thus doesn't establish its version with the
> + * driver.
> + */
Do we care about these old versions anymore, now that this is really
"new" code going into the kernel?
> +
> +#define VMCI_VERSIONVMCI_VERSION_NOVMVM
> +#define VMCI_VERSION_NOVMVM VMCI_MAKE_VERSION(11, 0)
> +#define VMCI_VERSION_NOTIFY VMCI_MAKE_VERSION(10, 0)
> +#define VMCI_VERSION_HOSTQP VMCI_MAKE_VERSION(9, 0)
> +#define VMCI_VERSION_PREHOSTQP VMCI_MAKE_VERSION(8, 0)
> +#define VMCI_VERSION_PREVERS2 VMCI_MAKE_VERSION(1, 0)
> +
> +#define VMCI_SOCKETS_MAKE_VERSION(_p)
> \
> + _p)[0] & 0xFF) << 24) | (((_p)[1] & 0xFF) << 16) | ((_p)[2]))
> +
> +/*
> + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> + * ioctl value. It is up to individual drivers to decode the value (for
> + * example to look at the size of a structure to determine which version
> + * of a specific command should be used) or not (which is what we
> + * currently do, so right now the ioctl value for a given command is the
> + * command itself).
> + *
> + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> + * intermediate IOCTLCMD_ representation.
> + */
> +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
Huh? I don't understand, why aren't the "normal" macros good enough for
you? What are you doing special from the entire rest of the kernel that
you need to do things differently?
> +enum {
> + /*
> + * We need to bracket the range of values used for ioctls,
> + * because x86_64 Linux forces us to explicitly register ioctl
> + * handlers by value for handling 32 bit ioctl syscalls.
> + * Hence FIRST and LAST. Pick something for FIRST that
> + * doesn't collide with vmmon (2001+).
> + */
> + IOCTLCMD(FIRST) = 1951,
> + IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
I don't understand, what are you doing here with the numbering?
> + /* BEGIN VMCI */
> + IOCTLCMD(INIT_CONTEXT),
> +
> + /*
> + * The following two were used for process and datagram
> + * process creation. They are not used anymore and reserved
> + * for future use. They will fail if issued.
> + */
> + IOCTLCMD(RESERVED1),
> + IOCTLCMD(RESERVED2),
> +
> + /*
> + * The following used to be for shared memory. It is now
> + * unused and and is reserved for future use. It will fail if
> + * issued.
> + */
> + IOCTLCMD(RESERVED3),
> +
> + /*
> + * The follwoing three were also used to be for shared
> + * memory. An old WS6 user-mode client might try to use them
> + * with the new driver, but since we ensure that only contexts
> + * created by VMX'en of the appropriate version
> + * (VMCI_VERSION_NOTIFY or VMCI_VERSION_NEWQP) or higher use
> + * these ioctl, everything is fine.
> + */
> + IOCTLCMD(QUEUEPAIR_SETVA),
> + IOCTLCMD(NOTIFY_RESOURCE),
> + IOCTLCMD(NOTIFICATIONS_RECEIVE),
> + IOCTLCMD(VERSION2),
> + IOCTLCMD(QUEUEPAIR_ALLOC),
> + IOCTLCMD(QUEUEPAIR_SETPAGEFILE),
> + IOCTLCMD(QUEUEPAIR_DETACH),
> + IOCTLCMD(DATAGRAM_SEND),
> + IOCTLCMD(DATAGRAM_RECEIVE),
> + IOCTLCMD(DATAGRAM_REQUEST_MAP),
> + IOCTLCMD(DATAGRAM_REMOVE_MAP),
> + IOCTLCMD(CTX_ADD_NOTIFICATION),
> + IOCTLCMD(CTX_REMOVE_NOTIFICATION),
> + IOCTLCMD(CTX_GET_CPT_STATE),
> + IOCTLCMD(CTX_SET_CPT_STATE),
> + IOCTLCMD(GET_CONTEXT_ID),
> + IOCTLCMD(LAST),
> + /* END VMCI */
> +
> + /*
> + * VMCI Socket
Re: [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: > --- /dev/null > +++ b/drivers/misc/vmw_vmci/Makefile > @@ -0,0 +1,43 @@ > + > +# > +# Linux driver for VMware's VMCI device. > +# > +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or > +# NON INFRINGEMENT. See the GNU General Public License for more > +# details. > +# > +# Maintained by: Andrew Stiegmann > +# > + That's a big boiler-plate for a makefile :) Wait, what's Andrew's name doing here, and yet it isn't on any of the signed-off-by: or From: lines of the driver? Surely you aren't the only contributor here? > +# > +# Makefile for the VMware VMCI > +# That's the only needed comment for this file, if even that. > + > +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o > + > +vmw_vmci-y += vmci_context.o > +vmw_vmci-y += vmci_datagram.o > +vmw_vmci-y += vmci_doorbell.o > +vmw_vmci-y += vmci_driver.o > +vmw_vmci-y += vmci_event.o > +vmw_vmci-y += vmci_guest.o > +vmw_vmci-y += vmci_handle_array.o > +vmw_vmci-y += vmci_host.o > +vmw_vmci-y += vmci_queue_pair.o > +vmw_vmci-y += vmci_resource.o > +vmw_vmci-y += vmci_route.o You can do this cleaner with multiple .o objects on the same line... > +vmci: > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules > + > +clean: > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean What are these two last targets for? I'm guessing this is from when you ported it from a stand-along module? Please remove them. greg k-h -- 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 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile | 43 + drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 85 +++ include/linux/vmw_vmci_defs.h | 977 +++ 7 files changed, 1158 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..be09746 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# Maintained by: Andrew Stiegmann +# + + +# +# Makefile for the VMware VMCI +# + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-y += vmci_context.o +vmw_vmci-y += vmci_datagram.o +vmw_vmci-y += vmci_doorbell.o +vmw_vmci-y += vmci_driver.o +vmw_vmci-y += vmci_event.o +vmw_vmci-y += vmci_guest.o +vmw_vmci-y += vmci_handle_array.o +vmw_vmci-y += vmci_host.o +vmw_vmci-y += vmci_queue_pair.o +vmw_vmci-y += vmci_resource.o +vmw_vmci-y += vmci_route.o + +vmci: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules + +clean: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile | 43 + drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 85 +++ include/linux/vmw_vmci_defs.h | 977 +++ 7 files changed, 1158 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..be09746 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# Maintained by: Andrew Stiegmann pv-driv...@vmware.com +# + + +# +# Makefile for the VMware VMCI +# + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-y += vmci_context.o +vmw_vmci-y += vmci_datagram.o +vmw_vmci-y += vmci_doorbell.o +vmw_vmci-y += vmci_driver.o +vmw_vmci-y += vmci_event.o +vmw_vmci-y += vmci_guest.o +vmw_vmci-y += vmci_handle_array.o +vmw_vmci-y += vmci_host.o +vmw_vmci-y += vmci_queue_pair.o +vmw_vmci-y += vmci_resource.o +vmw_vmci-y += vmci_route.o + +vmci: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules + +clean: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 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 _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI
Re: [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# Maintained by: Andrew Stiegmann pv-driv...@vmware.com +# + That's a big boiler-plate for a makefile :) Wait, what's Andrew's name doing here, and yet it isn't on any of the signed-off-by: or From: lines of the driver? Surely you aren't the only contributor here? +# +# Makefile for the VMware VMCI +# That's the only needed comment for this file, if even that. + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-y += vmci_context.o +vmw_vmci-y += vmci_datagram.o +vmw_vmci-y += vmci_doorbell.o +vmw_vmci-y += vmci_driver.o +vmw_vmci-y += vmci_event.o +vmw_vmci-y += vmci_guest.o +vmw_vmci-y += vmci_handle_array.o +vmw_vmci-y += vmci_host.o +vmw_vmci-y += vmci_queue_pair.o +vmw_vmci-y += vmci_resource.o +vmw_vmci-y += vmci_route.o You can do this cleaner with multiple .o objects on the same line... +vmci: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules + +clean: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean What are these two last targets for? I'm guessing this is from when you ported it from a stand-along module? Please remove them. greg k-h -- 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.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote:
+/*
+ * Driver version.
+ *
+ * Increment major version when you make an incompatible change.
+ * Compatibility goes both ways (old driver with new executable
+ * as well as new driver with old executable).
+ */
+
+/* Never change VMCI_VERSION_SHIFT_WIDTH */
+#define VMCI_VERSION_SHIFT_WIDTH 16
+#define VMCI_MAKE_VERSION(_major, _minor)\
+ ((_major) VMCI_VERSION_SHIFT_WIDTH | (u16) (_minor))
+
+#define VMCI_VERSION_MAJOR(v) ((u32) (v) VMCI_VERSION_SHIFT_WIDTH)
+#define VMCI_VERSION_MINOR(v) ((u16) (v))
+
+/*
+ * VMCI_VERSION is always the current version. Subsequently listed
+ * versions are ways of detecting previous versions of the connecting
+ * application (i.e., VMX).
+ *
+ * VMCI_VERSION_NOVMVM: This version removed support for VM to VM
+ * communication.
+ *
+ * VMCI_VERSION_NOTIFY: This version introduced doorbell notification
+ * support.
+ *
+ * VMCI_VERSION_HOSTQP: This version introduced host end point support
+ * for hosted products.
+ *
+ * VMCI_VERSION_PREHOSTQP: This is the version prior to the adoption of
+ * support for host end-points.
+ *
+ * VMCI_VERSION_PREVERS2: This fictional version number is intended to
+ * represent the version of a VMX which doesn't call into the driver
+ * with ioctl VERSION2 and thus doesn't establish its version with the
+ * driver.
+ */
Do we care about these old versions anymore, now that this is really
new code going into the kernel?
+
+#define VMCI_VERSIONVMCI_VERSION_NOVMVM
+#define VMCI_VERSION_NOVMVM VMCI_MAKE_VERSION(11, 0)
+#define VMCI_VERSION_NOTIFY VMCI_MAKE_VERSION(10, 0)
+#define VMCI_VERSION_HOSTQP VMCI_MAKE_VERSION(9, 0)
+#define VMCI_VERSION_PREHOSTQP VMCI_MAKE_VERSION(8, 0)
+#define VMCI_VERSION_PREVERS2 VMCI_MAKE_VERSION(1, 0)
+
+#define VMCI_SOCKETS_MAKE_VERSION(_p)
\
+ _p)[0] 0xFF) 24) | (((_p)[1] 0xFF) 16) | ((_p)[2]))
+
+/*
+ * Linux defines _IO* macros, but the core kernel code ignore the encoded
+ * ioctl value. It is up to individual drivers to decode the value (for
+ * example to look at the size of a structure to determine which version
+ * of a specific command should be used) or not (which is what we
+ * currently do, so right now the ioctl value for a given command is the
+ * command itself).
+ *
+ * Hence, we just define the IOCTL_VMCI_foo values directly, with no
+ * intermediate IOCTLCMD_ representation.
+ */
+#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
Huh? I don't understand, why aren't the normal macros good enough for
you? What are you doing special from the entire rest of the kernel that
you need to do things differently?
+enum {
+ /*
+ * We need to bracket the range of values used for ioctls,
+ * because x86_64 Linux forces us to explicitly register ioctl
+ * handlers by value for handling 32 bit ioctl syscalls.
+ * Hence FIRST and LAST. Pick something for FIRST that
+ * doesn't collide with vmmon (2001+).
+ */
+ IOCTLCMD(FIRST) = 1951,
+ IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
I don't understand, what are you doing here with the numbering?
+ /* BEGIN VMCI */
+ IOCTLCMD(INIT_CONTEXT),
+
+ /*
+ * The following two were used for process and datagram
+ * process creation. They are not used anymore and reserved
+ * for future use. They will fail if issued.
+ */
+ IOCTLCMD(RESERVED1),
+ IOCTLCMD(RESERVED2),
+
+ /*
+ * The following used to be for shared memory. It is now
+ * unused and and is reserved for future use. It will fail if
+ * issued.
+ */
+ IOCTLCMD(RESERVED3),
+
+ /*
+ * The follwoing three were also used to be for shared
+ * memory. An old WS6 user-mode client might try to use them
+ * with the new driver, but since we ensure that only contexts
+ * created by VMX'en of the appropriate version
+ * (VMCI_VERSION_NOTIFY or VMCI_VERSION_NEWQP) or higher use
+ * these ioctl, everything is fine.
+ */
+ IOCTLCMD(QUEUEPAIR_SETVA),
+ IOCTLCMD(NOTIFY_RESOURCE),
+ IOCTLCMD(NOTIFICATIONS_RECEIVE),
+ IOCTLCMD(VERSION2),
+ IOCTLCMD(QUEUEPAIR_ALLOC),
+ IOCTLCMD(QUEUEPAIR_SETPAGEFILE),
+ IOCTLCMD(QUEUEPAIR_DETACH),
+ IOCTLCMD(DATAGRAM_SEND),
+ IOCTLCMD(DATAGRAM_RECEIVE),
+ IOCTLCMD(DATAGRAM_REQUEST_MAP),
+ IOCTLCMD(DATAGRAM_REMOVE_MAP),
+ IOCTLCMD(CTX_ADD_NOTIFICATION),
+ IOCTLCMD(CTX_REMOVE_NOTIFICATION),
+ IOCTLCMD(CTX_GET_CPT_STATE),
+ IOCTLCMD(CTX_SET_CPT_STATE),
+ IOCTLCMD(GET_CONTEXT_ID),
+ IOCTLCMD(LAST),
+ /* END VMCI */
+
+ /*
+ * VMCI Socket IOCTLS are defined next and go from
+ * IOCTLCMD(LAST) (1972) to 1990. VMware reserves a range of
+ * 4 ioctls for VMCI
Re: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 07:32:55PM -0700, Greg KH wrote: On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-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 of the License 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, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# Maintained by: Andrew Stiegmann pv-driv...@vmware.com +# + That's a big boiler-plate for a makefile :) Wait, what's Andrew's name doing here, and yet it isn't on any of the signed-off-by: or From: lines of the driver? Surely you aren't the only contributor here? +# +# Makefile for the VMware VMCI +# That's the only needed comment for this file, if even that. + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-y += vmci_context.o +vmw_vmci-y += vmci_datagram.o +vmw_vmci-y += vmci_doorbell.o +vmw_vmci-y += vmci_driver.o +vmw_vmci-y += vmci_event.o +vmw_vmci-y += vmci_guest.o +vmw_vmci-y += vmci_handle_array.o +vmw_vmci-y += vmci_host.o +vmw_vmci-y += vmci_queue_pair.o +vmw_vmci-y += vmci_resource.o +vmw_vmci-y += vmci_route.o You can do this cleaner with multiple .o objects on the same line... +vmci: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules + +clean: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean What are these two last targets for? I'm guessing this is from when you ported it from a stand-along module? Please remove them. We'll clean it all up. Thanks for going over the code. -- Dmitry -- 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/
