From: Joao Martins <joao.m.martins@oracle.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"mgurtovoy@nvidia.com" <mgurtovoy@nvidia.com>,
Linuxarm <linuxarm@huawei.com>,
liulongfang <liulongfang@huawei.com>,
"Zengtao (B)" <prime.zeng@hisilicon.com>,
yuzenghui <yuzenghui@huawei.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: iommufd(+vfio-compat) dirty tracking
Date: Fri, 18 Mar 2022 17:12:01 +0000 [thread overview]
Message-ID: <052c5f12-4f2d-f302-c2a3-2f2b580e4b4d@oracle.com> (raw)
In-Reply-To: <c85a0d65-143e-6246-0d48-dec4e059e51a@oracle.com>
On 3/16/22 20:37, Joao Martins wrote:
> On 3/16/22 16:36, Joao Martins wrote:
>> On 3/15/22 19:29, Jason Gunthorpe wrote:
>>> On Fri, Mar 11, 2022 at 01:51:32PM +0000, Joao Martins wrote:
>>>> On 2/28/22 13:01, Joao Martins wrote:
>>>>> On 2/25/22 20:44, Jason Gunthorpe wrote:
>>>>>> On Fri, Feb 25, 2022 at 07:18:37PM +0000, Joao Martins wrote:
>>>>>>> On 2/23/22 01:03, Jason Gunthorpe wrote:
>>>>>>>> On Tue, Feb 22, 2022 at 11:55:55AM +0000, Joao Martins wrote:
>>>>>> Questions I have:
>>>>>> - Do we need ranges for some reason? You mentioned ARM SMMU wants
>>>>>> ranges? how/what/why?
>>>>>>
>
> An amend here.
>
> Sigh, ARM turns out is slightly more unique compared to x86. As I am re-reviewing
> the ARM side. Apparently you have two controls: one is a 'feature bit'
> just like x86 and another is a modifier (arm-only).
>
> The Context descriptor (CD) equivalent to AMD DTEs or Intel context descriptor
> equivalent for second-level. That's the top-level enabler to actually a *second*
> modifier bit per-PTE (or per-TTD for more accurate terminology) which is the so
> called DBM (dirty-bit-modifier). The latter when set, changes the meaning of
> read/write access-flags of the PTE AP[2].
>
> If you have CD.HD enabled (aka HTTU is enabled) *and* PTE.DBM set, then a
> transition in the SMMU from "writable Clean" to "written" means that the the
> access bits go from "read-only" (AP[2] = 1) to "read/write" (AP[2] = 0)
> if-and-only-if PTE.DBM = 1 (and does not generate a permission IO page fault
> like it normally would be with DBM = 0). Same thing for stage-2, except that
> the access-bits are reversed (S2AP[1] is set when "written" and it's cleared
> when it's "writable" (when DBM is also set).
>
> Now you could say that this allows you to control on a per-range basis.
> Gah, no, more like a per-PTE basis is more accurate.
>
> And in practice I suppose that means that dynamically switching on/off SMMU
> dirty-tracking *dynamically* means not only setting CD.HD but also walking the
> page tables, and atomically setting/clearing both the DBM and AP[2].
>
> References:
>
> DDI0487H, Table D5-30 Data access permissions
> SMMU 3.2 spec, 3.13.3 Dirty flag hardware update
I updated my branch and added an SMMUv3 implementation of the whole thing (slightly based
on the past work) and adjusted the 'set tracking' structure to cover this slightly
different h/w construct above. At the high-level we have 'set_dirty_tracking_range' API,
which is internal in iommufd obviously. The UAPI won't change ofc.
It's only compile-tested sadly as I have no SMMUv3.2 hardware, and to have this SMMUv3
DBM/HTTU support there's some requirements on the processor that I am not sure they can be
fully emulated. The Intel iommu implementation follows same model as AMD and I will get to
that next with a compliant iommu emulation too.
But now, I will be focusing on hw_pagetable UAPI part. I understand your thinking of being
tied to the hw_pagetable obj as opposed to IOAS for the dirty tracking APIs.
next prev parent reply other threads:[~2022-03-18 17:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 9:58 [RFC v2 0/4] vfio/hisilicon: add acc live migration driver Shameer Kolothum
2021-07-02 9:58 ` [RFC v2 1/4] hisi-acc-vfio-pci: add new vfio_pci driver for HiSilicon ACC devices Shameer Kolothum
2021-07-02 20:29 ` Alex Williamson
2021-07-05 7:20 ` Shameerali Kolothum Thodi
2021-07-04 7:03 ` Leon Romanovsky
2021-07-05 8:47 ` Shameerali Kolothum Thodi
2021-07-05 9:41 ` Max Gurtovoy
2021-07-05 10:18 ` Shameerali Kolothum Thodi
2021-07-05 18:27 ` Leon Romanovsky
2021-07-05 18:32 ` Jason Gunthorpe
2021-07-06 3:59 ` Leon Romanovsky
2021-07-06 4:39 ` Christoph Hellwig
2021-07-06 11:51 ` Jason Gunthorpe
2021-07-02 9:58 ` [RFC v2 2/4] hisi_acc_vfio_pci: Override ioctl method to limit BAR2 region size Shameer Kolothum
2021-07-02 20:29 ` Alex Williamson
2021-07-05 7:22 ` Shameerali Kolothum Thodi
2021-07-02 9:58 ` [RFC v2 3/4] crypto: hisilicon/qm - Export mailbox functions for common use Shameer Kolothum
2021-07-04 9:34 ` Max Gurtovoy
2021-07-05 10:23 ` Shameerali Kolothum Thodi
2021-07-02 9:58 ` [RFC v2 4/4] hisi_acc_vfio_pci: Add support for vfio live migration Shameer Kolothum
2022-02-02 13:14 ` [RFC v2 0/4] vfio/hisilicon: add acc live migration driver Jason Gunthorpe
2022-02-02 14:34 ` Shameerali Kolothum Thodi
2022-02-02 15:39 ` Jason Gunthorpe
2022-02-02 16:10 ` Shameerali Kolothum Thodi
2022-02-02 17:03 ` Jason Gunthorpe
2022-02-02 19:05 ` Joao Martins
2022-02-03 15:18 ` Jason Gunthorpe
2022-02-04 19:53 ` Joao Martins
2022-02-04 23:07 ` Jason Gunthorpe
2022-02-11 17:28 ` Joao Martins
2022-02-11 17:49 ` Jason Gunthorpe
2022-02-11 21:43 ` Joao Martins
2022-02-12 0:01 ` Jason Gunthorpe
2022-02-14 13:34 ` Joao Martins
2022-02-14 14:06 ` Jason Gunthorpe
2022-02-15 16:00 ` Joao Martins
2022-02-15 16:21 ` Jason Gunthorpe
2022-02-22 11:55 ` Joao Martins
2022-02-23 1:03 ` Jason Gunthorpe
2022-02-25 19:18 ` Joao Martins
2022-02-25 20:44 ` Jason Gunthorpe
2022-02-28 13:01 ` Joao Martins
2022-02-28 21:01 ` Jason Gunthorpe
2022-03-01 13:06 ` Joao Martins
2022-03-01 13:54 ` Jason Gunthorpe
2022-03-01 14:27 ` Joao Martins
2022-03-11 13:51 ` iommufd(+vfio-compat) dirty tracking (Was: Re: [RFC v2 0/4] vfio/hisilicon: add acc live migration driver) Joao Martins
2022-03-15 19:29 ` Jason Gunthorpe
2022-03-16 16:36 ` iommufd(+vfio-compat) dirty tracking Joao Martins
2022-03-16 20:37 ` Joao Martins
2022-03-18 17:12 ` Joao Martins [this message]
2022-03-18 17:34 ` Jason Gunthorpe
2022-02-02 17:30 ` [RFC v2 0/4] vfio/hisilicon: add acc live migration driver Alex Williamson
2022-02-02 18:04 ` Jason Gunthorpe
2022-02-18 16:37 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=052c5f12-4f2d-f302-c2a3-2f2b580e4b4d@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liulongfang@huawei.com \
--cc=mgurtovoy@nvidia.com \
--cc=prime.zeng@hisilicon.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).