On 19/12/18 21:54, Dave Hansen wrote: > I should have called this out in the changelog, but I removed *all* the > support because I assumed that guests don't need MPX because no other OS > supported it that I know of. Well, as long as you could have code that sets the MPX bits in XCR0, KVM will have to support it. My employer happens to sell one such kernel and will probably do so a little less than ten years from now. :) >> A simple fix would be to leave the XSAVE state enabled in the kernel >> unconditionally even if all the other gunk is removed; alternatively >> I can also try to save/restore it only for the guest FPU. > > We could do this in two phases: remove the APIs now, and then remove the > XSAVE enabling later (4.22 or whenever). > > But, on the other hand, if we want to remove XSAVE support for MPX, > we'll have to break live migration at _some_ point, so why not just do > it now? In fact I'm not sure we want to ever remove XSAVE support for MPX in KVM as long as the processor supports it. That is, when KVM does xsave/xrstor of the guest_fpu, we probably want to include MPX in there. That can be contained within KVM, Linux need not enable it in XCR0, but there is one ugly thing: the xsavec offsets would be different between guest_fpu and other FPUs. Since KVM is not using supervisor states, perhaps it's better if that part of the KVM code is completely detached from the kernel FPU code and uses xsaveopt/xrstoropt instead. So perhaps the plan should be: 1) remove MPX APIs now 2) then stop using kernel xsave code for KVM's guest_fpu 3) then stop enabling MPX XSAVE in core kernel. Paolo >> If this patch can be bumped to 4.22, I would prefer that because it >> would save me and Linus some merge window headaches. Considering that >> the patch lacked my Cc or Ack, perhaps it's the right thing to do. > > That's fine with me as well.
