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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 18/09/15 12:40, Zhang, Yang Z wrote:
> Jan Beulich wrote on 2015-09-18:
>>>>> "Zhang, Yang Z" <yang.z.zhang@intel.com> 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.

~Andrew