On 3/12/2025 11:19 PM, mhkelle...@gmail.com wrote: > From: Michael Kelley <mhkli...@outlook.com> > > Update hypercall call sites to use the new hv_hvcall_*() functions > to set up hypercall arguments. Since these functions zero the > fixed portion of input memory, remove now redundant calls to memset() > and explicit zero'ing of input fields. > > For hv_mark_gpa_visibility(), use the computed batch_size instead > of HV_MAX_MODIFY_GPA_REP_COUNT. Also update the associated gpa_page_list[] > field to have zero size, which is more consistent with other array > arguments to hypercalls. Due to the interaction with the calling > hv_vtom_set_host_visibility(), HV_MAX_MODIFY_GPA_REP_COUNT cannot be > completely eliminated without some further restructuring, but that's > for another patch set. > > Similarly, for the nested flush functions, update the gpa_list[] to > have zero size. Again, separate restructuring would be required to > completely eliminate the need for HV_MAX_FLUSH_REP_COUNT. > > Finally, hyperv_flush_tlb_others_ex() requires special handling > because the input consists of two arrays -- one for the hv_vp_set and > another for the gva list. The batch_size computed by hv_hvcall_in_array() > is adjusted to account for the number of entries in the hv_vp_set. > > Signed-off-by: Michael Kelley <mhkli...@outlook.com> > --- > > Notes: > Changes in v2: > * In hyperv_flush_tlb_others_ex(), added check of the adjusted > max_gvas to make sure it doesn't go to zero or negative, which would > happen if there is insufficient space to hold the hv_vpset and have > at least one entry in the gva list. Since an hv_vpset currently > represents a maximum of 4096 CPUs, the hv_vpset size does not exceed > 512 bytes and there should always be sufficent space. But do the > check just in case something changes. [Nuno Das Neves] > > arch/x86/hyperv/ivm.c | 18 +++++++++--------- > arch/x86/hyperv/mmu.c | 19 +++++-------------- > arch/x86/hyperv/nested.c | 14 +++++--------- > include/hyperv/hvgdk_mini.h | 4 ++-- > 4 files changed, 21 insertions(+), 34 deletions(-) >
Reviewed-by: Nuno Das Neves <nunodasne...@linux.microsoft.com>
