On Sun, Jan 08, 2023 at 07:20:46PM -0500, Scott Cheloha wrote: > On Sun, Jan 08, 2023 at 03:09:44PM -0500, Dave Voutila wrote: > > > > Philip Guenther <guent...@gmail.com> writes: > > > > > On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila <d...@sisu.io> wrote: > > > > > > Bringing this to tech@ to increase my chance of someone testing my > > > diff. > > > > > > As reported in this thread on misc@ [1], I believe newer Intel hardware > > > may be experiencing issues hosting Linux guests under vmm/vmd. It looks > > > like there are some newer instructions Intel added (TPAUSE specifically) > > > that also involve some new MSR(s). > > > > > > I don't have 12th gen Intel hardware to test this on (I think that's > > > Alder Lake). I'd like to mask this feature from vmm guests since it's > > > related to an MSR we don't yet pass through or emulate and has to do > > > with the TSC (which has it's own challenges in vmm). > > > > > > For someone testing, you should be able to grab an Alpine Linux iso > > > (-virt flavor) and boot it with vmd with the diff. (Without it should > > > "hang" and spike CPU or just die.) Also check that WAITPKG shows up in > > > your dmesg on the cpu feature output. > > > > > > This seem like it'll obviously work, but I guess it seems to me that this > > > "opt-out" approach is generally > > > unsafe/unstable and vmd should consider actively switching to "opt-in" on > > > all these CPUID feature bits. I mean, > > > what bits are defined in the SEFF first-leaf EDX that _do_ work with vmd? > > > > > > > Great point (I think you mean ECX). Here's an updated diff that flips it > > to a whitelist so Intel/AMD don't burn me with these new bits in the > > future. This better? > > I don't mean to fearmonger, but doesn't this open vmm(4) and the wider > kernel up to risk from all future "unknown unknowns"? We're basically > saying the guest can use any feature passed through from the host > before any developer has even glanced at the documentation for the new > bit, right? > > I'm not saying the "opt-out" approach shown in your patch is even > *likely* to be a problem. But the "opt-in" approach doesn't seem > unreasonably conservative to me. When something is widely used enough > to cause a problem, we add the bit. > > Or maybe every few months we ought to check for a new x86-64 ISA pdf > from Intel, since they seem to be the ones expanding the feature set.
Whoops, ignore this, I misunderstood guenther@'s idea and dv@'s patch.
