On 25.09.2023 12:01, Andrew Cooper wrote: > On 25/09/2023 10:46 am, Roger Pau Monné wrote: >> On Mon, Sep 25, 2023 at 08:36:03AM +0200, Jan Beulich wrote: >>> On 22.09.2023 22:03, Andrew Cooper wrote: >>>> On 08/08/2023 2:02 pm, Alejandro Vallejo wrote: >>>>> --- a/xen/common/Kconfig >>>>> +++ b/xen/common/Kconfig >>>>> @@ -23,6 +23,16 @@ config GRANT_TABLE >>>>> >>>>> If unsure, say Y. >>>>> >>>>> +config PDX_COMPRESSION >>>>> + bool "PDX (Page inDeX) compression support" if EXPERT >>>> This still needs hiding on x86. The minimal hack for 4.18 is "if EXPERT >>>> && !X86". >>> If you insist on complete hiding and I insist on allowing it to be used by >>> people who want to play with exotic hardware, then this won't go anywhere. >>> I think I've come far enough with accepting a compromise, and so I think >>> it's your turn now to also take a step from your original position. >> Just because I'm not familiar with this, is there any x86 hardware >> that has such sparse memory map that would benefit from PDX? > > There is one known system which never shipped. Xen's implementation was > from the anticipation of that system shipping. Nothing else known. > > None of the other major kernels have facilities such as this, which is > very likely a contributory factor to the system not shipping.
Possibly, yet there's one important difference (mentioned before): VA space that Xen can use (for directmap and frame_table[]) is far more constrained than for baremetal systems (Linux, Windows). Hence the guys who got in touch back at the time were not in need of Linux side changes at all (as far as I was told back then). Jan
