n-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> >>> On 24.09.15 at 03:50, <feng...@intel.com> wrote:
> > One issue is the number of vmexits is far far bigger than the number of
> > context switch. I test it for a quite sho
>>> On 24.09.15 at 03:50, wrote:
> One issue is the number of vmexits is far far bigger than the number of
> context switch. I test it for a quite short time and it shows there are
> 2910043 vmexits and 71733 context switch (only count the number in
> __context_switch() since
>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Tuesday, September 22, 2015 5:00 PM
> >>> To: Wu, Feng
> >>> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian,
> >> Kevin;
> >>> xen-devel@lists.xen.org;
ge Dunlap; Tian, Kevin;
>> xen-devel@lists.xen.org; Keir Fraser
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On 09/22/2015 03:01 PM, Jan Beulich wrote:
>>>>>> On 22.09.15 at 15:40, <feng...@inte
>>> On 23.09.15 at 17:25, wrote:
> So, at the moment my *advice* is to look into setting SN / NDST on
> vmexit/vmentry, and only having hooks at block/unblock.
>
> However, the __context_switch() path is also OK with me, if Jan and
> Dario are happy.
>
> Jan / Dario,
bject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
> >
> > Yes, we can go to blocked only from running state. let me clarify a
> > question first: Xen doesn't support kernel preemption, right?
> >
> No, it does not.
>
> >
On Wed, 2015-09-23 at 06:35 +, Wu, Feng wrote:
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > On 09/22/2015 08:19 AM, Wu, Feng wrote:
> > > In the arch_block() hook, we actually need to
> > > - Put vCPU to the blocking list
> > > - Set the NV to wakeup vector
> > > - Set
ay, September 21, 2015 10:25 PM
> >> To: Wu, Feng; George Dunlap; George Dunlap
> >> Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper;
> >> xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logi
bject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
> >
> > I cannot think the bad effect of the spurious PI as well. I was just
> > a little
> > confused about we can do this and why we don't do this. Maybe
> > context_switch()
On Wed, 2015-09-23 at 05:52 +, Wu, Feng wrote:
> George & Dario, thanks much for sharing so many scheduler knowledge
> to me, it is very useful.
>
Well, we're lucky enough that it's our job to do that. :-D
> > > So the only downside to doing everything in block(), wake(), and
> > >
On Thu, 2015-09-24 at 01:50 +, Wu, Feng wrote:
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > This seems to me to be a cleaner design. It removes the need to
> > modify
> > any code on context-switch path. It moves modification of NDST and
> >
: Wu, Feng
>>> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian,
>> Kevin;
>>> xen-devel@lists.xen.org; Keir Fraser
>>> Subject: RE: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>>> logic
>>> handling
>>&
esday, September 23, 2015 5:44 PM
> >> To: Jan Beulich; Wu, Feng
> >> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; Tian, Kevin;
> >> xen-devel@lists.xen.org; Keir Fraser
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On 09/22/2015 02:25 PM, Wu, Feng wrote:
> >>> But if we want to avoid spurious PI interrupts when running idle, then
> >>> yes, we need *some* kind of a hook on the lazy con
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Tue, 2015-09-22 at 15:15 +0100, George Dunlap wrote:
> > On 09/22/2015 02:52 PM, Wu, Feng wrote:
> > >
> > >
> > > > -Original Message-
> >
>>> On 22.09.15 at 09:19, wrote:
> However, I do find some issues with my proposal above, see below:
>
> 1. Set _VPF_blocked
> 2. ret = arch_block()
> 3. if ( ret || local_events_need_delivery() )
> clear_bit(_VPF_blocked, >pause_flags);
>
> After step #2, if ret ==
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: George Dunlap [mailto:george.dun...@citrix.com]
>
> > > You a
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
> >
>
> > > -Original Message-
> > > From: George Dunlap [mailto:george.dun...@citrix.com]
>
> > Speci
aggioli [mailto:dario.faggi...@citrix.com]
> >>> Sent: Monday, September 21, 2015 10:12 PM
> >>> To: Wu, Feng; George Dunlap
> >>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap;
> Andrew
> >>> Cooper; Jan Beulich
> >&
On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> Specifically, consider the following scheduling case happened on
> pCPUA:
> vCPUA --> idle --> vCPUB
>
> 1. First, vCPUA is running on pCPUA, so the
evel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> >>> On 22.09.15 at 09:19, <feng...@intel.com> wrote:
> > However, I do find some issues with my proposal above, see below:
> >
> > 1. Set _VPF_blocked
>
; Keir Fraser; George Dunlap; Andrew
>> Cooper; Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
>>>
>>>> -Original Message
; Keir Fraser; Andrew Cooper;
>> xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
>>>
>>>> -Original Message--
Feng; George Dunlap
>>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
>>> Cooper; Jan Beulich
>>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>>> logic
>>> handling
>>>
>>> O
lap; George Dunlap; Tian,
> Kevin;
>> xen-devel@lists.xen.org; Keir Fraser
>> Subject: RE: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> >>> On 22.09.15 at 09:19, <feng...@intel.com> wrote:
>> &
; Keir Fraser; George Dunlap; Andrew
>> Cooper; Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
>>>
>>
>>>> -Original Me
On 09/22/2015 02:25 PM, Wu, Feng wrote:
>>> But if we want to avoid spurious PI interrupts when running idle, then
>>> yes, we need *some* kind of a hook on the lazy context switch path.
>>>
>>> /me does some more thinking...
>>
>> To be honest, since we'll be get spurious PI interrupts in the
>>
On Tue, 2015-09-22 at 15:15 +0100, George Dunlap wrote:
> On 09/22/2015 02:52 PM, Wu, Feng wrote:
> >
> >
> > > -Original Message-
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > > Yes, the idle to vCPUB switch is covered by __context_switch(),
> > > but
> > it cannot
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>
> > >
On Mon, 2015-09-21 at 11:59 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > > I think the handling for lazy context switch is not only for the
> > > blocking case,
> > > we still need to do something for lazy context switch
eptember 17, 2015 5:38 PM
> >> To: Dario Faggioli; Wu, Feng
> >> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap;
> Andrew
> >> Cooper; Jan Beulich
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
e: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Mon, 2015-09-21 at 11:59 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: George Dunlap [mailto:george.dun...@citrix.com]
>
>
On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@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
> >
On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > Note that, in case of preemptions, we are switching from a non-idle
> > vcpu to another, non-idle, vcpu, so lazy context switching to the
> > idle
>
e Dunlap; Tian, Kevin; Keir Fraser; Andrew Cooper;
>> xen-devel@lists.xen.org; Wu, Feng
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On Fri, Sep 18, 2015 at 3:31 PM, George Dunlap
>> <george.d
t;> Dunlap
> >> Sent: Friday, September 18, 2015 10:34 PM
> >> To: Dario Faggioli
> >> Cc: Jan Beulich; George Dunlap; Tian, Kevin; Keir Fraser; Andrew Cooper;
> >> xen-devel@lists.xen.org; Wu, Feng
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT
; Keir Fraser; George Dunlap; Andrew
>> Cooper; Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
>> logic
>> handling
>>
>> On 09/17/2015 09:48 AM, Dario Faggioli wrote:
>>> On Thu, 2015-09-17 at 08:00 +
g; Wu, Feng
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> handling
>
> On Fri, Sep 18, 2015 at 3:31 PM, George Dunlap
> <george.dun...@eu.citrix.com> wrote:
> >> As said, me too. Perhaps we can go for option 1, which is
>>> George Dunlap 09/17/15 4:30 PM >>>
>On 09/17/2015 01:40 PM, Dario Faggioli wrote:
>So one option is to do the "blocking" stuff in an arch-specific call
>from vcpu_block():
>
>vcpu_block()
>set(_VPF_blocked)
>v->arch.block()
>- Add v to pcpu.pi_blocked_vcpu
>-
On Fri, 2015-09-18 at 00:27 -0600, Jan Beulich wrote:
> > George Dunlap 09/17/15 4:30 PM >>>The
> > > > vcpu_block()
> >set(_VPF_blocked)
> >v->arch.block()
> >- Add v to pcpu.pi_blocked_vcpu
> >- NV => pi_wakeup_vector
> >local_events_need_delivery()
>
On Fri, Sep 18, 2015 at 3:31 PM, George Dunlap
wrote:
>> As said, me too. Perhaps we can go for option 1, which is simpler,
>> cleaner and more consistent, considering the current status of the
>> code. We can always investigate, in future, whether and how to
>>
On Fri, Sep 18, 2015 at 10:22 AM, Dario Faggioli
wrote:
> On Fri, 2015-09-18 at 00:27 -0600, Jan Beulich wrote:
>> > George Dunlap 09/17/15 4:30 PM >>>The
>
>> > > > vcpu_block()
>> >set(_VPF_blocked)
>> >v->arch.block()
>> >- Add v to
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Thursday, September 17, 2015 1:18 AM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel]
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Thursday, September 17, 2015 4:48 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel]
On 09/17/2015 10:38 AM, George Dunlap wrote:
> Is it the case that the interrupt is not actually delivered to the
> processor, but that the pending bit will be set in the pi field, so that
> the interrupt will be delivered the next time the hypervisor returns
> into the guest?
>
> (I am assuming
On 09/17/2015 10:38 AM, George Dunlap wrote:
> On 09/17/2015 09:48 AM, Dario Faggioli wrote:
>> On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote:
>>
-Original Message-
From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>>
So, I guess, first of all, can you confirm
On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote:
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > So, I guess, first of all, can you confirm whether or not it's exploding
> > in debug builds?
>
> Does the following information in Config.mk mean it
On 09/17/2015 09:48 AM, Dario Faggioli wrote:
> On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote:
>
>>> -Original Message-
>>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>
>>> So, I guess, first of all, can you confirm whether or not it's exploding
>>> in debug builds?
>>
On Thu, 2015-09-17 at 12:44 +0100, George Dunlap wrote:
> On 09/17/2015 10:38 AM, George Dunlap wrote:
> > Is it the case that the interrupt is not actually delivered to the
> > processor, but that the pending bit will be set in the pi field, so that
> > the interrupt will be delivered the next
On Thu, 2015-09-17 at 15:30 +0100, George Dunlap wrote:
> On 09/17/2015 01:40 PM, Dario Faggioli wrote:
> >> I haven't yet decided whether I prefer my original suggestion of
> >> switching the interrupt and putting things on the wake-up list in
> >> vcpu_block(), or of deferring adding things to
On 09/17/2015 01:40 PM, Dario Faggioli wrote:
> On Thu, 2015-09-17 at 12:44 +0100, George Dunlap wrote:
>> On 09/17/2015 10:38 AM, George Dunlap wrote:
>>> Is it the case that the interrupt is not actually delivered to the
>>> processor, but that the pending bit will be set in the pi field, so
On Fri, 2015-09-11 at 16:29 +0800, Feng Wu wrote:
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Kevin Tian
> CC: George Dunlap
> CC: Dario Faggioli
On Wed, 2015-09-16 at 19:18 +0200, Dario Faggioli wrote:
> On Fri, 2015-09-11 at 16:29 +0800, Feng Wu wrote:
> > One remaining item:
> > Jan has concern about calling vcpu_unblock() in vmx_pre_ctx_switch_pi(),
> > need Dario or George's input about this.
> >
> Hi,
>
> Sorry for the delay in
On Fri, 2015-09-11 at 16:29 +0800, Feng Wu wrote:
> This patch includes the following aspects:
> - Handling logic when vCPU is blocked:
> * Add a global vector to wake up the blocked vCPU
> when an interrupt is being posted to it (This part
> was sugguested by Yang Zhang
This patch includes the following aspects:
- Handling logic when vCPU is blocked:
* Add a global vector to wake up the blocked vCPU
when an interrupt is being posted to it (This part
was sugguested by Yang Zhang ).
* Define two per-cpu variables:
55 matches
Mail list logo