From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Sheng Yang <sheng@linux.intel.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: Emulate MSI-X table in kernel
Date: Mon, 17 Jan 2011 15:31:40 +0200 [thread overview]
Message-ID: <20110117133140.GA25295@redhat.com> (raw)
In-Reply-To: <4D343638.30004@redhat.com>
On Mon, Jan 17, 2011 at 02:29:44PM +0200, Avi Kivity wrote:
> On 01/06/2011 12:19 PM, Sheng Yang wrote:
> >Then we can support mask bit operation of assigned devices now.
> >
> >
> >
> >+int kvm_assigned_device_update_msix_mask_bit(struct kvm *kvm,
> >+ int assigned_dev_id, int entry, bool mask)
> >+{
> >+ int r = -EFAULT;
> >+ struct kvm_assigned_dev_kernel *adev;
> >+ int i;
> >+
> >+ if (!irqchip_in_kernel(kvm))
> >+ return r;
> >+
> >+ mutex_lock(&kvm->lock);
> >+ adev = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
> >+ assigned_dev_id);
> >+ if (!adev)
> >+ goto out;
> >+
> >+ for (i = 0; i< adev->entries_nr; i++)
> >+ if (adev->host_msix_entries[i].entry == entry) {
> >+ if (mask)
> >+ disable_irq_nosync(
> >+ adev->host_msix_entries[i].vector);
>
> Is it okay to call disable_irq_nosync() here? IIRC we don't check
> the mask bit on irq delivery, so we may forward an interrupt to the
> guest after the mask bit was set.
>
> What does pci say about the mask bit? when does it take effect?
It is only guaranteed to take effect on the next read.
In practice, it takes effect earlier and guests
rely on this as an optimization.
> Another question is whether disable_irq_nosync() actually programs
> the device mask bit, or not. If it does, then it's slow, and it may
> be better to leave interrupts enabled but have an internal pending
> bit. If it doesn't program the mask bit, it's fine.
>
> >+ else
> >+ enable_irq(adev->host_msix_entries[i].vector);
> >+ r = 0;
> >+ break;
> >+ }
> >+out:
> >+ mutex_unlock(&kvm->lock);
> >+ return r;
> >+}
> >
> >+
> >+static int msix_table_mmio_read(struct kvm_io_device *this, gpa_t addr, int len,
> >+ void *val)
> >+{
> >+ struct kvm_msix_mmio_dev *mmio_dev =
> >+ container_of(this, struct kvm_msix_mmio_dev, table_dev);
> >+ struct kvm_msix_mmio *mmio;
> >+ int idx, ret = 0, entry, offset, r;
> >+
> >+ mutex_lock(&mmio_dev->lock);
> >+ idx = get_mmio_table_index(mmio_dev, addr, len);
> >+ if (idx< 0) {
> >+ ret = -EOPNOTSUPP;
> >+ goto out;
> >+ }
> >+ if ((addr& 0x3) || (len != 4&& len != 8))
> >+ goto out;
> >+
> >+ offset = addr& 0xf;
> >+ if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL&& len == 8)
> >+ goto out;
> >+
> >+ mmio =&mmio_dev->mmio[idx];
> >+ entry = (addr - mmio->table_base_addr) / PCI_MSIX_ENTRY_SIZE;
> >+ r = copy_from_user(val, (void __user *)(mmio->table_base_va +
> >+ entry * PCI_MSIX_ENTRY_SIZE + offset), len);
> >+ if (r)
> >+ goto out;
>
> and return ret == 0?
>
> >+out:
> >+ mutex_unlock(&mmio_dev->lock);
> >+ return ret;
> >+}
> >+
> >+static int msix_table_mmio_write(struct kvm_io_device *this, gpa_t addr,
> >+ int len, const void *val)
> >+{
> >+ struct kvm_msix_mmio_dev *mmio_dev =
> >+ container_of(this, struct kvm_msix_mmio_dev, table_dev);
> >+ struct kvm_msix_mmio *mmio;
> >+ int idx, entry, offset, ret = 0, r = 0;
> >+ gpa_t entry_base;
> >+ u32 old_ctrl, new_ctrl;
> >+ u32 *ctrl_pos;
> >+
> >+ mutex_lock(&mmio_dev->lock);
> >+ idx = get_mmio_table_index(mmio_dev, addr, len);
> >+ if (idx< 0) {
> >+ ret = -EOPNOTSUPP;
> >+ goto out;
> >+ }
> >+ if ((addr& 0x3) || (len != 4&& len != 8))
> >+ goto out;
> >+
> >+ offset = addr& 0xF;
> >+ if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL&& len == 8)
> >+ goto out;
> >+
> >+ mmio =&mmio_dev->mmio[idx];
> >+ entry = (addr - mmio->table_base_addr) / PCI_MSIX_ENTRY_SIZE;
> >+ entry_base = mmio->table_base_va + entry * PCI_MSIX_ENTRY_SIZE;
> >+ ctrl_pos = (u32 *)(entry_base + PCI_MSIX_ENTRY_VECTOR_CTRL);
> >+
> >+ if (get_user(old_ctrl, ctrl_pos))
> >+ goto out;
> >+
> >+ /* No allow writing to other fields when entry is unmasked */
> >+ if (!(old_ctrl& PCI_MSIX_ENTRY_CTRL_MASKBIT)&&
> >+ offset != PCI_MSIX_ENTRY_VECTOR_CTRL)
> >+ goto out;
> >+
> >+ if (copy_to_user((void __user *)(entry_base + offset), val, len))
> >+ goto out;
> >+
> >+ if (get_user(new_ctrl, ctrl_pos))
> >+ goto out;
>
> here, too.
>
> >+
> >+ if ((offset< PCI_MSIX_ENTRY_VECTOR_CTRL&& len == 4) ||
> >+ (offset< PCI_MSIX_ENTRY_DATA&& len == 8))
> >+ ret = -ENOTSYNC;
>
> goto out?
>
> >+ if (old_ctrl == new_ctrl)
> >+ goto out;
> >+ if (!(old_ctrl& PCI_MSIX_ENTRY_CTRL_MASKBIT)&&
> >+ (new_ctrl& PCI_MSIX_ENTRY_CTRL_MASKBIT))
> >+ r = update_msix_mask_bit(mmio_dev->kvm, mmio, entry, 1);
> >+ else if ((old_ctrl& PCI_MSIX_ENTRY_CTRL_MASKBIT)&&
> >+ !(new_ctrl& PCI_MSIX_ENTRY_CTRL_MASKBIT))
> >+ r = update_msix_mask_bit(mmio_dev->kvm, mmio, entry, 0);
> >+ if (r || ret)
> >+ ret = -ENOTSYNC;
> >+out:
> >+ mutex_unlock(&mmio_dev->lock);
> >+ return ret;
> >+}
> >+
>
> --
> error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-01-17 13:31 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 10:19 [PATCH 0/3 v7] MSI-X MMIO support for KVM Sheng Yang
2011-01-06 10:19 ` [PATCH 1/3] KVM: Move struct kvm_io_device to kvm_host.h Sheng Yang
2011-01-06 10:19 ` [PATCH 2/3] KVM: Emulate MSI-X table in kernel Sheng Yang
2011-01-17 11:54 ` Marcelo Tosatti
2011-01-17 12:18 ` Sheng Yang
2011-01-17 12:18 ` Avi Kivity
2011-01-17 12:48 ` Marcelo Tosatti
2011-01-17 12:51 ` Avi Kivity
2011-01-17 15:52 ` Marcelo Tosatti
2011-01-17 16:01 ` Avi Kivity
2011-01-17 12:39 ` Marcelo Tosatti
2011-01-19 8:37 ` Sheng Yang
2011-01-17 12:29 ` Avi Kivity
2011-01-17 13:31 ` Michael S. Tsirkin [this message]
2011-01-17 13:47 ` Jan Kiszka
2011-01-30 4:38 ` Sheng Yang
2011-01-31 13:09 ` Avi Kivity
2011-02-01 4:21 ` Sheng Yang
2011-01-06 10:19 ` [PATCH 3/3] KVM: Add documents for MSI-X MMIO API Sheng Yang
2011-01-17 12:21 ` Avi Kivity
2011-01-17 12:35 ` Sheng Yang
2011-01-17 12:45 ` Avi Kivity
2011-01-19 8:21 ` Sheng Yang
2011-01-25 12:47 ` Avi Kivity
2011-01-26 9:05 ` Sheng Yang
2011-01-31 13:24 ` Avi Kivity
2011-02-01 4:26 ` Sheng Yang
2011-01-12 2:23 ` [PATCH 0/3 v7] MSI-X MMIO support for KVM Sheng Yang
-- strict thread matches above, loose matches on Subject: below --
2011-01-30 5:11 [PATCH 0/3 v8] " Sheng Yang
2011-01-30 5:11 ` [PATCH 2/3] KVM: Emulate MSI-X table in kernel Sheng Yang
2011-02-03 1:05 ` Marcelo Tosatti
2011-02-18 8:15 ` Sheng Yang
2011-02-22 17:58 ` Marcelo Tosatti
2011-02-23 0:19 ` Alex Williamson
2011-02-23 6:59 ` Sheng Yang
2011-02-23 8:45 ` Michael S. Tsirkin
2011-02-24 8:08 ` Sheng Yang
2011-02-24 10:11 ` Michael S. Tsirkin
2011-02-25 5:54 ` Sheng Yang
2011-02-24 9:44 ` Sheng Yang
2011-02-24 10:17 ` Michael S. Tsirkin
2011-02-25 6:12 ` Sheng Yang
2011-02-25 8:46 ` Michael S. Tsirkin
2011-02-23 16:34 ` Alex Williamson
2011-02-23 18:39 ` Michael S. Tsirkin
2011-02-23 19:02 ` Alex Williamson
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=20110117133140.GA25295@redhat.com \
--to=mst@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=sheng@linux.intel.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).