On Wed, Jun 27, 2012 at 01:23:23PM -0600, Alex Williamson wrote:
> On Wed, 2012-06-27 at 15:37 +0300, Dan Carpenter wrote:
> > On Mon, Jun 25, 2012 at 10:55:52PM -0600, Alex Williamson wrote:
> > > Hi,
> > >
> > > VFIO has been kicking around for well over a year now and has been
> > > posted nume
On Wed, 27 Jun 2012 20:02:46 +0200
Stephen Warren wrote:
> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> >
> > (1) discontiguous memory with IOMMU
> > (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although memo
On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren wrote:
> On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> Different boards have different amounts of memory, and are sometimes
> targeted at different use-cases (e.g.
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding wrote:
> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> >
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> In the
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach wrote:
> > > > > Rather than introducing a new property, how about using
> > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > that this carveout size depends on the system usage/load.
> > > >
> > > > I
+ Paul
On 19 June 2012 12:48, Cousson, Benoit wrote:
> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>
>> Hi Benoit,
>>
>> On 19 June 2012 07:36, Cousson, Benoit wrote:
>>>
>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>
>> ...
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod =
On Wed, 2012-06-27 at 15:37 +0300, Dan Carpenter wrote:
> On Mon, Jun 25, 2012 at 10:55:52PM -0600, Alex Williamson wrote:
> > Hi,
> >
> > VFIO has been kicking around for well over a year now and has been
> > posted numerous times for review. The pre-requirements are finally
> > available in lin
On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
...
> I think that there are 2 cases:
>
> (1) discontiguous memory with IOMMU
> (2) contiguous memory without IOMMU(called "carveout" in general?)
...
> For (2), although memory is mostly anonymous one, we may need to know
> how much to allocate, whe
On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> Could you explain a bit more why you want carveout size on per-board basis?
Different boards have different amounts of memory, and are sometimes
targeted at different use-cases (e.g. server with simple display buffer,
vs. consumer-oriented device inten
On 06/27/2012 03:54 AM, Hiroshi DOYU wrote:
> allo_pdir() is called in smmu_iommu_domain_init() with spin_lock
> held. memory allocations in it have to be atomic/unsleepable.
Presumably this will cause allocation failures in situations with heavy
memory pressure, rather than triggering swapping. I
Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 16:08:10 +0200
> > Thierry Reding wrote:
> >
> > > * PGP Signed by an unknown key
> > >
> > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi
* Hiroshi DOYU (hd...@nvidia.com) wrote:
> allo_pdir() is called in smmu_iommu_domain_init() with spin_lock
> held. memory allocations in it have to be atomic/unsleepable.
>
> Signed-off-by: Hiroshi DOYU
> Reported-by: Chris Wright
Acked-by: Chris Wright
___
On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:08:10 +0200
> Thierry Reding wrote:
>
> > * PGP Signed by an unknown key
> >
> > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > Thierry Reding wro
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > On Tue, 26 Jun 2012 12:55:13 +0200 Thierry Reding
> > > wrote:
> > >> ...
> > I'm not sure I understand how informatio
On 06/26/2012 08:32 PM, Mark Zhang wrote:
>> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> On Tue, 26 Jun 2012 12:55:13 +0200
> Thierry Reding wrote:
>> ...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
>>>
>>> I think th
> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>> Thierry Reding wrote:
> ...
> >> I'm not sure I understand how information about the carveout would be
> >> obtained from the IOMMU API, though.
> >
> > I think that can be similar with current gart implemen
On 06/26/2012 07:46 PM, Mark Zhang wrote:
>>> On Tue, 26 Jun 2012 12:55:13 +0200
>>> Thierry Reding wrote:
...
>> I'm not sure I understand how information about the carveout would be
>> obtained from the IOMMU API, though.
>
> I think that can be similar with current gart implementation. Define
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > Hi,
> > >
> > > while I haven't got much time to work on the actual code right now,
> > > I think it might still be useful if we could get the device tree
> > > binding to a point
On Wed, 27 Jun 2012 16:08:10 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 07:14:18 +0200
> > Thierry Reding wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > On Tue, Jun 26, 201
On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 07:14:18 +0200
> Thierry Reding wrote:
>
> > * PGP Signed by an unknown key
> >
> > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > >> On 06/2
On Wed, 27 Jun 2012 07:14:18 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > On Tue, 26 Jun 2012 12:55:13 +020
On Wed, 27 Jun 2012 04:48:18 +0200
Stephen Warren wrote:
> On 06/26/2012 08:32 PM, Mark Zhang wrote:
> >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding wrote:
> >> ...
> I'm not sure I understand how information about the carveou
On Wed, 27 Jun 2012 04:32:07 +0200
Mark Zhang wrote:
> > On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>> Thierry Reding wrote:
> > ...
> > >> I'm not sure I understand how information about the carveout would be
> > >> obtained from the IOMMU API, tho
On Tue, 26 Jun 2012 16:00:33 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jun 26, 2012 at 04:02:24PM +0300, Hiroshi Doyu wrote:
> > Hi Thierry,
> >
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding wrote:
> >
> > > > Old Signed by an unknown key
> > >
> >
On Mon, Jun 25, 2012 at 10:55:52PM -0600, Alex Williamson wrote:
> Hi,
>
> VFIO has been kicking around for well over a year now and has been
> posted numerous times for review. The pre-requirements are finally
> available in linux-next (or will be in the 20120626 build) so I'd like
> to request
allo_pdir() is called in smmu_iommu_domain_init() with spin_lock
held. memory allocations in it have to be atomic/unsleepable.
Signed-off-by: Hiroshi DOYU
Reported-by: Chris Wright
---
drivers/iommu/tegra-smmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
Hi Chris,
Chris Wright wrote @ Tue, 26 Jun 2012 20:15:55 +0200:
> This looks buggy to me:
>
> drivers/iommu/tegra-smmu.c::smmu_iommu_domain_init()
>
> spin_lock_irqsave(&tmp->lock, flags); <-- lock held, interrupts off
> alloc_pdir(as = tmp)
> devm_kzalloc(..., GFP_KERNEL);<-
write_file_bool() modifies 32 bits of data, so "amd_iommu_unmap_flush"
needs to be 32 bits as well or we'll corrupt memory. Fortunately it
looks like the data is aligned with a gap after the declaration so this
is harmless in production.
Signed-off-by: Dan Carpenter
---
Originally sent on Fri, 2
28 matches
Mail list logo
