On Tue, Oct 16, 2018 at 09:11:09AM -0400, tedheadster wrote:
> Christoph,
> this fix has causes performance to decrease dramatically. Kernel
> builds that used to take 10-15 minutes are now taking 45-60 minutes on
> the same machine.
What is the comparism? Is this on a non-aic7xxx kernel with
> What is the comparism? Is this on a non-aic7xxx kernel with and without
> the fix?
Christoph,
I will try and do some strict before-and-after benchmarking of your
patch. It will take a few days because I am on travel. This is on an
aic7xxx (it does have that controller) kernel with and
On Wed, Oct 17, 2018 at 03:21:43PM +0100, Jean-Philippe Brucker wrote:
> Hi Jordan,
>
> On 12/10/2018 15:32, Jordan Crouse wrote:
> > On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
> >> Provide an API for allocating PASIDs and populating them manually. To ease
> >> cleanup
On Wed, Oct 17, 2018 at 12:54:28PM +0100, Jean-Philippe Brucker wrote:
> On 16/10/2018 21:31, Auger Eric wrote:
> > Hi Jean,
> >
> > On 10/16/18 8:44 PM, Jean-Philippe Brucker wrote:
> >> On 16/10/2018 10:25, Auger Eric wrote:
> >>> Hi Jean,
> >>>
> >>> On 10/12/18 4:59 PM, Jean-Philippe Brucker
On 17/10/18 18:07, Will Deacon wrote:
On Tue, Oct 16, 2018 at 12:31:07PM +0100, Robin Murphy wrote:
When we insert the sync sequence number into the CMD_SYNC.MSIData field,
we do so in CPU-native byte order, before writing out the whole command
as explicitly little-endian dwords. Thus on
On Mon, Oct 15, 2018 at 08:46:41PM +0100, Jean-philippe Brucker wrote:
> [Replying with my personal address because we're having SMTP issues]
>
> On 15/10/2018 11:52, Michael S. Tsirkin wrote:
> > On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
> >> s/iommu/IOMMU/ in subject
> >>
>
On Tue, Oct 16, 2018 at 12:31:07PM +0100, Robin Murphy wrote:
> When we insert the sync sequence number into the CMD_SYNC.MSIData field,
> we do so in CPU-native byte order, before writing out the whole command
> as explicitly little-endian dwords. Thus on big-endian systems, the SMMU
> will
On Fri, 12 Oct 2018 15:59:12 +0100, Jean-Philippe Brucker wrote:
> Some systems implement virtio-iommu as a PCI endpoint. The operating
> systems needs to discover the relationship between IOMMU and masters long
> before the PCI endpoint gets probed. Add a PCI child node to describe the
>
When we insert the sync sequence number into the CMD_SYNC.MSIData field,
we do so in CPU-native byte order, before writing out the whole command
as explicitly little-endian dwords. Thus on big-endian systems, the SMMU
will receive and write back a byteswapped version of sync_nr, which would
be
On Mon, Oct 15, 2018 at 01:56:18PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 10/15/2018 12:55 PM, Simon Horman wrote:
>
> > From: Hai Nguyen Pham
> >
> > Support the r8a77990 IPMMU and update IPMMU_OF_DECLARE to hook up
>
>That macro is gone, you need to update the description.
On Tue, 16 Oct 2018, tedheadster wrote:
> On Sun, Oct 14, 2018 at 3:52 AM Christoph Hellwig wrote:
> >
> > We already build the swiotlb code for 32b-t kernels with PAE support,
> > but the code to actually use swiotlb has only been enabled for 64-bit
> > kernel for an unknown reason.
> >
> >
From: Hai Nguyen Pham
Support the R-Car E3 (r8a77990) IPMMU.
Signed-off-by: Hai Nguyen Pham
Signed-off-by: Kazuya Mizuguchi
[simon: rebased; dropped no longer required IOMMU_OF_DECLARE hunk]
Signed-off-by: Simon Horman
---
v2 [Simon Horman]
* Update changelog
---
drivers/iommu/ipmmu-vmsa.c
On Fri, Oct 12, 2018 at 03:59:11PM +0100, Jean-Philippe Brucker wrote:
> The nature of a virtio-mmio node is discovered by the virtio driver at
> probe time. However the DMA relation between devices must be described
> statically. When a virtio-mmio node is a virtio-iommu device, it needs an
>
On 16/10/2018 21:31, Auger Eric wrote:
> Hi Jean,
>
> On 10/16/18 8:44 PM, Jean-Philippe Brucker wrote:
>> On 16/10/2018 10:25, Auger Eric wrote:
>>> Hi Jean,
>>>
>>> On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
Implement the virtio-iommu driver, following specification v0.8 [1].
Now that both sync methods are more or less the same shape, we can save
some code and levels of indirection by rolling them up together again,
with just a couple of simple conditionals to discriminate the MSI and
queue-polling specifics.
Signed-off-by: Robin Murphy
---
Even without the MSI trick, we can still do a lot better than hogging
the entire queue while it drains. All we actually need to do for the
necessary guarantee of completion is wait for our particular command to
have been consumed - as long as we keep track of where we inserted it,
there is no need
Hi Jordan,
On 12/10/2018 15:32, Jordan Crouse wrote:
> On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
>> Provide an API for allocating PASIDs and populating them manually. To ease
>> cleanup and factor allocation code, reuse the io_mm structure for private
>> PASID.
On 17/10/2018 15:21, Jean-Philippe Brucker wrote:
> Hi Jordan,
>
> On 12/10/2018 15:32, Jordan Crouse wrote:
>> On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
>>> Provide an API for allocating PASIDs and populating them manually. To ease
>>> cleanup and factor allocation
On 17/10/2018 14:56, Robin Murphy wrote:
Now that both sync methods are more or less the same shape, we can save
some code and levels of indirection by rolling them up together again,
with just a couple of simple conditionals to discriminate the MSI and
queue-polling specifics.
Hi Robin, Will,
19 matches
Mail list logo
