All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.