On 04/06/2025 4:15 pm, Jan Beulich wrote:
> On 04.06.2025 15:02, Andrew Cooper wrote:
>> @@ -246,6 +248,8 @@ static void cf_check vmcb_dump(unsigned char ch)
>> }
>> printk("\tVCPU %d\n", v->vcpu_id);
>> svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb);
>> +
>> + process_pending_softirqs();
> It's only an RCU read lock we're holding here, but it still feels somewhat
> odd to do this with any kind of lock held. Then again (I didn't even
> consider this upon earlier insertions of such into keyhandler functions)
> we may even be holding a real lock (the sysctl one) when getting here, yet
> apparently that was deemed fine in the past. Plus dump_domains() does the
> same as what we end up with here ...
The debug keys are debug functionality, and do play rather fast and loose.
While the Xen watchdog does hit first (5s), spending too long does cause
problems for the vCPU that's interrupted (usually soft lockup).
I was wondering if we should force schedule to idle before running most
keyhandlers. That prevents holding a vCPU hostage (and if it's hard
pinned, then tough luck).
We would want a way of blocking further sysctl-debug-key's while one is
pending.
~Andrew
