From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> To: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, Alex Williamson <alex.williamson@redhat.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Joerg Roedel <joro@8bytes.org>, David Woodhouse <dwmw2@infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, Christoph Hellwig <hch@infradead.org>, Lu Baolu <baolu.lu@linux.intel.com>, Yi L <yi.l.liu@linux.intel.com>, Auger Eric <eric.auger@redhat.com> Subject: Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function Date: Thu, 31 May 2018 10:09:46 +0100 [thread overview] Message-ID: <1c1094e8-ecbb-7731-910c-59e4de1e5c70@arm.com> (raw) In-Reply-To: <20180530125240.34e0e80c@jacob-builder> On 30/05/18 20:52, Jacob Pan wrote: >> However I think the model number should be added to >> pasid_table_config. For one thing it gives us a simple sanity-check, >> but it also tells which other fields are valid in pasid_table_config. >> Arm-smmu-v3 needs at least two additional 8-bit fields describing the >> PASID table format (number of levels and PASID0 behaviour), which are >> written to device context tables when installing the PASID table >> pointer. >> > We had model number field in v2 of this patchset. My thought was that > since the config info is meant to be generic, we shouldn't include > model info. But I also think a simple sanity check can be useful, > would that be sufficient to address Alex's concern? Of course we still > need sysfs for more specific IOMMU features. > > Would this work? > enum pasid_table_model { > PASID_TABLE_FORMAT_HOST, > PASID_TABLE_FORMAT_ARM_1LVL, > PASID_TABLE_FORMAT_ARM_2LVL, I'd rather use a single PASID_TABLE_FORMAT_ARM, because "2LVL" may be further split into 2LVL_4k or 2LVL_64k leaf tables... I think it's best if I add an arch-specific field in pasid_table_config for that, and for the PASID0 configuration, when adding FORMAT_ARM in a future patch > PASID_TABLE_FORMAT_AMD, > PASID_TABLE_FORMAT_INTEL, > }; > > /** > * PASID table data used to bind guest PASID table to the host IOMMU. This will > * enable guest managed first level page tables. > * @version: for future extensions and identification of the data format > * @bytes: size of this structure > * @model: PASID table format for different IOMMU models > * @base_ptr: PASID table pointer > * @pasid_bits: number of bits supported in the guest PASID table, must be less > * or equal than the host supported PASID size. > */ > struct pasid_table_config { > __u32 version; > #define PASID_TABLE_CFG_VERSION_1 1 > __u32 bytes; "bytes" could be passed by VFIO as argument to bind_pasid_table, since it can deduce it from argsz Thanks, Jean > enum pasid_table_model model; > __u64 base_ptr; > __u8 pasid_bits; > }; > > > >> Compatibility: new optional features are easy to add to a given model, >> just add a new sysfs file. If in the future, the host describes a new >> feature that is mandatory, or implements a different PASID table >> format, how does it ensure that user understands it? Perhaps use a >> new model number for this, e.g. "arm-smmu-v3-a=3", with similar >> features. I think it would be the same if the host stops supporting a >> feature for a given model, because they are ABI. But we can also >> define default values from the start, for example "if ssid_bits file >> isn't present, default value is 0 - PASID not supported" >> >> Thanks, >> Jean > > [Jacob Pan] >
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> To: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> Cc: Yi L <yi.l.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, "Raj, Ashok" <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, "Wysocki, Rafael J" <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Subject: Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function Date: Thu, 31 May 2018 10:09:46 +0100 [thread overview] Message-ID: <1c1094e8-ecbb-7731-910c-59e4de1e5c70@arm.com> (raw) In-Reply-To: <20180530125240.34e0e80c@jacob-builder> On 30/05/18 20:52, Jacob Pan wrote: >> However I think the model number should be added to >> pasid_table_config. For one thing it gives us a simple sanity-check, >> but it also tells which other fields are valid in pasid_table_config. >> Arm-smmu-v3 needs at least two additional 8-bit fields describing the >> PASID table format (number of levels and PASID0 behaviour), which are >> written to device context tables when installing the PASID table >> pointer. >> > We had model number field in v2 of this patchset. My thought was that > since the config info is meant to be generic, we shouldn't include > model info. But I also think a simple sanity check can be useful, > would that be sufficient to address Alex's concern? Of course we still > need sysfs for more specific IOMMU features. > > Would this work? > enum pasid_table_model { > PASID_TABLE_FORMAT_HOST, > PASID_TABLE_FORMAT_ARM_1LVL, > PASID_TABLE_FORMAT_ARM_2LVL, I'd rather use a single PASID_TABLE_FORMAT_ARM, because "2LVL" may be further split into 2LVL_4k or 2LVL_64k leaf tables... I think it's best if I add an arch-specific field in pasid_table_config for that, and for the PASID0 configuration, when adding FORMAT_ARM in a future patch > PASID_TABLE_FORMAT_AMD, > PASID_TABLE_FORMAT_INTEL, > }; > > /** > * PASID table data used to bind guest PASID table to the host IOMMU. This will > * enable guest managed first level page tables. > * @version: for future extensions and identification of the data format > * @bytes: size of this structure > * @model: PASID table format for different IOMMU models > * @base_ptr: PASID table pointer > * @pasid_bits: number of bits supported in the guest PASID table, must be less > * or equal than the host supported PASID size. > */ > struct pasid_table_config { > __u32 version; > #define PASID_TABLE_CFG_VERSION_1 1 > __u32 bytes; "bytes" could be passed by VFIO as argument to bind_pasid_table, since it can deduce it from argsz Thanks, Jean > enum pasid_table_model model; > __u64 base_ptr; > __u8 pasid_bits; > }; > > > >> Compatibility: new optional features are easy to add to a given model, >> just add a new sysfs file. If in the future, the host describes a new >> feature that is mandatory, or implements a different PASID table >> format, how does it ensure that user understands it? Perhaps use a >> new model number for this, e.g. "arm-smmu-v3-a=3", with similar >> features. I think it would be the same if the host stops supporting a >> feature for a given model, because they are ABI. But we can also >> define default values from the start, for example "if ssid_bits file >> isn't present, default value is 0 - PASID not supported" >> >> Thanks, >> Jean > > [Jacob Pan] >
next prev parent reply other threads:[~2018-05-31 9:10 UTC|newest] Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-16 21:48 [PATCH v4 00/22] IOMMU and VT-d driver support for Shared Virtual Address (SVA) Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 01/22] iommu: introduce bind_pasid_table API function Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 02/22] iommu/vt-d: move device_domain_info to header Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 03/22] iommu/vt-d: add a flag for pasid table bound status Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-17 19:10 ` Alex Williamson 2018-04-17 19:10 ` Alex Williamson 2018-04-20 18:25 ` Jean-Philippe Brucker 2018-04-20 18:25 ` Jean-Philippe Brucker 2018-04-20 23:42 ` Jacob Pan 2018-04-20 23:42 ` Jacob Pan 2018-05-29 20:09 ` Alex Williamson 2018-05-29 20:09 ` Alex Williamson 2018-05-30 1:41 ` Tian, Kevin 2018-05-30 1:41 ` Tian, Kevin 2018-05-30 3:17 ` Alex Williamson 2018-05-30 3:17 ` Alex Williamson 2018-05-30 3:45 ` Tian, Kevin 2018-05-30 3:45 ` Tian, Kevin 2018-05-30 11:53 ` Jean-Philippe Brucker 2018-05-30 11:53 ` Jean-Philippe Brucker 2018-05-30 19:52 ` Jacob Pan 2018-05-30 19:52 ` Jacob Pan 2018-05-31 9:09 ` Jean-Philippe Brucker [this message] 2018-05-31 9:09 ` Jean-Philippe Brucker 2018-06-05 17:32 ` Jacob Pan 2018-06-06 11:20 ` Jean-Philippe Brucker 2018-06-06 11:20 ` Jean-Philippe Brucker 2018-06-06 21:22 ` Jacob Pan 2018-06-07 13:21 ` Jean-Philippe Brucker 2018-04-20 23:22 ` Jacob Pan 2018-04-20 23:22 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 05/22] iommu: introduce iommu invalidate API function Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-20 18:19 ` Jean-Philippe Brucker 2018-04-20 18:19 ` Jean-Philippe Brucker 2018-04-23 20:43 ` Jacob Pan 2018-04-23 20:43 ` Jacob Pan 2018-04-27 18:07 ` Jean-Philippe Brucker 2018-04-27 18:07 ` Jean-Philippe Brucker 2018-04-28 2:41 ` Tian, Kevin 2018-04-28 2:41 ` Tian, Kevin 2018-05-01 22:58 ` Jacob Pan 2018-05-01 22:58 ` Jacob Pan 2018-05-02 9:31 ` Jean-Philippe Brucker 2018-05-02 9:31 ` Jean-Philippe Brucker 2018-05-04 4:46 ` Jacob Pan 2018-05-04 4:46 ` Jacob Pan 2018-05-04 18:07 ` Jacob Pan 2018-05-04 18:07 ` Jacob Pan 2018-05-08 10:35 ` Jean-Philippe Brucker 2018-05-08 10:35 ` Jean-Philippe Brucker 2018-05-09 12:55 ` Jacob Pan 2018-05-09 12:55 ` Jacob Pan 2018-05-05 22:19 ` Jerry Snitselaar 2018-05-05 22:19 ` Jerry Snitselaar 2018-05-07 15:41 ` Jacob Pan 2018-05-07 15:41 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 06/22] iommu/vt-d: add definitions for PFSID Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 07/22] iommu/vt-d: fix dev iotlb pfsid use Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 08/22] iommu/vt-d: support flushing more translation cache types Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 09/22] iommu/vt-d: add svm/sva invalidate function Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-17 19:10 ` Alex Williamson 2018-04-17 19:10 ` Alex Williamson 2018-04-20 22:36 ` Jacob Pan 2018-04-20 22:36 ` Jacob Pan 2018-04-16 21:48 ` [PATCH v4 10/22] iommu: introduce device fault data Jacob Pan 2018-04-16 21:48 ` Jacob Pan 2018-04-23 10:11 ` Jean-Philippe Brucker 2018-04-23 10:11 ` Jean-Philippe Brucker 2018-04-23 11:54 ` Jacob Pan 2018-04-23 11:54 ` Jacob Pan 2018-05-20 8:17 ` Liu, Yi L 2018-05-21 23:16 ` Jacob Pan 2018-05-21 23:16 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 11/22] driver core: add per device iommu param Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-23 10:26 ` Greg Kroah-Hartman 2018-04-23 10:26 ` Greg Kroah-Hartman 2018-04-16 21:49 ` [PATCH v4 12/22] iommu: introduce device fault report API Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-23 11:30 ` Jean-Philippe Brucker 2018-04-23 11:30 ` Jean-Philippe Brucker 2018-04-24 18:29 ` Jacob Pan 2018-04-24 18:29 ` Jacob Pan 2018-04-30 16:53 ` Jean-Philippe Brucker 2018-04-30 16:53 ` Jean-Philippe Brucker 2018-04-30 18:54 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 13/22] iommu: introduce page response function Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-23 11:47 ` Jean-Philippe Brucker 2018-04-23 11:47 ` Jean-Philippe Brucker 2018-04-23 12:16 ` Jacob Pan 2018-04-23 12:16 ` Jacob Pan 2018-04-23 15:50 ` Jean-Philippe Brucker 2018-04-23 15:50 ` Jean-Philippe Brucker 2018-04-16 21:49 ` [PATCH v4 14/22] iommu: handle page response timeout Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-23 15:36 ` Jean-Philippe Brucker 2018-04-25 15:37 ` Jacob Pan 2018-04-25 15:37 ` Jacob Pan 2018-04-30 10:58 ` Jean-Philippe Brucker 2018-04-30 10:58 ` Jean-Philippe Brucker 2018-04-30 17:54 ` Jacob Pan 2018-04-30 17:54 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 15/22] iommu/config: add build dependency for dmar Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 16/22] iommu/vt-d: report non-recoverable faults to device Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 17/22] iommu/intel-svm: report device page request Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 18/22] iommu/intel-svm: replace dev ops with fault report API Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 19/22] iommu/intel-svm: do not flush iotlb for viommu Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 20/22] iommu/vt-d: add intel iommu page response function Jacob Pan 2018-04-16 21:49 ` Jacob Pan 2018-04-16 21:49 ` [PATCH v4 21/22] trace/iommu: add sva trace events Jacob Pan 2018-04-16 21:49 ` [PATCH v4 22/22] iommu: use sva invalidate and device fault trace event Jacob Pan -- strict thread matches above, loose matches on Subject: below -- 2018-03-23 3:11 [PATCH v4 00/22] IOMMU and VT-d driver support for Shared Virtual Address (SVA) Jacob Pan 2018-03-23 3:11 ` [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function Jacob Pan 2018-03-23 3:11 ` Jacob Pan
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=1c1094e8-ecbb-7731-910c-59e4de1e5c70@arm.com \ --to=jean-philippe.brucker@arm.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@linux.intel.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=rafael.j.wysocki@intel.com \ --cc=yi.l.liu@intel.com \ --cc=yi.l.liu@linux.intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.