qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <dwg@au1.ibm.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Benjamin Herrenschmidt <benh@au1.ibm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stuart Yoder <b08248@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, "avi@redhat.com" <avi@redhat.com>,
	Scott Wood <scottwood@freescale.com>
Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files
Date: Fri, 30 Sep 2011 18:46:47 +1000	[thread overview]
Message-ID: <20110930084647.GF4512@yookeroo.fritz.box> (raw)
In-Reply-To: <1317062095.25515.75.camel@bling.home>

On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
> On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
> > Am 26.09.2011 um 09:51 schrieb David Gibson <david@gibson.dropbear.id.au>:
[snip]
> > Also, if you can come up with an interface that does not have variable
> > length descriptors but is still able to export all the required
> > generic information, please send a proposal to the list :)
> > 
> 
> Hi,
> 
> The other obvious possibility is a pure ioctl interface.  To match what
> this proposal is trying to describe, plus the runtime interfaces, we'd
> need something like:

Right, this also seems a reasonable possibility to me, depending on
the details.

> /* :0 - PCI devices, :1 - Devices path device, 63:2 - reserved */
> #define VFIO_DEVICE_GET_FLAGS			_IOR(, , u64)
> 
> 
> /* Return number of mmio/iop/config regions.
>  * For PCI this is always 8 (BAR0-5 + ROM + Config) */
> #define VFIO_DEVICE_GET_NUM_REGIONS		_IOR(, , int)
> 
> /* Return length for region index (may be zero) */
> #define VFIO_DEVICE_GET_REGION_LEN		_IOWR(, , u64)
> 
> /* Return flags for region index
>  * :0 - mmap'able, :1 - read-only, 63:2 - reserved */
> #define VFIO_DEVICE_GET_REGION_FLAGS		_IOR(, , u64)
> 
> /* Return file offset for region index */
> #define VFIO_DEVICE_GET_REGION_OFFSET		_IOWR(, , u64)

The above 3 can be be folded into one "getregioninfo" call.

> /* Return physical address for region index - not implemented for PCI */
> #define VFIO_DEVICE_GET_REGION_PHYS_ADDR	_IOWR(, , u64)
> 
> 
> 
> /* Return number of IRQs (Not including MSI/MSI-X for PCI) */
> #define VFIO_DEVICE_GET_NUM_IRQ			_IOR(, , int)
> 
> /* Set IRQ eventfd for IRQ index, arg[0] = index, arg[1] = fd */
> #define VFIO_DEVICE_SET_IRQ_EVENTFD		_IOW(, , int)
> 
> /* Unmask IRQ index */
> #define VFIO_DEVICE_UNMASK_IRQ			_IOW(, , int)
> 
> /* Set unmask eventfd for index, arg[0] = index, arg[1] = fd */
> #define VFIO_DEVICE_SET_UNMASK_IRQ_EVENTFD	_IOW(, , int)
> 
> 
> /* Return the device tree path for type/index into the user
>  * allocated buffer */
> struct dtpath {
> 	u32	type; (0 = region, 1 = IRQ)
> 	u32	index;
> 	u32	buf_len;
> 	char	*buf;
> };
> #define VFIO_DEVICE_GET_DTPATH			_IOWR(, , struct dtpath)
> 
> /* Return the device tree index for type/index */
> struct dtindex {
> 	u32	type; (0 = region, 1 = IRQ)
> 	u32	index;
> 	u32	prop_type;
> 	u32	prop_index;
> };
> #define VFIO_DEVICE_GET_DTINDEX			_IOWR(, , struct dtindex)

I think those need some work, but that doesn't impinge on the core
semantics.

> /* Reset the device */
> #define VFIO_DEVICE_RESET			_IO(, ,)
> 
> 
> /* PCI MSI setup, arg[0] = #, arg[1-n] = eventfds */
> #define VFIO_DEVICE_PCI_SET_MSI_EVENTFDS	_IOW(, , int)
> #define VFIO_DEVICE_PCI_SET_MSIX_EVENTFDS	_IOW(, , int)

Why does this need seperate controls, rather than just treating MSIs
as interrupts beyond the first for PCI devices?

> Hope that covers it.  Something I prefer about this interface is that
> everything can easily be generated on the fly, whereas reading out a
> table from the device means we really need to have that table somewhere
> in kernel memory to easily support reading random offsets.
> Thoughts?

I certainly prefer it to the previous proposal.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  parent reply	other threads:[~2011-09-30  9:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 13:11 [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files Stuart Yoder
2011-09-09 13:16 ` Stuart Yoder
2011-09-19 15:16 ` Alex Williamson
2011-09-19 19:37   ` Scott Wood
2011-09-19 21:07     ` Alex Williamson
2011-09-19 21:15       ` Scott Wood
2011-09-26  7:51 ` David Gibson
2011-09-26 10:04   ` Alexander Graf
2011-09-26 18:34     ` Alex Williamson
2011-09-26 20:03       ` Stuart Yoder
2011-09-26 20:42         ` Alex Williamson
2011-09-26 23:59       ` Scott Wood
2011-09-27  0:45         ` Alex Williamson
2011-09-27 21:28           ` Scott Wood
2011-09-28  2:40             ` Alex Williamson
2011-09-28  8:58               ` Alexander Graf
2011-09-30  8:55                 ` David Gibson
2011-09-30  8:50         ` David Gibson
2011-09-30  8:46       ` David Gibson [this message]
2011-09-30 16:37         ` Alex Williamson
2011-09-30 21:59         ` Alex Williamson
2011-09-30  8:40     ` David Gibson
2011-09-26 19:57   ` Stuart Yoder
2011-09-27  0:25     ` Scott Wood

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=20110930084647.GF4512@yookeroo.fritz.box \
    --to=dwg@au1.ibm.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=avi@redhat.com \
    --cc=b08248@gmail.com \
    --cc=benh@au1.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=scottwood@freescale.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).