Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.06.2025 17:20, Andrew Cooper wrote:
> 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 already invoke a tasklet in most situations, the main exception being
invocation via sysctl afaict.

> We would want a way of blocking further sysctl-debug-key's while one is
> pending.

That's guaranteed already by the sysctl lock, isn't it? Or did you mean
blocking sysctl ones while a non-sysctl one is in progress? (Along the
lines of what you say in the first sentence of your reply, right now we
simply assume responsible use by the host admin here.)

Jan