From: Roman Kisel <romank@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: hpa@zytor.com, kys@microsoft.com, bp@alien8.de,
dave.hansen@linux.intel.com, decui@microsoft.com,
eahariha@linux.microsoft.com, haiyangz@microsoft.com,
mingo@redhat.com, mhklinux@outlook.com,
nunodasneves@linux.microsoft.com, tglx@linutronix.de,
tiala@microsoft.com, wei.liu@kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, apais@microsoft.com, benhill@microsoft.com,
ssengar@microsoft.com, sunilmut@microsoft.com, vdso@hexbites.dev
Subject: Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the VTL mode
Date: Wed, 8 Jan 2025 12:37:17 -0800 [thread overview]
Message-ID: <95de0e7f-fb30-487e-820f-39d4e8c141cb@linux.microsoft.com> (raw)
In-Reply-To: <20250108191707.GA120@skinsburskii.>
On 1/8/2025 11:17 AM, Stanislav Kinsburskii wrote:
> On Tue, Jan 07, 2025 at 03:11:15PM -0800, Roman Kisel wrote:
[...]
>>
>> Avoiding using the output hypercall page leads to something like[1]
>> and it looks quite complicated although that's the bare bones, lots
>> of notes.
>>
>
> How is this related to the original discussion?
I was looking for ways to eliminate what I perceived as the source of
friction in the discussion -- allocating the hypercall output page.
> My concern was about the piece allocating of the output page guarded by
> the VTL config option.>> Thanks,
> Stas
>
>> [1]
>>
>> /*
>> * Fast extended hypercall with 20 bytes of input and 16 bytes of
>> * output for getting a VP register.
>> *
>> * NOTES:
>> * 1. The function is __init only atm, so the XMM context isn't
>> * used by the user mode.
>> * 2. X86_64 only.
>> * 3. Fast extended hypercalls may use XMM0..XMM6, and XMM is
>> * architerctural on X86_64 yet the support should be enabled
>> * in the CR's. Here, need RDX, R8 and XMM0 for input and RDX,
>> * R8 for output
>> * 4. No provisions for TDX and SEV-SNP for the sake of simplicity
>> * (the hypervisor cannot see the guest registers in the
>> * confidential VM), would need to fallback.
>> * 5. The robust implementation would need to check if fast extended
>> * hypercalls are available by checking the synthehtic CPUID leaves.
>> * A separate leaf indicates fast output support.
>> * It _almost_ certainly has to be, unless somehow disabled, hard
>> * to see why that would be needed.
>> */
>> struct hv_u128 {
>> u64 low_part;
>> u64 high_part;
>> } __packed;
>>
>> static __init u64 hv_vp_get_register_xfast(u32 reg_name,
>> struct hv_u128 *value)
>> {
>> u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS |
>> HV_HYPERCALL_FAST_BIT;
>> unsigned long flags;
>> u64 hv_status;
>>
>> union {
>> struct hv_get_vp_registers_input input;
>> struct {
>> u64 lo;
>> u64 hi;
>> } __packed as_u128;
>> } hv_input;
>> register u64 rdx asm("rdx");
>> register u64 r8 asm("r8");
>> register u64 r12 asm("r12");
>>
>> local_irq_save(flags);
>>
>> hv_input.as_u128.lo = hv_input.as_u128.hi = 0;
>> hv_input.input.header.partitionid = HV_PARTITION_ID_SELF;
>> hv_input.input.header.vpindex = HV_VP_INDEX_SELF;
>> hv_input.input.header.inputvtl = 0;
>>
>> rdx = hv_input.as_u128.lo;
>> r8 = hv_input.as_u128.hi;
>> r12 = reg_name;
>>
>> __asm__ __volatile__(
>> "subq $16, %%rsp\n"
>> "movups %%xmm0, 16(%%rsp)\n"
>> "movd %%r12, %%xmm0\n"
>> CALL_NOSPEC
>> "movups 16(%%rsp), %%xmm0\n"
>> "addq $16, %%rsp\n"
>> : "=a" (hv_status), ASM_CALL_CONSTRAINT,
>> "+c" (control), "+r" (rdx), "+r" (r8)
>> : THUNK_TARGET(hv_hypercall_pg), "r"(r12)
>> : "cc", "memory", "r9", "r10", "r11");
>>
>> if (hv_result_success(hv_status)) {
>> value->low_part = rdx;
>> value->high_part = r8;
>> }
>>
>> local_irq_restore(flags);
>> return hv_status;
>> }
>>
>> #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>> u8 __init get_vtl(void)
>> {
>> struct hv_u128 reg_value;
>> u64 ret = hv_vp_get_register_xfast(HV_REGISTER_VSM_VP_STATUS, ®_value);
>>
>> if (hv_result_success(ret)) {
>> ret = reg_value.low_part & HV_VTL_MASK;
>> } else {
>> pr_err("Failed to get VTL(error: %lld) exiting...\n", ret);
>> BUG();
>> }
>>
>> return ret;
>> }
>> #endif
>>
>>>
>>> Thanks,
>>> Stas
>>
>> --
>> Thank you,
>> Roman
>>
--
Thank you,
Roman
next prev parent reply other threads:[~2025-01-08 20:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 18:09 [PATCH v5 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id() Roman Kisel
2024-12-30 18:09 ` [PATCH v5 1/5] hyperv: Define struct hv_output_get_vp_registers Roman Kisel
2025-01-06 17:37 ` Michael Kelley
2025-01-06 20:24 ` Roman Kisel
2025-01-08 7:34 ` Wei Liu
2025-01-08 17:48 ` Roman Kisel
2025-01-08 17:58 ` Nuno Das Neves
2025-01-08 18:22 ` Michael Kelley
2025-01-08 18:29 ` Roman Kisel
2024-12-30 18:09 ` [PATCH v5 2/5] hyperv: Fix pointer type in get_vtl(void) Roman Kisel
2025-01-08 17:59 ` Nuno Das Neves
2024-12-30 18:09 ` [PATCH v5 3/5] hyperv: Enable the hypercall output page for the VTL mode Roman Kisel
2025-01-03 19:20 ` Stanislav Kinsburskii
2025-01-03 21:39 ` Roman Kisel
2025-01-06 17:11 ` Stanislav Kinsburskii
2025-01-06 18:11 ` Roman Kisel
2025-01-06 19:32 ` Stanislav Kinsburskii
2025-01-06 21:07 ` Roman Kisel
2025-01-07 19:18 ` Stanislav Kinsburskii
2025-01-07 23:11 ` Roman Kisel
2025-01-08 8:04 ` Wei Liu
2025-01-08 19:17 ` Stanislav Kinsburskii
2025-01-08 20:37 ` Roman Kisel [this message]
2025-01-08 22:19 ` Stanislav Kinsburskii
2025-01-08 23:04 ` Roman Kisel
2025-01-03 22:08 ` Michael Kelley
[not found] ` <CAJ-90NKKfF-KcWJ7sdMCXK9fWiXwMG-9xtjQn9fVhXgjRinZbA@mail.gmail.com>
2025-01-06 14:53 ` Alex Ionescu
2025-01-06 16:10 ` Michael Kelley
2025-01-06 17:23 ` Stanislav Kinsburskii
2025-01-06 18:18 ` Michael Kelley
2025-01-06 19:19 ` Stanislav Kinsburskii
2025-01-06 19:49 ` Michael Kelley
2025-01-06 21:12 ` Stanislav Kinsburskii
2025-01-08 21:08 ` Nuno Das Neves
2025-01-08 21:22 ` Roman Kisel
2024-12-30 18:09 ` [PATCH v5 4/5] hyperv: Do not overlap the hvcall IO areas in get_vtl() Roman Kisel
2025-01-08 7:36 ` Wei Liu
2025-01-08 17:47 ` Roman Kisel
2024-12-30 18:09 ` [PATCH v5 5/5] hyperv: Do not overlap the hvcall IO areas in hv_vtl_apicid_to_vp_id() Roman Kisel
2024-12-30 18:16 ` [PATCH v5 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id() Borislav Petkov
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=95de0e7f-fb30-487e-820f-39d4e8c141cb@linux.microsoft.com \
--to=romank@linux.microsoft.com \
--cc=apais@microsoft.com \
--cc=benhill@microsoft.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=eahariha@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=nunodasneves@linux.microsoft.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tglx@linutronix.de \
--cc=tiala@microsoft.com \
--cc=vdso@hexbites.dev \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).