>>
>> Current VP wake up logic thru INIT/SIPI doesn't support this when
>> irqchip in kernel.
>>
>>
>
> Doesn't this code imply that waiting for SIPI is supported?
It is supported to wake up VCPU in kernel, but can't wake up the VCPU
in user level since irqchip_in_kernel is TRUE here. vcpu->mp_state
doesn't export to user level.
>>
>
> You can put a goto to the top of the loop to redo the mmu reload. In
> any case you need to do that because you don't want to execute
> the reset
> code with interrupts and preemption disabled.
A goto cross function? It is too aggresive and bad code style IMO.
The vcpu->request check is in __vcpu_run, while entering block
state is in its parent function kvm_vcpu_ioctl_run.
But if you want, we can return a special value,
say REQUEST_INTERNAL_LOOP, to
kvm_vcpu_ioctl_run and let kvm_vcpu_ioctl_run use sepcial logic
to do goto within function if it see the special return value
REQUEST_INTERNAL_LOOP. But is it cleaner?
Also we will add more kernel to user EXIT reason, such as RESET request
from kernel sensored guest tripple fault etc.
>>
>> The VCPU may be executing in kernel still, which may modify kernel
>> device state. E.g. A VCPU may be doing PIO emulating.
>>
>>
>
> In that case we will wait when taking kvm->lock.
Lock doesn't help. Lock can only avoid no 2+ modifcation
in same time. But what we care if all other VCPUs can't
do modification after BSP do device reset.
It is different semantics.
Maybe you are still arguing it is the AP who do RESET ops.
Let us go to next discussion first.
>
>> If BSP reset the kernel devices earlier than the VCPU modify the
>> device state, we are in trouble.
>>
>> No, VCPU0 (BSP) is current VCPU (though you don't have the current
>> vcpu parameter explicitly) like mentioned in previous mail and
>> as pre-requirement of user level change. Please refer my abswer
>> above of this mail.
>>
>>
>
> We can't rely on user space not to cause host kernel corruption.
???
Even an AP trigger RESET, it just sets a reset_request flag in user
level.
It is another VCPU who will execute RESET operation.
It seems the argument is who should do the RESET operation,
say RST_CPU. BSP only or AP too. For me, since after RESET
only BSP can execute, and the thread executing
qemu_system_reset will continously execute
(after RESET kernel) per current Qemu code, so what we can do is:
1: RST_CPU=BSP. Then BSP does qemu_system_reset, or
2: RST_CPU = AP, say RAP, does qemu_system_reset, user level
then
need to block RAP after qemu_system_reset and wake up BSP to take over.
A point here we can't blcok RAP in case 2 at kernel RESET time,
since
kernel RESET may be not the last step of qemu_system_reset. It may go
to kernel again.
If we go with #1, just 1 line change as in my previous mail.
If we go with #2, we have to add a new ABI for the AP to enter
kernel
wait for INIT/SIPI/SIPI state, otherwise normal INIT/SIPI/SIPI couldn't
wake it up.
I see much complicate in #2 while #1 has same functionality but
simple.
thanks, eddie
-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
