On 11.08.20 10:12, Peter Zijlstra wrote:
On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get the same case I mentioned to Peter,
raw_local_irq_save(); /* or other IRQs off without tracing */
...
kvm_wait() /* IRQ state tracing gets confused */
...
raw_local_irq_restore();
and therefore, using raw variants in kvm_wait() works. It's also safe
because it doesn't call any other libraries that would result in corrupt
Yes, this is definitely an issue.
Tracing, we also musn't call into tracing when using raw_local_irq_*().
Because then we re-intoduce this same issue all over again.
Both halt() and safe_halt() are more paravirt calls, but given we're in
a KVM paravirt call already, I suppose we can directly use native_*()
here.
Something like so then... I suppose, but then the Xen variants need TLC
too.
Just to be sure I understand you correct:
You mean that xen_qlock_kick() and xen_qlock_wait() and all functions
called by those should gain the "notrace" attribute, right?
I am not sure why the kick variants need it, though. IMO those are
called only after the lock has been released, so they should be fine
without notrace.
The issue happens when someone uses arch_spinlock_t under
raw_local_irq_*().
And again: we shouldn't forget the Hyper-V variants.
Bah, my grep failed :/ Also *groan*, that's calling apic->send_IPI().
In case you don't want to do it I can send the patch for the Xen
variants.
Juergen
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
