* [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked @ 2009-09-10 5:47 Kouya Shimura 2009-09-10 6:49 ` Keir Fraser 2009-09-11 12:07 ` Konrad Rzeszutek Wilk 0 siblings, 2 replies; 18+ messages in thread From: Kouya Shimura @ 2009-09-10 5:47 UTC (permalink / raw) To: xen-devel [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 328 bytes --] Hi, I've found that modern windows OS never use the PIT timer, and neither cpu#0's LAPIC timer after boot. Despite that, xen emulates them busily. It's inefficient. Note: this patch ignores the IRQ mask of legacy i8259 since rombios frequently modifies it. Thanks, Kouya Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> [-- Attachment #2: freeze_vpt.patch --] [-- Type: text/x-patch, Size: 5928 bytes --] diff -r d2a32e24fe50 xen/arch/x86/hvm/i8254.c --- a/xen/arch/x86/hvm/i8254.c Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/arch/x86/hvm/i8254.c Thu Sep 10 09:55:29 2009 +0900 @@ -421,6 +421,8 @@ static int pit_load(struct domain *d, hv spin_unlock(&pit->lock); + pt_freeze_pit_timer_if_irqmasked(d); + return 0; } diff -r d2a32e24fe50 xen/arch/x86/hvm/vioapic.c --- a/xen/arch/x86/hvm/vioapic.c Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/arch/x86/hvm/vioapic.c Thu Sep 10 09:55:29 2009 +0900 @@ -158,6 +158,9 @@ static void vioapic_write_redirent( pent->fields.remote_irr = 1; vioapic_deliver(vioapic, idx); } + + if ( idx == hvm_isa_irq_to_gsi(0) && !top_word ) + pt_freeze_pit_timer_if_irqmasked(d); spin_unlock(&d->arch.hvm_domain.irq_lock); } diff -r d2a32e24fe50 xen/arch/x86/hvm/vlapic.c --- a/xen/arch/x86/hvm/vlapic.c Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/arch/x86/hvm/vlapic.c Thu Sep 10 09:55:29 2009 +0900 @@ -655,6 +655,8 @@ static int vlapic_write(struct vcpu *v, vlapic_set_reg(vlapic, offset, val); if ( offset == APIC_LVT0 ) vlapic_adjust_i8259_target(v->domain); + if ( offset == APIC_LVTT ) + pt_freeze_lapic_timer_if_irqmasked(&vlapic->pt); break; case APIC_TMICT: @@ -770,10 +772,13 @@ void vlapic_adjust_i8259_target(struct d v = d->vcpu ? d->vcpu[0] : NULL; found: - if ( d->arch.hvm_domain.i8259_target == v ) - return; - d->arch.hvm_domain.i8259_target = v; - pt_adjust_global_vcpu_target(v); + if ( d->arch.hvm_domain.i8259_target != v ) + { + d->arch.hvm_domain.i8259_target = v; + pt_adjust_global_vcpu_target(v); + } + + pt_freeze_pit_timer_if_irqmasked(d); } int vlapic_has_pending_irq(struct vcpu *v) @@ -934,6 +939,7 @@ static int lapic_load_regs(struct domain vlapic_adjust_i8259_target(d); lapic_rearm(s); + pt_freeze_lapic_timer_if_irqmasked(&s->pt); return 0; } diff -r d2a32e24fe50 xen/arch/x86/hvm/vpt.c --- a/xen/arch/x86/hvm/vpt.c Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/arch/x86/hvm/vpt.c Thu Sep 10 09:55:29 2009 +0900 @@ -211,6 +211,10 @@ static void pt_timer_fn(void *data) pt_process_missed_ticks(pt); set_timer(&pt->timer, pt->scheduled); } + else + { + pt->frozen_by_irqmask = 0; + } if ( !pt_irq_masked(pt) ) vcpu_kick(pt->vcpu); @@ -394,6 +398,7 @@ void create_periodic_time( pt->on_list = 1; list_add(&pt->list, &v->arch.hvm_vcpu.tm_list); + pt->frozen_by_irqmask = 0; init_timer(&pt->timer, pt_timer_fn, pt, v->processor); set_timer(&pt->timer, pt->scheduled); @@ -411,6 +416,7 @@ void destroy_periodic_time(struct period if ( pt->on_list ) list_del(&pt->list); pt->on_list = 0; + pt->frozen_by_irqmask = 0; pt_unlock(pt); /* @@ -469,3 +475,75 @@ void pt_adjust_global_vcpu_target(struct pt_adjust_vcpu(&pl_time->vhpet.pt[i], v); spin_unlock(&pl_time->vhpet.lock); } + + +static void pt_freeze_timer(struct periodic_time *pt) +{ + struct vcpu *v = NULL; + + pt_lock(pt); + if ( pt->on_list ) + { + v = pt->vcpu; + pt->frozen_by_irqmask = 1; + pt->on_list = 0; + list_del(&pt->list); + stop_timer(&pt->timer); + } + pt_unlock(pt); + + if ( v ) + gdprintk(XENLOG_INFO, "vcpu%d freeze %s timer(irq=%d)\n", v->vcpu_id, + pt->source == PTSRC_lapic ? "LAPIC" : "ISA", pt->irq); +} + +static void pt_thaw_timer(struct periodic_time *pt) +{ + struct vcpu *v = NULL; + + pt_lock(pt); + if ( !pt->on_list && pt->frozen_by_irqmask ) + { + v = pt->vcpu; + pt->on_list = 1; + list_add(&pt->list, &v->arch.hvm_vcpu.tm_list); + migrate_timer(&pt->timer, v->processor); + /* + * It may set the past time, however, TIMER_SOFTIRQ is raised + * and pt_timer_fn() will reset the timer appropriately. + */ + set_timer(&pt->timer, pt->scheduled); + } + pt->frozen_by_irqmask = 0; + pt_unlock(pt); + + if ( v ) + gdprintk(XENLOG_INFO, "vcpu%d thaw %s timer(irq=%d)\n", v->vcpu_id, + pt->source == PTSRC_lapic ? "LAPIC" : "ISA", pt->irq); +} + +void pt_freeze_pit_timer_if_irqmasked(struct domain *d) +{ + struct periodic_time *pt = &d->arch.hvm_domain.pl_time.vpit.pt0; + unsigned int gsi = hvm_isa_irq_to_gsi(pt->irq); + + if ( pt->vcpu == NULL ) + return; + + if ( !vlapic_accept_pic_intr(pt->vcpu) && + domain_vioapic(d)->redirtbl[gsi].fields.mask ) + pt_freeze_timer(pt); + else + pt_thaw_timer(pt); +} + +void pt_freeze_lapic_timer_if_irqmasked(struct periodic_time *pt) +{ + if ( pt->vcpu == NULL ) + return; + + if (vlapic_get_reg(vcpu_vlapic(pt->vcpu), APIC_LVTT) & APIC_LVT_MASKED) + pt_freeze_timer(pt); + else + pt_thaw_timer(pt); +} diff -r d2a32e24fe50 xen/include/asm-x86/hvm/vpt.h --- a/xen/include/asm-x86/hvm/vpt.h Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/include/asm-x86/hvm/vpt.h Thu Sep 10 09:55:29 2009 +0900 @@ -44,6 +44,7 @@ struct periodic_time { bool_t do_not_freeze; bool_t irq_issued; bool_t warned_timeout_too_short; + bool_t frozen_by_irqmask; #define PTSRC_isa 1 /* ISA time source */ #define PTSRC_lapic 2 /* LAPIC time source */ u8 source; /* PTSRC_ */ @@ -145,7 +146,10 @@ void pt_adjust_global_vcpu_target(struct ((d)->arch.hvm_domain.i8259_target ? : (d)->vcpu ? (d)->vcpu[0] : NULL) /* Is given periodic timer active? */ -#define pt_active(pt) ((pt)->on_list) +#define pt_active(pt) ((pt)->on_list || (pt)->frozen_by_irqmask) + +void pt_freeze_pit_timer_if_irqmasked(struct domain *d); +void pt_freeze_lapic_timer_if_irqmasked(struct periodic_time *pt); /* * Create/destroy a periodic (or one-shot!) timer. [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 5:47 [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked Kouya Shimura @ 2009-09-10 6:49 ` Keir Fraser 2009-09-10 8:22 ` Kouya Shimura 2009-09-11 12:07 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 18+ messages in thread From: Keir Fraser @ 2009-09-10 6:49 UTC (permalink / raw) To: Kouya Shimura, xen-devel Although I can see the sense here, the patch makes me a bit uneasy. Also I think neater code would result from simply making vpt.c's handling of periodic timers less stupid. By this I mean that calling set_timer() from the timer handler is not really necessary -- you already know an interrupt is now pending and the vcpu is kicked. May as well not set_timer() until the pending interrupt(s) are delivered. That would then effectively get your optimisation "for free", wouldn't it? -- Keir On 10/09/2009 06:47, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > Hi, > > I've found that modern windows OS never use the PIT timer, > and neither cpu#0's LAPIC timer after boot. > Despite that, xen emulates them busily. It's inefficient. > > Note: this patch ignores the IRQ mask of legacy i8259 since > rombios frequently modifies it. > > Thanks, > Kouya > > Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 6:49 ` Keir Fraser @ 2009-09-10 8:22 ` Kouya Shimura 2009-09-10 8:32 ` Keir Fraser 0 siblings, 1 reply; 18+ messages in thread From: Kouya Shimura @ 2009-09-10 8:22 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel Well, this patch has two aims. One is to stop the xen's timer by stop_timer(). And another is to simplify pt_update_irq() which searches the earliest platform timer. To answer the latter aim, this patch gets rid of unused (masked by IRQ) platform timer from vcpu->arch.hvm_vcpu.tm_list. Your suggestion satisfies the first but the latter, I think. Besides, pt_update_irq() is more critical since it is called on every VM_EXIT. Although I understand your uneasiness, is there any other way? Thanks, Kouya Keir Fraser writes: > Although I can see the sense here, the patch makes me a bit uneasy. Also I > think neater code would result from simply making vpt.c's handling of > periodic timers less stupid. By this I mean that calling set_timer() from > the timer handler is not really necessary -- you already know an interrupt > is now pending and the vcpu is kicked. May as well not set_timer() until the > pending interrupt(s) are delivered. That would then effectively get your > optimisation "for free", wouldn't it? > > -- Keir > > On 10/09/2009 06:47, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > > > Hi, > > > > I've found that modern windows OS never use the PIT timer, > > and neither cpu#0's LAPIC timer after boot. > > Despite that, xen emulates them busily. It's inefficient. > > > > Note: this patch ignores the IRQ mask of legacy i8259 since > > rombios frequently modifies it. > > > > Thanks, > > Kouya > > > > Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 8:22 ` Kouya Shimura @ 2009-09-10 8:32 ` Keir Fraser 2009-09-10 9:54 ` Kouya Shimura 0 siblings, 1 reply; 18+ messages in thread From: Keir Fraser @ 2009-09-10 8:32 UTC (permalink / raw) To: Kouya Shimura; +Cc: xen-devel Do you get a measurable performance win from this patch? Not using pt_irq_masked() seems odd. Is it to avoid 859 IRQ mask checks, and if so why are you doing that? Why do we care that rombios twiddles the 8259 masks a bunch during boot? -- Keir On 10/09/2009 09:22, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > Well, this patch has two aims. One is to stop the xen's timer by > stop_timer(). And another is to simplify pt_update_irq() which > searches the earliest platform timer. > > To answer the latter aim, this patch gets rid of unused (masked > by IRQ) platform timer from vcpu->arch.hvm_vcpu.tm_list. > Your suggestion satisfies the first but the latter, I think. > Besides, pt_update_irq() is more critical since it is called on > every VM_EXIT. > > Although I understand your uneasiness, is there any other way? > > Thanks, > Kouya > > Keir Fraser writes: >> Although I can see the sense here, the patch makes me a bit uneasy. Also I >> think neater code would result from simply making vpt.c's handling of >> periodic timers less stupid. By this I mean that calling set_timer() from >> the timer handler is not really necessary -- you already know an interrupt >> is now pending and the vcpu is kicked. May as well not set_timer() until the >> pending interrupt(s) are delivered. That would then effectively get your >> optimisation "for free", wouldn't it? >> >> -- Keir >> >> On 10/09/2009 06:47, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: >> >>> Hi, >>> >>> I've found that modern windows OS never use the PIT timer, >>> and neither cpu#0's LAPIC timer after boot. >>> Despite that, xen emulates them busily. It's inefficient. >>> >>> Note: this patch ignores the IRQ mask of legacy i8259 since >>> rombios frequently modifies it. >>> >>> Thanks, >>> Kouya >>> >>> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> >>> >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 8:32 ` Keir Fraser @ 2009-09-10 9:54 ` Kouya Shimura 2009-09-10 12:32 ` Keir Fraser 0 siblings, 1 reply; 18+ messages in thread From: Kouya Shimura @ 2009-09-10 9:54 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel Keir Fraser writes: > Do you get a measurable performance win from this patch? Sorry, I don't measure yet. Probably a little bit win. > Not using pt_irq_masked() seems odd. Is it to avoid 859 IRQ mask checks, and > if so why are you doing that? Why do we care that rombios twiddles the 8259 > masks a bunch during boot? I guessed that the cost of freezing/thawing a timer with the 8259 mask is higher than timer emulation. And the PIT timer is actually active while rombios masks the 8259. If using pt_irq_masked() is desirable, I'll remake it. Thanks, Kouya > > -- Keir > > On 10/09/2009 09:22, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > > > Well, this patch has two aims. One is to stop the xen's timer by > > stop_timer(). And another is to simplify pt_update_irq() which > > searches the earliest platform timer. > > > > To answer the latter aim, this patch gets rid of unused (masked > > by IRQ) platform timer from vcpu->arch.hvm_vcpu.tm_list. > > Your suggestion satisfies the first but the latter, I think. > > Besides, pt_update_irq() is more critical since it is called on > > every VM_EXIT. > > > > Although I understand your uneasiness, is there any other way? > > > > Thanks, > > Kouya > > > > Keir Fraser writes: > >> Although I can see the sense here, the patch makes me a bit uneasy. Also I > >> think neater code would result from simply making vpt.c's handling of > >> periodic timers less stupid. By this I mean that calling set_timer() from > >> the timer handler is not really necessary -- you already know an interrupt > >> is now pending and the vcpu is kicked. May as well not set_timer() until the > >> pending interrupt(s) are delivered. That would then effectively get your > >> optimisation "for free", wouldn't it? > >> > >> -- Keir > >> > >> On 10/09/2009 06:47, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > >> > >>> Hi, > >>> > >>> I've found that modern windows OS never use the PIT timer, > >>> and neither cpu#0's LAPIC timer after boot. > >>> Despite that, xen emulates them busily. It's inefficient. > >>> > >>> Note: this patch ignores the IRQ mask of legacy i8259 since > >>> rombios frequently modifies it. > >>> > >>> Thanks, > >>> Kouya > >>> > >>> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> > >>> > >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 9:54 ` Kouya Shimura @ 2009-09-10 12:32 ` Keir Fraser 2009-09-16 6:46 ` Kouya Shimura 0 siblings, 1 reply; 18+ messages in thread From: Keir Fraser @ 2009-09-10 12:32 UTC (permalink / raw) To: Kouya Shimura; +Cc: xen-devel On 10/09/2009 10:54, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: >> Not using pt_irq_masked() seems odd. Is it to avoid 859 IRQ mask checks, and >> if so why are you doing that? Why do we care that rombios twiddles the 8259 >> masks a bunch during boot? > > I guessed that the cost of freezing/thawing a timer with the 8259 mask > is higher than timer emulation. And the PIT timer is actually active > while rombios masks the 8259. > > If using pt_irq_masked() is desirable, I'll remake it. If your patch works without even any theoretical lost of correctness, then that makes it more attractive, obviously. Some evidence that the cost saving is at all measurable would also be good. Premature optimisation being evil, etc. ;-) -- Keir ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 12:32 ` Keir Fraser @ 2009-09-16 6:46 ` Kouya Shimura 2009-09-16 6:50 ` [PATCH 1/2] x86 hvm: don't set periodical timer again until its IRQ is delivered Kouya Shimura 2009-09-16 7:40 ` [PATCH] x86 hvm: freeze PIT/LAPIC " Keir Fraser 0 siblings, 2 replies; 18+ messages in thread From: Kouya Shimura @ 2009-09-16 6:46 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 1194 bytes --] I remade the patch and measured the performance win. Attached is a benchmark program which I wrote. It is complied by cygwin's gcc by -O2 and runs on Windows XP(32bit). And my cpu is Intel Core2 Quad Q9450@2.66GHz. The result is that my patch saves 32 cycles(TSC) per one VM_EXIT(cpuid). (2696 tsc => 2664 tsc) The patch is split to two. I'll post them in another mail. Thanks, Kouya Keir Fraser writes: > On 10/09/2009 10:54, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > > >> Not using pt_irq_masked() seems odd. Is it to avoid 859 IRQ mask checks, and > >> if so why are you doing that? Why do we care that rombios twiddles the 8259 > >> masks a bunch during boot? > > > > I guessed that the cost of freezing/thawing a timer with the 8259 mask > > is higher than timer emulation. And the PIT timer is actually active > > while rombios masks the 8259. > > > > If using pt_irq_masked() is desirable, I'll remake it. > > If your patch works without even any theoretical lost of correctness, then > that makes it more attractive, obviously. > > Some evidence that the cost saving is at all measurable would also be good. > Premature optimisation being evil, etc. ;-) > > -- Keir [-- Attachment #2: cpuidbench.c --] [-- Type: text/plain, Size: 368 bytes --] #include <stdio.h> #include <stdint.h> #define rdtsc(val) asm volatile("rdtsc" : "=a" (val)) static void cpuid(uint32_t idx) { uint32_t a,b,c,d; asm volatile("cpuid": "=a"(a), "=b"(b), "=c"(c), "=d"(d) : "0"(idx) ); } main() { uint32_t tsc1, tsc2; while(1) { rdtsc(tsc1); cpuid(0x40000000); rdtsc(tsc2); printf("tsc=%d\n", tsc2 - tsc1); } } [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 1/2] x86 hvm: don't set periodical timer again until its IRQ is delivered. 2009-09-16 6:46 ` Kouya Shimura @ 2009-09-16 6:50 ` Kouya Shimura 2009-09-16 6:53 ` [PATCH 2/2] x86 hvm: suspend platform timer emulation while its IRQ is masked Kouya Shimura 2009-09-16 7:40 ` [PATCH] x86 hvm: freeze PIT/LAPIC " Keir Fraser 1 sibling, 1 reply; 18+ messages in thread From: Kouya Shimura @ 2009-09-16 6:50 UTC (permalink / raw) To: xen-devel; +Cc: Keir Fraser [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 536 bytes --] Modern Windows OS (ex XP,2003,2008) never use the PIT timer, and neither cpu#0's LAPIC timer after boot. Despite that, xen emulates them busily. It's inefficient. With this patch, setting a timer is defered while its IRQ is masked. The reasons why pt_timer_fn() simply calls vcpu_kick() are: - checking by pt_irq_masked() is duplicated. pt_update_irq() also does. - pt_timer_fn() is likely called on the same processor as pt->vcpu->processor. Hence vcpu_kick() hardly send IPI. Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> [-- Attachment #2: vpt1.patch --] [-- Type: text/x-patch, Size: 2364 bytes --] # HG changeset patch # User Kouya Shimura <kouya@jp.fujitsu.com> # Date 1253081156 -32400 # Node ID 864f20763d03ef989501fbc43d74034027679a56 # Parent d2a32e24fe504b9626e6732b4f213c7cb1bc8b57 x86 hvm: don't set periodical timer again until its IRQ is delivered. Modern Windows OS (ex XP,2003,2008) never use the PIT timer, and neither cpu#0's LAPIC timer after boot. Despite that, xen emulates them busily. It's inefficient. With this patch, setting a timer is defered while its IRQ is masked. The reasons why pt_timer_fn() simply calls vcpu_kick() are: - checking by pt_irq_masked() is duplicated. pt_update_irq() also does. - pt_timer_fn() is likely called on the same processor as pt->vcpu->processor. Hence vcpu_kick() hardly send IPI. Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> diff -r d2a32e24fe50 -r 864f20763d03 xen/arch/x86/hvm/vpt.c --- a/xen/arch/x86/hvm/vpt.c Wed Sep 09 16:39:41 2009 +0100 +++ b/xen/arch/x86/hvm/vpt.c Wed Sep 16 15:05:56 2009 +0900 @@ -187,8 +187,11 @@ void pt_restore_timer(struct vcpu *v) list_for_each_entry ( pt, head, list ) { - pt_process_missed_ticks(pt); - set_timer(&pt->timer, pt->scheduled); + if ( pt->pending_intr_nr == 0 ) + { + pt_process_missed_ticks(pt); + set_timer(&pt->timer, pt->scheduled); + } } pt_thaw_time(v); @@ -205,15 +208,7 @@ static void pt_timer_fn(void *data) pt->pending_intr_nr++; pt->do_not_freeze = 0; - if ( !pt->one_shot ) - { - pt->scheduled += pt->period; - pt_process_missed_ticks(pt); - set_timer(&pt->timer, pt->scheduled); - } - - if ( !pt_irq_masked(pt) ) - vcpu_kick(pt->vcpu); + vcpu_kick(pt->vcpu); pt_unlock(pt); } @@ -302,6 +297,9 @@ void pt_intr_post(struct vcpu *v, struct } else { + pt->scheduled += pt->period; + pt_process_missed_ticks(pt); + if ( mode_is(v->domain, one_missed_tick_pending) || mode_is(v->domain, no_missed_ticks_pending) ) { @@ -313,6 +311,9 @@ void pt_intr_post(struct vcpu *v, struct pt->last_plt_gtime += pt->period; pt->pending_intr_nr--; } + + if ( pt->pending_intr_nr == 0 ) + set_timer(&pt->timer, pt->scheduled); } if ( mode_is(v->domain, delay_for_missed_ticks) && [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] x86 hvm: suspend platform timer emulation while its IRQ is masked 2009-09-16 6:50 ` [PATCH 1/2] x86 hvm: don't set periodical timer again until its IRQ is delivered Kouya Shimura @ 2009-09-16 6:53 ` Kouya Shimura 0 siblings, 0 replies; 18+ messages in thread From: Kouya Shimura @ 2009-09-16 6:53 UTC (permalink / raw) To: xen-devel; +Cc: Keir Fraser [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 904 bytes --] This patch gets rid of a timer which IRQ is masked from vcpu's timer list. It reduces the overhead of VM EXIT and context switch of vm. Also fixes a potential bug. (1) VCPU#0: mask the IRQ of a timer. (ex. vioapic.redir[2].mask=1) (2) VCPU#1: pt_timer_fn() is invoked by expiration of the timer. (3) VCPU#1: pt_update_irq() is called but does nothing by pt_irq_masked()=1. (4) VCPU#1: sleep by halt. (5) VCPU#0: unmask the IRQ of the timer. After that, no one wakes up the VCPU#1. IRQ of ISA is masked by: - PIC's IMR - IOAPIC's redir[0] - IOAPIC's redir[N].mask - LAPIC's LVT0 - LAPIC enabled/disabled IRQ of LAPIC timer is masked by: - LAPIC's LVTT - LAPIC disabled When above stuffs are changed, the corresponding vcpu is kicked and suspended timer emulation is resumed. In addition, a small bug fix in pt_adjust_global_vcpu_target(). Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> [-- Attachment #2: vpt2.patch --] [-- Type: text/x-patch, Size: 8310 bytes --] # HG changeset patch # User Kouya Shimura <kouya@jp.fujitsu.com> # Date 1253080328 -32400 # Node ID b62a5e4c6125e62fd5fd1e28f7ae1c8a093b689d # Parent 58ef1439ca982cdd2f7e4698ce9bdba1f4b38853 x86 hvm: suspend platform timer emulation while its IRQ is masked This patch gets rid of a timer which IRQ is masked from vcpu's timer list. It reduces the overhead of VM EXIT and context switch of vm. Also fixes a potential bug. (1) VCPU#0: mask the IRQ of a timer. (ex. vioapic.redir[2].mask=1) (2) VCPU#1: pt_timer_fn() is invoked by expiration of the timer. (3) VCPU#1: pt_update_irq() is called but does nothing by pt_irq_masked()=1. (4) VCPU#1: sleep by halt. (5) VCPU#0: unmask the IRQ of the timer. After that, no one wakes up the VCPU#1. IRQ of ISA is masked by: - PIC's IMR - IOAPIC's redir[0] - IOAPIC's redir[N].mask - LAPIC's LVT0 - LAPIC enabled/disabled IRQ of LAPIC timer is masked by: - LAPIC's LVTT - LAPIC disabled When above stuffs are changed, the corresponding vcpu is kicked and suspended timer emulation is resumed. In addition, a small bug fix in pt_adjust_global_vcpu_target(). Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> diff -r 58ef1439ca98 -r b62a5e4c6125 xen/arch/x86/hvm/vioapic.c --- a/xen/arch/x86/hvm/vioapic.c Tue Sep 15 10:08:12 2009 +0100 +++ b/xen/arch/x86/hvm/vioapic.c Wed Sep 16 14:52:08 2009 +0900 @@ -125,6 +125,7 @@ static void vioapic_write_redirent( struct domain *d = vioapic_domain(vioapic); struct hvm_irq *hvm_irq = &d->arch.hvm_domain.irq; union vioapic_redir_entry *pent, ent; + int unmasked = 0; spin_lock(&d->arch.hvm_domain.irq_lock); @@ -138,10 +139,12 @@ static void vioapic_write_redirent( } else { + unmasked = ent.fields.mask; /* Remote IRR and Delivery Status are read-only. */ ent.bits = ((ent.bits >> 32) << 32) | val; ent.fields.delivery_status = 0; ent.fields.remote_irr = pent->fields.remote_irr; + unmasked = unmasked && !ent.fields.mask; } *pent = ent; @@ -160,6 +163,9 @@ static void vioapic_write_redirent( } spin_unlock(&d->arch.hvm_domain.irq_lock); + + if ( idx == 0 || unmasked ) + pt_may_unmask_irq(d, NULL); } static void vioapic_write_indirect( diff -r 58ef1439ca98 -r b62a5e4c6125 xen/arch/x86/hvm/vlapic.c --- a/xen/arch/x86/hvm/vlapic.c Tue Sep 15 10:08:12 2009 +0100 +++ b/xen/arch/x86/hvm/vlapic.c Wed Sep 16 14:52:08 2009 +0900 @@ -624,7 +624,10 @@ static int vlapic_write(struct vcpu *v, } } else + { vlapic->hw.disabled &= ~VLAPIC_SW_DISABLED; + pt_may_unmask_irq(vlapic_domain(vlapic), &vlapic->pt); + } break; case APIC_ESR: @@ -654,7 +657,12 @@ static int vlapic_write(struct vcpu *v, val &= vlapic_lvt_mask[(offset - APIC_LVTT) >> 4]; vlapic_set_reg(vlapic, offset, val); if ( offset == APIC_LVT0 ) + { vlapic_adjust_i8259_target(v->domain); + pt_may_unmask_irq(v->domain, NULL); + } + if ( (offset == APIC_LVTT) && !(val & APIC_LVT_MASKED) ) + pt_may_unmask_irq(NULL, &vlapic->pt); break; case APIC_TMICT: @@ -719,10 +727,12 @@ void vlapic_msr_set(struct vlapic *vlapi { vlapic_reset(vlapic); vlapic->hw.disabled &= ~VLAPIC_HW_DISABLED; + pt_may_unmask_irq(vlapic_domain(vlapic), &vlapic->pt); } else { vlapic->hw.disabled |= VLAPIC_HW_DISABLED; + pt_may_unmask_irq(vlapic_domain(vlapic), NULL); } } diff -r 58ef1439ca98 -r b62a5e4c6125 xen/arch/x86/hvm/vpic.c --- a/xen/arch/x86/hvm/vpic.c Tue Sep 15 10:08:12 2009 +0100 +++ b/xen/arch/x86/hvm/vpic.c Wed Sep 16 14:52:08 2009 +0900 @@ -178,7 +178,7 @@ static void vpic_ioport_write( struct hvm_hw_vpic *vpic, uint32_t addr, uint32_t val) { int priority, cmd, irq; - uint8_t mask; + uint8_t mask, unmasked = 0; vpic_lock(vpic); @@ -190,6 +190,7 @@ static void vpic_ioport_write( /* Clear edge-sensing logic. */ vpic->irr &= vpic->elcr; + unmasked = vpic->imr; /* No interrupts masked or in service. */ vpic->imr = vpic->isr = 0; @@ -268,6 +269,7 @@ static void vpic_ioport_write( { case 0: /* OCW1 */ + unmasked = vpic->imr & (~val); vpic->imr = val; break; case 1: @@ -295,6 +297,9 @@ static void vpic_ioport_write( vpic_update_int_output(vpic); vpic_unlock(vpic); + + if ( unmasked ) + pt_may_unmask_irq(vpic_domain(vpic), NULL); } static uint32_t vpic_ioport_read(struct hvm_hw_vpic *vpic, uint32_t addr) diff -r 58ef1439ca98 -r b62a5e4c6125 xen/arch/x86/hvm/vpt.c --- a/xen/arch/x86/hvm/vpt.c Tue Sep 15 10:08:12 2009 +0100 +++ b/xen/arch/x86/hvm/vpt.c Wed Sep 16 14:52:08 2009 +0900 @@ -221,19 +221,30 @@ void pt_update_irq(struct vcpu *v) void pt_update_irq(struct vcpu *v) { struct list_head *head = &v->arch.hvm_vcpu.tm_list; - struct periodic_time *pt, *earliest_pt = NULL; + struct periodic_time *pt, *temp, *earliest_pt = NULL; uint64_t max_lag = -1ULL; int irq, is_lapic; spin_lock(&v->arch.hvm_vcpu.tm_lock); - list_for_each_entry ( pt, head, list ) + list_for_each_entry_safe ( pt, temp, head, list ) { - if ( pt->pending_intr_nr && !pt_irq_masked(pt) && - ((pt->last_plt_gtime + pt->period) < max_lag) ) + if ( pt->pending_intr_nr ) { - max_lag = pt->last_plt_gtime + pt->period; - earliest_pt = pt; + if ( pt_irq_masked(pt) ) + { + /* suspend timer emulation */ + list_del(&pt->list); + pt->on_list = 0; + } + else + { + if ( (pt->last_plt_gtime + pt->period) < max_lag ) + { + max_lag = pt->last_plt_gtime + pt->period; + earliest_pt = pt; + } + } } } @@ -411,6 +422,7 @@ void destroy_periodic_time(struct period if ( pt->on_list ) list_del(&pt->list); pt->on_list = 0; + pt->pending_intr_nr = 0; pt_unlock(pt); /* @@ -450,11 +462,13 @@ static void pt_adjust_vcpu(struct period void pt_adjust_global_vcpu_target(struct vcpu *v) { - struct pl_time *pl_time = &v->domain->arch.hvm_domain.pl_time; + struct pl_time *pl_time; int i; if ( v == NULL ) return; + + pl_time = &v->domain->arch.hvm_domain.pl_time; spin_lock(&pl_time->vpit.lock); pt_adjust_vcpu(&pl_time->vpit.pt0, v); @@ -469,3 +483,35 @@ void pt_adjust_global_vcpu_target(struct pt_adjust_vcpu(&pl_time->vhpet.pt[i], v); spin_unlock(&pl_time->vhpet.lock); } + + +static void pt_resume(struct periodic_time *pt) +{ + if ( pt->vcpu == NULL ) + return; + + pt_lock(pt); + if ( pt->pending_intr_nr && !pt->on_list ) + { + pt->on_list = 1; + list_add(&pt->list, &pt->vcpu->arch.hvm_vcpu.tm_list); + vcpu_kick(pt->vcpu); + } + pt_unlock(pt); +} + +void pt_may_unmask_irq(struct domain *d, struct periodic_time *vlapic_pt) +{ + int i; + + if ( d ) + { + pt_resume(&d->arch.hvm_domain.pl_time.vpit.pt0); + pt_resume(&d->arch.hvm_domain.pl_time.vrtc.pt); + for ( i = 0; i < HPET_TIMER_NUM; i++ ) + pt_resume(&d->arch.hvm_domain.pl_time.vhpet.pt[i]); + } + + if ( vlapic_pt ) + pt_resume(vlapic_pt); +} diff -r 58ef1439ca98 -r b62a5e4c6125 xen/include/asm-x86/hvm/vpt.h --- a/xen/include/asm-x86/hvm/vpt.h Tue Sep 15 10:08:12 2009 +0100 +++ b/xen/include/asm-x86/hvm/vpt.h Wed Sep 16 14:52:08 2009 +0900 @@ -144,8 +144,10 @@ void pt_adjust_global_vcpu_target(struct #define pt_global_vcpu_target(d) \ ((d)->arch.hvm_domain.i8259_target ? : (d)->vcpu ? (d)->vcpu[0] : NULL) +void pt_may_unmask_irq(struct domain *d, struct periodic_time *vlapic_pt); + /* Is given periodic timer active? */ -#define pt_active(pt) ((pt)->on_list) +#define pt_active(pt) ((pt)->on_list || (pt)->pending_intr_nr) /* * Create/destroy a periodic (or one-shot!) timer. [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 6:46 ` Kouya Shimura 2009-09-16 6:50 ` [PATCH 1/2] x86 hvm: don't set periodical timer again until its IRQ is delivered Kouya Shimura @ 2009-09-16 7:40 ` Keir Fraser 2009-09-16 8:00 ` Cui, Dexuan 1 sibling, 1 reply; 18+ messages in thread From: Keir Fraser @ 2009-09-16 7:40 UTC (permalink / raw) To: Kouya Shimura; +Cc: xen-devel On 16/09/2009 07:46, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > I remade the patch and measured the performance win. Attached is > a benchmark program which I wrote. It is complied by cygwin's gcc > by -O2 and runs on Windows XP(32bit). And my cpu is > Intel Core2 Quad Q9450@2.66GHz. > > The result is that my patch saves 32 cycles(TSC) per one VM_EXIT(cpuid). > (2696 tsc => 2664 tsc) > > The patch is split to two. I'll post them in another mail. That's really not enough of a win to bother with, is it. -- Keir ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 7:40 ` [PATCH] x86 hvm: freeze PIT/LAPIC " Keir Fraser @ 2009-09-16 8:00 ` Cui, Dexuan 2009-09-16 8:20 ` Keir Fraser 2009-09-16 8:28 ` Kouya Shimura 0 siblings, 2 replies; 18+ messages in thread From: Cui, Dexuan @ 2009-09-16 8:00 UTC (permalink / raw) To: Keir Fraser, Kouya Shimura; +Cc: xen-devel Looks the little win doesn't deserve the increased complexity in code. BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) Thanks, -- Dexuan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: 2009?9?16? 15:41 To: Kouya Shimura Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked On 16/09/2009 07:46, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > I remade the patch and measured the performance win. Attached is > a benchmark program which I wrote. It is complied by cygwin's gcc > by -O2 and runs on Windows XP(32bit). And my cpu is > Intel Core2 Quad Q9450@2.66GHz. > > The result is that my patch saves 32 cycles(TSC) per one VM_EXIT(cpuid). > (2696 tsc => 2664 tsc) > > The patch is split to two. I'll post them in another mail. That's really not enough of a win to bother with, is it. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 8:00 ` Cui, Dexuan @ 2009-09-16 8:20 ` Keir Fraser 2009-09-16 8:40 ` Cui, Dexuan 2009-09-16 8:28 ` Kouya Shimura 1 sibling, 1 reply; 18+ messages in thread From: Keir Fraser @ 2009-09-16 8:20 UTC (permalink / raw) To: Cui, Dexuan, Kouya Shimura; +Cc: xen-devel On 16/09/2009 09:00, "Cui, Dexuan" <dexuan.cui@intel.com> wrote: > Looks the little win doesn't deserve the increased complexity in code. > > BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and > VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) Makes it more appealing doesn't it? As this path will be a greater proportion of an overall vmexit/vmenter cycle. -- Keir ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 8:20 ` Keir Fraser @ 2009-09-16 8:40 ` Cui, Dexuan 2009-09-16 9:09 ` Keir Fraser 0 siblings, 1 reply; 18+ messages in thread From: Cui, Dexuan @ 2009-09-16 8:40 UTC (permalink / raw) To: Keir Fraser, Kouya Shimura; +Cc: xen-devel I'm not sure if the number of the saved cycles is the same on recent Intel CPUs, so the proportion may not be greater. :-) Thanks, -- Dexuan -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2009?9?16? 16:21 To: Cui, Dexuan; Kouya Shimura Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked On 16/09/2009 09:00, "Cui, Dexuan" <dexuan.cui@intel.com> wrote: > Looks the little win doesn't deserve the increased complexity in code. > > BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and > VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) Makes it more appealing doesn't it? As this path will be a greater proportion of an overall vmexit/vmenter cycle. -- Keir ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 8:40 ` Cui, Dexuan @ 2009-09-16 9:09 ` Keir Fraser 0 siblings, 0 replies; 18+ messages in thread From: Keir Fraser @ 2009-09-16 9:09 UTC (permalink / raw) To: Cui, Dexuan, Kouya Shimura; +Cc: xen-devel Perhaps. Anyway, the patches fixed bugs and generally cleaned up some logic, so I think they are good for reasons other than the few saved cycles on vmenter. -- Keir On 16/09/2009 09:40, "Cui, Dexuan" <dexuan.cui@intel.com> wrote: > I'm not sure if the number of the saved cycles is the same on recent Intel > CPUs, so the proportion may not be greater. :-) > > Thanks, > -- Dexuan > > -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: 2009?9?16? 16:21 > To: Cui, Dexuan; Kouya Shimura > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation > while its IRQ is masked > > On 16/09/2009 09:00, "Cui, Dexuan" <dexuan.cui@intel.com> wrote: > >> Looks the little win doesn't deserve the increased complexity in code. >> >> BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and >> VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) > > Makes it more appealing doesn't it? As this path will be a greater > proportion of an overall vmexit/vmenter cycle. > > -- Keir ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 8:00 ` Cui, Dexuan 2009-09-16 8:20 ` Keir Fraser @ 2009-09-16 8:28 ` Kouya Shimura 2009-09-16 8:36 ` Keir Fraser 1 sibling, 1 reply; 18+ messages in thread From: Kouya Shimura @ 2009-09-16 8:28 UTC (permalink / raw) To: Cui, Dexuan; +Cc: xen-devel, Keir Fraser Cui, Dexuan writes: > Looks the little win doesn't deserve the increased complexity in code. Agreed. I don't strongly push my patches. But this win is given by 2/2 patch and it fixes a certain bug. Besides, 1/2 patch simplifies the code, I think. > BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) I have a "Mottainai"(http://en.wikipedia.org/wiki/Mottainai) spirit. :-) Thanks, Kouya > > Thanks, > -- Dexuan > > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser > Sent: 2009?9?16? 15:41 > To: Kouya Shimura > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked > > On 16/09/2009 07:46, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > > > I remade the patch and measured the performance win. Attached is > > a benchmark program which I wrote. It is complied by cygwin's gcc > > by -O2 and runs on Windows XP(32bit). And my cpu is > > Intel Core2 Quad Q9450@2.66GHz. > > > > The result is that my patch saves 32 cycles(TSC) per one VM_EXIT(cpuid). > > (2696 tsc => 2664 tsc) > > > > The patch is split to two. I'll post them in another mail. > > That's really not enough of a win to bother with, is it. > > -- Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-16 8:28 ` Kouya Shimura @ 2009-09-16 8:36 ` Keir Fraser 0 siblings, 0 replies; 18+ messages in thread From: Keir Fraser @ 2009-09-16 8:36 UTC (permalink / raw) To: Kouya Shimura, Cui, Dexuan; +Cc: xen-devel I liked both patches when I looked at them, so I checked them in and we'll see how well they work! -- Keir On 16/09/2009 09:28, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: > Cui, Dexuan writes: >> Looks the little win doesn't deserve the increased complexity in code. > > Agreed. I don't strongly push my patches. > But this win is given by 2/2 patch and it fixes a certain bug. > Besides, 1/2 patch simplifies the code, I think. > >> BTW, recent Intel CPUs run much faster with respect to VMEntry/VMExit and >> VMREAD/VMWRITE, so I don't think the SW optimizatin is appearling here. :-) > > I have a "Mottainai"(http://en.wikipedia.org/wiki/Mottainai) spirit. :-) > > Thanks, > Kouya > >> >> Thanks, >> -- Dexuan >> >> >> >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser >> Sent: 2009?9?16? 15:41 >> To: Kouya Shimura >> Cc: xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation >> while its IRQ is masked >> >> On 16/09/2009 07:46, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote: >> >>> I remade the patch and measured the performance win. Attached is >>> a benchmark program which I wrote. It is complied by cygwin's gcc >>> by -O2 and runs on Windows XP(32bit). And my cpu is >>> Intel Core2 Quad Q9450@2.66GHz. >>> >>> The result is that my patch saves 32 cycles(TSC) per one VM_EXIT(cpuid). >>> (2696 tsc => 2664 tsc) >>> >>> The patch is split to two. I'll post them in another mail. >> >> That's really not enough of a win to bother with, is it. >> >> -- Keir >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-10 5:47 [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked Kouya Shimura 2009-09-10 6:49 ` Keir Fraser @ 2009-09-11 12:07 ` Konrad Rzeszutek Wilk 2009-09-14 5:58 ` Kouya Shimura 1 sibling, 1 reply; 18+ messages in thread From: Konrad Rzeszutek Wilk @ 2009-09-11 12:07 UTC (permalink / raw) To: Kouya Shimura; +Cc: xen-devel On Thu, Sep 10, 2009 at 02:47:22PM +0900, Kouya Shimura wrote: Content-Description: message body text > Hi, > > I've found that modern windows OS never use the PIT timer, What about older Linux versions? Like RHEL3? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked 2009-09-11 12:07 ` Konrad Rzeszutek Wilk @ 2009-09-14 5:58 ` Kouya Shimura 0 siblings, 0 replies; 18+ messages in thread From: Kouya Shimura @ 2009-09-14 5:58 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: xen-devel Konrad Rzeszutek Wilk writes: > On Thu, Sep 10, 2009 at 02:47:22PM +0900, Kouya Shimura wrote: > Content-Description: message body text > > Hi, > > > > I've found that modern windows OS never use the PIT timer, > > What about older Linux versions? Like RHEL3? older Linux uses the PIT timer. Although I don't know about RHEL3, RHEL5 uses the PIT timer actually. Any way, my patch doesn't give a benefit to Linux. For example, linux-2.6.28 (ubuntu 9.04) stops the PIT timer by itself. Thanks, Kouya ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-09-16 9:09 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-10 5:47 [PATCH] x86 hvm: freeze PIT/LAPIC timer emulation while its IRQ is masked Kouya Shimura 2009-09-10 6:49 ` Keir Fraser 2009-09-10 8:22 ` Kouya Shimura 2009-09-10 8:32 ` Keir Fraser 2009-09-10 9:54 ` Kouya Shimura 2009-09-10 12:32 ` Keir Fraser 2009-09-16 6:46 ` Kouya Shimura 2009-09-16 6:50 ` [PATCH 1/2] x86 hvm: don't set periodical timer again until its IRQ is delivered Kouya Shimura 2009-09-16 6:53 ` [PATCH 2/2] x86 hvm: suspend platform timer emulation while its IRQ is masked Kouya Shimura 2009-09-16 7:40 ` [PATCH] x86 hvm: freeze PIT/LAPIC " Keir Fraser 2009-09-16 8:00 ` Cui, Dexuan 2009-09-16 8:20 ` Keir Fraser 2009-09-16 8:40 ` Cui, Dexuan 2009-09-16 9:09 ` Keir Fraser 2009-09-16 8:28 ` Kouya Shimura 2009-09-16 8:36 ` Keir Fraser 2009-09-11 12:07 ` Konrad Rzeszutek Wilk 2009-09-14 5:58 ` Kouya Shimura
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.