On Tue, Sep 12, 2023 at 02:29:50AM +0000, Mike Larkin wrote: > 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. > > >
P.S. I replied to the qubes issue from Andrew.
