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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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