On Sun, Sep 10, 2023 at 06:33:50PM +1000, Jonathan Gray wrote: > 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. >
Agree 100%. > > - 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. >
