[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a5b1e040-fbd8-1727-3707-0ac7337d6472@linux.intel.com>
Date: Thu, 6 Dec 2018 09:19:56 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Joerg Roedel <joro@...tes.org>
Cc: baolu.lu@...ux.intel.com, "Liu, Yi L" <yi.l.liu@...el.com>,
David Woodhouse <dwmw2@...radead.org>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
"Pan, Jacob jun" <jacob.jun.pan@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
"Sun, Yi Y" <yi.y.sun@...el.com>,
"peterx@...hat.com" <peterx@...hat.com>,
Jean-Philippe Brucker <jean-philippe.brucker@....com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [PATCH v5 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
support
Hi Joerg,
On 12/5/18 11:56 PM, Joerg Roedel wrote:
> On Tue, Dec 04, 2018 at 02:13:31PM +0800, Lu Baolu wrote:
>> The existing code uses GFP_ATOMIC, this patch only changes the size of
>> the allocated desc_page.
>>
>> I don't think we really need GFP_ATOMIC here (and also for some other
>> places). I will clean up them in a separated patch.
>
> Okay, thanks.
>
>>> In this patch, there is some code like the code below. It calculates
>>> destination address of memcpy with qi->desc. If it's still struct qi_desc
>>> pointer, the calculation result would be wrong.
>>>
>>> + memcpy(desc, qi->desc + (wait_index << shift),
>>> + 1 << shift);
>>>
>>> The change of the calculation method is to support 128 bits invalidation
>>> descriptors and 256 invalidation descriptors in this unified code logic.
>>>
>>> Also, the conversation between Baolu and me may help.
>>>
>>> https://lore.kernel.org/patchwork/patch/1006756/
>>
>> Yes. We need to support different descriptor size.
>
> Okay, pointer arithmetic on void* isn't well defined in the C standard,
> afaik. But it should work with GCC, so it's probably fine.
>
> Unrelated to this patch-set, the whole qi management code needs some
> cleanups, it queues a sync after every command and has very tricky
> locking. This patch-set further complicates matters there, so it is
> probably time for a clean re-write of that part?
Sure. I will start the cleanups(including the unnecessary ATOMIC page
allocation) and submit them in a separated patch set after well tested.
Best regards,
Lu Baolu
Powered by blists - more mailing lists