Re: [PATCH] doc/virt/kvm: move KVM_X86_SET_MSR_FILTER in section 8
On 16/03/21 18:08, Emanuele Giuseppe Esposito wrote: KVM_X86_SET_MSR_FILTER is a capability, not an ioctl. Therefore move it from section 4.97 to the new 8.31 (other capabilities). Here and in the subject I think KVM_X86_SET_MSR_FILTER should be replaced by KVM_CAP_PPC_MULTITCE. Otherwise looks good, so I queued it. Thanks, Paolo To fill the gap, move KVM_X86_SET_MSR_FILTER (was 4.126) to 4.97, and shifted Xen-related ioctl (were 4.127 - 4.130) by one place (4.126 - 4.129). Also fixed minor typo in KVM_GET_MSR_INDEX_LIST ioctl description (section 4.3).
Re: [PATCH] doc/virt/kvm: move KVM_X86_SET_MSR_FILTER in section 8
On 13/04/21 23:20, Jonathan Corbet wrote: Emanuele Giuseppe Esposito writes: KVM_X86_SET_MSR_FILTER is a capability, not an ioctl. Therefore move it from section 4.97 to the new 8.31 (other capabilities). To fill the gap, move KVM_X86_SET_MSR_FILTER (was 4.126) to 4.97, and shifted Xen-related ioctl (were 4.127 - 4.130) by one place (4.126 - 4.129). Also fixed minor typo in KVM_GET_MSR_INDEX_LIST ioctl description (section 4.3). Signed-off-by: Emanuele Giuseppe Esposito --- Documentation/virt/kvm/api.rst | 250 - 1 file changed, 125 insertions(+), 125 deletions(-) Paolo, what's your thought on this one? If it's OK should I pick it up? I missed the patch, I'll queue it up for 5.13. Paolo Thanks, jon diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1a2b5210cdbf..a230140d6a7f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -201,7 +201,7 @@ Errors: == EFAULT the msr index list cannot be read from or written to - E2BIG the msr index list is to be to fit in the array specified by + E2BIG the msr index list is too big to fit in the array specified by the user. == @@ -3686,31 +3686,105 @@ which is the maximum number of possibly pending cpu-local interrupts. Queues an SMI on the thread's vcpu. -4.97 KVM_CAP_PPC_MULTITCE -- +4.97 KVM_X86_SET_MSR_FILTER + -:Capability: KVM_CAP_PPC_MULTITCE -:Architectures: ppc -:Type: vm +:Capability: KVM_X86_SET_MSR_FILTER +:Architectures: x86 +:Type: vm ioctl +:Parameters: struct kvm_msr_filter +:Returns: 0 on success, < 0 on error -This capability means the kernel is capable of handling hypercalls -H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user -space. This significantly accelerates DMA operations for PPC KVM guests. -User space should expect that its handlers for these hypercalls -are not going to be called if user space previously registered LIOBN -in KVM (via KVM_CREATE_SPAPR_TCE or similar calls). +:: -In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest, -user space might have to advertise it for the guest. For example, -IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is -present in the "ibm,hypertas-functions" device-tree property. + struct kvm_msr_filter_range { + #define KVM_MSR_FILTER_READ (1 << 0) + #define KVM_MSR_FILTER_WRITE (1 << 1) + __u32 flags; + __u32 nmsrs; /* number of msrs in bitmap */ + __u32 base; /* MSR index the bitmap starts at */ + __u8 *bitmap; /* a 1 bit allows the operations in flags, 0 denies */ + }; -The hypercalls mentioned above may or may not be processed successfully -in the kernel based fast path. If they can not be handled by the kernel, -they will get passed on to user space. So user space still has to have -an implementation for these despite the in kernel acceleration. + #define KVM_MSR_FILTER_MAX_RANGES 16 + struct kvm_msr_filter { + #define KVM_MSR_FILTER_DEFAULT_ALLOW (0 << 0) + #define KVM_MSR_FILTER_DEFAULT_DENY (1 << 0) + __u32 flags; + struct kvm_msr_filter_range ranges[KVM_MSR_FILTER_MAX_RANGES]; + }; -This capability is always enabled. +flags values for ``struct kvm_msr_filter_range``: + +``KVM_MSR_FILTER_READ`` + + Filter read accesses to MSRs using the given bitmap. A 0 in the bitmap + indicates that a read should immediately fail, while a 1 indicates that + a read for a particular MSR should be handled regardless of the default + filter action. + +``KVM_MSR_FILTER_WRITE`` + + Filter write accesses to MSRs using the given bitmap. A 0 in the bitmap + indicates that a write should immediately fail, while a 1 indicates that + a write for a particular MSR should be handled regardless of the default + filter action. + +``KVM_MSR_FILTER_READ | KVM_MSR_FILTER_WRITE`` + + Filter both read and write accesses to MSRs using the given bitmap. A 0 + in the bitmap indicates that both reads and writes should immediately fail, + while a 1 indicates that reads and writes for a particular MSR are not + filtered by this range. + +flags values for ``struct kvm_msr_filter``: + +``KVM_MSR_FILTER_DEFAULT_ALLOW`` + + If no filter range matches an MSR index that is getting accessed, KVM will + fall back to allowing access to the MSR. + +``KVM_MSR_FILTER_DEFAULT_DENY`` + + If no filter range matches an MSR index that is getting accessed, KVM will + fall back to rejecting access to the MSR. In this mode, all MSRs that should + be processed by KVM need to explicitly be marked as allowed in the bitmaps. + +This ioctl allows user space to define up to 16 bitmaps of MSR ranges to +specify whether a certain MSR access should be explicitly filtered for
Re: [PATCH] doc/virt/kvm: move KVM_X86_SET_MSR_FILTER in section 8
Emanuele Giuseppe Esposito writes: > KVM_X86_SET_MSR_FILTER is a capability, not an ioctl. > Therefore move it from section 4.97 to the new 8.31 (other capabilities). > > To fill the gap, move KVM_X86_SET_MSR_FILTER (was 4.126) to > 4.97, and shifted Xen-related ioctl (were 4.127 - 4.130) by > one place (4.126 - 4.129). > > Also fixed minor typo in KVM_GET_MSR_INDEX_LIST ioctl description > (section 4.3). > > Signed-off-by: Emanuele Giuseppe Esposito > --- > Documentation/virt/kvm/api.rst | 250 - > 1 file changed, 125 insertions(+), 125 deletions(-) Paolo, what's your thought on this one? If it's OK should I pick it up? Thanks, jon > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 1a2b5210cdbf..a230140d6a7f 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -201,7 +201,7 @@ Errors: > >== >EFAULT the msr index list cannot be read from or written to > - E2BIG the msr index list is to be to fit in the array specified by > + E2BIG the msr index list is too big to fit in the array specified by > the user. >== > > @@ -3686,31 +3686,105 @@ which is the maximum number of possibly pending > cpu-local interrupts. > > Queues an SMI on the thread's vcpu. > > -4.97 KVM_CAP_PPC_MULTITCE > -- > +4.97 KVM_X86_SET_MSR_FILTER > + > > -:Capability: KVM_CAP_PPC_MULTITCE > -:Architectures: ppc > -:Type: vm > +:Capability: KVM_X86_SET_MSR_FILTER > +:Architectures: x86 > +:Type: vm ioctl > +:Parameters: struct kvm_msr_filter > +:Returns: 0 on success, < 0 on error > > -This capability means the kernel is capable of handling hypercalls > -H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user > -space. This significantly accelerates DMA operations for PPC KVM guests. > -User space should expect that its handlers for these hypercalls > -are not going to be called if user space previously registered LIOBN > -in KVM (via KVM_CREATE_SPAPR_TCE or similar calls). > +:: > > -In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest, > -user space might have to advertise it for the guest. For example, > -IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is > -present in the "ibm,hypertas-functions" device-tree property. > + struct kvm_msr_filter_range { > + #define KVM_MSR_FILTER_READ (1 << 0) > + #define KVM_MSR_FILTER_WRITE (1 << 1) > + __u32 flags; > + __u32 nmsrs; /* number of msrs in bitmap */ > + __u32 base; /* MSR index the bitmap starts at */ > + __u8 *bitmap; /* a 1 bit allows the operations in flags, 0 denies */ > + }; > > -The hypercalls mentioned above may or may not be processed successfully > -in the kernel based fast path. If they can not be handled by the kernel, > -they will get passed on to user space. So user space still has to have > -an implementation for these despite the in kernel acceleration. > + #define KVM_MSR_FILTER_MAX_RANGES 16 > + struct kvm_msr_filter { > + #define KVM_MSR_FILTER_DEFAULT_ALLOW (0 << 0) > + #define KVM_MSR_FILTER_DEFAULT_DENY (1 << 0) > + __u32 flags; > + struct kvm_msr_filter_range ranges[KVM_MSR_FILTER_MAX_RANGES]; > + }; > > -This capability is always enabled. > +flags values for ``struct kvm_msr_filter_range``: > + > +``KVM_MSR_FILTER_READ`` > + > + Filter read accesses to MSRs using the given bitmap. A 0 in the bitmap > + indicates that a read should immediately fail, while a 1 indicates that > + a read for a particular MSR should be handled regardless of the default > + filter action. > + > +``KVM_MSR_FILTER_WRITE`` > + > + Filter write accesses to MSRs using the given bitmap. A 0 in the bitmap > + indicates that a write should immediately fail, while a 1 indicates that > + a write for a particular MSR should be handled regardless of the default > + filter action. > + > +``KVM_MSR_FILTER_READ | KVM_MSR_FILTER_WRITE`` > + > + Filter both read and write accesses to MSRs using the given bitmap. A 0 > + in the bitmap indicates that both reads and writes should immediately fail, > + while a 1 indicates that reads and writes for a particular MSR are not > + filtered by this range. > + > +flags values for ``struct kvm_msr_filter``: > + > +``KVM_MSR_FILTER_DEFAULT_ALLOW`` > + > + If no filter range matches an MSR index that is getting accessed, KVM will > + fall back to allowing access to the MSR. > + > +``KVM_MSR_FILTER_DEFAULT_DENY`` > + > + If no filter range matches an MSR index that is getting accessed, KVM will > + fall back to rejecting access to the MSR. In this mode, all MSRs that > should > + be processed by KVM need to explicitly be marked as allowed in the bitmaps. > + > +This ioctl allows user space to define up to 16
[PATCH] doc/virt/kvm: move KVM_X86_SET_MSR_FILTER in section 8
KVM_X86_SET_MSR_FILTER is a capability, not an ioctl. Therefore move it from section 4.97 to the new 8.31 (other capabilities). To fill the gap, move KVM_X86_SET_MSR_FILTER (was 4.126) to 4.97, and shifted Xen-related ioctl (were 4.127 - 4.130) by one place (4.126 - 4.129). Also fixed minor typo in KVM_GET_MSR_INDEX_LIST ioctl description (section 4.3). Signed-off-by: Emanuele Giuseppe Esposito --- Documentation/virt/kvm/api.rst | 250 - 1 file changed, 125 insertions(+), 125 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1a2b5210cdbf..a230140d6a7f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -201,7 +201,7 @@ Errors: == EFAULT the msr index list cannot be read from or written to - E2BIG the msr index list is to be to fit in the array specified by + E2BIG the msr index list is too big to fit in the array specified by the user. == @@ -3686,31 +3686,105 @@ which is the maximum number of possibly pending cpu-local interrupts. Queues an SMI on the thread's vcpu. -4.97 KVM_CAP_PPC_MULTITCE -- +4.97 KVM_X86_SET_MSR_FILTER + -:Capability: KVM_CAP_PPC_MULTITCE -:Architectures: ppc -:Type: vm +:Capability: KVM_X86_SET_MSR_FILTER +:Architectures: x86 +:Type: vm ioctl +:Parameters: struct kvm_msr_filter +:Returns: 0 on success, < 0 on error -This capability means the kernel is capable of handling hypercalls -H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user -space. This significantly accelerates DMA operations for PPC KVM guests. -User space should expect that its handlers for these hypercalls -are not going to be called if user space previously registered LIOBN -in KVM (via KVM_CREATE_SPAPR_TCE or similar calls). +:: -In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest, -user space might have to advertise it for the guest. For example, -IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is -present in the "ibm,hypertas-functions" device-tree property. + struct kvm_msr_filter_range { + #define KVM_MSR_FILTER_READ (1 << 0) + #define KVM_MSR_FILTER_WRITE (1 << 1) + __u32 flags; + __u32 nmsrs; /* number of msrs in bitmap */ + __u32 base; /* MSR index the bitmap starts at */ + __u8 *bitmap; /* a 1 bit allows the operations in flags, 0 denies */ + }; -The hypercalls mentioned above may or may not be processed successfully -in the kernel based fast path. If they can not be handled by the kernel, -they will get passed on to user space. So user space still has to have -an implementation for these despite the in kernel acceleration. + #define KVM_MSR_FILTER_MAX_RANGES 16 + struct kvm_msr_filter { + #define KVM_MSR_FILTER_DEFAULT_ALLOW (0 << 0) + #define KVM_MSR_FILTER_DEFAULT_DENY (1 << 0) + __u32 flags; + struct kvm_msr_filter_range ranges[KVM_MSR_FILTER_MAX_RANGES]; + }; -This capability is always enabled. +flags values for ``struct kvm_msr_filter_range``: + +``KVM_MSR_FILTER_READ`` + + Filter read accesses to MSRs using the given bitmap. A 0 in the bitmap + indicates that a read should immediately fail, while a 1 indicates that + a read for a particular MSR should be handled regardless of the default + filter action. + +``KVM_MSR_FILTER_WRITE`` + + Filter write accesses to MSRs using the given bitmap. A 0 in the bitmap + indicates that a write should immediately fail, while a 1 indicates that + a write for a particular MSR should be handled regardless of the default + filter action. + +``KVM_MSR_FILTER_READ | KVM_MSR_FILTER_WRITE`` + + Filter both read and write accesses to MSRs using the given bitmap. A 0 + in the bitmap indicates that both reads and writes should immediately fail, + while a 1 indicates that reads and writes for a particular MSR are not + filtered by this range. + +flags values for ``struct kvm_msr_filter``: + +``KVM_MSR_FILTER_DEFAULT_ALLOW`` + + If no filter range matches an MSR index that is getting accessed, KVM will + fall back to allowing access to the MSR. + +``KVM_MSR_FILTER_DEFAULT_DENY`` + + If no filter range matches an MSR index that is getting accessed, KVM will + fall back to rejecting access to the MSR. In this mode, all MSRs that should + be processed by KVM need to explicitly be marked as allowed in the bitmaps. + +This ioctl allows user space to define up to 16 bitmaps of MSR ranges to +specify whether a certain MSR access should be explicitly filtered for or not. + +If this ioctl has never been invoked, MSR accesses are not guarded and the +default KVM in-kernel emulation behavior is fully preserved. + +Calling this ioctl with an empty set of ranges (all nmsrs == 0) disables MSR +filtering. In that