From: Sheng Yang <sheng@linux.intel.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH 01/10] KVM: Add a route layer to convert MSI message to GSI
Date: Thu, 8 Jan 2009 15:30:33 +0800 [thread overview]
Message-ID: <200901081530.34420.sheng@linux.intel.com> (raw)
In-Reply-To: <20090107161839.GD5442@amt.cnet>
On Thursday 08 January 2009 00:18:39 Marcelo Tosatti wrote:
> Hi Sheng,
>
Thanks for the careful review! :)
> On Wed, Jan 07, 2009 at 06:42:37PM +0800, Sheng Yang wrote:
> > diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
> > index 5162a41..7460e7f 100644
> > --- a/virt/kvm/irq_comm.c
> > +++ b/virt/kvm/irq_comm.c
> > @@ -123,3 +123,73 @@ void kvm_fire_mask_notifiers(struct kvm *kvm, int
> > irq, bool mask) kimn->func(kimn, mask);
> > }
> >
> > +int kvm_update_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry
> > *entry) +{
> > + struct kvm_gsi_route_entry *found_entry, *new_entry;
> > + int r, gsi;
> > +
> > + mutex_lock(&kvm->lock);
> > + /* Find whether we need a update or a new entry */
> > + found_entry = kvm_find_gsi_route_entry(kvm, entry->gsi);
> > + if (found_entry)
> > + *found_entry = *entry;
> > + else {
>
> Having a kvm_find_alloc_gsi_route_entry which either returns a present
> entry if found or returns a newly allocated one makes the code easier to
> read for me. Then just
>
> entry = kvm_find_alloc_gsi_route_entry
> *entry = *new_entry;
>
> Just style, feel free to ignore the comment.
A little different, for we have to use kvm_find_alloc_gsi_route_entry() to
find correlated gsi for injecting interrupt, so allocate a new one is not that
proper here.
>
> > + gsi = find_first_zero_bit(kvm->gsi_route_bitmap,
> > + KVM_NR_GSI_ROUTE_ENTRIES);
> > + if (gsi >= KVM_NR_GSI_ROUTE_ENTRIES) {
> > + r = -ENOSPC;
> > + goto out;
> > + }
> > + __set_bit(gsi, kvm->gsi_route_bitmap);
> > + entry->gsi = gsi | KVM_GSI_ROUTE_MASK;
> > + new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
>
> Allocate first, then set the bit in the bitmap?
>
> > + if (!new_entry) {
> > + r = -ENOMEM;
> > + goto out;
>
> Because here you don't clear the state on failure.
>
> </NITPICK MODE>
Oh, you are right.:)
>
> > + }
> > + *new_entry = *entry;
> > + hlist_add_head(&new_entry->link, &kvm->gsi_route_list);
> > + }
> > + r = 0;
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return r;
> > +}
> > +
> >
> > +static int kvm_vm_ioctl_request_gsi_route(struct kvm *kvm,
> > + struct kvm_gsi_route_guest *gsi_route,
> > + struct kvm_gsi_route_entry_guest *guest_entries)
> > +{
> > + struct kvm_gsi_route_entry entry;
> > + int r, i;
> > +
> > + for (i = 0; i < gsi_route->entries_nr; i++) {
> > + memcpy(&entry, &guest_entries[i], sizeof(entry));
> > + r = kvm_update_gsi_route(kvm, &entry);
> > + if (r == 0)
> > + guest_entries[i].gsi = entry.gsi;
> > + else
> > + break;
> > + }
> > + return r;
> > +}
> > +
> > +static int kvm_vm_ioctl_free_gsi_route(struct kvm *kvm,
> > + struct kvm_gsi_route_guest *gsi_route,
> > + struct kvm_gsi_route_entry_guest *guest_entries)
> > +{
> > + struct kvm_gsi_route_entry *entry;
> > + int r, i;
> > +
> > + mutex_lock(&kvm->lock);
> > + for (i = 0; i < gsi_route->entries_nr; i++) {
> > + entry = kvm_find_gsi_route_entry(kvm, guest_entries[i].gsi);
> > + if (!entry ||
> > + memcmp(entry, &guest_entries[i], sizeof(*entry)) != 0) {
> > + printk(KERN_WARNING "kvm: illegal gsi mapping!");
>
> Don't think you need that printk?
After reconsidering, I am not sure if I should verify guest entry here, or
just leave a gsi number to kernel for freeing. I am a little prefer only gsi
here, for I think I can trust userspace to some degree... I would update the
patch.(in fact, I didn't use this ioctl in userspace for now...)
>
> > + r = -EINVAL;
> > + goto out;
> > + }
> > + kvm_free_gsi_route(kvm, entry);
> > + }
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return r;
> > +}
> > +
> > static long kvm_vcpu_ioctl(struct file *filp,
> > unsigned int ioctl, unsigned long arg)
> > {
> > @@ -1803,6 +1846,7 @@ static long kvm_vm_ioctl(struct file *filp,
> > {
> > struct kvm *kvm = filp->private_data;
> > void __user *argp = (void __user *)arg;
> > + struct kvm_gsi_route_entry_guest *gsi_entries = NULL;
> > int r;
> >
> > if (kvm->mm != current->mm)
> > @@ -1887,10 +1931,72 @@ static long kvm_vm_ioctl(struct file *filp,
> > break;
> > }
> > #endif
> > + case KVM_REQUEST_GSI_ROUTE: {
> > + struct kvm_gsi_route_guest gsi_route;
>
> r = -EFAULT;
> if (copy_from_user...)
> goto out;
>
> etc...
>
> To conform with the rest of the code in the function?
OK...
>
> > + r = copy_from_user(&gsi_route, argp, sizeof gsi_route);
> > + if (r)
> > + goto out;
> > + if (gsi_route.entries_nr == 0) {
> > + r = -EFAULT;
> > + goto out;
> > + }
>
> Should check for a max of KVM_NR_GSI_ROUTE_ENTRIES ?
Yeah.
>
> > + gsi_entries = kmalloc(gsi_route.entries_nr *
> > + sizeof(struct kvm_gsi_route_entry_guest),
> > + GFP_KERNEL);
>
> And use vmalloc/vfree instead.
Yeah... kmalloc is not necessary here...
>
> > + if (!gsi_entries) {
> > + r = -ENOMEM;
> > + goto out;
> > + }
> > + r = copy_from_user(gsi_entries,
> > + (void __user *)gsi_route.entries,
> > + gsi_route.entries_nr *
> > + sizeof(struct kvm_gsi_route_entry_guest));
> > + if (r)
> > + goto out;
> > + r = kvm_vm_ioctl_request_gsi_route(kvm, &gsi_route,
> > + gsi_entries);
> > + if (r)
> > + goto out;
> > + r = copy_to_user((void __user *)gsi_route.entries,
> > + gsi_entries,
> > + gsi_route.entries_nr *
> > + sizeof(struct kvm_gsi_route_entry_guest));
> > + if (r)
> > + goto out;
> > + break;
> > + }
> > + case KVM_FREE_GSI_ROUTE: {
> > + struct kvm_gsi_route_guest gsi_route;
> > + r = copy_from_user(&gsi_route, argp, sizeof gsi_route);
> > + if (r)
> > + goto out;
> > + if (gsi_route.entries_nr == 0) {
> > + r = -EFAULT;
> > + goto out;
> > + }
>
> Check KVM_NR_GSI_ROUTE_ENTRIES and vmalloc.
Sure.
--
regards
Yang, Sheng
next prev parent reply other threads:[~2009-01-08 7:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 10:42 [PATCH 0/10][v4]GSI route layer for MSI/MSI-X Sheng Yang
2009-01-07 10:42 ` [PATCH 01/10] KVM: Add a route layer to convert MSI message to GSI Sheng Yang
2009-01-07 16:18 ` Marcelo Tosatti
2009-01-08 7:30 ` Sheng Yang [this message]
2009-01-07 10:42 ` [PATCH 02/10] KVM: Using gsi route for MSI device assignment Sheng Yang
2009-01-07 10:42 ` [PATCH 03/10] KVM: Improve MSI dispatch function Sheng Yang
2009-01-07 10:42 ` [PATCH 04/10] KVM: Using ioapic_irqchip() macro for kvm_set_irq Sheng Yang
2009-01-07 10:42 ` [PATCH 05/10] KVM: Merge MSI handling to kvm_set_irq Sheng Yang
2009-01-07 21:39 ` Marcelo Tosatti
2009-01-08 9:24 ` Sheng Yang
2009-01-08 13:54 ` Mike Day
2009-01-09 1:32 ` Sheng Yang
2009-01-07 10:42 ` [PATCH 06/10] KVM: Split IOAPIC structure Sheng Yang
2009-01-07 10:42 ` [PATCH 07/10] KVM: Unified the delivery of IOAPIC and MSI Sheng Yang
2009-01-07 10:42 ` [PATCH 08/10] KVM: Change API of kvm_ioapic_get_delivery_bitmask Sheng Yang
2009-01-07 10:42 ` [PATCH 09/10] KVM: Update intr delivery func to accept unsigned long* bitmap Sheng Yang
2009-01-08 0:38 ` Marcelo Tosatti
2009-01-07 10:42 ` [PATCH 10/10] KVM: bit ops for deliver_bitmap Sheng Yang
-- strict thread matches above, loose matches on Subject: below --
2008-12-30 5:55 [PATCH 0/10][v3] GSI->MSG route layer for MSI/MSI-X Sheng Yang
2008-12-30 5:55 ` [PATCH 01/10] KVM: Add a route layer to convert MSI message to GSI Sheng Yang
2008-12-30 10:39 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200901081530.34420.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).