Avi Kivity wrote: >> >> If BSP mp_state becomes VCPU_MP_STATE_UNINITIALIZED, current code >> can't wakeup it. We need additional code that I am not aware of now. >> >> Current VCPU must be BSP, otherwise the code executing in Qemu will >> have problem too. >> > > But, for an ungraceful reset, nothing prevents an AP from > issuing a reset?
Mmm, Yes, but I think current architecture can't handle this. The thread where AP issues "RESET" will continue run, which means it becomes BSP now and wake up other APs later on. Or We can block that AP first and then inform BSP to do RESET job. Here we need to block the AP in kernel so that we can wake up. It can be a future task which is not that high priority IMO. I will focus on SMP boot 1st. Your opnion? > > >> >> Mmm, almost Yes, then it is same with force_to_quit. >> But reset doesn't mean lapic_reset only, it needs to >> enter wait for INIT/SIPI cycles. So using mp_state is >> much closer. >> >> > > What I mean is to use mp_state within the vcpu code (while holding the > vcpu mutex) and to use vcpu->requests as a means to tell the vcpu it > needs to change state. > Then we need to add code to enter waitqueque here. I think force_to_quit is much simple and efficient since we don't need to test (atomic test) at each VM Exit even light weight VM Exit. But certainly it can. If you want to save the per VCPU force_to_quit, we can share it with vcpu_request, but test in external IRQ is better IMO since we take a kick now. >>> Sounds good. But the BSP starts executing immediately, no? >>> >> >> Yes, BSP will continue. current VCPU=BSP. >> > > It's a vm ioctl, there is no current vcpu! > Yes, but it is in the thread BSP use :-) Thx,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
