Re: kernel device reset support

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>>     
>>>> N+1, for me is that synchronous device emulation (like pio and mmio)
>>>> happens in in the vcpu thread and asynchronous device emulation
>>>> (handling signals in qemu, performing dma, and injecting interrupts)
>>>> happens in the device thread.  This minimizes context switching and
>>>> heavyweight exits. 
>>>>
>>>>
>>>>         
>>> If this is true, then the N+1 thread won't be able to execute
>>> qemu_system_reset which is in VCPU contents,
>>>       
>> I don't understand.  It can certainly access any qemu object (after
>> taking qemu_mutex), and it can call any kvm vm ioctl.
>>     
>
> It can in theory, but do we have the real usage for
> qemu_system_reset which is the only caller of
> KERNEL RESET.
>
>   

Well, if the guest resets itself, then reset is called from the vcpu 
thread.  If we reset from the qemu monitor, it can be called from a 
non-vcpu thread.

>>>       
>> Do you mean signal handlers?  Sure, but we wait for socket I/O in
>> select() and even dequeue signals synchronously.
>>
>>
>>     
> Qemu_system_reset is called only when a VCPU thread is doing.
>
> Anyway, wanna to see your whole proposal.
>   

Yes, I'll prepare and post patched for review.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/