Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Andrew Cooper wrote on 2015-09-18:
> On 18/09/15 12:40, Zhang, Yang Z wrote:
>> Jan Beulich wrote on 2015-09-18:
>>>>>> "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> 09/18/15 2:29 AM >>>
>>>> Zhang, Yang Z wrote on 2015-09-08:
>>>> I have a quick check on current code. I am curious that is current
>>>> Xen preemptive?
>>>> 
>>>> Also, when return from an interrupt handler, hypervisor didn't
>>>> check whether reschedule is needed if the interrupt is occurred in kernel 
>>>> context.
>>>> ENTRY(ret_from_intr)
>>>> GET_CURRENT(%rbx)
>>>> testb $3,UREGS_cs(%rsp)
>>>> jz    restore_all_xen              //call iret directly to restore
>>> previous context where interrupt occur if it is in kernel space.
>>> 
>>>> If Xen isn't preemptive, the above case I mentioned should never
>>>> happen since the VCPU still run in the same PCPU. Am I right?
>>> I have to admit that I don't see the connection to preemptiveness:
>>> The reference above is to a code section with interrupts disabled.
>> Ok. Maybe I am asking a wrong question. My initial question is how
>> Xen to
> support the preemption. For example, if VCPU is running in hypervisor
> (executing any code), can this VCPU be preempted immediately? If yes,
> how to achieve it because I didn't find any related code. I know if
> the PCPU get an SCHED_SOFTIRQ, the VCPU will do the schedule before do
> vmentry. But it only happens before do vmentry. Is it possible that
> VCPU been preempted at any time when running in hypervisor mode?
> 
> All vcpus may be preempted at any time by the Xen scheduler.
> 
> However, paths through the hypervisor are synchronous, so a vcpu will
> notice that it has been preempted on the return-to-guest path, and a
> context switch will occur as appropriate.

So the context switch only occurs on the return-to-guest patch or if the VCPU 
call schedule() by itself. It seems a little different from linux kernel which 
possible to preempt a task at any point.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel