> From: Liu, Jing2 <jing2.liu@xxxxxxxxx> > Sent: Tuesday, December 14, 2021 10:42 PM > > On 12/14/2021 6:16 PM, Paolo Bonzini wrote: > > > > On 12/14/21 08:06, Tian, Kevin wrote: > > >> - if (dynamic_enabled & ~guest_fpu->user_perm) != 0, then this is a > > >> userspace error and you can #GP the guest without any issue. > > >> Userspace is buggy > > > > > > Is it a general guideline that an error caused by emulation itself (e.g. > > > due to no memory) can be reflected into the guest as #GP, even when > > > from guest p.o.v there is nothing wrong with its setting? > > > > No memory is a tricky one, if possible it should propagate -ENOMEM up to > > KVM_RUN or KVM_SET_MSR. But it's basically an impossible case anyway, > > because even with 8K TILEDATA we're within the limit of > > PAGE_ALLOC_COSTLY_ORDER. > > > > So, since it's not easy to do it right now, we can look at it later. > > For the way handling xcr0 and xfd ioctl failure, xcr0 and xfd have > different handlings. Current KVM_SET_XCRS returns -EINVAL to > userspace. KVM_SET_MSR is always allowed as the discussion in > another thread. > > So I'm thinking if reallocation failure in KVM_SET_XCRS and > KVM_SET_MSR (may due to NOMEM or EPERM or ENOTSUPP), > what is the way we would like to choose? > KVM_SET_MSRS can definitely accept failure according to msr_io(). I think Paolo's point is more about that the restore path should not inherit any check related to vCPU capability. It's a different matter if the error is caused by other host kernel errors. Given that we don't need any special handling between the two scenarios (set by guest vs. set by host) in those emulation paths. Just return '1' to indicate error and whatever error policy exists in those scenarios is just applied. Thanks Kevin
