RE: [PATCH 2/2] hyperv: Do not overlap the input and output hypercall areas in get_vtl(void)

[Michael Kelley]

From: Roman Kisel <romank@xxxxxxxxxxxxxxxxxxx> Sent: Thursday, December 26, 2024 8:46 AM
> 
> On 12/24/2024 8:45 AM, Michael Kelley wrote:
> 
> [...]
> 
> >
> > OK, my understanding is that your concern about spec conformance is
> > just that Linux should be able to allocate enough input and output space
> > for the maximum case, which is 4KiB of input *plus* 4KiB of output. If
> > the total amount of input plus output for a particular hypercall is less
> > than 4KiB, then there's no conformance problem with having the input
> > and output share a page, as long as the "no overlap" rule is observed.
> >
> Appreciate bearing with me and guiding me towards expressing the intent
> clearer :) Yes, the logic chain has been:
> 
> * can't overlap input and output due to TLFS req's =>
> * need to fix get_vtl() *&&* dom0 uses the output page *&&* VTLs use
>    the output page =>
> * let us fix the overlap *&&* make get_vtl() look as get_vp_register()
>    as this is what it actually is so soon we should be able to have less
>    code.
> 
> Getting rid of the hypercall output page feels like too much as if the
> code base is dovetailed to that and the hypervisor gets a hypercall
> whose output is as large as a page (however unlikely that sounds, but
> first there was an opinion that 640KiB is plenty, then 32 address lines,
> then 48 bits in the PA and 4 level pages, then 57 bits and 5 levels,
> ...), we'd need to fix the code or allocate and deallocate on demand.
> That tradeoff b/w saving a page and adding special cases makes me lean
> to just allocate the page as it is allocated anyway.
> 
> > There's an idea kicking around in my head about a different way to
> > handle all this that might be cleaner and less code all-around. If I
> > get motivated, I may code it up and see if it really works. If so,
> > I'll run it by you to see what you think.
> MUCH appreciated!! The complexity appears to be increasing over time,
> and it would be incredible to pack all we got into less code without
> constraining ourselves too much :)
> 

As I was looking at how hypercall input and output arguments are
managed in upstream code and in the OHCL-Linux-Kernel repo,
I noticed two things:

1) There's a bug in mshv_vtl_hvcall_call() in the OHCL-Linux-Kernel
repo, for which I filed a github issue. [1]

2) hv_vtl_apicid_to_vp_id() also has the overlapping hypercall input
and output spec violation. You might want to fix that occurrence as
well in this patch set.

Michael

[1] https://github.com/microsoft/OHCL-Linux-Kernel/issues/33