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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 8E8EBC761A1 for ; Thu, 20 Feb 2020 02:04:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E45321D56 for ; Thu, 20 Feb 2020 02:04:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E45321D56 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EA5026ECCC; Thu, 20 Feb 2020 02:04:46 +0000 (UTC) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 740186ECCB for ; Thu, 20 Feb 2020 02:04:45 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2020 18:04:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,462,1574150400"; d="scan'208";a="269405683" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 19 Feb 2020 18:04:44 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 19 Feb 2020 18:04:44 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 19 Feb 2020 18:04:40 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 19 Feb 2020 18:04:40 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.5]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.97]) with mapi id 14.03.0439.000; Thu, 20 Feb 2020 10:04:38 +0800 From: "Tian, Kevin" To: Chia-I Wu Subject: RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type Thread-Topic: [RFC PATCH 0/3] KVM: x86: honor guest memory type Thread-Index: AQHV4rTrI5AbOd4/PkCv4vZnvR6EuagZISQAgAAKbYCAAMs9AIAAnj+AgAAgCACAAAK0AIAAAeyAgAXrxoCAAaZGgIAAIIsAgADkwxA= Date: Thu, 20 Feb 2020 02:04:38 +0000 Message-ID: References: <20200213213036.207625-1-olvaffe@gmail.com> <8fdb85ea-6441-9519-ae35-eaf91ffe8741@redhat.com> <20200214195229.GF20690@linux.intel.com> <20200214220341.GJ20690@linux.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGI4Yzk2N2ItZDY1OS00Mjk1LThmNmItZmE0NzY3YzE4ZjdjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiT2huajlkdHd6eUd4UmFzbm5BTmZiQVwvNjBBR0VkY1dpQW1WNmpaNGlwQ2h4aFVUYzRibjBQRGhGS0ZYNEJvcEcifQ== dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wanpeng Li , ML dri-devel , kvm list , Joerg Roedel , "Christopherson, Sean J" , Gurchetan Singh , Gerd Hoffmann , Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > From: Chia-I Wu > Sent: Thursday, February 20, 2020 3:37 AM > > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote: > > > > > From: Paolo Bonzini > > > Sent: Wednesday, February 19, 2020 12:29 AM > > > > > > On 14/02/20 23:03, Sean Christopherson wrote: > > > >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote: > > > >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not > > > >>> verified, but svm_get_mt_mask returns 0 which supposedly means > the > > > NPT > > > >>> does not restrict what the guest PAT can do). This diff would do the > > > >>> trick for Intel without needing any uapi change: > > > >> I would be concerned about Intel CPU errata such as SKX40 and SKX59. > > > > The part KVM cares about, #MC, is already addressed by forcing UC for > > > MMIO. > > > > The data corruption issue is on the guest kernel to correctly use WC > > > > and/or non-temporal writes. > > > > > > What about coherency across live migration? The userspace process > would > > > use cached accesses, and also a WBINVD could potentially corrupt guest > > > memory. > > > > > > > In such case the userspace process possibly should conservatively use > > UC mapping, as if for MMIO regions on a passthrough device. However > > there remains a problem. the definition of KVM_MEM_DMA implies > > favoring guest setting, which could be whatever type in concept. Then > > assuming UC is also problematic. I'm not sure whether inventing another > > interface to query effective memory type from KVM is a good idea. There > > is no guarantee that the guest will use same type for every page in the > > same slot, then such interface might be messy. Alternatively, maybe > > we could just have an interface for KVM userspace to force memory type > > for a given slot, if it is mainly used in para-virtualized scenarios (e.g. > > virtio-gpu) where the guest is enlightened to use a forced type (e.g. WC)? > KVM forcing the memory type for a given slot should work too. But the > ignore-guest-pat bit seems to be Intel-specific. We will need to > define how the second-level page attributes combine with the guest > page attributes somehow. oh, I'm not aware of that difference. without an ipat-equivalent capability, I'm not sure how to forcing random type here. If you look at table 11-7 in Intel SDM, none of MTRR (EPT) memory type can lead to consistent effective type when combining with random PAT value. So it is definitely a dead end. > > KVM should in theory be able to tell that the userspace region is > mapped with a certain memory type and can force the same memory type > onto the guest. The userspace does not need to be involved. But that > sounds very slow? This may be a dumb question, but would it help to > add KVM_SET_DMA_BUF and let KVM negotiate the memory type with the > in-kernel GPU drivers? > > KVM_SET_DMA_BUF looks more reasonable. But I guess we don't need KVM to be aware of such negotiation. We can continue your original proposal to have KVM simply favor guest memory type (maybe still call KVM_MEM_DMA). On the other hand, Qemu should just mmap on the fd handle of the dmabuf passed from the virtio-gpu device backend, e.g. to conduct migration. That way the mmap request is finally served by DRM and underlying GPU drivers, with proper type enforced automatically. Thanks Kevin _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel