From patchwork Tue Dec 1 08:53:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 336856 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, 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 6AB94C64E7A for ; Tue, 1 Dec 2020 09:06:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E71A421D7A for ; Tue, 1 Dec 2020 09:06:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="P7gJr6uF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388255AbgLAJF4 (ORCPT ); Tue, 1 Dec 2020 04:05:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:42320 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389063AbgLAJFR (ORCPT ); Tue, 1 Dec 2020 04:05:17 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 523F3221FF; Tue, 1 Dec 2020 09:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1606813476; bh=m2ecZMJCKQdHyauhAWtGasi2sL9Unt2Ri2KjJ9IgrH8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P7gJr6uFGXT0fmVLdlv3dGw/DVI3r465/r4O5b+vVE3FNAE0mBYYQga5fk1UnQUT6 76VRgJBoroLHp7JZjrSJKG6veYsv0cKQQdvCncCUChLNGK5E2yYjFv+R41tDZwbqvZ YeA+sMNibvAMZbkUtTyqOxSW9pXqa5MZSRnY0rSg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Boqun Feng , Dexuan Cui , Michael Kelley , Haiyang Zhang , Wei Liu , Sasha Levin Subject: [PATCH 5.4 52/98] video: hyperv_fb: Fix the cache type when mapping the VRAM Date: Tue, 1 Dec 2020 09:53:29 +0100 Message-Id: <20201201084657.651422493@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201201084652.827177826@linuxfoundation.org> References: <20201201084652.827177826@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dexuan Cui [ Upstream commit 5f1251a48c17b54939d7477305e39679a565382c ] x86 Hyper-V used to essentially always overwrite the effective cache type of guest memory accesses to WB. This was problematic in cases where there is a physical device assigned to the VM, since that often requires that the VM should have control over cache types. Thus, on newer Hyper-V since 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM users start to complain that Linux VM's VRAM becomes very slow, and it turns out that Linux VM should not map the VRAM uncacheable by ioremap(). Fix this slowness issue by using ioremap_cache(). On ARM64, ioremap_cache() is also required as the host also maps the VRAM cacheable, otherwise VM Connect can't display properly with ioremap() or ioremap_wc(). With this change, the VRAM on new Hyper-V is as fast as regular RAM, so it's no longer necessary to use the hacks we added to mitigate the slowness, i.e. we no longer need to allocate physical memory and use it to back up the VRAM in Generation-1 VM, and we also no longer need to allocate physical memory to back up the framebuffer in a Generation-2 VM and copy the framebuffer to the real VRAM. A further big change will address these for v5.11. Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver") Tested-by: Boqun Feng Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Reviewed-by: Haiyang Zhang Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin --- drivers/video/fbdev/hyperv_fb.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c index 2dcb7c58b31e1..81671272aa58f 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -703,7 +703,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info) goto err1; } - fb_virt = ioremap(par->mem->start, screen_fb_size); + /* + * Map the VRAM cacheable for performance. This is also required for + * VM Connect to display properly for ARM64 Linux VM, as the host also + * maps the VRAM cacheable. + */ + fb_virt = ioremap_cache(par->mem->start, screen_fb_size); if (!fb_virt) goto err2;