[{"id":3687138,"web_url":"http://patchwork.ozlabs.org/comment/3687138/","msgid":"","list_archive_url":null,"date":"2026-05-06T14:43:10","subject":"Re: [PATCH v2 0/7] target/i386/mshv: use hv_vp_register_page for\n fast register access","submitter":{"id":90753,"url":"http://patchwork.ozlabs.org/api/people/90753/","name":"Magnus Kulke","email":"magnuskulke@linux.microsoft.com"},"content":"On Tue, May 05, 2026 at 09:50:21PM +0300, Doru Blânzeanu wrote:\n> This series adds support for using the hypervisor's vp register page\n> in the mshv accelerator to optimize vcpu register access on mmio and pio\n> exits.\n> \n> Currently, all register reads and write go through hypercalls (ioctls),\n> which adds overhead on every VM exit. The VP register page is a shared\n> memory page that the hypervisor populates with vcpu register state,\n> allowing Qemu to read and write registers directly without hypercalls.\n> \n> The series is structured as follows:\n> 1. Remove the duplicate `fetch_guest_state` function, consolidating\n> register loading into `mshv_load_regs`.\n> 2. Move `mshv_arch_init_vcpu` after vcpu creation so the vcpu fd is\n> valid when we need it for mmap.\n> 3. Define the `hv_vp_register_page` structure in `hvgdk_mini.h`, matching\n> the layout used by the Linux kernel's mshv driver.\n> 4. Set up the register page by mmapping the vcpu fd at init time. If the\n> mmap fails, we fall back gracefully to the existing hypercall path.\n\nI think we don't have to fallback gracefully here. If the hypervisor\ndoesn't support the register page, it's likely that other assumption\ndon't hold either. I would suggest to abort here and relax that\nconstraint later, if we encounter a legit scenario where mmaping the\nregister page would fail.\n\n> 5. Use the register page to read registers on VM exit. General purpose\n> registers, RIP, RFLAGS, segment registers, and control registers\n> (CR0, CR4, CR4, CR8, EFER) are read directly from the page. Registers\n> not present on the page (TR, LDTR, GDTR, IDTR, CR2, APIC_BASE) are still\n> fetched via hypercall.\n> 6. Use register page to write registers on vmentry. GP registers,\n> RIP, and RFLAGS are written to the page with the appropriate dirty\n> bits set, avoiding the hypercall for the standard register store.\n> \n> The register page is only used when it has been successfully mmapped and\n> the hypervisor has marked it as valid (`isvalid != 0`). Otherwise, the\n> existing hypercall-based path is used as a fallback.\n> \n> Changes since v1:\n> - move hv_register_page struct definition to hvhdk.h\n> - add a compile time guard around regs_page in CPUArchState\n> - modify mshv_get_special_regs_vp_page to only retrieve the special\n> registers present in the register page (removed TR, LDTR, GDTR, IDTR,\n> CR2, APIC_BASE)\n> In local testing this hasn't created any regressions, and it is unlikely\n> that the mmio operations need this registers.\n> We'll want to keep an eye on this in case there are decoded operations\n> that rely on fetching these registers on every VM exit.\n> - add commit to fix handle_pio_non_str and handle_pio_str to correctly\n> store modified registers back to the register page after the pio\n> operation, and clear the cpu->accel->dirty flag to avoid the\n> mshv_arch_put_registers from resetting some registers state (fpu).\n> - modified register page setup to signal an error instead of a warning\n> in case mmap fails.\n> I am not sure aborting here is fine because it would make some of the\n> fallback logic redundant, and I think that's a bigger refactoring.\n> \n> Doru Blânzeanu (7):\n> target/i386/mshv: remove duplicate function for reading vcpu registers\n> accel/mshv: move vcpu arch specific initialization after vcpu creation\n> include/hw/hyperv: add hv_vp_register_page struct definition\n> target/i386/mshv: hv_vp_register_page setup for the vcpu\n> target/i386/mshv: use the register page to get registers\n> target/i386/mshv: use the register page to set registers\n> target/i386/mshv: fix pio handlers clobbering device-modified\n> registers\n> \n> accel/mshv/mshv-all.c | 3 +-\n> include/hw/hyperv/hvgdk.h | 2 +\n> include/hw/hyperv/hvhdk.h | 105 ++++++++++++++\n> target/i386/cpu.h | 5 +\n> target/i386/mshv/mshv-cpu.c | 269 ++++++++++++++++++++++++++++--------\n> 5 files changed, 327 insertions(+), 57 deletions(-)\n> \n> -- \n> 2.53.0","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.microsoft.com header.i=@linux.microsoft.com\n header.a=rsa-sha256 header.s=default header.b=aOMIC2HI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9dRq1zD0z1y04\n\tfor ; Thu, 07 May 2026 00:43:51 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wKdT6-0003Nh-Lh; Wed, 06 May 2026 10:43:20 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wKdT4-0003NL-3B\n for qemu-devel@nongnu.org; Wed, 06 May 2026 10:43:18 -0400","from linux.microsoft.com ([13.77.154.182])\n by eggs.gnu.org with esmtp (Exim 4.90_1)\n (envelope-from ) id 1wKdT2-0001pM-EA\n for qemu-devel@nongnu.org; Wed, 06 May 2026 10:43:17 -0400","from example.com (unknown [167.220.208.68])\n by linux.microsoft.com (Postfix) with ESMTPSA id E3CF920B7165;\n Wed, 6 May 2026 07:43:10 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.11.0 linux.microsoft.com E3CF920B7165","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;\n s=default; t=1778078592;\n bh=WtkjqwgRPIp+n7EAoPzJrvzmuuKuZz9AF4ANkZCiVA8=;\n h=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n b=aOMIC2HIY4O4uLAlSI6qoBSKwKjW7DMf9/EqOuVWz0tOA+1n3OzOUX9PIEGPHDypw\n +meV0DnhpDSLR0fusbFQy2LtzlJLZZaD4sioPQ+eBpMxAulC8cd6VCUFlFEXJ9lNEj\n AGdx6UxF7WILetfQGA7z/m57PO3CBgHij3Js7Ir4=","Date":"Wed, 6 May 2026 16:43:10 +0200","From":"Magnus Kulke ","To":"Doru =?iso-8859-1?q?Bl=E2nzeanu?= ","Cc":"qemu-devel@nongnu.org, Zhao Liu ,\n Wei Liu , Paolo Bonzini ","Subject":"Re: [PATCH v2 0/7] target/i386/mshv: use hv_vp_register_page for\n fast register access","Message-ID":"","References":"<20260505185028.237207-1-dblanzeanu@linux.microsoft.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260505185028.237207-1-dblanzeanu@linux.microsoft.com>","Received-SPF":"pass client-ip=13.77.154.182;\n envelope-from=magnuskulke@linux.microsoft.com; helo=linux.microsoft.com","X-Spam_score_int":"-19","X-Spam_score":"-2.0","X-Spam_bar":"--","X-Spam_report":"(-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]