> We should basically never be using sizeof(struct fpu), anywhere. As you > saw, it's about a page in size, but the actual hardware FPU structure > can be as small as ~500 bytes or as big as ~3k. Doing it this way is a > pretty unnecessary waste of memory because sizeof(struct fpu) is sized > for the worst-case (largest) possible XSAVE buffer that we support on > *any* CPU. It will also get way worse if anyone ever throws a bunch > more state into the XSAVE area and we need to make it way bigger. > > If you want a kmem cache for this, I'd suggest creating a cache which is > the size of the host XSAVE buffer. That can be found in a variable > called 'fpu_kernel_xstate_size'. I'm assuming here that the guest FPU > is going to support a strict subset of host kernel XSAVE states. This suggestion sounds good. Though, I have one uncertainty. KVM explicitly cast guest_fpu.state as a fxregs_state in a few places (e.g., the ioctls). Yet, I see a code path in fpu__init_system_xstate_size_legacy() that sets fpu_kernel_xstate_size to sizeof(struct fregs_state). Will this cause problems? You mentioned that the fpu's state field is expected to range from ~500 bytes to ~3k, which implies that it should never get set to sizeof(struct fregs_state). But I want to confirm. > > > The other alternative is to calculate the actual size of the XSAVE > buffer that the guest needs. You can do that from the values that KVM > sets to limit guest XCR0 values (the name of the control field is > escaping me at the moment).
