[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240308135138.GJ9179@nvidia.com>
Date: Fri, 8 Mar 2024 09:51:38 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Cc: linux-kernel@...r.kernel.org, iommu@...ts.linux.dev, joro@...tes.org,
yi.l.liu@...el.com, kevin.tian@...el.com, nicolinc@...dia.com,
eric.auger@...hat.com, vasant.hegde@....com, jon.grimm@....com,
santosh.shukla@....com, Dhaval.Giani@....com, pandoh@...gle.com,
loganodell@...gle.com
Subject: Re: [RFCv2 PATCH 2/7] iommu/amd: Refactor set_dte_entry
On Thu, Jan 11, 2024 at 06:06:41PM -0600, Suravee Suthikulpanit wrote:
> - old_domid = dev_table[devid].data[1] & DEV_DOMID_MASK;
> - dev_table[devid].data[1] = flags;
> - dev_table[devid].data[0] = pte_root;
> + dev_table[devid].data[0] = target.data[0];
> + dev_table[devid].data[1] = target.data[1];
> + dev_table[devid].data[2] = target.data[2];
Maybe you could have convinced me this doesn't have bugs today with 2
qword updates, but no way this is OK.
The multi qword update needs to be sequenced correctly so the HW
doesn't have tearing. The manual talks about this and it talks about
128 bit updates too.
This needs to follow the design ARM has where it uses the special
update logic to reliably sequence the change. Since nesting is making
the update more complex it becomes important.
Jason
Powered by blists - more mailing lists