[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/7] x86: detect PIC aliasing on ports other than 0x[2A][01]
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 30 Oct 2023 16:19:22 +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=RcBEXizaahuBBHyZND5VnUFmhl1MFtWBu49OgJMt4CA=; b=lchpqgFxDKVrkDcTo7VwOOYM/21IZrERfoRFqX3ldnF5Afp/C8agny+0xwersnKC2fV6kM7azCk+ZbStRgm639OeD5zmoANApkDvu2uC8w8wE/ISQUwiegOiovvQr1JT857y2/XAV5rw50DpDnErKLM0H3RflmZh8D+RErNwj1hHHa3yPsgczpt/QvEHit7I8ZQh7OziCWQp1df0WQskhYoFyYZa6A3flMnxEtQ22U/j/x4ApQ07E0872Lk5E6eS4wERwLsXXbeW72iXl5wxYIQ0uJ9Weu2IxxYP/vjqL95nrDE/G0pkzj7mFm7kUSDXqpBsYftXaaopcfL6PXK4JQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KtZ52NXFv2KrJ9JL8K4mEyyjVWvp5O+YbtQQzdK9wyu3ILSy6haY2oLQfwDISu2+JPhXoDoT0mTAslR3cpCU6sz/XH/N6J9Gt5nUvoXBZZ3LoGjZ+NMvOLocXJZNmBGeYn3T+AMne8aqI6wXI5nG8gY8Ky9H1PJngYN+XZxOwpAm0trevcYikemPTmuaTaVtsxqWvf+kev+ubiakNZq4XQQ/NiIi4aXgcXmTC4ITN6KfbcyfrN9WG5dKpy9hd8jRW4EEEw+4bS1zfihd5U3IdRSJf6qgWqCT7hKhQPsXP0Ixszc/lRyL2+pERTGOSKdOoo1XA+iGFFyno/zGxCPvxg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Mon, 30 Oct 2023 15:19:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 30.10.2023 16:14, Roger Pau Monné wrote:
> On Mon, Oct 30, 2023 at 01:24:52PM +0100, Jan Beulich wrote:
>> On 26.10.2023 17:19, Roger Pau Monné wrote:
>>> Maybe the issue is that PV_SHIM_EXCLUSIVE shouldn't have been a
>>> Kconfig option in the first place, and instead a specific Kconfig
>>> config file?
>>>
>>> Maybe it's not possible to achieve the same using just a Kconfig
>>> config file.
>>
>> I'm afraid I don't understand what you mean by "Kconfig config file". It
>> can't really be just another .../Kconfig file somewhere in the tree, as
>> it doesn't really matter where an option like this would be defined.
>
> No, I was thinking of splitting what PV_SHIM_EXCLUSIVE actually
> implies, for example by adding CONFIG_DOMCTL_HYPERCALLL or
> CONFIG_PLATFORM_HYPERCALL and re-work the pvshim_defconfig config file
> based on those, so that we don't end up with negative relations.
>
> Note sure all usages of PV_SHIM_EXCLUSIVE can be split in such a way,
> maybe we would need some compromise.
Wouldn't such a CONFIG_DOMCTL_HYPERCALL then still want to depend on
!PV_SHIM_EXCLUSIVE, which is the kind of dependency we want to avoid?
Aiui the two (splitting and inverting) are largely orthogonal aspects.
Jan
|
