Re: [PATCH 1/2] KVM: SEV: IBPB-on-Entry guest support

[Tom Lendacky]

On 1/30/26 09:45, Borislav Petkov wrote:
> On Fri, Jan 30, 2026 at 08:56:07AM -0600, Tom Lendacky wrote:
>> It can be added. Any of the features added to SNP_FEATURES_PRESENT that
>> aren't set in the SNP_FEATURES_IMPL_REQ bitmap are really a no-op. The
>> SNP_FEATURES_PRESENT bitmap is meant to contain whatever bits are set in
>> SNP_FEATURES_IMPL_REQ when an implementation has been implemented for the
>> guest.
>>
>> But, yeah, we could add all the bits that aren't set in
>> SNP_FEATURES_IMPL_REQ to SNP_FEATURES_PRESENT if it makes it clearer.
> 
> Right, that's the question. SNP_FEATURES_PRESENT is used in the masking
> operation to get the unsupported features.
> 
> But when we say a SNP feature is present, then, even if it doesn't need guest
> implementation, that feature is still present nonetheless.
> 
> So our nomenclature is kinda imprecise here.
> 
> I'd say, we can always rename SNP_FEATURES_PRESENT to denote what it is there
> for, i.e., the narrower functionality of the masking.
> 
> Or, if we want to gather there *all* features that are present, then we can
> start adding them...
> 
>> If we do that, it should probably be a separate patch (?) that also
>> rewords the comment above SNP_FEATURES_PRESENT
> 
> ... yes, as a separate patch.
> 
> Question is, what do we really wanna do here?
> 
> Does it make sense and is it useful to have SNP_FEATURES_PRESENT contain *all*
> guest SNP features...

I guess it really depends on the persons point of view. I agree that
renaming the SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL(EMENTED) would
match up nicely with SNP_FEATURES_IMPL_REQ. Maybe that's all that is
needed...

Thanks,
Tom


> 
> Thx.
>