On Fri, Apr 03, 2026 at 03:54:52AM +0000, Anirudh Rayabharam wrote: > On Thu, Apr 02, 2026 at 10:57:09AM -0700, Stanislav Kinsburskii wrote: > > On Thu, Apr 02, 2026 at 04:33:24PM +0000, Anirudh Rayabharam wrote: > > > On Wed, Apr 01, 2026 at 10:12:40PM +0000, Stanislav Kinsburskii wrote: > > > > The mshv_mem_region structure represents guest address space regions, > > > > which can be either RAM-backed memory or memory-mapped IO regions > > > > without physical backing. The "mem_" prefix incorrectly suggests the > > > > structure only handles memory regions, creating confusion about its > > > > actual purpose. > > > > > > > > Remove the "mem_" prefix to align with existing function naming > > > > (mshv_region_map, mshv_region_pin, etc.) and accurately reflect that > > > > this structure manages arbitrary guest address space mappings > > > > regardless of their backing type. > > > > > > I don't think the "mem_" prefix automatically suggested the backing > > > type. > > > > > > > What else can it suggest? > > To me it just suggested that the struct contained info or properties of > a guest memory region. The name itself didn't suggest what backing type > the memory has. >
Right, that’s what the old name suggested to me too. And that’s the problem. It’s inaccurate for MMIO regions. They have nothing to do with memory. They are never backed by it. > > > > > Isn't mshv_region too vague now? Region of what? > > > > > > > The region of address space, which can or can not be backed by memory. > > Yeah but that's not obvious just from the new name. The new name just > says mshv_region and doesn't what the region is of. > I hear you, but what else can we do? Keeping mshv_mem_region isn’t good for the reasons above. Renaming it to `mshv_gpa_region` also feels redundant detailization. To me, this is a good tradeoff. Yes, it’s a bit too generic. But it’s concise, and we don’t have any other regions in the codebase. So I don’t think it will cause confusion. Thanks, Stanislav > Thanks, > Anirudh. > > > > > Thanks, > > Stanislav > > > > > Thanks, > > > Anirudh.
