Re: [PATCH v10 05/10] iommu/amd: Introduce helper function to update 256-bit DTE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 14, 2024 at 5:29 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
>
> On Wed, Nov 13, 2024 at 08:50:08PM +0100, Uros Bizjak wrote:
>
> > Then write_dte_upper128() would look like:
> >
> > static void write_dte_upper128(struct dev_table_entry *ptr, struct
> > dev_table_entry *new)
> > {
> >     struct dev_table_entry old = {}; <--- do we need to initialize struct here?
> >
> >     old.data128[1] = ptr->data128[1];
> >
> >     /*
> >      * Preserve DTE_DATA2_INTR_MASK. This needs to be
> >      * done here since it requires to be inside
> >      * spin_lock(&dev_data->dte_lock) context.
> >      */
> >     new->data[2] &= ~DTE_DATA2_INTR_MASK;
> >     new->data[2] |= old.data[2] & DTE_DATA2_INTR_MASK;
> >
> >     iommu_atomic128_set(&ptr->data128[1], new->data128[1]);
> > }
> >
> > and in a similar way implement write_dte_lower128().
>
> That makes sense to me, but also we have drifted really far from the
> purpose of this series and missed this merge window because of this :\
>
> Let's conclude something please

The most important fact here is that data won't change (I was not
aware of that), and that we would like to exercise only the 128bit
atomic write property of the cmpxchg16b. So, we actually don't need a
"lockless" approach, where we would need __READ_ONCE() and cmpxchg
loop. The atomic write can be a simple arch_cmpxchg128(ptr, *ptr,
new), and because *ptr won't change between preload and compare, the
xchg will always succeed.

Uros.





[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux