Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1237665pxb; Fri, 13 Nov 2020 07:37:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJzhgCCOs+mJoitz7vjNtPnDild0geNlfTqSzLPM2KMoOZSh5JUH4Q+L0mL1RX2P6fzY0UEh X-Received: by 2002:a17:906:d784:: with SMTP id pj4mr2382717ejb.78.1605281856420; Fri, 13 Nov 2020 07:37:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605281856; cv=none; d=google.com; s=arc-20160816; b=blbzYHoMeq2q3KOcFrOKPnCKgiN3eHgI9qxRud9uHJfJDnq3aWloR+Ogi3ldIMY2yt ms7nzECk7y75I9yHUQJyKMPwH8M6n6/Vb+0iDfyMEFBI7GbL5TrOmMZpJrHfQbowPm01 XoTRVzbemVpBZEzWuUJupMMyzLO/2MVciYe6U+rqAEu1wqRMewSjuwyJyvLF8IVXmPf0 XxpWnfaWl6an2fPK82KJ7ICrWWPXo8R0SjRM0OY+a1qrDBwo3eFTAqFCqJvGJxGZYNgE jSNq/IR/o9AtHgpvne3fBrB1Rj6F2EcmFmIoJlxkDfkGLqd1VbRQsiMolCauCTVwp9X0 g85w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=gA1KPAigbuqo7QYg0x8mo1oWjdg2I5P+vvwNAb+YGgk=; b=PYbX6X6GUKAU6FlYj3Xo5ubEVtrH3v0o5AW0aADRQ69rHQzdyR8bMA0Xv7zal0OLHe 73nFhAfkD/tA+JMVkXn+I2R9FE3nW5WwJtm24EGtP3O2qKnH3FkzC6vKmucf70ghFDvV MI9cNrl6GRbeSdp2Z0wWY7/Uoj9G70JGCcFgOMjt8kUST/fSIpjfGfKNQ/2K/zBJp5hg 3nFI0eIrbdrd4UinlFuB6TWcs86Rjd/NeeKu3QjhWni3PRqxeegWbegzBOhml8jOO7OX rkavG31Djn+zFWwu3gv/9NY3BrcbobnTa6ScxJ6Bz5ckodfTvRnvgfMkrb1H85GYQg3r 23QQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i5si6575200edn.310.2020.11.13.07.37.11; Fri, 13 Nov 2020 07:37:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726787AbgKMPdp (ORCPT + 99 others); Fri, 13 Nov 2020 10:33:45 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:39529 "EHLO mail-wr1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726278AbgKMPdm (ORCPT ); Fri, 13 Nov 2020 10:33:42 -0500 Received: by mail-wr1-f54.google.com with SMTP id o15so10352764wru.6; Fri, 13 Nov 2020 07:33:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gA1KPAigbuqo7QYg0x8mo1oWjdg2I5P+vvwNAb+YGgk=; b=G4U4jHlz7TMLlFkPOc2QNZdfT5hrEfFy8FvDXPl/nQaP+FOSd9FF6ejN3/WRf6RpOH I+TfomP/4IrrYMkoQwGkeNvl3PtYZTu40zp0Pio5lXZWA3NC8rCBYfIrpwWSkq/9tRCs UsFFSdimMR/QiwzFZ8yI30Grem8HapAoBFeRhTUDNj4k7IwtGGNDWMs/l2eJvWMP/8Gu rLZ7ckR9CmhjTcJZZc0gJRCf9NK5UuwnN9yFpb5hsixlTHLOCX9eNbaRrXGmRmjiCSk2 ql/nZ8yLWi+j2PflQjIlT/JeRc2T9QPM7sM4bUFUNEmr7HqSVgC5ZtE7PRtpRMM81BhQ WU8g== X-Gm-Message-State: AOAM532SESo6quYJe42Aj5SINQCMQmBcDph8RZP37xZ8UmbHO1ib3VlE ysTZk25tB6JRGxFY15LDKC0= X-Received: by 2002:adf:8063:: with SMTP id 90mr4246564wrk.148.1605281615664; Fri, 13 Nov 2020 07:33:35 -0800 (PST) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id l16sm11234318wrx.5.2020.11.13.07.33.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Nov 2020 07:33:35 -0800 (PST) Date: Fri, 13 Nov 2020 15:33:33 +0000 From: Wei Liu To: Vitaly Kuznetsov Cc: Wei Liu , Linux on Hyper-V List , virtualization@lists.linux-foundation.org, Linux Kernel List , Michael Kelley , Vineeth Pillai , Sunil Muthuswamy , Nuno Das Neves , Lillian Grassin-Drake , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" Subject: Re: [PATCH v2 08/17] x86/hyperv: handling hypercall page setup for root Message-ID: <20201113153333.yt54enp5dbqjj5nu@liuwe-devbox-debian-v2> References: <20201105165814.29233-1-wei.liu@kernel.org> <20201105165814.29233-9-wei.liu@kernel.org> <874kluy3o2.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874kluy3o2.fsf@vitty.brq.redhat.com> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2020 at 04:51:09PM +0100, Vitaly Kuznetsov wrote: > Wei Liu writes: > > > When Linux is running as the root partition, the hypercall page will > > have already been setup by Hyper-V. Copy the content over to the > > allocated page. > > > > The suspend, resume and cleanup paths remain untouched because they are > > not supported in this setup yet. > > What about adding BUG_ONs there then? I generally avoid cluttering code if I'm sure it definitely does not work. In any case, adding BUG_ONs is not the right answer. Both hv_suspend and hv_resume can return an error code. I would rather just do if (hv_root_partition) return -EPERM; in both places. And also make hv_is_hibernation_supported return false when Linux is the root partition. > > + > > + if (hv_root_partition) { > > + struct page *pg; > > + void *src, *dst; > > + > > + /* > > + * For the root partition, the hypervisor will set up its > > + * hypercall page. The hypervisor guarantees it will not show > > + * up in the root's address space. The root can't change the > > + * location of the hypercall page. > > + * > > + * Order is important here. We must enable the hypercall page > > + * so it is populated with code, then copy the code to an > > + * executable page. > > + */ > > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > + > > + pg = vmalloc_to_page(hv_hypercall_pg); > > + dst = kmap(pg); > > + src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE, > > + MEMREMAP_WB); > > + BUG_ON(!(src && dst)); > > + memcpy(dst, src, PAGE_SIZE); > > Super-nit: while on x86 PAGE_SIZE always matches HV_HYP_PAGE_SIZE, would > it be more accurate to use the later here? Sure. That can be done. Wei.