From: George Dunlap <george.dunlap@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Dario Faggioli <dario.faggioli@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 v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts
Date: Mon, 21 Sep 2015 10:45:07 +0100 [thread overview]
Message-ID: <55FFD1A3.3040601@citrix.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F002722BAF@SHSMSX104.ccr.corp.intel.com>
On 09/21/2015 06:07 AM, Wu, Feng wrote:
>
>
>> -----Original Message-----
>> From: Wu, Feng
>> Sent: Thursday, September 17, 2015 2:16 PM
>> To: George Dunlap; Jan Beulich
>> Cc: Tian, Kevin; Keir Fraser; Andrew Cooper; Dario Faggioli;
>> xen-devel@lists.xen.org; Wu, Feng
>> Subject: RE: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for
>> VT-d posted interrupts
>>
>>
>>
>>> -----Original Message-----
>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of
>> George
>>> Dunlap
>>> Sent: Thursday, September 17, 2015 12:57 AM
>>> To: Jan Beulich
>>> Cc: Wu, Feng; Tian, Kevin; Keir Fraser; Andrew Cooper; Dario Faggioli;
>>> xen-devel@lists.xen.org
>>> Subject: Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for
>>> VT-d posted interrupts
>>>
>>> On Mon, Sep 7, 2015 at 1:54 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 25.08.15 at 03:57, <feng.wu@intel.com> wrote:
>>>>> --- a/xen/arch/x86/domain.c
>>>>> +++ b/xen/arch/x86/domain.c
>>>>> @@ -1573,6 +1573,22 @@ static void __context_switch(void)
>>>>> per_cpu(curr_vcpu, cpu) = n;
>>>>> }
>>>>>
>>>>> +static inline void pi_ctxt_switch_from(struct vcpu *prev)
>>>>> +{
>>>>> + /*
>>>>> + * When switching from non-idle to idle, we only do a lazy context
>>> switch.
>>>>> + * However, in order for posted interrupt (if available and enabled)
>> to
>>>>> + * work properly, we at least need to update the descriptors.
>>>>> + */
>>>>> + if ( prev->arch.pi_ctxt_switch_from && !is_idle_vcpu(prev) )
>>>>> + prev->arch.pi_ctxt_switch_from(prev);
>>>>> +}
>>>>> +
>>>>> +static inline void pi_ctxt_switch_to(struct vcpu *next)
>>>>> +{
>>>>> + if ( next->arch.pi_ctxt_switch_to && !is_idle_vcpu(next) )
>>>>> + next->arch.pi_ctxt_switch_to(next);
>>>>> +}
>>>>>
>>>>> void context_switch(struct vcpu *prev, struct vcpu *next)
>>>>> {
>>>>> @@ -1605,9 +1621,12 @@ void context_switch(struct vcpu *prev, struct
>>> vcpu *next)
>>>>>
>>>>> set_current(next);
>>>>>
>>>>> + pi_ctxt_switch_from(prev);
>>>>> +
>>>>> if ( (per_cpu(curr_vcpu, cpu) == next) ||
>>>>> (is_idle_domain(nextd) && cpu_online(cpu)) )
>>>>> {
>>>>> + pi_ctxt_switch_to(next);
>>>>> local_irq_enable();
>>>>
>>>> This placement, if really intended that way, needs explanation (in a
>>>> comment) and perhaps even renaming of the involved symbols, as
>>>> looking at it from a general perspective it seems wrong (with
>>>> pi_ctxt_switch_to() excluding idle vCPU-s it effectively means you
>>>> want this only when switching back to what got switched out lazily
>>>> before, i.e. this would be not something to take place on an arbitrary
>>>> context switch). As to possible alternative names - maybe make the
>>>> hooks ctxt_switch_prepare() and ctxt_switch_cancel()?
>>>
>>> Why on earth is this more clear than what he had before?
>>>
>>> In the first call, he's not "preparing" anything -- he's actually
>>> switching the PI context out for prev. And in the second call, he's
>>> not "cancelling" anything -- he's actually switching the PI context in
>>> for next. The names you suggest are actively confusing, not helpful.
>>>
>>> But before talking about how to make things more clear, one side
>>> question -- do we need to actually call pi_ctxt_switch_to() in
>>> __context_switch()?
>>>
>>> The only other place __context_switch() is called is
>>> from__sync_local_execstate(). But the only reason that needs to be
>>> called is because sometimes we *don't* call __context_switch(), and so
>>> there are things on the cpu that aren't copied into the vcpu struct.
>>
>> Thanks for the comments!
>>
>> From my understanding, __sync_local_execstate() can only get called
>> in the following two cases:
>> #1) this_cpu(curr_vcpu) == current, in this case, __context_switch() is
>> not called.
>> #2) this_cpu(curr_vcpu) != current, and current == idle_vcpu, that means
>> we just switched from a non-idle vCPU to idle vCPU, so here we need to
>> call __context_switch() to copy things to the original vcpu struct.
>>
>> Please correct me if the above understanding is wrong or incomplete?
>
> Hi George / Dario,
>
> Could you please confirm the above understanding is correct? (In fact, it is
> Related to lazy context switch, right?) if so I can continue with the
> pi_context_switch() way George suggested.
Yes, that's the general idea. Normally, you can access the registers of
a non-running vcpu from the vcpu struct. But if we've done a lazy
context switch, that's not true -- so to access those registers properly
we need to go through and do the full context switch *on that pcpu*.
Since we need to do the full context switch for PI every time, there
should never be any "local" state which needs to be synced.
I think at this point you should probably just give it a try. :-)
-George
next prev parent reply other threads:[~2015-09-21 9:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 5:07 [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts Wu, Feng
2015-09-21 9:45 ` George Dunlap [this message]
2015-09-21 12:07 ` Wu, Feng
-- strict thread matches above, loose matches on Subject: below --
2015-08-25 1:57 [PATCH v6 00/18] Add VT-d Posted-Interrupts support Feng Wu
2015-08-25 1:57 ` [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts Feng Wu
2015-09-07 12:54 ` Jan Beulich
2015-09-09 8:56 ` Wu, Feng
2015-09-09 10:26 ` Jan Beulich
2015-09-10 2:07 ` Wu, Feng
2015-09-10 8:27 ` Jan Beulich
2015-09-10 8:59 ` Wu, Feng
2015-09-10 9:26 ` Jan Beulich
2015-09-10 9:41 ` Wu, Feng
2015-09-10 10:01 ` Jan Beulich
2015-09-10 12:34 ` Wu, Feng
2015-09-10 12:44 ` Jan Beulich
2015-09-10 12:58 ` Wu, Feng
2015-09-10 13:15 ` Jan Beulich
2015-09-10 13:27 ` Wu, Feng
2015-09-10 14:01 ` Jan Beulich
2015-09-16 8:56 ` Wu, Feng
2015-09-16 17:08 ` George Dunlap
2015-09-17 6:26 ` Wu, Feng
2015-09-16 16:56 ` George Dunlap
2015-09-17 6:15 ` Wu, Feng
2015-09-21 8:23 ` Jan Beulich
2015-09-21 9:28 ` George Dunlap
2015-09-21 11:56 ` Jan Beulich
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=55FFD1A3.3040601@citrix.com \
--to=george.dunlap@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=feng.wu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).