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 206AFC35DF0 for ; Tue, 25 Feb 2020 01:29:16 +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 EE6E62072D for ; Tue, 25 Feb 2020 01:29:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE6E62072D 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 F12EE6E9C9; Tue, 25 Feb 2020 01:29:14 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id A0EA76E9C9 for ; Tue, 25 Feb 2020 01:29:13 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2020 17:29:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,482,1574150400"; d="scan'208";a="241177888" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga006.jf.intel.com with ESMTP; 24 Feb 2020 17:29:12 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 24 Feb 2020 17:29:12 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 24 Feb 2020 17:29:11 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 24 Feb 2020 17:29:11 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.5]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.141]) with mapi id 14.03.0439.000; Tue, 25 Feb 2020 09:29:09 +0800 From: "Tian, Kevin" To: Chia-I Wu , "Christopherson, Sean J" 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+AgAAgCACAAAK0AIAAAeyAgAXrxoCAAaZGgIAAIIsAgADkwxCAABT4UIAAx02AgACimmD//8gUAIAAAZSAgACPE8CAACuogIAAJ5gAgAWxe0A= Date: Tue, 25 Feb 2020 01:29:09 +0000 Message-ID: References: <20200221155939.GG12665@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzU3OGNhOTQtMjAzNC00YzJmLWJjMDAtM2YxZDE1ZjAwM2M1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUkZ0TjZUamxMcU5ENHluMlp6TUM4ZDZmK1hpQ01yN2FiVU1hNVp6M1ROZlpvaVFxZ21JUFBWK0x4UkdwbTRLOCJ9 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 , kvm list , Joerg Roedel , ML dri-devel , 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: Saturday, February 22, 2020 2:21 AM > > On Fri, Feb 21, 2020 at 7:59 AM Sean Christopherson > wrote: > > > > On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote: > > > > From: Chia-I Wu > > > > Sent: Friday, February 21, 2020 12:51 PM > > > > If you think it is the best for KVM to inspect hva to determine the > memory > > > > type with page granularity, that is reasonable and should work for us > too. > > > > The userspace can do something (e.g., add a GPU driver dependency to > the > > > > hypervisor such that the dma-buf is imported as a GPU memory and > mapped > > > > using > > > > vkMapMemory) or I can work with dma-buf maintainers to see if dma- > buf's > > > > semantics can be changed. > > > > > > I think you need consider the live migration requirement as Paolo pointed > out. > > > The migration thread needs to read/write the region, then it must use the > > > same type as GPU process and guest to read/write the region. In such > case, > > > the hva mapped by Qemu should have the desired type as the guest. > However, > > > adding GPU driver dependency to Qemu might trigger some concern. I'm > not > > > sure whether there is generic mechanism though, to share dmabuf fd > between GPU > > > process and Qemu while allowing Qemu to follow the desired type w/o > using > > > vkMapMemory... > > > > Alternatively, KVM could make KVM_MEM_DMA and > KVM_MEM_LOG_DIRTY_PAGES > > mutually exclusive, i.e. force a transition to WB memtype for the guest > > (with appropriate zapping) when migration is activated. I think that > > would work? > Hm, virtio-gpu does not allow live migration when the 3D function > (virgl=on) is enabled. This is the relevant code in qemu: > > if (virtio_gpu_virgl_enabled(g->conf)) { > error_setg(&g->migration_blocker, "virgl is not yet migratable"); > > Although we (virtio-gpu and virglrenderer projects) plan to make host > GPU buffers available to the guest via memslots, those buffers should > be considered a part of the "GPU state". The migration thread should > work with virglrenderer and let virglrenderer save/restore them, if > live migration is to be supported. Thanks for your explanation. Your RFC makes more sense now. One remaining open is, although for live migration we can explicitly state that migration thread itself should not access the dma-buf region, how can we warn other usages which may potentially simply walk every memslot and access the content through the mmap-ed virtual address? Possibly we may need a flag to indicate a memslot which is mmaped only for KVM to retrieve its page table mapping but not for direct access in Qemu. > > QEMU depends on GPU drivers already when configured with > --enable-virglrenderer. There is vhost-user-gpu that can move the > dependency to a GPU process. But there are still going to be cases > (e.g., nVidia's proprietary driver does not support dma-buf) where > QEMU cannot avoid GPU driver dependency. > > > > > > > Note this is orthogonal to whether introducing a new uapi or implicitly > checking > > > hva to favor guest memory type. It's purely about Qemu itself. Ideally > anyone > > > with the desire to access a dma-buf object should follow the expected > semantics. > > > It's interesting that dma-buf sub-system doesn't provide a centralized > > > synchronization about memory type between multiple mmap paths. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel