Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, 2012-06-28 at 11:38 +0300, Michael S. Tsirkin wrote: On Wed, Jun 27, 2012 at 04:24:30PM +0200, Cornelia Huck wrote: On Tue, 26 Jun 2012 23:09:04 -0600 Alex Williamson alex.william...@redhat.com wrote: Prune this down to just the struct kvm_irqfd so we can avoid changing function definition for every flag or field we use. Signed-off-by: Alex Williamson alex.william...@redhat.com I'm currently trying to find a way to make irqfd workable for s390 which will likely include using a new field in kvm_irqfd, so I'd like to have this change (and I also think it makes the code nicer to read). So: Acked-by: Cornelia Huck cornelia.h...@de.ibm.com Unfortunately it looks like we are not sanitizing kvm_irqfd at all so we won't be able to use the padding :( We'll need a new ioctl instead. I think you're jumping the gun on this decision. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Wed, Jun 27, 2012 at 04:24:30PM +0200, Cornelia Huck wrote: On Tue, 26 Jun 2012 23:09:04 -0600 Alex Williamson alex.william...@redhat.com wrote: Prune this down to just the struct kvm_irqfd so we can avoid changing function definition for every flag or field we use. Signed-off-by: Alex Williamson alex.william...@redhat.com I'm currently trying to find a way to make irqfd workable for s390 which will likely include using a new field in kvm_irqfd, so I'd like to have this change (and I also think it makes the code nicer to read). So: Acked-by: Cornelia Huck cornelia.h...@de.ibm.com Unfortunately it looks like we are not sanitizing kvm_irqfd at all so we won't be able to use the padding :( We'll need a new ioctl instead. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, 28 Jun 2012 11:38:57 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 27, 2012 at 04:24:30PM +0200, Cornelia Huck wrote:
On Tue, 26 Jun 2012 23:09:04 -0600
Alex Williamson alex.william...@redhat.com wrote:
Prune this down to just the struct kvm_irqfd so we can avoid
changing function definition for every flag or field we use.
Signed-off-by: Alex Williamson alex.william...@redhat.com
I'm currently trying to find a way to make irqfd workable for s390
which will likely include using a new field in kvm_irqfd, so I'd like
to have this change (and I also think it makes the code nicer to read).
So:
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Unfortunately it looks like we are not sanitizing kvm_irqfd
at all so we won't be able to use the padding :(
We'll need a new ioctl instead.
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
On Thu, 28 Jun 2012 11:38:57 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 27, 2012 at 04:24:30PM +0200, Cornelia Huck wrote:
On Tue, 26 Jun 2012 23:09:04 -0600
Alex Williamson alex.william...@redhat.com wrote:
Prune this down to just the struct kvm_irqfd so we can avoid
changing function definition for every flag or field we use.
Signed-off-by: Alex Williamson alex.william...@redhat.com
I'm currently trying to find a way to make irqfd workable for s390
which will likely include using a new field in kvm_irqfd, so I'd like
to have this change (and I also think it makes the code nicer to read).
So:
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Unfortunately it looks like we are not sanitizing kvm_irqfd
at all so we won't be able to use the padding :(
We'll need a new ioctl instead.
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
Looks a bit weird - shouldn't all this be part of gsi routing?
But no idea really, I don't see the big picture here.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, 28 Jun 2012 12:34:43 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
Looks a bit weird - shouldn't all this be part of gsi routing?
But no idea really, I don't see the big picture here.
Well, on s390 we don't have anything like gsi routing (I'm not even
really sure what that is).
My understanding is the following:
- Basically, we want to notify the guest for a virtqueue.
- For this, we want to inject an interrupt for the associated device.
- On x86, this means raising an interrupt on an interrupt line, as
specified by some kind of number.
- On s390, we need some more information to (a) identify the device and
(b) additional information that needs to be transmitted for an
interrupt (device specific). (This is what basically goes into struct
kvm_s390_interrupt, which I reproduced in the s390 part.)
Cornelia
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, Jun 28, 2012 at 02:00:41PM +0200, Cornelia Huck wrote:
On Thu, 28 Jun 2012 12:34:43 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
Looks a bit weird - shouldn't all this be part of gsi routing?
But no idea really, I don't see the big picture here.
Well, on s390 we don't have anything like gsi routing (I'm not even
really sure what that is).
I really mean kvm_irq_routing. This has options for
irqchip, msi, I guess we can add more.
My understanding is the following:
- Basically, we want to notify the guest for a virtqueue.
- For this, we want to inject an interrupt for the associated device.
- On x86, this means raising an interrupt on an interrupt line, as
specified by some kind of number.
Not just that: for MSI we pass in data encoding priority
destination etc.
- On s390, we need some more information to (a) identify the device and
(b) additional information that needs to be transmitted for an
interrupt (device specific). (This is what basically goes into struct
kvm_s390_interrupt, which I reproduced in the s390 part.)
Cornelia
Is this b mostly static or does it change for each interrupt?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, 28 Jun 2012 15:09:49 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 02:00:41PM +0200, Cornelia Huck wrote:
On Thu, 28 Jun 2012 12:34:43 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
Looks a bit weird - shouldn't all this be part of gsi routing?
But no idea really, I don't see the big picture here.
Well, on s390 we don't have anything like gsi routing (I'm not even
really sure what that is).
I really mean kvm_irq_routing. This has options for
irqchip, msi, I guess we can add more.
I stared at irq_comm.c for a bit and it seems to fulfill a purpose
similar to arch/s390/kvm/interrupt.c (although it looks more static).
But I don't really see how they could fit together easily.
My understanding is the following:
- Basically, we want to notify the guest for a virtqueue.
- For this, we want to inject an interrupt for the associated device.
- On x86, this means raising an interrupt on an interrupt line, as
specified by some kind of number.
Not just that: for MSI we pass in data encoding priority
destination etc.
- On s390, we need some more information to (a) identify the device and
(b) additional information that needs to be transmitted for an
interrupt (device specific). (This is what basically goes into struct
kvm_s390_interrupt, which I reproduced in the s390 part.)
Cornelia
Is this b mostly static or does it change for each interrupt?
For Linux guests it will be static, although the architecture would
allow for changing (some of) it.
Cornelia
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Thu, Jun 28, 2012 at 06:51:09PM +0200, Cornelia Huck wrote:
On Thu, 28 Jun 2012 15:09:49 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 02:00:41PM +0200, Cornelia Huck wrote:
On Thu, 28 Jun 2012 12:34:43 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
How about something like this as parameter for the new ioctl?
struct kvm_irqfd2 {
__u32 fd;
__u32 flags; /* for things like deassign */
__u64 type; /* determines the payload */
union {
/* type traditional */
struct {
__u32 gsi;
} trad;
/* type s390 */
struct {
__u32 int_type;
__u32 parm;
__u64 parm64;
} s390;
__u8 pad[20];
};
}
This could be combined with an arch or a per-kvm callback to keep the
generic code clean of architecture dependencies.
Cornelia
Looks a bit weird - shouldn't all this be part of gsi routing?
But no idea really, I don't see the big picture here.
Well, on s390 we don't have anything like gsi routing (I'm not even
really sure what that is).
I really mean kvm_irq_routing. This has options for
irqchip, msi, I guess we can add more.
I stared at irq_comm.c for a bit and it seems to fulfill a purpose
similar to arch/s390/kvm/interrupt.c (although it looks more static).
But I don't really see how they could fit together easily.
My understanding is the following:
- Basically, we want to notify the guest for a virtqueue.
- For this, we want to inject an interrupt for the associated device.
- On x86, this means raising an interrupt on an interrupt line, as
specified by some kind of number.
Not just that: for MSI we pass in data encoding priority
destination etc.
- On s390, we need some more information to (a) identify the device and
(b) additional information that needs to be transmitted for an
interrupt (device specific). (This is what basically goes into struct
kvm_s390_interrupt, which I reproduced in the s390 part.)
Cornelia
Is this b mostly static or does it change for each interrupt?
For Linux guests it will be static, although the architecture would
allow for changing (some of) it.
Cornelia
So storing this info in routing might be a good fit.
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Tue, Jun 26, 2012 at 11:09:04PM -0600, Alex Williamson wrote:
Prune this down to just the struct kvm_irqfd so we can avoid
changing function definition for every flag or field we use.
Signed-off-by: Alex Williamson alex.william...@redhat.com
This is not needed anymore, right? We are not adding
new fields.
---
include/linux/kvm_host.h |4 ++--
virt/kvm/eventfd.c | 20 ++--
virt/kvm/kvm_main.c |2 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 27ac8a4..ae3b426 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -824,7 +824,7 @@ static inline void kvm_free_irq_routing(struct kvm *kvm)
{}
#ifdef CONFIG_HAVE_KVM_EVENTFD
void kvm_eventfd_init(struct kvm *kvm);
-int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
+int kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args);
void kvm_irqfd_release(struct kvm *kvm);
void kvm_irq_routing_update(struct kvm *, struct kvm_irq_routing_table *);
int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args);
@@ -833,7 +833,7 @@ int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
*args);
static inline void kvm_eventfd_init(struct kvm *kvm) {}
-static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+static inline int kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args)
{
return -EINVAL;
}
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f59c1e8..c307c24 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -198,7 +198,7 @@ static void irqfd_update(struct kvm *kvm, struct _irqfd
*irqfd,
}
static int
-kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
+kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
{
struct kvm_irq_routing_table *irq_rt;
struct _irqfd *irqfd, *tmp;
@@ -212,12 +212,12 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
return -ENOMEM;
irqfd-kvm = kvm;
- irqfd-gsi = gsi;
+ irqfd-gsi = args-gsi;
INIT_LIST_HEAD(irqfd-list);
INIT_WORK(irqfd-inject, irqfd_inject);
INIT_WORK(irqfd-shutdown, irqfd_shutdown);
- file = eventfd_fget(fd);
+ file = eventfd_fget(args-fd);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
goto fail;
@@ -298,19 +298,19 @@ kvm_eventfd_init(struct kvm *kvm)
* shutdown any irqfd's that match fd+gsi
*/
static int
-kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
+kvm_irqfd_deassign(struct kvm *kvm, struct kvm_irqfd *args)
{
struct _irqfd *irqfd, *tmp;
struct eventfd_ctx *eventfd;
- eventfd = eventfd_ctx_fdget(fd);
+ eventfd = eventfd_ctx_fdget(args-fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
spin_lock_irq(kvm-irqfds.lock);
list_for_each_entry_safe(irqfd, tmp, kvm-irqfds.items, list) {
- if (irqfd-eventfd == eventfd irqfd-gsi == gsi) {
+ if (irqfd-eventfd == eventfd irqfd-gsi == args-gsi) {
/*
* This rcu_assign_pointer is needed for when
* another thread calls kvm_irq_routing_update before
@@ -338,12 +338,12 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
}
int
-kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args)
{
- if (flags KVM_IRQFD_FLAG_DEASSIGN)
- return kvm_irqfd_deassign(kvm, fd, gsi);
+ if (args-flags KVM_IRQFD_FLAG_DEASSIGN)
+ return kvm_irqfd_deassign(kvm, args);
- return kvm_irqfd_assign(kvm, fd, gsi);
+ return kvm_irqfd_assign(kvm, args);
}
/*
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 02cb440..b4ad14cc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2059,7 +2059,7 @@ static long kvm_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(data, argp, sizeof data))
goto out;
- r = kvm_irqfd(kvm, data.fd, data.gsi, data.flags);
+ r = kvm_irqfd(kvm, data);
break;
}
case KVM_IOEVENTFD: {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Tue, 26 Jun 2012 23:09:04 -0600 Alex Williamson alex.william...@redhat.com wrote: Prune this down to just the struct kvm_irqfd so we can avoid changing function definition for every flag or field we use. Signed-off-by: Alex Williamson alex.william...@redhat.com I'm currently trying to find a way to make irqfd workable for s390 which will likely include using a new field in kvm_irqfd, so I'd like to have this change (and I also think it makes the code nicer to read). So: Acked-by: Cornelia Huck cornelia.h...@de.ibm.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
On Wed, 2012-06-27 at 12:35 +0300, Michael S. Tsirkin wrote: On Tue, Jun 26, 2012 at 11:09:04PM -0600, Alex Williamson wrote: Prune this down to just the struct kvm_irqfd so we can avoid changing function definition for every flag or field we use. Signed-off-by: Alex Williamson alex.william...@redhat.com This is not needed anymore, right? We are not adding new fields. Right, but I still prefer it. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/6] kvm: Pass kvm_irqfd to functions
Prune this down to just the struct kvm_irqfd so we can avoid
changing function definition for every flag or field we use.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
include/linux/kvm_host.h |4 ++--
virt/kvm/eventfd.c | 20 ++--
virt/kvm/kvm_main.c |2 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 27ac8a4..ae3b426 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -824,7 +824,7 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
#ifdef CONFIG_HAVE_KVM_EVENTFD
void kvm_eventfd_init(struct kvm *kvm);
-int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
+int kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args);
void kvm_irqfd_release(struct kvm *kvm);
void kvm_irq_routing_update(struct kvm *, struct kvm_irq_routing_table *);
int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args);
@@ -833,7 +833,7 @@ int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
*args);
static inline void kvm_eventfd_init(struct kvm *kvm) {}
-static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+static inline int kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args)
{
return -EINVAL;
}
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f59c1e8..c307c24 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -198,7 +198,7 @@ static void irqfd_update(struct kvm *kvm, struct _irqfd
*irqfd,
}
static int
-kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
+kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
{
struct kvm_irq_routing_table *irq_rt;
struct _irqfd *irqfd, *tmp;
@@ -212,12 +212,12 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
return -ENOMEM;
irqfd-kvm = kvm;
- irqfd-gsi = gsi;
+ irqfd-gsi = args-gsi;
INIT_LIST_HEAD(irqfd-list);
INIT_WORK(irqfd-inject, irqfd_inject);
INIT_WORK(irqfd-shutdown, irqfd_shutdown);
- file = eventfd_fget(fd);
+ file = eventfd_fget(args-fd);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
goto fail;
@@ -298,19 +298,19 @@ kvm_eventfd_init(struct kvm *kvm)
* shutdown any irqfd's that match fd+gsi
*/
static int
-kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
+kvm_irqfd_deassign(struct kvm *kvm, struct kvm_irqfd *args)
{
struct _irqfd *irqfd, *tmp;
struct eventfd_ctx *eventfd;
- eventfd = eventfd_ctx_fdget(fd);
+ eventfd = eventfd_ctx_fdget(args-fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
spin_lock_irq(kvm-irqfds.lock);
list_for_each_entry_safe(irqfd, tmp, kvm-irqfds.items, list) {
- if (irqfd-eventfd == eventfd irqfd-gsi == gsi) {
+ if (irqfd-eventfd == eventfd irqfd-gsi == args-gsi) {
/*
* This rcu_assign_pointer is needed for when
* another thread calls kvm_irq_routing_update before
@@ -338,12 +338,12 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
}
int
-kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args)
{
- if (flags KVM_IRQFD_FLAG_DEASSIGN)
- return kvm_irqfd_deassign(kvm, fd, gsi);
+ if (args-flags KVM_IRQFD_FLAG_DEASSIGN)
+ return kvm_irqfd_deassign(kvm, args);
- return kvm_irqfd_assign(kvm, fd, gsi);
+ return kvm_irqfd_assign(kvm, args);
}
/*
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 02cb440..b4ad14cc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2059,7 +2059,7 @@ static long kvm_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(data, argp, sizeof data))
goto out;
- r = kvm_irqfd(kvm, data.fd, data.gsi, data.flags);
+ r = kvm_irqfd(kvm, data);
break;
}
case KVM_IOEVENTFD: {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
