On Sun, Sep 10, 2023 at 03:48:34AM -0400, Solène Rapenne wrote: > In the GitHub thread, Andrew Cooper, a Xen developer reported that it's > a Xen and OpenBSD issue at the same time. I got the issue because of a > new Xen version, here is his answer: > > --- > > I'm fairly sure it was broken in Xen 4.15 by > https://lore.kernel.org/xen-devel/0c8043e3-07aa-6242-19bd-07b04f574...@suse.com/, > a series committed over my objections concerning the correctness of the > changes. > > It appears it was to shut up Linux, which makes different and equally dubious > model specific assumptions about the availability of certain MSRs. > > - It is buggy for Linux to declare TSCFREQSEL missing to be a firmware bug - > it may legitimately be so due to levelling. > - It's buggy for Xen to advertise the bit like that - because it's not > levelled and not part of the migration stream. > - It's buggy for OpenBSD to perform any model-specific checks without first > checking for !hypervisor.
Do any of the architecture documents state that model specific registers for a particular model are not implmented if the hypervisor bit is set? They claim to be a particular model but don't implement the msrs for that model. > - And it's probably buggy for Xen to state "TSC counts at the P0 frequency" > without giving the P0 frequency, but the jury is still out on this final > point because there's no possible way the guest is going to get to see Pstate > information.
