> > On Fri, Nov 20, 2020 at 12:03 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > We may want to taint the kernel if one of these flags is used I agree with Andy. I can imagine a distro would want to see the taint bit set if a user overrides the default that they ship and support. Chang, Please taint when the enable flag is used -- Thanks! > because, > frankly, Intel’s track record is poor. Suppose we get a new feature > with PKRU-like semantics -- switching it blindly using > XSAVE(C,S,OPT,whatever) would simply incorrect. A valid concern. To mitigate, there is a new CPUID bit on the way to tell us explicitly which features are simple (require just XSAVE), versus which features are not simple and require more complex support.n t When that bit is locked down, we will add that sanity check here. > And XFD itself has > problems — supposedly it’s difficult or impossible to virtualize. It > wouldn’t utterly shock me if Intel were to drop IA32_XFD_ERR and > replace it with a new mechanism that’s less janky. > > So this whole thing makes me quite nervous. > > (I'm not a virtualization expert, but AIUI IA32_XFD_ERR has some > issues. If it's too late to fix those issues, Intel could probably > get away with completely dropping IA32_XFD_ERR from the spec -- OSes > can handle AMX just fine without it. Then the next XFD-able feature > could introduce a new improved way of reporting which feature > triggered #NM.) I don't follow the XFD concern. There are a couple of cases. If the hypervisor isn't aware of XFD, it neither uses it, or shows it to the guests. If the hypervisor is aware of XFD and supports TMUL, it allocates its own context switch buffers at boot time, and does not use the XFD optimization to save space inside the hypervisor. It can expose XFD to the guests, (and context switch it when guests switch on/off physical CPUs) The guest sees two cases, either XFD exists or it doesn't, just like on real hardware. thanks, Len Brown, Intel Open Source Technology Center
