[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 2/2] x86/shadow: further correct MMIO handling in _sh_propagate()
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 13 Jan 2023 09:48:16 +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=B1oV9eOFNOGvXVgiJ+rg0AtuPcAmRh13n0oNq2fBO88=; b=gzlbZV3WLme3h01AW50G8U8F+xefSLtdQ0MLEzqpSS6rFMPnzUpnNkpaJqP+YTTt8AOYfe5pEHWRRdMCQoe4xhphKSq769vaxAjYpxAOMhWz+xN0YMyY5e6yxPA18qbsBiiv6X+s+dqKbBtzAkHtvw48M6cWzTZhBgb1z76hXxwvAsWfo12ab4+lU22/kqr+cGCBczBY48zJeaMjroAAvYsP2dQ0zB7rSrhlwfksyLdxYRprW9DlLuBCWlnVEYyaDuJm7Qs0yWRGE8wR0MGLFgKIGOCvPNmDDUmixQlNz37dw9GDa/jrJsx25AENhYFractcly3jOK7ixZDCQwvzaA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mar/jKBke6h4QjhUVgZt3oODFDBI5NYhVJ3TDpb5JhxVcLCKC3rkAxBnephlL8G2RJqqtreyJDgWvWPJkF8JW6foWKwS7PvV+EPgNCt+1eBmQTXhVviwO5RrYVDDAjNK5JXGm/KfYmp4nxAz069sWbeMtY0dYS/Z/4UrC/KJgOMZuLiS5Qo6GjxaQUTn29vIgc9H2sZ8jDDR+Wv6fLrPvqi0RflyYDZlwajIcFkd2iTpTNmt5cozMc15MixvZsWCUO7wE/4/2oZFULtj+SMV8HIdcMcfClRxnpohM3bEbniavHIoNAjkWhU6394O6UJ7fFzrxUaacJEwfCGWJRL67g==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
- Delivery-date: Fri, 13 Jan 2023 08:48:22 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
While c61a6f74f80e ("x86: enforce consistent cachability of MMIO
mappings") correctly converted one !mfn_valid() check there, two others
were wrongly left untouched: Both cachability control and log-dirty
tracking ought to be uniformly handled/excluded for all (non-)MMIO
ranges, not just ones qualifiable by mfn_valid().
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Note that this is orthogonal to there looking to be plans to undo other
aspects of said commit (XSA-154).
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -543,8 +543,7 @@ _sh_propagate(struct vcpu *v,
* caching attributes in the shadows to match what was asked for.
*/
if ( (level == 1) && is_hvm_domain(d) &&
- (!mfn_valid(target_mfn) ||
- !is_special_page(mfn_to_page(target_mfn))) )
+ (mmio_mfn || !is_special_page(mfn_to_page(target_mfn))) )
{
int type;
@@ -655,8 +654,7 @@ _sh_propagate(struct vcpu *v,
* (We handle log-dirty entirely inside the shadow code, without using the
* p2m_ram_logdirty p2m type: only HAP uses that.)
*/
- if ( level == 1 && unlikely(shadow_mode_log_dirty(d)) &&
- mfn_valid(target_mfn) )
+ if ( level == 1 && unlikely(shadow_mode_log_dirty(d)) && !mmio_mfn )
{
if ( ft & FETCH_TYPE_WRITE )
paging_mark_dirty(d, target_mfn);
|
