From: Dario Faggioli <dario.faggioli@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>,
George Dunlap <george.dunlap@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
"Tian, Kevin" <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
Jan Beulich <jbeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling
Date: Mon, 21 Sep 2015 16:24:32 +0200 [thread overview]
Message-ID: <1442845472.2691.88.camel@citrix.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F002723E44@SHSMSX104.ccr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2062 bytes --]
On Mon, 2015-09-21 at 12:22 +0000, Wu, Feng wrote:
>
> > -----Original Message-----
> > From: George Dunlap [mailto:george.dunlap@citrix.com]
> > You also need to check that local_events_need_delivery() will
> > return
> > "true" if you get an interrupt between that time and entering the
> > hypervisor. Will that happen automatically from
> > hvm_local_events_need_delivery() -> hvm_vcpu_has_pending_irq() ->
> > vlapic_has_pending_irq()? Or will you need to add a hook in
> > hvm_vcpu_has_pending_irq()?
>
> I think I don't need to add hook in hvm_vcpu_has_pending_irq(), what
> I need
> to do in vcpu_block() and do_poll() is as below:
>
> 1. set_bit(_VPF_blocked, &v->pause_flags);
>
> 2. ret = v->arch.arch_block(), in this hook, we can re-use the same
> logic in
> vmx_pre_ctx_switch_pi(), and check whether ON bit is set during
> updating
> posted-interrupt descriptor, can return 1 when ON is set
>
It think it would be ok for an hook to return a value (maybe, if doing
that, let's pick variable names and use comments to explain what goes
on as good as we can).
I think I also see why you seem to prefer doing it that way, rather
than hacking local_events_need_delivery(), but can you please elaborate
on that? (My feeling is that you want to avoid having to update the
data structures in between _VPF_blocked and the check
local_events_need_delivery(), and then having to roll such update back
if local_events_need_delivery() ends up being false, is that the
case?).
Code would look better, IMO, if we manage to fold that somehow inside
local_events_need_delivery(), but that:
1. is hard to tell without actually seeing how the code will end up
being
2. might be my opinion only, so let's see what others think.
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
next prev parent reply other threads:[~2015-09-21 14:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 5:09 [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling Wu, Feng
2015-09-21 9:54 ` George Dunlap
2015-09-21 12:22 ` Wu, Feng
2015-09-21 14:24 ` Dario Faggioli [this message]
2015-09-22 7:19 ` Wu, Feng
2015-09-22 8:59 ` Jan Beulich
2015-09-22 13:40 ` Wu, Feng
2015-09-22 14:01 ` Jan Beulich
2015-09-23 9:44 ` George Dunlap
2015-09-23 12:35 ` Wu, Feng
2015-09-23 15:25 ` George Dunlap
2015-09-23 15:38 ` Jan Beulich
2015-09-24 1:50 ` Wu, Feng
2015-09-24 3:35 ` Dario Faggioli
2015-09-24 7:51 ` Jan Beulich
2015-09-24 8:03 ` Wu, Feng
2015-09-22 10:26 ` George Dunlap
2015-09-23 6:35 ` Wu, Feng
2015-09-23 7:11 ` Dario Faggioli
2015-09-23 7:20 ` Wu, Feng
-- strict thread matches above, loose matches on Subject: below --
2015-09-21 5:08 Wu, Feng
2015-09-21 9:18 ` George Dunlap
2015-09-21 11:59 ` Wu, Feng
2015-09-21 13:31 ` Dario Faggioli
2015-09-21 13:50 ` Wu, Feng
2015-09-21 14:11 ` Dario Faggioli
2015-09-22 5:10 ` Wu, Feng
2015-09-22 10:43 ` George Dunlap
2015-09-22 10:46 ` George Dunlap
2015-09-22 13:25 ` Wu, Feng
2015-09-22 13:40 ` Dario Faggioli
2015-09-22 13:52 ` Wu, Feng
2015-09-22 14:15 ` George Dunlap
2015-09-22 14:38 ` Dario Faggioli
2015-09-23 5:52 ` Wu, Feng
2015-09-23 7:59 ` Dario Faggioli
2015-09-23 8:11 ` Wu, Feng
2015-09-22 14:28 ` George Dunlap
2015-09-23 5:37 ` Wu, Feng
2015-09-11 8:28 [PATCH v7 00/17] Add VT-d Posted-Interrupts support Feng Wu
2015-09-11 8:29 ` [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling Feng Wu
2015-09-16 16:00 ` Dario Faggioli
2015-09-16 17:18 ` Dario Faggioli
2015-09-16 18:05 ` Dario Faggioli
2015-09-17 8:00 ` Wu, Feng
2015-09-17 8:48 ` Dario Faggioli
2015-09-17 9:16 ` Wu, Feng
2015-09-17 9:38 ` George Dunlap
2015-09-17 9:39 ` George Dunlap
2015-09-17 11:44 ` George Dunlap
2015-09-17 12:40 ` Dario Faggioli
2015-09-17 14:30 ` George Dunlap
2015-09-17 16:36 ` Dario Faggioli
2015-09-18 6:27 ` Jan Beulich
2015-09-18 9:22 ` Dario Faggioli
2015-09-18 14:31 ` George Dunlap
2015-09-18 14:34 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1442845472.2691.88.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.