On Sun, Apr 28, 2013 at 12:20:12PM +0200, Jan Kiszka wrote:
> On 2013-04-28 12:19, Gleb Natapov wrote:
> > On Sun, Apr 28, 2013 at 12:15:05PM +0200, Jan Kiszka wrote:
> >> On 2013-03-17 09:47, Gleb Natapov wrote:
> >>> On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
> From: Jan Kis
On 2013-04-28 12:19, Gleb Natapov wrote:
> On Sun, Apr 28, 2013 at 12:15:05PM +0200, Jan Kiszka wrote:
>> On 2013-03-17 09:47, Gleb Natapov wrote:
>>> On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
From: Jan Kiszka
If the guest didn't take the last APIC timer interrupt
On Sun, Apr 28, 2013 at 12:15:05PM +0200, Jan Kiszka wrote:
> On 2013-03-17 09:47, Gleb Natapov wrote:
> > On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> If the guest didn't take the last APIC timer interrupt yet and generates
> >> another one on top, e
On 2013-03-17 09:47, Gleb Natapov wrote:
> On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If the guest didn't take the last APIC timer interrupt yet and generates
>> another one on top, e.g. via periodic mode, we do not block the VCPU
>> even if the guest sta
On Sun, Mar 24, 2013 at 10:45:53AM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-03-22:
> > On Fri, Mar 22, 2013 at 07:43:03AM -0300, Marcelo Tosatti wrote:
> >> On Fri, Mar 22, 2013 at 08:53:15AM +0200, Gleb Natapov wrote:
> >>> On Thu, Mar 21, 2013 at 08:06:41PM -0300, Marcelo Tosatti
Gleb Natapov wrote on 2013-03-22:
> On Fri, Mar 22, 2013 at 07:43:03AM -0300, Marcelo Tosatti wrote:
>> On Fri, Mar 22, 2013 at 08:53:15AM +0200, Gleb Natapov wrote:
>>> On Thu, Mar 21, 2013 at 08:06:41PM -0300, Marcelo Tosatti wrote:
On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrot
On Fri, Mar 22, 2013 at 07:43:03AM -0300, Marcelo Tosatti wrote:
> On Fri, Mar 22, 2013 at 08:53:15AM +0200, Gleb Natapov wrote:
> > On Thu, Mar 21, 2013 at 08:06:41PM -0300, Marcelo Tosatti wrote:
> > > On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote:
> > > > On Thu, Mar 21, 2013 at 0
On Fri, Mar 22, 2013 at 08:53:15AM +0200, Gleb Natapov wrote:
> On Thu, Mar 21, 2013 at 08:06:41PM -0300, Marcelo Tosatti wrote:
> > On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote:
> > > On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote:
> > > > > > > But current PI patc
On Thu, Mar 21, 2013 at 08:06:41PM -0300, Marcelo Tosatti wrote:
> On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote:
> > On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote:
> > > > > > But current PI patches do break them, thats my point. So we either
> > > > > > need to re
Marcelo Tosatti wrote on 2013-03-22:
> On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote:
>> On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote:
>> But current PI patches do break them, thats my point. So we either
>> need to revise them again, or drop LAPIC timer re
On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote:
> On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote:
> > > > > But current PI patches do break them, thats my point. So we either
> > > > > need to revise them again, or drop LAPIC timer reinjection. Making
> > > > > apic_a
On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote:
> > > > But current PI patches do break them, thats my point. So we either
> > > > need to revise them again, or drop LAPIC timer reinjection. Making
> > > > apic_accept_irq semantics "it returns coalescing info, but only
> > > > som
> > > But current PI patches do break them, thats my point. So we either
> > > need to revise them again, or drop LAPIC timer reinjection. Making
> > > apic_accept_irq semantics "it returns coalescing info, but only sometimes"
> > > is dubious though.
> > We may rollback to the initial idea: test b
On Thu, Mar 21, 2013 at 02:27:22PM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-03-21:
> > On Thu, Mar 21, 2013 at 11:02:24AM -0300, Marcelo Tosatti wrote:
> >> On Thu, Mar 21, 2013 at 06:54:46AM +0200, Gleb Natapov wrote:
> >>> On Wed, Mar 20, 2013 at 08:19:13PM -0300, Marcelo Tosatti
Gleb Natapov wrote on 2013-03-21:
> On Thu, Mar 21, 2013 at 11:02:24AM -0300, Marcelo Tosatti wrote:
>> On Thu, Mar 21, 2013 at 06:54:46AM +0200, Gleb Natapov wrote:
>>> On Wed, Mar 20, 2013 at 08:19:13PM -0300, Marcelo Tosatti wrote:
On Wed, Mar 20, 2013 at 11:32:38PM +0200, Gleb Natapov wrot
On Thu, Mar 21, 2013 at 11:02:24AM -0300, Marcelo Tosatti wrote:
> On Thu, Mar 21, 2013 at 06:54:46AM +0200, Gleb Natapov wrote:
> > On Wed, Mar 20, 2013 at 08:19:13PM -0300, Marcelo Tosatti wrote:
> > > On Wed, Mar 20, 2013 at 11:32:38PM +0200, Gleb Natapov wrote:
> > > > On Wed, Mar 20, 2013 at 0
On Thu, Mar 21, 2013 at 06:54:46AM +0200, Gleb Natapov wrote:
> On Wed, Mar 20, 2013 at 08:19:13PM -0300, Marcelo Tosatti wrote:
> > On Wed, Mar 20, 2013 at 11:32:38PM +0200, Gleb Natapov wrote:
> > > On Wed, Mar 20, 2013 at 05:03:19PM -0300, Marcelo Tosatti wrote:
> > > > On Wed, Mar 20, 2013 at 0
On Wed, Mar 20, 2013 at 08:19:13PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 20, 2013 at 11:32:38PM +0200, Gleb Natapov wrote:
> > On Wed, Mar 20, 2013 at 05:03:19PM -0300, Marcelo Tosatti wrote:
> > > On Wed, Mar 20, 2013 at 04:30:33PM -0300, Marcelo Tosatti wrote:
> > > > On Sun, Mar 17, 2013 a
On Wed, Mar 20, 2013 at 11:32:38PM +0200, Gleb Natapov wrote:
> On Wed, Mar 20, 2013 at 05:03:19PM -0300, Marcelo Tosatti wrote:
> > On Wed, Mar 20, 2013 at 04:30:33PM -0300, Marcelo Tosatti wrote:
> > > On Sun, Mar 17, 2013 at 12:47:17PM +0200, Gleb Natapov wrote:
> > > > On Sun, Mar 17, 2013 at 1
On Wed, Mar 20, 2013 at 05:03:19PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 20, 2013 at 04:30:33PM -0300, Marcelo Tosatti wrote:
> > On Sun, Mar 17, 2013 at 12:47:17PM +0200, Gleb Natapov wrote:
> > > On Sun, Mar 17, 2013 at 11:45:34AM +0100, Jan Kiszka wrote:
> > > > On 2013-03-17 09:47, Gleb N
On Wed, Mar 20, 2013 at 04:30:33PM -0300, Marcelo Tosatti wrote:
> On Sun, Mar 17, 2013 at 12:47:17PM +0200, Gleb Natapov wrote:
> > On Sun, Mar 17, 2013 at 11:45:34AM +0100, Jan Kiszka wrote:
> > > On 2013-03-17 09:47, Gleb Natapov wrote:
> > > > On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszk
On Sun, Mar 17, 2013 at 12:47:17PM +0200, Gleb Natapov wrote:
> On Sun, Mar 17, 2013 at 11:45:34AM +0100, Jan Kiszka wrote:
> > On 2013-03-17 09:47, Gleb Natapov wrote:
> > > On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
> > >> From: Jan Kiszka
> > >>
> > >> If the guest didn't take
On Sun, Mar 17, 2013 at 11:45:34AM +0100, Jan Kiszka wrote:
> On 2013-03-17 09:47, Gleb Natapov wrote:
> > On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> If the guest didn't take the last APIC timer interrupt yet and generates
> >> another one on top, e
On 2013-03-17 09:47, Gleb Natapov wrote:
> On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If the guest didn't take the last APIC timer interrupt yet and generates
>> another one on top, e.g. via periodic mode, we do not block the VCPU
>> even if the guest sta
On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> If the guest didn't take the last APIC timer interrupt yet and generates
> another one on top, e.g. via periodic mode, we do not block the VCPU
> even if the guest state is halted. The reason is that
> apic_has_pen
From: Jan Kiszka
If the guest didn't take the last APIC timer interrupt yet and generates
another one on top, e.g. via periodic mode, we do not block the VCPU
even if the guest state is halted. The reason is that
apic_has_pending_timer continues to return a non-zero value.
Fix this busy loop by
26 matches
Mail list logo
