Date: Sat, 1 Aug 2020 08:38:14 +1000 From: Peter Grehan <grehan@freebsd.org> To: Chuck Tuffli <chuck@tuffli.net> Cc: John Baldwin <jhb@freebsd.org>, freebsd-virtualization@freebsd.org Subject: rdtscp support (was Re: bhyve guest illegal instruction) Message-ID: <d21b2a6f-8d0f-9904-f7a3-500482fa1c9f@freebsd.org> In-Reply-To: <CAM0tzX3EO1Z_x%2B_jPuLQ3fVTtZjWC6wYCFHaN-OY%2BLKbj8VH6Q@mail.gmail.com> References: <CAM0tzX3EO1Z_x%2B_jPuLQ3fVTtZjWC6wYCFHaN-OY%2BLKbj8VH6Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Chuck, > 12 time1 = __builtin_ia32_rdtscp(&dummy); rdtscp shouldn't be used without checking that it's available via CPUID first, but as you mentioned the feature is available on the host, just hidden from the guest. > This same program works on the FreeBSD 12-stable machine hosting the VM > as well as another bare-metal Linux host. Poking around in the vmm code, > I found > /* > * Hide rdtscp/ia32_tsc_aux until we know how > * to deal with them. > */ > regs[3] &= ~AMDID_RDTSCP; > break; > in sys/amd64/vmm/x86.c which I _think_ is relevant because lscpu doesn't > show the rdtscp flag. If this is the root cause, what would need to be > done to implement this? At a quick glance, if the feature is available on the host you'd need to - expose it via CPUID - save/restore the TSC_AUX MSR, but using the VMCS MSR h/w save/restore mechanism that will have to be resurrected. (this avoids any preemption issues,even at NMI level). - set the "enable RDTSCP" VM-execution control to one in the VMCS That being said, I've heard anecdotally that rdtscp results in VM-exits on other hypervisors so there may be reason to emulate it rather than allow a pass-thru. More investigation may be required. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d21b2a6f-8d0f-9904-f7a3-500482fa1c9f>