On Fri, Nov 01, 2024 at 10:40:05AM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> > Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> > arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> >
> > All other drive
On Fri, Nov 01, 2024 at 11:58:29AM +, Will Deacon wrote:
> On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> > Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> > arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> >
> > All other drivers w
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> example if a 2
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> example if a 2
Hi Jason,
On Thu, Oct 24, 2024 at 10:44:11AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 24, 2024 at 02:05:53PM +0100, Will Deacon wrote:
>
> > My recollection is hazy, but I seem to remember VFIO using the largest
> > page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then
> > using
On Thu, Oct 24, 2024 at 02:05:53PM +0100, Will Deacon wrote:
> My recollection is hazy, but I seem to remember VFIO using the largest
> page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then
> using the smallest page size for unmap() requests, so you'd end up
> cracking block mappings
Hi Jason,
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> exa
On Mon, Oct 21, 2024 at 02:50:34PM +0100, Robin Murphy wrote:
> Beware that whatever the Mali drivers might have the option to do for
> themselves, there's still no notion of "atomic update" for SMMU and
> io-pgtable-arm in general, other than perhaps for permission changes - even
> BBML is quite
On 21/10/2024 1:17 pm, Jason Gunthorpe wrote:
On Mon, Oct 21, 2024 at 12:32:21PM +0100, Steven Price wrote:
that, we can always do it in two steps (unmap the 2M region and remap
the borders). At some point it'd be good to have some kind of atomic
page table updates, so we don't have this short
On Mon, Oct 21, 2024 at 12:32:21PM +0100, Steven Price wrote:
> > that, we can always do it in two steps (unmap the 2M region and remap
> > the borders). At some point it'd be good to have some kind of atomic
> > page table updates, so we don't have this short period of time during
> > which nothi
On 21/10/2024 10:17, Boris Brezillon wrote:
> On Fri, 18 Oct 2024 14:19:26 -0300
> Jason Gunthorpe wrote:
>
>> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
>> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>>
>> All other drivers will unmap the large IOP
On Fri, 18 Oct 2024 14:19:26 -0300
Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> example if a 2M IOP
Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
arm_lpae is unique in how it handles partial unmap of large IOPTEs.
All other drivers will unmap the large IOPTE and return it's length. For
example if a 2M IOPTE is present and the first 4K is requested to be
unmapped then unmap
13 matches
Mail list logo
