Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7351439imu; Mon, 3 Dec 2018 11:26:27 -0800 (PST) X-Google-Smtp-Source: AFSGD/WWCI3dM2E9LiWEp3hZ18s10mTb+EMsZmJ9P1pjTHLrhideRMoOB4MWrFJXEGLdOAw9uvvE X-Received: by 2002:a17:902:9047:: with SMTP id w7mr17292055plz.270.1543865187281; Mon, 03 Dec 2018 11:26:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543865187; cv=none; d=google.com; s=arc-20160816; b=S4kVxk/ZLnOW+yQdMGiLKSaxgtxkDsiGcLvfpacjQoxGfZR2CI/c48AHfkwFMWymHz CbyAf8mYUudP16D3CdvjWcOnxMm+uwFzy8muTPBjIxRzU+pti/CgYU4aNrWvJWmhRITY kPowKaj7tIO7L4pjbcZIPjYEVHRO8GI1iQkzTb89E9hguOTCe9ITCVCkYgyDXR0YcfSs JpLY9yy4OUU8VUiMuh5ds5Zv//V0+tRKii3tkpeOqKFutlUzXIo+3LSMIii1iDp42D7G mOlE7BSI76IYZ8zLM/D7cXdNP17PDoprvozMjzzMgGJm0GtieKVSQv4T4PGRfmtRBgW6 Xotw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:date:cc:to:from:subject; bh=nkqXuF0ytvC3SApjipIZqEerutFLAk8vjd0jB+y1gf8=; b=V63Mdev3r+8OdCERZU+ocCx3uv0tvSLSIDu30z2BchMfyY+5omdZZRTS0X4wcyGJLU NBNt0kVscQTn3mdChka2hJ8aw8uhegEhKSAYgwRH2CTF+Si1iCLQE4D/aik+1HHWACzw eM/EsuvdlLYww30bkv4e9IKwx/kMC8T0qvFwNssoYNXHDa7Q0vJimKFymnS4GWQDfv4/ 0VyKoHlS5+m/qTVlVfVtLbebjCANL9M/uSPtHtwOKBndJ4laaZIzLkjiKy/wZG4gCxn/ S+lyf0YnIr2ortk9erek5UmrBegfvJUmkQOdEHdN7XfCn2u6dymLMF4pngZZZBfJ9KNg 1Tdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b186si15066231pfb.24.2018.12.03.11.26.12; Mon, 03 Dec 2018 11:26:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726041AbeLCTZ1 (ORCPT + 99 others); Mon, 3 Dec 2018 14:25:27 -0500 Received: from mga09.intel.com ([134.134.136.24]:12025 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725908AbeLCTZ0 (ORCPT ); Mon, 3 Dec 2018 14:25:26 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2018 11:25:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,311,1539673200"; d="scan'208";a="115600452" Received: from ahduyck-desk1.amr.corp.intel.com ([10.7.198.76]) by orsmga001.jf.intel.com with ESMTP; 03 Dec 2018 11:25:20 -0800 Subject: [PATCH RFC 0/3] Fix KVM misinterpreting Reserved page as an MMIO page From: Alexander Duyck To: dan.j.williams@intel.com, pbonzini@redhat.com, yi.z.zhang@linux.intel.com, brho@google.com, kvm@vger.kernel.org, linux-nvdimm@lists.01.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, dave.jiang@intel.com, yu.c.zhang@intel.com, pagupta@redhat.com, david@redhat.com, jack@suse.cz, hch@lst.de, rkrcmar@redhat.com, jglisse@redhat.com Date: Mon, 03 Dec 2018 11:25:20 -0800 Message-ID: <154386493754.27193.1300965403157243427.stgit@ahduyck-desk1.amr.corp.intel.com> User-Agent: StGit/unknown-version MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I have loosely based this patch series off of the following patch series from Zhang Yi: https://lore.kernel.org/lkml/cover.1536342881.git.yi.z.zhang@linux.intel.com The original set had attempted to address the fact that DAX pages were treated like MMIO pages which had resulted in reduced performance. It attempted to address this by ignoring the PageReserved flag if the page was either a DEV_DAX or FS_DAX page. I am proposing this as an alternative to that set. The main reason for this is because I believe there are a few issues that were overlooked with that original set. Specifically KVM seems to have two different uses for the PageReserved flag. One being whether or not we can pin the memory, the other being if we should be marking the pages as dirty or accessed. I believe only the pinning really applies so I have split the uses of kvm_is_reserved_pfn and updated the function uses to determine support for page pinning to include a check of the pgmap to see if it supports pinning. --- Alexander Duyck (3): kvm: Split use cases for kvm_is_reserved_pfn to kvm_is_refcounted_pfn mm: Add support for exposing if dev_pagemap supports refcount pinning kvm: Add additional check to determine if a page is refcounted arch/x86/kvm/mmu.c | 6 +++--- drivers/nvdimm/pfn_devs.c | 2 ++ include/linux/kvm_host.h | 2 +- include/linux/memremap.h | 5 ++++- include/linux/mm.h | 11 +++++++++++ virt/kvm/kvm_main.c | 34 +++++++++++++++++++++++++--------- 6 files changed, 46 insertions(+), 14 deletions(-) --