[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2.1 8/7] x86/IOMMU: Use altcall, and __initconst_cf_clobber
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 22 Feb 2022 12:04:58 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FvfCc6pd7XsMdZa6RKY+0prVe21M3C3KKFxAYVblUG0=; b=JeN43FGpmTqoitdLIbgNBgCYLLe9Ri0EaKDfmskqAF9pV7H8i6UTY4oaZ8l8VfULxDaqUKathaTjvTNYMicyyrUZ1EOBQyfSc43hzsOjdwrUsd6QxEJZAQdIhMhkB1BoqSZ3kxHaXjW0ZIdorcn3/bRGI7QPQxy1Q5KY9DNmP+iLYypVF1HtlqXRnWkNQDUsf+ObVSp4i0yQtotvjeHq3P9k9akYzHrqEJjSt4hQQHyyoNynNQ7A/KniF+e0wazms4MVGx6wclT/u2ICcEhCUKH2f7lHs3V9BIbCImRhVKNFZo09ZGMP92tZzPyaQ94T1apNywp7VG5BjFomD2cKdw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZxebqtGCwZHhaCYDD4lDUjJ0aiP4StSRUqIsKPP0/zkIajg6IMsgsYSMzbwTXGVwRLP4jLGCb7fWamRcKUrv+ZqhR8PhR0UnvzUFz2TU3amYMTs2EZZOFhKeuKOsoqz+hS9buHlylf5nTtS3f+LRcZUT6+IVsKBsAmABqkBb9t2oRVF30T+P/igNHVLQQ5D0/mZdp1ElXaFZyE4Q1ebIlFG+ET/yQIfS1fftkqwdu7MgtmowgnViPQPrryKl2MKJslLJcBk988BbkzZoT4Py+ZXlhpUFtH0KvL9SicZX/jhBy/f2xLtf9tUOzdRbw68N5Y31Wr/U2NeF4WB8PstfxA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 22 Feb 2022 11:05:07 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 22.02.2022 11:54, Andrew Cooper wrote:
> On 22/02/2022 09:29, Jan Beulich wrote:
>> On 21.02.2022 19:03, Andrew Cooper wrote:
>>> --- a/xen/drivers/passthrough/iommu.c
>>> +++ b/xen/drivers/passthrough/iommu.c
>>> @@ -540,7 +540,7 @@ int __init iommu_setup(void)
>>> int iommu_suspend()
>>> {
>>> if ( iommu_enabled )
>>> - return iommu_get_ops()->suspend();
>>> + return iommu_call(iommu_get_ops(), suspend);
>> This use of iommu_get_ops() in such constructs is a pattern we didn't
>> have so far. Perhaps it just looks bogus, and all is fine in reality
>> (apart from the whole idea being wrong for Arm, or really any
>> environment where multiple dissimilar IOMMUs may be in use). Or wait,
>> there are pre-existing cases (just not immediately visible when
>> grep-ing for "iommu_v?call") in iommu_get_reserved_device_memory() and
>> iommu_setup_hpet_msi().
>
> I think this means your happy(ish) with the change?
Yes. It looks a little odd, but since we have precedents this ought
to be fine.
Jan
|
