Re: [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1728 bytes --]

On Wed, 2015-10-28 at 03:03 -0600, Jan Beulich wrote:
> > > > On 28.10.15 at 03:58, <feng.wu@intel.com> wrote:

> > We still call arch_vcpu_block() in vcpu_block(), but we don't need
> > to
> > call arch_vcpu_block_cancel(v) when local_events_need_delivery()
> > returns true. Then before VM-Entry, we can check if 'NV' field is
> > ' pi_wakeup_vector', if it is, we change the PI status and remove
> > it from the blocking list.
> > 
> > Jan, if #2 is what you mean, I think it worth a try. If I don't
> > understand
> > your comments correctly, could you please elaborate it more? Thanks
> > a lot!
> 
> Ideally we'd avoid both arch_vcpu_*() calls by doing what is needed
> in arch code (e.g. the VM entry path). 
>
+1

> If only avoiding the cancel
> hook is reasonably possible this way, then so be it - still better to
> have just one hook here than having two.
> 
+1 again

As an aside, I've spoked with some ARM people, the context being that
they will get to implement a similar feature in the nearish future.

They said that, although they can't be sure, they don't think they'll
be interested in arch hooks in the scheduling code and that, actually,
having them risk being more harmful than helpful.

Of course, that does not mean that we shouldn't add them for the sake
of this patch, if we can't avoid doing that. But if we can avoid them,
that is perhaps one more reason for doing things that way.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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