[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on VM fence infrastructure
From: |
Rafael David Tinoco |
Subject: |
Re: Thoughts on VM fence infrastructure |
Date: |
Mon, 30 Sep 2019 16:45:08 -0300 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
>>> There are times when the main loop can get blocked even though the CPU
>>> threads can be running and can in some configurations perform IO
>>> even without the main loop (I think!).
>> Ah, that's a very good point. Indeed, you can perform IO in those
>> cases specially when using vhost devices.
>>
>>> By setting a timer in the kernel that sends a signal to qemu, the kernel
>>> will send that signal however broken qemu is.
>> Got you now. That's probably better. Do you reckon a signal is
>> preferable over SIGEV_THREAD?
> Not sure; probably the safest is getting the kernel to SIGKILL it - but
> that's a complete nightmare to debug - your process just goes *pop*
> with no apparent reason why.
> I've not used SIGEV_THREAD - it looks promising though.
Sorry to "enter" the discussion, but, in "real" HW, its not by accident
that watchdog devices timeout generates a NMI to CPUs, causing the
kernel to handle the interrupt - and panic (or to take other action set
by specific watchdog drivers that re-implements the default ones).
Can't you simple "inject" a NMI in all guest vCPUs BEFORE you take any
action in QEMU itself? Just like the virtual watchdog device would do,
from inside the guest (/dev/watchdog), but capable of being updated by
outside, in this case of yours (if I understood correctly).
Possibly you would have to have a dedicated loop for this "watchdog
device" (AIO threads ?) not to compete with existing coroutines/BH Tasks
and their jittering on your "realtime watchdog needs".
Regarding remaining existing I/OS for the guest's devices in question
(vhost/vhost-user etc), would be just like a real host where the "bus"
received commands, but sender died right after...
- Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Dr. David Alan Gilbert, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Dr. David Alan Gilbert, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Dr. David Alan Gilbert, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Dr. David Alan Gilbert, 2019/09/30
- Re: Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30
- Re: Thoughts on VM fence infrastructure,
Rafael David Tinoco <=
- Re: Thoughts on VM fence infrastructure, Felipe Franciosi, 2019/09/30