[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86/livepatch: Fix livepatch application when CET is active
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 17 Apr 2023 16:51:42 +0200
- 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=jGs3nfNqAPwJY3bJq44yxmf503e25eaRRdy+jNP8/8c=; b=bpE2fPk8Aw8/zuJfy3AvFC1n9RBgdIp+eHSam6yQ7BOCFpXYEFD5tepKKjoJE1xPN966E0rdRZ4HoNySJ4qT92GvwLrxCaPJt+m3tNd60goZ4kS5hrysIGCvjjWGDs+j2LEJl4HA9ZqJ+t4/1Qk4ZJ22AF0kV8Q3Z849FuEx9OOlFR7g32Go0OC9vr8npyDTC2ysAkHGSFmoTwzfFI5zIW3JNYybEz/GJOpfkeUkUXH5LfBpqv/SPYsgmxxUQu+3+rIZmGv/tWrOUU9ai6zxsJd1TlIEG1Y9iTT0+QOGe9YsKW2yDNs2DNwB0RTml3NeQzvnua08neR7uJcpVldyxQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIjZL3qvVsJtwAESoND4tMX6wP+dVBa1qe1OFw7tF3+ioMTjnNE1Vw/2MIWv6G0rkpSrwM/09UOBeuuhpXSOkc5pKB7Rg1CDrYIRLswrIEY7oMoXsjzJdCfLLr46oL+FKOJ+DUjUBRPp++pHhPgiJIN/+2xhdvfZvEzieSXNsEU3QGMfYaqo/GGhugz/i1F6SsYT1HOLSfNuvemV+FgpGfpO5gR/OyxOd6jZCyJi3X6I/XSalT/L637Jn2nPKaGKvq45JC2PWGehpyir43L64jfsGF0BgX2pkd7Ycq0FcvQIxzYrHU45lg4XonCMJ3AAja+NMMD3YpGTPTGpRXD3aw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 17 Apr 2023 14:52:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 17.04.2023 16:41, Andrew Cooper wrote:
> On 17/04/2023 2:59 pm, Jan Beulich wrote:
>> On 17.04.2023 15:52, Andrew Cooper wrote:
>>> @@ -5879,6 +5880,73 @@ int destroy_xen_mappings(unsigned long s, unsigned
>>> long e)
>>> return modify_xen_mappings(s, e, _PAGE_NONE);
>>> }
>>>
>>> +/*
>>> + * Similar to modify_xen_mappings(), but used by the alternatives and
>>> + * livepatch in weird contexts. All synchronization, TLB flushing, etc is
>>> the
>>> + * responsibility of the caller, and *MUST* not be introduced here.
>>> + *
>>> + * Must be limited to XEN_VIRT_{START,END}, i.e. over l2_xenmap[].
>>> + * Must be called with present flags, and over present mappings.
>>> + * Must be called on leaf page boundaries.
>> This last sentence, while wording-wise correct, could do with making more
>> explicit that it is the caller's responsibility to know whether large page
>> mappings are in use, due to ...
>
> The meaning here is really "this doesn't shatter superpages", and this
> was the most concise I could come up with.
>
> Would ", i.e. won't shatter 2M pages." as a clarification work?
Yes, that would definitely help. Nevertheless I was more after something
like "..., i.e. for 2M mappings on 2M boundaries." Which, thinking about
it, points out that while you have a respective check for the start
address, the full 2M page would be changed even if the end address wasn't
2M aligned (but fell in the middle of a 2M page).
Jan
|