kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).