From: Wei Liu <wei.liu@kernel.org> To: Praveen Kumar <kumarpraveen@linux.microsoft.com> Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, viremana@linux.microsoft.com, sunilmut@microsoft.com, nunodasneves@linux.microsoft.com Subject: Re: [PATCH] hyperv: root partition faults writing to VP ASSIST MSR PAGE Date: Tue, 20 Jul 2021 11:20:11 +0000 [thread overview] Message-ID: <20210720112011.7nxhiy6iyz4gz3j5@liuwe-devbox-debian-v2> (raw) In-Reply-To: <20210719185126.3740-1-kumarpraveen@linux.microsoft.com> The commit message needs a bit of work. On Tue, Jul 20, 2021 at 12:21:26AM +0530, Praveen Kumar wrote: > The root partition is not supposed to write to VP ASSIST PAGE as this MSR > is specific to Guest VP, and thus below stack is observed. > Yes, root kernel is supposed to write to this MSR, but that's not because this MSR is specific to children (guest) partitions. It is just that for root this is read-only. You should mention VP assist pages for root are pre-determined by the hypervisor. Root kernel is not allowed to change them to different locations. > [ 2.778197] unchecked MSR access error: WRMSR to 0x40000073 (tried to write 0x0000000145ac5001) at rIP: 0xffffffff810c1084 (native_write_msr+0x4/0x30) > [ 2.784867] Call Trace: > [ 2.791507] hv_cpu_init+0xf1/0x1c0 > [ 2.798144] ? hyperv_report_panic+0xd0/0xd0 > [ 2.804806] cpuhp_invoke_callback+0x11a/0x440 > [ 2.811465] ? hv_resume+0x90/0x90 > [ 2.818137] cpuhp_issue_call+0x126/0x130 > [ 2.824782] __cpuhp_setup_state_cpuslocked+0x102/0x2b0 > [ 2.831427] ? hyperv_report_panic+0xd0/0xd0 > [ 2.838075] ? hyperv_report_panic+0xd0/0xd0 > [ 2.844723] ? hv_resume+0x90/0x90 > [ 2.851375] __cpuhp_setup_state+0x3d/0x90 > [ 2.858030] hyperv_init+0x14e/0x410 > [ 2.864689] ? enable_IR_x2apic+0x190/0x1a0 > [ 2.871349] apic_intr_mode_init+0x8b/0x100 > [ 2.878017] x86_late_time_init+0x20/0x30 > [ 2.884675] start_kernel+0x459/0x4fb > [ 2.891329] secondary_startup_64_no_verify+0xb0/0xbb > > Root partition actually shares the VP ASSIST page with hypervisor, and So do children partitions. This page is by design shared between hypervisor and any partitions that use it. > thus as a solution, this patch memremaps the memory from hypervisor > during hv_cpu_init and unmaps during hv_cpu_die calls. > > Further, this patch also resolve some error handling and checkpatch > errors > > Signed-off-by: Praveen Kumar <kumarpraveen@linux.microsoft.com> > --- > arch/x86/hyperv/hv_init.c | 57 +++++++++++++++++++++++++++------------ > 1 file changed, 40 insertions(+), 17 deletions(-) > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > index 6f247e7e07eb..292b17e0b173 100644 > --- a/arch/x86/hyperv/hv_init.c > +++ b/arch/x86/hyperv/hv_init.c > @@ -44,7 +44,7 @@ EXPORT_SYMBOL_GPL(hv_vp_assist_page); > > static int hv_cpu_init(unsigned int cpu) > { > - struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()]; > + struct hv_vp_assist_page **hvp = NULL; > int ret; > > ret = hv_common_cpu_init(cpu); > @@ -54,25 +54,43 @@ static int hv_cpu_init(unsigned int cpu) > if (!hv_vp_assist_page) > return 0; > > + hvp = &hv_vp_assist_page[smp_processor_id()]; > + Why is this needed? Is it because of checkpatch? > /* > - * The VP ASSIST PAGE is an "overlay" page (see Hyper-V TLFS's Section > - * 5.2.1 "GPA Overlay Pages"). Here it must be zeroed out to make sure > - * we always write the EOI MSR in hv_apic_eoi_write() *after* the > - * EOI optimization is disabled in hv_cpu_die(), otherwise a CPU may > - * not be stopped in the case of CPU offlining and the VM will hang. > + * For Root partition we need to map the hypervisor VP ASSIST PAGE > + * instead of allocating a new page. > */ > - if (!*hvp) { > - *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO); > - } This path suggests that it is possible to enter this function with *hvp already set. The new path for root is missing this check. > + if (hv_root_partition && > + ms_hyperv.features & HV_MSR_APIC_ACCESS_AVAILABLE) { Is HV_MSR_APIC_ACCESS_AVAILABLE a root only flag? Shouldn't non-root kernel check this too? Wei.
next prev parent reply other threads:[~2021-07-20 11:20 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 18:51 Praveen Kumar 2021-07-20 11:20 ` Wei Liu [this message] 2021-07-20 13:25 ` Praveen Kumar 2021-07-20 13:35 ` Wei Liu 2021-07-20 16:20 ` Michael Kelley 2021-07-20 16:29 ` Wei Liu 2021-07-21 4:10 ` Michael Kelley 2021-07-21 7:12 ` Praveen Kumar 2021-07-21 10:10 ` Wei Liu 2021-07-21 11:32 ` Praveen Kumar 2021-07-21 15:07 ` Michael Kelley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210720112011.7nxhiy6iyz4gz3j5@liuwe-devbox-debian-v2 \ --to=wei.liu@kernel.org \ --cc=bp@alien8.de \ --cc=decui@microsoft.com \ --cc=haiyangz@microsoft.com \ --cc=hpa@zytor.com \ --cc=kumarpraveen@linux.microsoft.com \ --cc=kys@microsoft.com \ --cc=linux-hyperv@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=nunodasneves@linux.microsoft.com \ --cc=sthemmin@microsoft.com \ --cc=sunilmut@microsoft.com \ --cc=tglx@linutronix.de \ --cc=viremana@linux.microsoft.com \ --cc=x86@kernel.org \ --subject='Re: [PATCH] hyperv: root partition faults writing to VP ASSIST MSR PAGE' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).