On Tue, Jan 07, 2025 at 03:11:15PM -0800, Roman Kisel wrote: > > > On 1/7/2025 11:18 AM, Stanislav Kinsburskii wrote: > > On Mon, Jan 06, 2025 at 01:07:25PM -0800, Roman Kisel wrote: > > > > [...] > > > My point is that the proposed fix looks more like an Underhill-tailored > > bandage and doesn't take the needs of other stake holders into > > consideration. > The patch takes as much into consideration as present in the hyperv-next > tree. Working on the open-source project seems to be harder otherwise. > A bandage, or not, that's a matter of opinion. There's a been a break, > here's the bandage. > > > > > What is the urgency in merging of this particular change? > > The get_vtl function is broken thus blocking any further work on > upstreaming VTL mode patches, ARM64 and more. That's not an urgent > urgency where customers are in pain, more like the urgency of needing > to take the trash out, and until that happens, continuing inhaling the > fumes. > > The urgency of unblocking is to continue work on proposing VTL mode > patches not to carry lots of out-of-tree code in the fork. > > There might be a future where the Hyper-V code offers an API surface > covering needs of consumers like dom0 and VTLs whereby they maybe can > be built as an out-of-tree modules so the opinions wouldn't clash as > much. > > 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. > > [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. I am not worried about this point. There are architectural defined ways to handle this. > * 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. > */ The rest I agree. Not worth the effort just to add that support here for a single user. I've been thinking about adding the extended hypercall support for a while, but I'm not sure if it's worth the effort overall. An aspiring developer who's interested in this area is building a prototype to see if extended fast hypercall can give a boost to some of the frequent hypercalls. In any case, I think this patch is fine. Thanks, Wei.
