On 27.06.2024 14:02, Alejandro Vallejo wrote: > On Thu Jun 27, 2024 at 10:42 AM BST, Jan Beulich wrote: >> Plus what about a guest which was configured to have the CPUID bit for MTRRs >> clear? >> I think we ought to document this as not supported for PVH (we may > > By "this" do you mean PVH _must_ have MTRR support? I would agree.
That was my first thought, yes. But then further down I adjusted my considerations. >> actually choose to refuse building such a guest), but in principle the MTRR >> save/load operations should simply fail for a HVM guest in said >> configuration. > > What use cases does that cover? With the adjustment I mention at the top that > should be sorted. I'm wondering why we allow !mtrr at all. Not allowing it would open up for a mess in what CPUID bits we allow to override and for which ones we'd deny overrides. >> Making such a change in Xen now would, afaict, be benign to the tool stack. >> After this adjustment it would result in a perceived regression, when there >> shouldn't be any. > > Fair point. > >> >> Thinking about it, even for PVH it may make sense to allow CPUID.MTRR=0, as >> long as CPUID.PAT=1, thus forcing it into PAT-only mode. I think we did even >> discuss this possible configuration before. > > Is PAT-only an existing real HW configuration? Can't say I've seen any. I don't think there are any, but the architecture doesn't preclude it, and that's a simpler model overall for an OS to work with. Hence why it was discussed (to some degree) before (if my memory doesn't fail me there). Jan
