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=-5.5 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E7B8CC63697 for ; Fri, 13 Nov 2020 15:36:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC596208D5 for ; Fri, 13 Nov 2020 15:36:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726821AbgKMPdp (ORCPT ); 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-Google-Smtp-Source: ABdhPJzgHnYfKEQTelHs6ytElg4q8ljn/Vvj5EyLvy05cwv1SGzrFPy8D7LeJSA+015V0MjREJKZPw== 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.