On 16.11.2022 02:19, Stefano Stabellini wrote: > On Fri, 28 Oct 2022, George Dunlap wrote: >> On Thu, Oct 27, 2022 at 8:12 AM Jan Beulich <[email protected]> wrote: >> On 26.10.2022 21:22, Andrew Cooper wrote: >> > On 26/10/2022 14:42, Jan Beulich wrote: >> >> >> > paging isn't a great name. While it's what we call the >> infrastructure >> > in x86, it has nothing to do with paging things out to disk (the >> thing >> > everyone associates the name with), nor the xenpaging infrastructure >> > (Xen's version of what OS paging supposedly means). >> >> Okay, "paging" can be somewhat misleading. But "p2m" also doesn't fit >> the use(s) on x86. Yet we'd like to use a name clearly better than the >> previous (and yet more wrong/misleading) "shadow". I have to admit that >> I can't think of any other sensible name, and among the ones discussed >> I still think "paging" is the one coming closest despite the >> generally different meaning of the word elsewhere. >> >> >> Inside the world of operating systems / hypervisors, "paging" has always >> meant "things related to a pagetable"; this includes "paging out >> to disk". In fact, the latter already has a perfectly good name -- "swap" >> (e.g., swap file, swappiness, hypervisor swap). >> >> Grep for "paging" inside of Xen. We have the paging lock, paging modes, >> nested paging, and so on. There's absolutely no reason to start >> thinking of "paging" as exclusively meaning "hypervisor swap". >> >> [ A bunch of stuff about using bytes as a unit size] >> >> > This is going to be a reoccurring theme through fixing the ABIs. Its >> > one of a several areas where there is objectively one right answer, >> both >> > in terms of ease of use, and compatibility to future circumstances. >> >> Well, I wouldn't say using whatever base granularity as a unit is >> "objectively" less right. >> >> >> Personally I don't think bytes or pages either have a particular advantage: >> >> * Using bytes >> - Advantage: Can always use the same number regardless of the underlying >> page size >> - Disadvantage: "Trap" where if you forget to check the page size, you >> might accidentally pass an invalid input. Or to put it >> differently, most "reasonable-looking" numbers are actually invalid (since >> most numbers aren't page-aligned)/ >> * Using pages >> - Advantage: No need to check page alignment in HV, no accidentally invalid >> input >> - Disadvantage: Caller must check page size and do a shift on every call >> >> What would personally tip me one way or the other is consistency with other >> hypercalls. If most of our hypercalls (or even most of our MM >> hypercalls) use bytes, then I'd lean towards bytes. Whereas if most of our >> hypercalls use pages, I'd lean towards pages. > > > Joining the discussion late to try to move things forward. > > Let me premise that I don't have a strong feeling either way, but I > think it would be clearer to use "bytes" instead of "pages" as argument. > The reason is that with pages you are never sure of the actual > granularity. Is it 4K? 16K? 64K? Especially considering that hypervisor > pages can be of different size than guest pages. In theory you could > have a situation where Xen uses 4K, Dom0 uses 16K and domU uses 64K, or > any combination of the three. With bytes, at least you know the actual > size. > > If we use "bytes" as argument, then it also makes sense not to use the > word "pages" in the hypercall name. > > That said, any name would work and both bytes and pages would work, so > I would leave it to the contributor who is doing the work to choose.
FAOD: There was no suggestion to use "pages" in the name; it was "paging" which was suggested. Jan
