Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
Stefan Berger writes: > Daniel Kiper wrote on 07/19/2016 11:00:04 AM: > >> Subject: Re: [PATCH] acpi: Re-license ACPI builder files from GPLv2 >> to LGPLv2.1 >> >> On Mon, Jul 18, 2016 at 10:01:27AM -0400, Boris Ostrovsky wrote: >> > ACPI builder is currently distributed under GPLv2 license. >> > >> > We plan to make the builder available to components other >> > than the hvmloader (which is also GPLv2). Some of these >> > components (such as libxl) may be distributed under LGPL-2.1 >> > so that they can be used by non-GPLv2 callers. But this >> > will not be possible if we incorporate the ACPI builder in >> > those other components. >> > >> > To avoid this problem we are relicensing sources in ACPI >> > bulder directory to the Lesser GNU Public License (LGPL) >> > version 2.1 >> > >> > Signed-off-by: Boris Ostrovsky >> > CC: Kouya Shimura >> > CC: Daniel Kiper >> > CC: Stefan Berger >> > CC: Simon Horman >> > CC: Keir Fraser >> > CC: Ian Jackson >> > CC: Lars Kurth >> >> Acked-by: Daniel Kiper > Acked-by: Stefan Berger Acked-by: Kouya Shimura ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] x86/hvm: fix saved pmtimer value
Jan Beulich writes: > From: Kouya Shimura > > The ACPI PM timer is sometimes broken on live migration. > Since vcpu->arch.hvm_vcpu.guest_time is always zero in other than > "delay for missed ticks mode". Even in "delay for missed ticks mode", > vcpu's guest_time field is not valid (i.e. zero) when > the state of vcpu is "blocked". (see pt_save_timer function) > > The original author (Tim Deegan) of pmtimer_save() must have intended > that it saves the last scheduled time of the vcpu. Unfortunately it was > already implied this bug. FYI, there is no other timer mode than > "delay for missed ticks mode" then. > > For consistency with HPET, pmtimer_save() should refer hvm_get_guest_time() > to update the counter as well as hpet_save() does. > > Without this patch, the clock of windows server 2012R2 without HPET > might leap forward several minutes on live migration. > > Signed-off-by: Kouya Shimura > > Retain use of ->arch.hvm_vcpu.guest_time when non-zero. Do the inverse > adjustment for vHPET. I'm fine with this change. Why not modify the subject too? > > Signed-off-by: Jan Beulich > Release-acked-by: Wei Liu Reviewed-by: Kouya Shimura Thanks, Kouya ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V2] x86/hvm: fix saved pmtimer value
The ACPI PM timer is sometimes broken on live migration. Since vcpu->arch.hvm_vcpu.guest_time is always zero in other than "delay for missed ticks mode". Even in "delay for missed ticks mode", vcpu's guest_time field is not valid (i.e. zero) when the state of vcpu is "blocked". (see pt_save_timer function) The original author (Tim Deegan) of pmtimer_save() must have intended that it saves the last scheduled time of the vcpu. Unfortunately it was already implied this bug. FYI, there is no other timer mode than "delay for missed ticks mode" then. For consistency with HPET, pmtimer_save() should refer hvm_get_guest_time() to update the counter as well as hpet_save() does. Without this patch, the clock of windows server 2012R2 without HPET might leap forward several minutes on live migration. Signed-off-by: Kouya Shimura Cc: Jan Beulich Release-acked-by: Wei Liu --- V2: improved description. xen/arch/x86/hvm/pmtimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c index 07594e1..282efd0 100644 --- a/xen/arch/x86/hvm/pmtimer.c +++ b/xen/arch/x86/hvm/pmtimer.c @@ -252,7 +252,7 @@ static int pmtimer_save(struct domain *d, hvm_domain_context_t *h) /* Update the counter to the guest's current time. We always save * with the domain paused, so the saved time should be after the * last_gtime, but just in case, make sure we only go forwards */ -x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32; +x = ((hvm_get_guest_time(s->vcpu) - s->last_gtime) * s->scale) >> 32; if ( x < 1UL<<31 ) s->pm.tmr_val += x; if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb ) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value
Jan Beulich writes: On 09.09.15 at 09:31, wrote: >> The ACPI PM timer is sometimes broken on live migration. >> Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. > > I.e. in other than "delay for missed ticks mode". Would have been > nice if you had spelled this out explicitly. Actually, I tried "delay for missed ticks mode" (timer_mode=0). Even in this case, the pmtimer was broken. I don't know why. > With that the question then is - > should the field perhaps be used when non-zero, and the > function only be called otherwise? The adjustment of timer value in pmtimer_save() was introduced before other timer_modes were implemented. I'm not sure (skeptical) the small adjustment is really necessary in pmtimer_save. Thanks, Kouya > > Wei - regardless of the answer to the above (i.e. regardless of > whether a v2 is going to be needed) I think we want this in 4.6. > > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value
The ACPI PM timer is sometimes broken on live migration. Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. Without this patch, the clock of windows server 2012R2 without HPET might leap forward several minutes on live migration. Signed-off-by: Kouya Shimura --- xen/arch/x86/hvm/pmtimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c index 07594e1..282efd0 100644 --- a/xen/arch/x86/hvm/pmtimer.c +++ b/xen/arch/x86/hvm/pmtimer.c @@ -252,7 +252,7 @@ static int pmtimer_save(struct domain *d, hvm_domain_context_t *h) /* Update the counter to the guest's current time. We always save * with the domain paused, so the saved time should be after the * last_gtime, but just in case, make sure we only go forwards */ -x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32; +x = ((hvm_get_guest_time(s->vcpu) - s->last_gtime) * s->scale) >> 32; if ( x < 1UL<<31 ) s->pm.tmr_val += x; if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb ) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
