joerg.roe...@amd.com; konrad.w...@oracle.com;
> ag...@suse.de; d...@au1.ibm.com; chr...@sous-sol.org; Yoder Stuart-B08248;
> io...@lists.linux-foundation.org; a...@redhat.com; linux-
> p...@vger.kernel.org; Wood Scott-B07421; be...@cisco.com
> Subject: Re: [Qemu-devel] [RFC PATCH] vfio: V
joerg.roe...@amd.com; konrad.w...@oracle.com;
> ag...@suse.de; d...@au1.ibm.com; chr...@sous-sol.org; Yoder Stuart-B08248;
> io...@lists.linux-foundation.org; a...@redhat.com; linux-
> p...@vger.kernel.org; Wood Scott-B07421; be...@cisco.com
> Subject: Re: [Qemu-devel] [RFC PATCH] vfio: V
On 12/02/2011 12:45 PM, Bhushan Bharat-R65777 wrote:
> Scott, I am not sure if there is any real use case where device needed to
> assigned beyond 2 level (host + immediate guest) in nested virtualization.
Userspace drivers in the guest is a more likely scenario than nested
virtualization, at lea
On 12/02/2011 08:40 AM, Stuart Yoder wrote:
> On Thu, Dec 1, 2011 at 3:25 PM, Alex Williamson
> wrote:
>> On Thu, 2011-12-01 at 14:58 -0600, Stuart Yoder wrote:
>>> One other mechanism we need as well is the ability to
>>> enable/disable a domain.
>>>
>>> For example-- suppose a device is assigned
1.ibm.com; qemu-devel@nongnu.org; joerg.roe...@amd.com;
> konrad.w...@oracle.com; ag...@suse.de; d...@au1.ibm.com; chrisw@sous-
> sol.org; Yoder Stuart-B08248; io...@lists.linux-foundation.org;
> a...@redhat.com; linux-...@vger.kernel.org; Wood Scott-B07421;
> be...@cisco.com
> Subject: Re:
On 12/02/2011 12:11 PM, Bhushan Bharat-R65777 wrote:
> How do we determine whether guest is ready or not? There can be multiple
> device get ready at different time.
The guest makes a hypercall with a device handle -- at least that's how
we do it in Topaz.
> Further if guest have given the devic
On Thu, Dec 1, 2011 at 3:25 PM, Alex Williamson
wrote:
> On Thu, 2011-12-01 at 14:58 -0600, Stuart Yoder wrote:
>> One other mechanism we need as well is the ability to
>> enable/disable a domain.
>>
>> For example-- suppose a device is assigned to a VM, the
>> device is in use when the VM is abru
On 29/11/11 16:48, Alex Williamson wrote:
> On Tue, 2011-11-29 at 15:34 +1100, Alexey Kardashevskiy wrote:
>> Hi!
>>
>> On 29/11/11 14:46, Alex Williamson wrote:
>>> On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
Hi!
I tried (successfully) to run it on POWER and while
On Thu, 2011-12-01 at 14:58 -0600, Stuart Yoder wrote:
> >> The attributes are not intrinsic features of the domain. User space will
> >> need to set them. But in thinking about it a bit more I think the
> >> attributes
> >> are more properties of the domain rather than a per map() operation
> >
>> The attributes are not intrinsic features of the domain. User space will
>> need to set them. But in thinking about it a bit more I think the attributes
>> are more properties of the domain rather than a per map() operation
>> characteristic. I think a separate API might be appropriate. Defi
On Wed, 2011-11-30 at 09:41 -0600, Stuart Yoder wrote:
> On Tue, Nov 29, 2011 at 5:44 PM, Alex Williamson
> wrote:
> > On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote:
> >> >
> >> > BTW, github now has updated trees:
> >> >
> >> > git://github.com/awilliam/linux-vfio.git vfio-next-2029
>
On Tue, Nov 29, 2011 at 5:44 PM, Alex Williamson
wrote:
> On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote:
>> >
>> > BTW, github now has updated trees:
>> >
>> > git://github.com/awilliam/linux-vfio.git vfio-next-2029
>> > git://github.com/awilliam/qemu-vfio.git vfio-ng
>>
>> Hi Alex,
>>
On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote:
> >
> > BTW, github now has updated trees:
> >
> > git://github.com/awilliam/linux-vfio.git vfio-next-2029
> > git://github.com/awilliam/qemu-vfio.git vfio-ng
>
> Hi Alex,
>
> Have been looking at vfio a bit. A few observations and thin
>
> BTW, github now has updated trees:
>
> git://github.com/awilliam/linux-vfio.git vfio-next-2029
> git://github.com/awilliam/qemu-vfio.git vfio-ng
Hi Alex,
Have been looking at vfio a bit. A few observations and things
we'll need to figure out as it relates to the Freescale iommu.
__vfio
On Mon, 2011-11-28 at 20:54 -0700, Alex Williamson wrote:
> On Tue, 2011-11-29 at 13:01 +1100, Alexey Kardashevskiy wrote:
> > Hi all,
> >
> > Another problem I hit on POWER - MSI interrupts allocation. The existing
> > VFIO does not expect a PBH
> > to support less interrupts that a device might
On Tue, 2011-11-29 at 15:34 +1100, Alexey Kardashevskiy wrote:
> Hi!
>
> On 29/11/11 14:46, Alex Williamson wrote:
> > On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
> >> Hi!
> >>
> >> I tried (successfully) to run it on POWER and while doing that I found
> >> some issues. I'll tr
Hi!
On 29/11/11 14:46, Alex Williamson wrote:
> On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
>> Hi!
>>
>> I tried (successfully) to run it on POWER and while doing that I found some
>> issues. I'll try to
>> explain them in separate mails.
>
> Great!
>
>> IOMMU domain setup. O
On Tue, 2011-11-29 at 13:01 +1100, Alexey Kardashevskiy wrote:
> Hi all,
>
> Another problem I hit on POWER - MSI interrupts allocation. The existing VFIO
> does not expect a PBH
> to support less interrupts that a device might request. In my case, PHB's
> limit is 8 interrupts
> while my test c
On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
> Hi!
>
> I tried (successfully) to run it on POWER and while doing that I found some
> issues. I'll try to
> explain them in separate mails.
Great!
> IOMMU domain setup. On POWER, the linux drivers capable of DMA transfer want
> t
Hi all again,
It was actually the very first problem - endianess :-)
I am still not sure what format is better for cached config space or whether we
should cache it all.
Also, as Benh already mentioned, vfio_virt_init reads a config space to a cache
by pci_read_config_dword
for the whole space
Hi all,
Another problem I hit on POWER - MSI interrupts allocation. The existing VFIO
does not expect a PBH
to support less interrupts that a device might request. In my case, PHB's limit
is 8 interrupts
while my test card (10Gb ethernet CXGB3) wants 9. Below are the patches to
demonstrate the
Hi!
I tried (successfully) to run it on POWER and while doing that I found some
issues. I'll try to
explain them in separate mails.
IOMMU domain setup. On POWER, the linux drivers capable of DMA transfer want to
know
a DMA window, i.e. its start and length in the PHB address space. This comes
On Tue, 2011-11-22 at 14:00 -0600, Scott Wood wrote:
> On 11/22/2011 01:16 PM, Alex Williamson wrote:
> > On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
> >> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> >>> Ugh, I suppose you're thinking of an ILP64 platform with ILP32 co
On 11/22/2011 01:16 PM, Alex Williamson wrote:
> On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
>> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
>>> Ugh, I suppose you're thinking of an ILP64 platform with ILP32 compat
>>> mode.
>>
>> Does Linux support ILP64? There are "in
On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
>> Hmm, that might be cleaner than eliminating the size with just using
>> _IO(). So we might have something like:
>>
>> #define VFIO_IOMMU_MAP_DMA _IOWR(';', 106, st
On Mon, 2011-11-21 at 13:47 +1100, David Gibson wrote:
> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> > On Thu, 2011-11-17 at 11:02 +1100, David Gibson wrote:
> > > On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> > > > On Tue, 2011-11-15 at 17:34 +1100, Davi
On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> On Thu, 2011-11-17 at 11:02 +1100, David Gibson wrote:
> > On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> > > On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> > > > On Thu, Nov 03, 2011 at 02:12:24PM -060
On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> Hmm, that might be cleaner than eliminating the size with just using
> _IO(). So we might have something like:
>
> #define VFIO_IOMMU_MAP_DMA _IOWR(';', 106, struct vfio_dma_map)
> #define VFIO_IOMMU_MAP_DMA_V2
On Thu, 2011-11-17 at 11:02 +1100, David Gibson wrote:
> On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> > On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> > > On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > > > +Groups, Devices, IOMMUs, oh my
> > >
On Thu, Nov 17, 2011 at 01:22:17PM -0700, Alex Williamson wrote:
> On Wed, 2011-11-16 at 11:52 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
> > What would be the return value if somebody tried to unmask an edge one?
> > Should that be docu
On Wed, 2011-11-16 at 11:47 -0600, Scott Wood wrote:
> On 11/11/2011 04:10 PM, Alex Williamson wrote:
> >
> > Thanks Konrad! Comments inline.
> >
> > On Fri, 2011-11-11 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> >>> +When
On Wed, 2011-11-16 at 11:52 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
> > > > +
> > > > +Regions are described by a struct vfio_region_info, which is retrieved
> > > > by
> > > > +using the GET_REGION_INFO ioctl with vfio_region_info.in
On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> > On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> > > new file mode 100644
> > > index 00
On Tue, 2011-11-15 at 16:29 -0600, Scott Wood wrote:
> On 11/15/2011 03:40 PM, Aaron Fabbri wrote:
> >
> >
> >
> > On 11/15/11 12:10 PM, "Scott Wood" wrote:
> >
> >> On 11/15/2011 12:34 AM, David Gibson wrote:
> >
> +static int allow_unsafe_intrs;
> +module_param(allow_unsafe_intrs
On 11/11/2011 04:10 PM, Alex Williamson wrote:
>
> Thanks Konrad! Comments inline.
>
> On Fri, 2011-11-11 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
>>> +When supported, as indicated by the device flags, reset the device.
>>>
On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
>
> Thanks Konrad! Comments inline.
>
> On Fri, 2011-11-11 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > > VFIO provides a secure, IOMMU based interface for us
On 11/15/2011 03:40 PM, Aaron Fabbri wrote:
>
>
>
> On 11/15/11 12:10 PM, "Scott Wood" wrote:
>
>> On 11/15/2011 12:34 AM, David Gibson wrote:
>
+static int allow_unsafe_intrs;
+module_param(allow_unsafe_intrs, int, 0);
+MODULE_PARM_DESC(allow_unsafe_intrs,
+"Allo
On 11/15/11 12:10 PM, "Scott Wood" wrote:
> On 11/15/2011 12:34 AM, David Gibson wrote:
>>> +static int allow_unsafe_intrs;
>>> +module_param(allow_unsafe_intrs, int, 0);
>>> +MODULE_PARM_DESC(allow_unsafe_intrs,
>>> +"Allow use of IOMMUs which do not support interrupt remapping");
>
On 11/15/2011 12:34 AM, David Gibson wrote:
> I think we need to pin exactly what "MAP_ANY" means down better. Now,
> VFIO is pretty much a lost cause if you can't map any normal process
> memory page into the IOMMU, so I think the only thing that is really
> covered is IOVAs. But saying "can map
On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> > new file mode 100644
> > index 000..5866896
> > --- /dev/null
> > +++ b/Documentation/vfio.txt
> > @@ -0
On Mon, 2011-11-14 at 13:54 -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> > On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > > + int (*get)(void *);
> > > + void(*put)(void *);
> > > + ssize_t (*read)
On Tue, 2011-11-15 at 11:05 +1100, David Gibson wrote:
> Being strict, or at least enforcing strictness, requires that the
> infrastructure track all the maps, so that the unmaps can be
> matching. This is not a natural thing with the data structures you
> want for all IOMMUs. For example on POWE
On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
> Thanks Konrad! Comments inline.
> On Fri, 2011-11-11 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
[snip]
> > > +The GET_NUM_REGIONS ioctl tells us how many region
On Mon, Nov 14, 2011 at 03:59:00PM -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 16:22 -0600, Christian Benvenuti (benve) wrote:
[snip]
> > - the user either unmaps one specific mapping or 'all of them'.
> > The 'all of them' case would also take care of those cases where
> > the user
On Fri, 2011-11-11 at 16:22 -0600, Christian Benvenuti (benve) wrote:
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 11, 2011 10:04 AM
> > To: Christian Benvenuti (benve)
> > Cc: chr...@sous-sol.org; a...@au1.ibm.com; p...@au1
Am 14.11.2011 um 23:26 schrieb Scott Wood :
> On 11/14/2011 02:54 PM, Alex Williamson wrote:
>> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
>>> What are the semantics of "desired and/or returned dma address"?
>>
>> I believe the original intention was that a user could leave dmaaddr
>>
On 11/14/2011 02:54 PM, Alex Williamson wrote:
> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
>> What are the semantics of "desired and/or returned dma address"?
>
> I believe the original intention was that a user could leave dmaaddr
> clear and let the iommu layer provide an iova address
On Mon, 2011-11-14 at 13:54 -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> > On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > > + for (i = 0; i < npage; i++, iova += PAGE_SIZE, vaddr += PAGE_SIZE) {
> > > + unsigned long pfn = 0;
> > > +
> > > +
On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > +Many modern system now provide DMA and interrupt remapping facilities
> > +to help ensure I/O devices behave within the boundaries they've been
> > +allotted. This includes x86 hardware with
On 11/03/2011 03:12 PM, Alex Williamson wrote:
> +Many modern system now provide DMA and interrupt remapping facilities
> +to help ensure I/O devices behave within the boundaries they've been
> +allotted. This includes x86 hardware with AMD-Vi and Intel VT-d as
> +well as POWER systems with Partit
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 11, 2011 10:04 AM
> To: Christian Benvenuti (benve)
> Cc: chr...@sous-sol.org; a...@au1.ibm.com; p...@au1.ibm.com;
> d...@au1.ibm.com; joerg.roe...@amd.com; ag...@suse.de; Aaron Fabbri
On Wed, 2011-11-09 at 18:57 -0600, Christian Benvenuti (benve) wrote:
> Here are few minor comments on vfio_iommu.c ...
Sorry, I've been poking sticks at trying to figure out a clean way to
solve the force vfio driver attach problem.
> > diff --git a/drivers/vfio/vfio_iommu.c b/drivers/vfio/vfio_
Here are few minor comments on vfio_iommu.c ...
> diff --git a/drivers/vfio/vfio_iommu.c b/drivers/vfio/vfio_iommu.c
> new file mode 100644
> index 000..029dae3
> --- /dev/null
> +++ b/drivers/vfio/vfio_iommu.c
> @@ -0,0 +1,530 @@
> +/*
> + * VFIO: IOMMU DMA mapping support
> + *
> + * Copyrig
On Wed, 2011-11-09 at 15:08 -0600, Christian Benvenuti (benve) wrote:
> > > > +
> > > > +struct vfio_group {
> > > > + dev_t devt;
> > > > + unsigned intgroupid;
> > >
> > > This groupid is returned by the device_group callback you recently
> > added
> > >
On Wed, 2011-11-09 at 02:11 -0600, Christian Benvenuti (benve) wrote:
> I have not gone through the all patch yet, but here are
> my first comments/questions about the code in vfio_main.c
> (and pci/vfio_pci.c).
Thanks! Comments inline...
> > -Original Message-
> > From: Alex Williamson
On Tue, 2011-11-08 at 20:17 -0800, Aaron Fabbri wrote:
> I'm going to send out chunks of comments as I go over this stuff. Below
> I've covered the documentation file and vfio_iommu.c. More comments coming
> soon...
>
> On 11/3/11 1:12 PM, "Alex Williamson" wrote:
>
> > VFIO provides a secure,
I'm going to send out chunks of comments as I go over this stuff. Below
I've covered the documentation file and vfio_iommu.c. More comments coming
soon...
On 11/3/11 1:12 PM, "Alex Williamson" wrote:
> VFIO provides a secure, IOMMU based interface for user space
> drivers, including device ass
57 matches
Mail list logo
