From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 2/3] KVM: Emulate MSI-X table in kernel Date: Fri, 18 Feb 2011 16:15:38 +0800 Message-ID: <201102181615.38479.sheng@linux.intel.com> References: <1296364276-2351-1-git-send-email-sheng@linux.intel.com> <1296364276-2351-3-git-send-email-sheng@linux.intel.com> <20110203010555.GA20541@amt.cnet> Mime-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "Michael S. Tsirkin" , kvm@vger.kernel.org, Alex Williamson To: Marcelo Tosatti Return-path: Received: from mga02.intel.com ([134.134.136.20]:12410 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753474Ab1BRINi (ORCPT ); Fri, 18 Feb 2011 03:13:38 -0500 In-Reply-To: <20110203010555.GA20541@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 03 February 2011 09:05:55 Marcelo Tosatti wrote: > On Sun, Jan 30, 2011 at 01:11:15PM +0800, Sheng Yang wrote: > > Then we can support mask bit operation of assigned devices now. > > > > Signed-off-by: Sheng Yang > > > > +int kvm_vm_ioctl_register_msix_mmio(struct kvm *kvm, > > + struct kvm_msix_mmio_user *mmio_user) > > +{ > > + struct kvm_msix_mmio_dev *mmio_dev = &kvm->msix_mmio_dev; > > + struct kvm_msix_mmio *mmio = NULL; > > + int r = 0, i; > > + > > + mutex_lock(&mmio_dev->lock); > > + for (i = 0; i < mmio_dev->mmio_nr; i++) { > > + if (mmio_dev->mmio[i].dev_id == mmio_user->dev_id && > > + (mmio_dev->mmio[i].type & KVM_MSIX_MMIO_TYPE_DEV_MASK) == > > + (mmio_user->type & KVM_MSIX_MMIO_TYPE_DEV_MASK)) { > > + mmio = &mmio_dev->mmio[i]; > > + if (mmio->max_entries_nr != mmio_user->max_entries_nr) { > > + r = -EINVAL; > > + goto out; > > + } > > + break; > > + } > > Why allow this ioctl to succeed if there's an entry already present? > This case is broken as mmio_dev->mmio_nr is increased below. Oh, It's a bug to let mmio_nr increase even with MMIO found. I've fixed it. The reason we allow multiply callings is userspace can register different types of address here(table address and PBA address). > PCI bits must be reviewed... Pardon? PCI related things are already in 2.6.38-rc. -- regards Yang, Sheng