qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] exec: Safe work in quiescent state


From: Sergey Fedorov
Subject: [Qemu-devel] exec: Safe work in quiescent state
Date: Fri, 10 Jun 2016 00:51:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

Hi,

For certain kinds of tasks we might need a quiescent state to perform an
operation safely. Quiescent state means no CPU thread executing, and
probably BQL held as well. The tasks could include:
- Translation buffer flush (user and system-mode)
- Cross-CPU TLB flush (system-mode)
- Exclusive operation emulation (user-mode)

If we use a single shared translation buffer which is not managed by RCU
and simply flushed when full, we'll need a quiescent state to flush it
safely.

In multi-threaded TCG, cross-CPU TLB flush from TCG helpers could
probably be made with async_run_on_cpu(). I suppose it is always the
guest system that needs to synchronise this operation properly. And as
soon as we request the target CPU to exit its execution loop for serving
the asynchronous work, we should probably be okay to continue execution
on the CPU requested the operation while the target CPU executing till
the end of its current TB before it actually flushed its TLB.

As of slow-path LL/SC emulation in multi-threaded TCG, cross-CPU TLB
flushes (actually TLB flushes on all CPUs) must me done synchronously
and thus might require quiescent state.

Exclusive operation emulation in user-mode is currently implemented in
this manner, see for start_exclusive(). It might change to some generic
mechanism of atomic/exclusive instruction emulation for system and
user-mode.

It looks like we need to implement a common mechanism to perform safe
work in a quiescent state which could work in both system and user-mode,
at least for safe translation bufferflush in user-mode and MTTCG. I'm
going to implement such a mechanism. I would appreciate any suggestions,
comments and remarks.

Thanks,
Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]