> Date: Thu, 21 Feb 2013 09:01:53 +0000
> From: tim@xxxxxxx
> To: zhangzhi2022@xxxxxxxxxxx
> CC: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen hypervisor
>
> Hi,
>
> At 23:59 +0800 on 15 Feb (1360972763), henry wrote:
> > In the context of multi-core mode, core 1 is in root-mode, meaning
> > that it's running VMM. And core 2 is in non-root mode, meaning that it's
> > running guest OS in kernel level. If core 1 wants core2 to execute a
> > pre-defined program located in kernel-mode, say a syscall or a virtual
> > external interrupt handler(the program is completed via syscall or another
> > kernel module). Considering that core1 is in vmm mode, and core2 is not
> > supposed to vm-exit, so I can't use the method of event-delivery. What kind
> > of thing should core 1 do ?
>
> If you need the VM on core 2 to act immediately (and it's currently
> doing something other than waiting for core 1 to send it a message) then
> you'll need to send it some sort of interrupt. There's no way of doing
> that in Xen without core 2 vm-exiting, because all interrupts are
> handled in Xen.
>
> In theory you could implement something like ELI for Xen. That could be
> interesting, not least as a piece of repeated research, but it's quite a
> serious undertaking.
> (http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)
>
I've read about ELI already, which is quite interesting and a software implementation of ipi withou vmexits. Recently, according to kvm mailing list, Intel announced a new feature, called posted interrupts, that enables a VMM running on core0 to inject virtual interrupts to a guest running on core1 without vmexits. The feature is described in details in the latest Intel-x86 software developer manual.
In a nutshell, I'm still considering the implementation of ipi based on the new intel feature, compared to software method.
> Of course, if you don't need an immediate answer, any shared-memory
> protocol will do. You just need to arrange for the VM to check for
> messages periodically.
>
yes, you are right, but I need an immediate response anyway. At first, polling mechanism is considered but then given up because of the performance cost.
> Cheers,
>
> Tim.
Best regards,
henry
