(fixed misspelled Cc: email address of intel-gfx list) On Friday, 2 June 2023 16:53:30 CEST Juergen Gross wrote: > On 02.06.23 16:48, Juergen Gross wrote: > > On 02.06.23 16:43, Borislav Petkov wrote: > >> On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: > >>> As described in the commit message, this only works on bare metal due to the > >>> PAT bit not being needed for WC mappings. > >>> > >>> Making this patch Xen specific would try to cure the symptoms without fixing > >>> the underlying problem: _PAGE_PAT should be regarded the same way as the bits > >>> for caching mode (_PAGE_CHG_MASK). > >> > >> So why isn't _PAGE_PAT part of _PAGE_CHG_MASK? > > > > This would result in problems for large pages: _PAGE_PSE is at the same > > position as _PAGE_PAT (large pages are using _PAGE_PAT_LARGE instead). > > > > Yes, x86 ABI is a mess. > > Oh, wait: I originally thought _PAGE_CHG_MASK would be used for large pages, > too. There is _HPAGE_CHG_MASK for that purpose. Since _HPAGE_CHG_MASK has the _PAGE_PSE aka _PAGE_PAT bit already set, while _PAGE_CHK_MASK has not, the real question is not about large pages processing, I believe, which won't change whether we add _PAGE_PAT to _PAGE_CHG_MASK or not. If we extend _PAGE_CHG_MASK with _PAGE_PAT bit then its value will be not any different from _HPAGE_CHG_MASK. Then, one may ask why _HPAGE_CHG_MASK, with _PAGE_PSE aka PAGE_PAT bit set unlike in _PAGE_CHG_MASK, was introduced once for use with large pages, and _PAGE_CHG_MASK left intact for use with standard pages, if we now think that adding that bit to _PAGE_CHG_MASK won't break processing of standard pages. If we are sure that adding _PAGE_PAT to _PAGE_CHG_MASK won't break any of its users then let's go for it. Thanks, Janusz > > So adding _PAGE_PAT to _PAGE_CHG_MASK and _PAGE_PAT_LARGE to _HPAGE_CHG_MASK > should do the job. At least I hope so. > > > Juergen >
