Re: [PATCH] kvm: First step to push iothread lock out of inner run loop

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-06-26 21:34, Marcelo Tosatti wrote:
> The following plan would allow progressive convertion to parallel
> operation.
> 
> Jan mentioned the MMIO handler->MMIO handler deadlock in a private message.
> 
> Jan: if there is recursive MMIO accesses, you can detect that and skip
> such MMIO handlers in dev_can_use_lock() ? Or blacklist.

The problem is harder as it may appear on first sight. I checked our
code again, and it also still contains at least one unhandled lockup
scenario. We could try to detect this but it's tricky, maybe even
fragile in more complex scenarios (risk of false positives when using
timeouts e.g.).

Well, such kind of mutual device-to-device requests are likely all
pathological, and I guess it would be ok to actually let the devices
lock up. But then we need some way to recover them, at least via a
virtual machine reset. That implies, of course, they must not lock up
while holding the central lock...

Need to look into details of your approach now.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux