Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 25 Oct 2021 20:34:59 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Tian, Kevin" <kevin.tian@intel.com>
Cc:     Alex Williamson <alex.williamson@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>, "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: Re: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO
Message-ID: <20211025233459.GM2744544@nvidia.com>
References: <BN9PR11MB54333BDB1E58387FD9999DF18CA39@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210923114219.GG964074@nvidia.com>
 <BN9PR11MB5433519229319BA951CA97638CAA9@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210930222355.GH964074@nvidia.com>
 <BN9PR11MB5433530032DC8400B71FCB788CB89@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20211014154259.GT2744544@nvidia.com>
 <BN9PR11MB543327BB6D58AEF91AD2C9D18CB99@BN9PR11MB5433.namprd11.prod.outlook.com>
 <BL1PR11MB5429973588E4FBCEC8F519A88CBF9@BL1PR11MB5429.namprd11.prod.outlook.com>
 <20211021233036.GN2744544@nvidia.com>
 <BN9PR11MB5433482C3754A8A383C3B6298C809@BN9PR11MB5433.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BN9PR11MB5433482C3754A8A383C3B6298C809@BN9PR11MB5433.namprd11.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?cPULKCTIhOfvacJS/CfTb5qFmGRSwk7OblABDqzTBq2CoS1NFdKpxg1WouNW?=
 =?us-ascii?Q?/4F3vGre+boBE5YFYNe3Mv6QjpnGtmBYDq21zM7N04YWHZEZLnTsbst/pD1k?=
 =?us-ascii?Q?8yrUVg9iWxTFgExl519C3YpXYFSiqaarw82AXYjyDUJtFKLO0U4Dnx+C4wal?=
 =?us-ascii?Q?VoTSOkTqzD5N9bpvN1kH3S53RpL7c7+HBdZz7qt8UmA7uH7cACpPJdT8IKRt?=
 =?us-ascii?Q?AubSwX8qgl/mF+Wc3bSTDeear+doUtA9Q+CzilOQ3TUP5OmTff9vJZP9cl7f?=
 =?us-ascii?Q?YhR0aIu040kXJf96EMYTImJGxrMlCwbINTavV6MQpFRJW/c+73WJciickb2X?=
 =?us-ascii?Q?Ef+/DLZXS6Hmi6+BCwTnsxkQ9wRZf5bUJyiSBz4he5S4T/0lc/R1iCzMUaw0?=
 =?us-ascii?Q?TpryU/0jbb4yAvYDNgWlQyXJBD7cvSoqOgoAvbqjn4swcT0WlQVtW7N/pk7j?=
 =?us-ascii?Q?ASt3Dve58MsymlcGqMBM3ejPd3Gdy7shMhzAxra1aiqLVTnz419whixIpSjl?=
 =?us-ascii?Q?NpY0EEEWbOeSuDhqPZqhuLwj3VU/ODEOsxQs7XEDLTWEZvgr5/0P0JmbRptd?=
 =?us-ascii?Q?SBWECSM1bVNqlEEHoO6H/bpqA4rnVmg9MCBATU9zbhxCgtQe1VjtmU34ksCz?=
 =?us-ascii?Q?6nUZYZ2Z+tAP+qX0L7t0Sm7X6e3zyxst951sGtJQzhof9svZWXWD4NonJvLf?=
 =?us-ascii?Q?ZN2xo0R6g7OLpKWpPC07cyfBmr2+hf4EnXsAkxC3Okb5P8IPQ/r/P0/TW/U0?=
 =?us-ascii?Q?icKAR7R+7x8CdiX/DWRo2EYh4FKTui4s6kOFFe/OrKHhFUIeYhiDgzgDdyJq?=
 =?us-ascii?Q?nQtXrOTXvtLybnMOTU2oGe4H8RuEug8ISK5wDvf/dJzkGtAjXyV0XAwDcp7l?=
 =?us-ascii?Q?H2+DFX1F34JwWZ1VA3EOXTXrIEdo9soTEmbKxjHcnIIiXJFF0ytpccNisz7x?=
 =?us-ascii?Q?zpWDBMU0Z3FD67ScM3nyDXZz9RdLMGzySeCkidP1UA3OadHQJ4OOin4oJ5wC?=
 =?us-ascii?Q?ku0ZrSlk1McOvZpIVWkG7OOF6sIcO0AIdzESBN+Y9DuvyZtuDQR53+GsgUtz?=
 =?us-ascii?Q?A+h9ZQT/CWGLh8EJa1GY538SFeFHpBaUnBVpt6OePky6osB2r9fGDE5Q75xB?=
 =?us-ascii?Q?EYf8WmmsqbKB5CBJLJNPIcA6D/0pRumWlQ+NSQBqSe7j6rGwtY8AFnWqpplq?=
 =?us-ascii?Q?ispzXSsRt3uc1D3pEF16GyNM6DI9QEK/2RzSZllZM8S/EuKT+4wr86WUvABo?=
 =?us-ascii?Q?WOIq9VEu8Lm5zbjrhib1u9gUY3DZWNfdSj5lwc6/4dcIu7KjtuViXaoCnk2n?=
 =?us-ascii?Q?Ryj4AUHclMYI81JFaZaCwVRANHeZForUc7hER8lmfJjSnwTlj65ytR5Cxw6V?=
 =?us-ascii?Q?UbeXbv2CwZjGI9s0qn/lHrBl8fZ6VO3lSbQD8NjJbagy+7QwTF0qpMe9BWnT?=
 =?us-ascii?Q?7thl8AvRRMAU5zFM6oRXqoYgAuQf8SKEt8nSBkYUnu2DOh6EkhncJ/Z7dqni?=
 =?us-ascii?Q?G0XVkQXovU98zpSID5uot6y+z1dQ8nmAwJ/uAdFFlT95Zj+gwzVIQzskkMHl?=
 =?us-ascii?Q?OCvr6xFvCclL4aqIwvA=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f4b06b24-bc6d-4f5e-6938-08d998101051
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2021 23:35:01.2585
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yfN262F/VGGEyqwbTgrl7HZk0bPuS+69eqU6UVsddONR3Y0S3shR9Z803q+GwHkE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5253
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 22, 2021 at 03:08:06AM +0000, Tian, Kevin wrote:

> > I have no idea what security model makes sense for wbinvd, that is the
> > major question you have to answer.
> 
> wbinvd flushes the entire cache in local cpu. It's more a performance
> isolation problem but nothing can prevent it once the user is allowed
> to call this ioctl. This is the main reason why wbinvd is a privileged 
> instruction and is emulated by kvm as a nop unless an assigned device
> has no-snoop requirement. alternatively the user may call clflush
> which is unprivileged and can invalidate a specific cache line, though 
> not efficient for flushing a big buffer.
>
> One tricky thing is that the process might be scheduled to different 
> cpus between writing buffers and calling wbinvd ioctl. Since wbvind 
> only has local behavior, it requires the ioctl to call wbinvd on all
> cpus that this process has previously been scheduled on.

That is such a hassle, you may want to re-open this with the kvm
people as it seems ARM also has different behavior between VM and
process here.

The ideal is already not being met, so maybe we can keep special
casing cache ops?

> Is there any concern if iommufd also follows the same mechanism?
> Currently looks preempt notifier is only  used by kvm. Not sure whether
> there is strong criteria around using it. and this local behavior may
> not apply to all platforms (then better hidden behind arch callback?)

I don't have any desire to see a performance cost to implement an
ioctl that nothing will ever call just to satisify a idealized target
from the kvm folks..

Jason