[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181205155646.GD16835@8bytes.org>
Date: Wed, 5 Dec 2018 16:56:46 +0100
From: Joerg Roedel <joro@...tes.org>
To: Lu Baolu <baolu.lu@...ux.intel.com>
Cc: "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
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?
Regards,
Joerg
Powered by blists - more mailing lists