From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Monday, December 9, 2024 12:20 PM > > On 12/7/2024 6:59 PM, Michael Kelley wrote: > > From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Friday, December 6, 2024 2:22 PM > >> > >> There are several bits of Hyper-V-related code that today live in > >> arch/x86 but are not really specific to x86_64 and will work on arm64 > >> too. > >> > >> Some of these will be needed in the upcoming mshv driver code (for > >> Linux as root partition on Hyper-V). > > > > Previously, Linux as the root partition on Hyper-V was x86 only, which is > > why the code is currently under arch/x86. So evidently the mshv driver > > is being expanded to support both x86 and arm64, correct? Assuming > > that's the case, I have some thoughts about how the source code should > > be organized and built. It's probably best to get this right to start with so > > it doesn't need to be changed again. > > Yes, we plan on supporting both architectures (eventually). I completely agree > that it's better to sort out these issues now rather than later. > > > > > * Patch 2 of this series moves hv_call_deposit_pages() and > > hv_call_create_vp() to common code, but does not move > > hv_call_add_logical_proc(). All three are used together, so > > I'm wondering why hv_call_add_logical_proc() isn't moved. > > > > The only reason is that in our internal tree there's no common or arm64 code > yet that uses it - there is no reason it can't also become common code! Maybe I'm missing your point, but hv_call_add_logical_proc() and hv_call_create_vp() are called in succession in hv_smp_prepare_cpus(), so it seems like they very much go together. Presumably a similar sequence will be needed on the arm64 side when running as the root partition? > > > * These three functions were originally put in a separate source > > code file because of being specific to running in the root partition, > > and not needed for generic Linux guest support. I think there's > > value in keeping them in a separate file, rather than merging them > > into hv_common.c. Maybe just move the entire hv_proc.c file? > > Agreed. I think it should be renamed too - this file will eventually > contain some additional hypercall helper functions, some of which may also be > shared by the driver code. Something like "hv_call_common.c"? I went back and looked at your patch series from a year ago [1], and got a better understanding of where this work is headed. I wanted to comment on that series back then, but got subsumed in wrapping things up for my retirement. :-( I see significant portions of that series have been posted independently and accepted, so my further comments here assume the rest of the series is still the macro-level approach you are taking.
