[dpdk-dev] [EXT] Re: [PATCH] bus/pci: fix IOVA as VA mode selection

Bruce Richardson bruce.richardson at intel.com
Tue Jul 9 11:32:23 CEST 2019


On Tue, Jul 09, 2019 at 09:05:07AM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson at intel.com>
> > Sent: Tuesday, July 9, 2019 2:10 PM
> > To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>
> > Cc: David Marchand <david.marchand at redhat.com>; dev <dev at dpdk.org>;
> > Thomas Monjalon <thomas at monjalon.net>; Ben Walker
> > <benjamin.walker at intel.com>; Burakov, Anatoly
> > <anatoly.burakov at intel.com>
> > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: fix IOVA as VA mode
> > selection
> > 
> > On Mon, Jul 08, 2019 at 07:13:28PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > See below,
> > >
> > > Please send the email as text to avoid formatting issue.(No HTML)
> > >
> > > From: David Marchand <david.marchand at redhat.com>
> > > Sent: Tuesday, July 9, 2019 12:09 AM
> > > To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>
> > > Cc: dev <dev at dpdk.org>; Thomas Monjalon <thomas at monjalon.net>;
> > Ben
> > > Walker <benjamin.walker at intel.com>; Burakov, Anatoly
> > > <anatoly.burakov at intel.com>
> > > Subject: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode
> > > selection
> > >
> > > ________________________________________
> > >
> > > On Mon, Jul 8, 2019 at 4:25 PM <mailto:jerinj at marvell.com> wrote:
> > > From: Jerin Jacob <mailto:jerinj at marvell.com>
> > >
> > > Existing logic fails to select IOVA mode as VA if driver request to
> > > enable IOVA as VA.
> > >
> > > IOVA as VA has more strict requirement than other modes, so enabling
> > > positive logic for IOVA as VA selection.
> > >
> > > This patch also updates the default IOVA mode as PA for PCI devices as
> > > it has to deal with DMA engines unlike the virtual devices that may
> > > need only IOVA as DC.
> > >
> > > We have three cases:
> > > - driver/hw supports IOVA as PA only
> > >
> > > [Jerin] It is not driver cap, it is more of system cap(IOMMU vs non
> > > IOMMU). We are already addressing that case
> > >
> > 
> > Not necessarily. It's possible to have hardware that does not use the IOMMU
> > on a platform. Therefore, you have more than two options to support.
> 
> Any example such device?
> 

On further investigation, it appears I was wrong/misinformed. All devices
I'm aware of work fine with an IOMMU if one is one the platform. Please
ignore my previous assertion, and thanks for getting me to follow up on this!

/Bruce


More information about the dev mailing list