[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sh_unshadow_for_p2m_change() vs p2m_set_entry()
- To: Tim Deegan <tim@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 1 Oct 2021 13:37:10 +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=COHAO2ioaNtZiSiI2FN60iFBiB2A1fK4DC2JbR5HJUI=; b=L/airL83yfv7ZKlwyiX3SqpHOyfVtvqQNA1sd5zxRNlDSYWidhWxqnGBiwsRjXE9otNxggzO3z/Dp3cL1BhWPho7NFderNuC5vZqMGlCFhPCM9ZiJyZ6qERfdmx4ueq/kkSrYi8cEEpTk5dJu5hu7v1HimmNJ+ncVTtv694zLnnaPu4syAymY3muqVp8h/wvrrtsFNzf6q8De07P//zwdY168Vn/BaoMHxLu/D9doKN7+u1Cvu/NNy7AhpvubajMBFLPcza7xJ2b1xjA26SB4rSi9oRPMfLOjgdjNvzdEuH2K5iSyzvIW9z03csX+gFB41KYd6up7TzkH7siARMb0Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SwZFwwcav57pb8g3x+UgIXOPOLGtjJxTodXIk44S4jYn9lLxe14D+lzVesOY8LjnQOdSs73Zha3fblASlEZj1XU3srvkmsByNrqyVkJ2oSVoe33m/rrDvdCGXptGIpOCItdKFu1lHP/t+tznfMzTZksyqX1aBbZ3Nj5pbBsdj1cb4cCT+RIslyOjexV6nr41xYtJNZpHxci3jnzY6YCY5jyd285OOlImjCwoqpxzE9Vrq9DiVsJiPsfvBRTIbwRtnDt22piS/K3n/XT9OofC3GlxAHKQkIQNe2SABXnv/s120Zpqv7aAfuqAefpObIfq/Xu3GZnIM39mZI6tPUp9Gw==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 01 Oct 2021 11:37:21 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 01.10.2021 13:22, Tim Deegan wrote:
> At 07:59 +0200 on 01 Oct (1633075173), Jan Beulich wrote:
>> On 27.09.2021 22:25, Tim Deegan wrote:
>>> At 13:31 +0200 on 24 Sep (1632490304), Jan Beulich wrote:
>>>> The 2M logic also first checks _PAGE_PRESENT (and _PAGE_PSE), while
>>>> the 4k logic appears to infer that the old page was present from
>>>> p2m_is_{valid,grant}().
>>>
>>> I think the p2m_type check is the right one (rather than
>>> _PAGE_PRESENT), since that's the one that the p2m lookups will obey
>>> when causing things to get shadowed. But the extra _PAGE_PSE check
>>> should stay.
>>
>> Actually, having transformed things into patch form, I'm now puzzled
>> by you explicitly saying this. Wasn't this check wrong in the first
>> place? I don't see anything preventing an L1 page table getting
>> zapped (or replaced by a 2M mapping) all in one go.
>
> ISTR that this couldn't happen, but I don't remember exactly exactly
> why. It may just be that the p2m update code didn't have that path,
> but it's a bit fragile to rely on that.
I'm guessing that this is what the vague "potential errors when hap is
disabled" may have been referring to in that pretty old commit that I
had dug out.
Jan
|
