Re: kernel device reset support

Avi Kivity
2007-10-09T10:55:55Z

Dong, Eddie wrote:
> 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 should call vcpu_halt() immediately after reset.

> It can be a future task which is not that high priority IMO.
> I will focus on SMP boot 1st. Your opnion?
>

Agree. But let's make it close to the complete solution.

>>>
>>>
>> 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.
>

The test for vcpu->requests already exists (and is needed for tlb
flushes) so there is no additional performance hit.

> 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.
>

The vcpu may have exited due to some other reason, and the interrupt
taken in host context?

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