On 20.01.2023 19:15, Andrew Cooper wrote: > On 18/01/2023 9:55 am, Jan Beulich wrote: >> On 17.01.2023 23:04, Andrew Cooper wrote: >>> On 19/10/2022 8:43 am, Jan Beulich wrote: >>>> In preparation of the introduction of new vCPU operations allowing to >>>> register the respective areas (one of the two is x86-specific) by >>>> guest-physical address, flesh out the map/unmap functions. >>>> >>>> Noteworthy differences from map_vcpu_info(): >>>> - areas can be registered more than once (and de-registered), >>> When register by GFN is available, there is never a good reason to the >>> same area twice. >> Why not? Why shouldn't different entities be permitted to register their >> areas, one after the other? This at the very least requires a way to >> de-register. > > Because it's useless and extra complexity.
As to this: Looking at the code I think that I would actually add complexity (just a little - an extra check) to prevent re-registration. Things come out more naturally, from what I can tell, by allowing it. This can also be seen in "common: convert vCPU info area registration" where I'm actually adding such a (conditional) check to maintain the "no re-registration" property of the sub-op there. Granted there can be an argument towards making that check unconditional then ... Jan
