* Jozef Hatala <jh-openbsd-t...@skrt.org> [2020-11-29 00:32:17 -0800]:

On Sun, Nov 29, 2020 at 12:04:04AM -0800, I wrote:
On Sun, Nov 29, 2020 at 06:36:17AM +0000, Mike wrote:
> And what are you going to return for the other leaf nodes now that
> you are claiming a CPUID level of 0x15, on CPUs that are less than
> that?
>
> Eg, if your host supports level 0xb (11), what happens in your diff
> if the guest VM requests CPUID leaf node 0x0c (12)?
>
> It seems you are only handing the single 0x15 case.

That is true.

We need to note though that the current situation is not correct either.
[...]
What do you suggest?

Two ideas spring to mind for how to resolve this:

(a) Figure out from Intel's documentation for each leaf (and sub-leaf)
what response is correct and does not require us to emulate too much.

(b) Add a sysctl knob that controls whether we even announce a higher
cpu level to the guest than what the host supports, so that we do not
expose people to the incorrectness by default.

What do you think?

jh


Hi Jozef,

I don't see Mike's replies but can you try Dave's linux kernel module [0]
and see if it performs well when linux chooses to use it?  disclaimer:
I haven't tried it but my attempt to attach kvm-clock itself worked [1].

This cpuid emulation bit was added during the time when using tsc was
the only way to get a precise clock and before pvclock was added [2].  This
also doesn't work on AMD machines (on at least mine).  We could get rid
of this cpuid emulation.


0: https://github.com/voutilad/vmm_clock
1: http://ix.io/2lzK
2: https://github.com/openbsd/src/commit/fa1855cdc021

--
Pratik

Reply via email to