Re: [PATCH 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES

[Kim Phillips <kim.phillips@amd.com>]

On 2/24/25 6:02 PM, Tom Lendacky wrote:
> On 2/20/25 16:51, Tom Lendacky wrote:
>> On 2/18/25 19:26, Sean Christopherson wrote:
>>> This is a hastily thrown together series, barely above RFC, to try and
>>> address the worst of the issues that arise with guest controlled SEV
>>> features (thanks AP creation)[1].
>>>
>>> In addition to the initial flaws with DebugSwap, I came across a variety
>>> of issues when trying to figure out how best to handle SEV features in
>>> general.  E.g. AFAICT, KVM doesn't guard against userspace manually making
>>> a vCPU RUNNABLE after it has been DESTROYED (or after a failed CREATE).
>>>
>>> This is essentially compile-tested only, as I don't have easy access to a
>>> system with SNP enabled.  I ran the SEV-ES selftests, but that's not much
>>> in the way of test coverage.
>>>
>>> AMD folks, I would greatly appreciate reviews, testing, and most importantly,
>>> confirmation that all of this actually works the way I think it does.
>>
>> A quick test of a 64 vCPU SNP guest booted successfully, so that's a
>> good start. I'll take a closer look at these patches over the next few days.
> 
> Everything looks good. I'm going to try messing around with the
> DebugSwap feature bit just to try some of those odd cases and make sure
> everything does what it is supposed to. Should have results in a day or two.

My host and guest kernels are based on kvm-x86/next and, following the
instructions under "Tested with:" [1], I don't see gdb stopping on the
watchpoint in the guest gdb session:

...
Reading symbols from a.out...
Hardware watchpoint 1: x
Starting program: /home/ubuntu/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 957) exited normally]

It happens regardless of the kvm_amd debug_swap= setting, and
regardless of whether this cleanup series is applied or not.

Doing a break on main and running interactively makes gdb stop at main(),
as it should.

Am I doing something wrong?  Does anyone know whether
DebugSwap under SEV-ES (not just SNP) was tested?

Thanks,

Kim

[1] https://lore.kernel.org/kvm/20230411125718.2297768-6-aik@amd.com/