From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DATE_IN_FUTURE_06_12, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C623C5CFE7 for ; Tue, 10 Jul 2018 08:23:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CAED42083B for ; Tue, 10 Jul 2018 08:23:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAED42083B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933229AbeGJIXI (ORCPT ); Tue, 10 Jul 2018 04:23:08 -0400 Received: from mga11.intel.com ([192.55.52.93]:7794 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbeGJIXE (ORCPT ); Tue, 10 Jul 2018 04:23:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 01:23:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,333,1526367600"; d="scan'208";a="71491554" Received: from linux.intel.com ([10.54.29.200]) by orsmga001.jf.intel.com with ESMTP; 10 Jul 2018 01:23:03 -0700 Received: from dazhang1-ssd.sh.intel.com (unknown [10.239.48.78]) by linux.intel.com (Postfix) with ESMTP id 3E49B580388; Tue, 10 Jul 2018 01:23:02 -0700 (PDT) From: Zhang Yi To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, pbonzini@redhat.com, dan.j.williams@intel.com, jack@suse.cz, hch@lst.de, yu.c.zhang@intel.com Cc: linux-mm@kvack.org, rkrcmar@redhat.com, yi.z.zhang@intel.com, Zhang Yi Subject: [PATCH V2 0/4] Fix kvm misconceives NVDIMM pages as reserved mmio Date: Wed, 11 Jul 2018 01:01:25 +0800 Message-Id: X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For device specific memory space, when we move these area of pfn to memory zone, we will set the page reserved flag at that time, some of these reserved for device mmio, and some of these are not, such as NVDIMM pmem. Now, we map these dev_dax or fs_dax pages to kvm for DIMM/NVDIMM backend, since these pages are reserved. the check of kvm_is_reserved_pfn() misconceives those pages as MMIO. Therefor, we introduce 2 page map types, MEMORY_DEVICE_FS_DAX/MEMORY_DEVICE_DEV_DAX, to indentify these pages are from NVDIMM pmem. and let kvm treat these as normal pages. Without this patch, Many operations will be missed due to this mistreatment to pmem pages. For example, a page may not have chance to be unpinned for KVM guest(in kvm_release_pfn_clean); not able to be marked as dirty/accessed(in kvm_set_pfn_dirty/accessed) etc. V1: https://lkml.org/lkml/2018/7/4/91 V2: *Add documentation for MEMORY_DEVICE_DEV_DAX memory type in comment block *Add is_dax_page() in mm.h to differentiate the pages is from DAX device. *Remove the function kvm_is_nd_pfn(). Zhang Yi (4): kvm: remove redundant reserved page check mm: introduce memory type MEMORY_DEVICE_DEV_DAX mm: add a function to differentiate the pages is from DAX device memory kvm: add a check if pfn is from NVDIMM pmem. drivers/dax/pmem.c | 1 + include/linux/memremap.h | 9 +++++++++ include/linux/mm.h | 12 ++++++++++++ virt/kvm/kvm_main.c | 16 ++++++++-------- 4 files changed, 30 insertions(+), 8 deletions(-) -- 2.7.4