Skip site navigation (1)Skip section navigation (2)
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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time1 =3D __builtin_=
ia32_rdtscp(&dummy);

  rdtscp shouldn't be used without checking that it's available via=20
CPUID first, but as you mentioned the feature is available on the host,=20
just hidden from the guest.

> This same program works on the FreeBSD 12-stable machine hosting the VM=
=20
> as well as another bare-metal Linux host. Poking around in the vmm code=
,=20
> I found
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 /*
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0* Hide rdtscp/ia32_tsc_aux until we know how
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0* to deal with them.
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0*/
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 regs[3] &=3D ~AMDID_RDTSCP;
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 break;
> in sys/amd64/vmm/x86.c which I _think_ is relevant because lscpu doesn'=
t=20
> show the rdtscp flag. If this is the root cause, what would need to be=20
> done to implement this?

  At a quick glance, if the feature is available on the host you'd need t=
o
   - expose it via CPUID
   - save/restore the TSC_AUX MSR, but using the VMCS MSR h/w=20
save/restore mechanism that will have to be resurrected. (this avoids=20
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=20
VM-exits on other hypervisors so there may be reason to emulate it=20
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>