lkml.org 
[lkml]   [2023]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v2 5/6] x86/hyperv: Support hypercalls for TDX guests
Date
> From: Zhi Wang <zhi.wang.linux@gmail.com>
> Sent: Friday, January 6, 2023 3:24 AM
> > @@ -83,6 +94,9 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64
> > input1) u64 hv_status, control = (u64)code | HV_HYPERCALL_FAST_BIT;
> >
> > #ifdef CONFIG_X86_64
> > + if (hv_isolation_type_tdx())
> > + return hv_tdx_hypercall(control, input1, 0);
> > +
> > {
> > __asm__ __volatile__(CALL_NOSPEC
> > : "=a" (hv_status),
> > ASM_CALL_CONSTRAINT, @@ -114,6 +128,9 @@ static inline u64
> > hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2) u64 hv_status,
> > control = (u64)code | HV_HYPERCALL_FAST_BIT;
> > #ifdef CONFIG_X86_64
> > + if (hv_isolation_type_tdx())
> > + return hv_tdx_hypercall(control, input1, input2);
> > +
> In some paths, for example vmbus_set_event(), choosing the SNP-based or

In a SNP guest with pavavisor on Hyper-V, hv_ghcb_hypercall() is called in
only two places: vmbus_set_event() and hv_post_message(), where the
hypercalls, which are done via GHCB, need to be handled by the Hyper-V
hypervisor directly; in other places, the hypercalls, which are done via the
hypercall page, need to be handled by the pavavisor. That's to say, there
are 2 different kinds of hypercalls for a SNP guest with pavavisor on Hyper-V,
and hence we have to use 2 styles.

> generic hypercall happens in the caller, while now TDX-based hypercall is
> embraced in the generic hypercall path, e.g. hv_do_fast_hypercall8(). Which
> style will be chosen in the future? Seems the coding structure needs to be
> aligned.

For a TDX guest without pavavisor on Hyper-V, there is only one style of
hypercalls, so I make the change in hv_do_hypercall() and
hv_do_fast_hypercall*() directly.

I don't think we can make any clean-up changes right now. When we
support the TDX guest with pavavisor on Hyper-V, we'll figure out if we
can make any improvement.

> void vmbus_set_event(struct vmbus_channel *channel)
> {
> u32 child_relid = channel->offermsg.child_relid;
>
> if (!channel->is_dedicated_interrupt)
> vmbus_send_interrupt(child_relid);
>
> ++channel->sig_events;
>
> if (hv_isolation_type_snp())
> hv_ghcb_hypercall(HVCALL_SIGNAL_EVENT,
> &channel->sig_event,
> NULL, sizeof(channel->sig_event));
> else
> hv_do_fast_hypercall8(HVCALL_SIGNAL_EVENT,
> channel->sig_event);
> }
>
>
> > {
> > __asm__ __volatile__("mov %4, %%r8\n"
> > CALL_NOSPEC

\
 
 \ /
  Last update: 2023-03-26 23:32    [W:0.073 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site