qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] vfio/pci: Add ioeventfd support


From: Alex Williamson
Subject: Re: [Qemu-devel] [PATCH 3/3] vfio/pci: Add ioeventfd support
Date: Thu, 15 Mar 2018 15:07:01 -0600

On Tue, 13 Mar 2018 14:12:34 +0100
Auger Eric <address@hidden> wrote:
> On 28/02/18 21:15, Alex Williamson wrote:
> > +long vfio_pci_ioeventfd(struct vfio_pci_device *vdev, loff_t offset,
> > +                   uint64_t data, int count, int fd)
> > +{
> > +   struct pci_dev *pdev = vdev->pdev;
> > +   loff_t pos = offset & VFIO_PCI_OFFSET_MASK;
> > +   int ret, bar = VFIO_PCI_OFFSET_TO_INDEX(offset);
> > +   struct vfio_pci_ioeventfd *ioeventfd;
> > +   int (*handler)(void *addr, void *value);
> > +
> > +   /* Only support ioeventfds into BARs */
> > +   if (bar > VFIO_PCI_BAR5_REGION_INDEX)
> > +           return -EINVAL;
> > +
> > +   if (pos + count > pci_resource_len(pdev, bar))
> > +           return -EINVAL;
> > +
> > +   /* Disallow ioeventfds working around MSI-X table writes */
> > +   if (bar == vdev->msix_bar &&
> > +       !(pos + count <= vdev->msix_offset ||
> > +         pos >= vdev->msix_offset + vdev->msix_size))
> > +           return -EINVAL;
> > +
> > +   switch (count) {
> > +   case 1:
> > +           handler = &vfio_pci_ioeventfd_handler8;
> > +           break;
> > +   case 2:
> > +           handler = &vfio_pci_ioeventfd_handler16;
> > +           break;
> > +   case 4:
> > +           handler = &vfio_pci_ioeventfd_handler32;
> > +           break;
> > +#ifdef iowrite64
> > +   case 8:
> > +           handler = &vfio_pci_ioeventfd_handler64;
> > +           break;  
> from a user point of view, it is straightforward this setup will be
> rejected? This is not documented in the uapi at the moment.

I added a mention in the uapi, do you see any need for more?
Essentially I consider this an entirely optional accelerator, bus
drivers are free to implement as much or little as they want.
Userspace can clearly make due without it, we've gone this long, and
it's easy to reject cases we don't want to support.  Thanks,

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]