| Message ID | 1314883405-6394-1-git-send-email-stefan.bader@canonical.com |
|---|---|
| State | New |
| Headers | show |
On 09/01/2011 07:23 AM, Stefan Bader wrote: > I would like to propose the following SAUCE patch for Oneiric. Without > this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or > newer hypervisor (which we ship in Oneiric). > > It should be only temporary, but I am not sure we find a proper solution > within the time before final freeze and I rather would see the released > kernel at least booting. > > Changes only affect code paths used when booting in HVM mode under Xen, > so there should be no other impact. > > -Stefan > Can you think of any possible impact this might have for an LTS backport ? We're not doing anything for -ec2 backports, right ? rtg
On 01.09.2011 15:39, Tim Gardner wrote: > On 09/01/2011 07:23 AM, Stefan Bader wrote: >> I would like to propose the following SAUCE patch for Oneiric. Without >> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >> newer hypervisor (which we ship in Oneiric). >> >> It should be only temporary, but I am not sure we find a proper solution >> within the time before final freeze and I rather would see the released >> kernel at least booting. >> >> Changes only affect code paths used when booting in HVM mode under Xen, >> so there should be no other impact. >> >> -Stefan >> > > Can you think of any possible impact this might have for an LTS backport ? We're > not doing anything for -ec2 backports, right ? > > rtg We do not have an LTS backport for EC2. Of course people can an do run the normal (generic-pae for i386, amd64 should be ok with any flavour) LTS backport kernel in Lucid installations. If the hyperviser is older that 4.1.1 this has no impact at all. And for the other ones it would cause the same issue. -Stefan
On 01.09.2011 15:54, Stefan Bader wrote: > On 01.09.2011 15:39, Tim Gardner wrote: >> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>> I would like to propose the following SAUCE patch for Oneiric. Without >>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>> newer hypervisor (which we ship in Oneiric). >>> >>> It should be only temporary, but I am not sure we find a proper solution >>> within the time before final freeze and I rather would see the released >>> kernel at least booting. >>> >>> Changes only affect code paths used when booting in HVM mode under Xen, >>> so there should be no other impact. >>> >>> -Stefan >>> >> >> Can you think of any possible impact this might have for an LTS backport ? We're >> not doing anything for -ec2 backports, right ? >> >> rtg > > We do not have an LTS backport for EC2. Of course people can an do run the > normal (generic-pae for i386, amd64 should be ok with any flavour) LTS backport > kernel in Lucid installations. If the hyperviser is older that 4.1.1 this has no > impact at all. And for the other ones it would cause the same issue. > > -Stefan > Of course I meant "under Xen" somewhere above...
On 09/01/2011 07:56 AM, Stefan Bader wrote: > On 01.09.2011 15:54, Stefan Bader wrote: >> On 01.09.2011 15:39, Tim Gardner wrote: >>> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>>> I would like to propose the following SAUCE patch for Oneiric. Without >>>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>>> newer hypervisor (which we ship in Oneiric). >>>> >>>> It should be only temporary, but I am not sure we find a proper solution >>>> within the time before final freeze and I rather would see the released >>>> kernel at least booting. >>>> >>>> Changes only affect code paths used when booting in HVM mode under Xen, >>>> so there should be no other impact. >>>> >>>> -Stefan >>>> >>> >>> Can you think of any possible impact this might have for an LTS backport ? We're >>> not doing anything for -ec2 backports, right ? >>> >>> rtg >> >> We do not have an LTS backport for EC2. Of course people can an do run the >> normal (generic-pae for i386, amd64 should be ok with any flavour) LTS backport >> kernel in Lucid installations. If the hyperviser is older that 4.1.1 this has no >> impact at all. And for the other ones it would cause the same issue. >> >> -Stefan >> > Of course I meant "under Xen" somewhere above... > So if someone was running Lucid user space as a Xen domU guest on a hypervisor older then 4.1.1, then installing the Oneiric LTS backport would normally work, right? Will this patch impact that ? rtg
On 01.09.2011 16:12, Tim Gardner wrote: > On 09/01/2011 07:56 AM, Stefan Bader wrote: >> On 01.09.2011 15:54, Stefan Bader wrote: >>> On 01.09.2011 15:39, Tim Gardner wrote: >>>> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>>>> I would like to propose the following SAUCE patch for Oneiric. Without >>>>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>>>> newer hypervisor (which we ship in Oneiric). >>>>> >>>>> It should be only temporary, but I am not sure we find a proper solution >>>>> within the time before final freeze and I rather would see the released >>>>> kernel at least booting. >>>>> >>>>> Changes only affect code paths used when booting in HVM mode under Xen, >>>>> so there should be no other impact. >>>>> >>>>> -Stefan >>>>> >>>> >>>> Can you think of any possible impact this might have for an LTS backport ? >>>> We're >>>> not doing anything for -ec2 backports, right ? >>>> >>>> rtg >>> >>> We do not have an LTS backport for EC2. Of course people can an do run the >>> normal (generic-pae for i386, amd64 should be ok with any flavour) LTS backport >>> kernel in Lucid installations. If the hyperviser is older that 4.1.1 this has no >>> impact at all. And for the other ones it would cause the same issue. >>> >>> -Stefan >>> >> Of course I meant "under Xen" somewhere above... >> > > So if someone was running Lucid user space as a Xen domU guest on a hypervisor > older then 4.1.1, then installing the Oneiric LTS backport would normally work, > right? Will this patch impact that ? > > rtg No, hypervisors older than 4.1.1 will not offer the vector callback feature, which in turn prevents pv spinlocks (as well as pv IPIs) from being tried to enable by a 3.0 kernel. So those work as before. -Stefan
On 09/01/2011 08:17 AM, Stefan Bader wrote: > On 01.09.2011 16:12, Tim Gardner wrote: >> On 09/01/2011 07:56 AM, Stefan Bader wrote: >>> On 01.09.2011 15:54, Stefan Bader wrote: >>>> On 01.09.2011 15:39, Tim Gardner wrote: >>>>> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>>>>> I would like to propose the following SAUCE patch for Oneiric. Without >>>>>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>>>>> newer hypervisor (which we ship in Oneiric). >>>>>> >>>>>> It should be only temporary, but I am not sure we find a proper solution >>>>>> within the time before final freeze and I rather would see the released >>>>>> kernel at least booting. >>>>>> >>>>>> Changes only affect code paths used when booting in HVM mode under Xen, >>>>>> so there should be no other impact. >>>>>> >>>>>> -Stefan >>>>>> >>>>> >>>>> Can you think of any possible impact this might have for an LTS backport ? >>>>> We're >>>>> not doing anything for -ec2 backports, right ? >>>>> >>>>> rtg >>>> >>>> We do not have an LTS backport for EC2. Of course people can an do run the >>>> normal (generic-pae for i386, amd64 should be ok with any flavour) LTS backport >>>> kernel in Lucid installations. If the hyperviser is older that 4.1.1 this has no >>>> impact at all. And for the other ones it would cause the same issue. >>>> >>>> -Stefan >>>> >>> Of course I meant "under Xen" somewhere above... >>> >> >> So if someone was running Lucid user space as a Xen domU guest on a hypervisor >> older then 4.1.1, then installing the Oneiric LTS backport would normally work, >> right? Will this patch impact that ? >> >> rtg > > No, hypervisors older than 4.1.1 will not offer the vector callback feature, > which in turn prevents pv spinlocks (as well as pv IPIs) from being tried to > enable by a 3.0 kernel. > So those work as before. > > -Stefan Uh, I think what you just said is that Oneiric will work fine on hypervisors prior to 4.1.1 regardless of whether this patch is applied. rtg
On 01.09.2011 16:25, Tim Gardner wrote: > On 09/01/2011 08:17 AM, Stefan Bader wrote: >> On 01.09.2011 16:12, Tim Gardner wrote: >>> On 09/01/2011 07:56 AM, Stefan Bader wrote: >>>> On 01.09.2011 15:54, Stefan Bader wrote: >>>>> On 01.09.2011 15:39, Tim Gardner wrote: >>>>>> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>>>>>> I would like to propose the following SAUCE patch for Oneiric. Without >>>>>>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>>>>>> newer hypervisor (which we ship in Oneiric). >>>>>>> >>>>>>> It should be only temporary, but I am not sure we find a proper solution >>>>>>> within the time before final freeze and I rather would see the released >>>>>>> kernel at least booting. >>>>>>> >>>>>>> Changes only affect code paths used when booting in HVM mode under Xen, >>>>>>> so there should be no other impact. >>>>>>> >>>>>>> -Stefan >>>>>>> >>>>>> >>>>>> Can you think of any possible impact this might have for an LTS backport ? >>>>>> We're >>>>>> not doing anything for -ec2 backports, right ? >>>>>> >>>>>> rtg >>>>> >>>>> We do not have an LTS backport for EC2. Of course people can an do run the >>>>> normal (generic-pae for i386, amd64 should be ok with any flavour) LTS >>>>> backport >>>>> kernel in Lucid installations. If the hyperviser is older that 4.1.1 this >>>>> has no >>>>> impact at all. And for the other ones it would cause the same issue. >>>>> >>>>> -Stefan >>>>> >>>> Of course I meant "under Xen" somewhere above... >>>> >>> >>> So if someone was running Lucid user space as a Xen domU guest on a hypervisor >>> older then 4.1.1, then installing the Oneiric LTS backport would normally work, >>> right? Will this patch impact that ? >>> >>> rtg >> >> No, hypervisors older than 4.1.1 will not offer the vector callback feature, >> which in turn prevents pv spinlocks (as well as pv IPIs) from being tried to >> enable by a 3.0 kernel. >> So those work as before. >> >> -Stefan > > Uh, I think what you just said is that Oneiric will work fine on hypervisors > prior to 4.1.1 regardless of whether this patch is applied. > > rtg Yes. -Stefan
On 09/01/2011 08:37 AM, Stefan Bader wrote: > On 01.09.2011 16:25, Tim Gardner wrote: >> On 09/01/2011 08:17 AM, Stefan Bader wrote: >>> On 01.09.2011 16:12, Tim Gardner wrote: >>>> On 09/01/2011 07:56 AM, Stefan Bader wrote: >>>>> On 01.09.2011 15:54, Stefan Bader wrote: >>>>>> On 01.09.2011 15:39, Tim Gardner wrote: >>>>>>> On 09/01/2011 07:23 AM, Stefan Bader wrote: >>>>>>>> I would like to propose the following SAUCE patch for Oneiric. Without >>>>>>>> this the Oneiric kernel fails to boot in HVM mode from a Xen 4.1.1 or >>>>>>>> newer hypervisor (which we ship in Oneiric). >>>>>>>> >>>>>>>> It should be only temporary, but I am not sure we find a proper solution >>>>>>>> within the time before final freeze and I rather would see the released >>>>>>>> kernel at least booting. >>>>>>>> >>>>>>>> Changes only affect code paths used when booting in HVM mode under Xen, >>>>>>>> so there should be no other impact. >>>>>>>> >>>>>>>> -Stefan >>>>>>>> >>>>>>> >>>>>>> Can you think of any possible impact this might have for an LTS backport ? >>>>>>> We're >>>>>>> not doing anything for -ec2 backports, right ? >>>>>>> >>>>>>> rtg >>>>>> >>>>>> We do not have an LTS backport for EC2. Of course people can an do run the >>>>>> normal (generic-pae for i386, amd64 should be ok with any flavour) LTS >>>>>> backport >>>>>> kernel in Lucid installations. If the hyperviser is older that 4.1.1 this >>>>>> has no >>>>>> impact at all. And for the other ones it would cause the same issue. >>>>>> >>>>>> -Stefan >>>>>> >>>>> Of course I meant "under Xen" somewhere above... >>>>> >>>> >>>> So if someone was running Lucid user space as a Xen domU guest on a hypervisor >>>> older then 4.1.1, then installing the Oneiric LTS backport would normally work, >>>> right? Will this patch impact that ? >>>> >>>> rtg >>> >>> No, hypervisors older than 4.1.1 will not offer the vector callback feature, >>> which in turn prevents pv spinlocks (as well as pv IPIs) from being tried to >>> enable by a 3.0 kernel. >>> So those work as before. >>> >>> -Stefan >> >> Uh, I think what you just said is that Oneiric will work fine on hypervisors >> prior to 4.1.1 regardless of whether this patch is applied. >> >> rtg > > Yes. > > -Stefan
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 14dc31f..57727c5 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1360,8 +1360,10 @@ static int __cpuinit xen_hvm_cpu_notify(struct notifier_block *self, switch (action) { case CPU_UP_PREPARE: per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu]; + /* FIXME: Disable until a final solution is found (lp#838026) if (xen_have_vector_callback) xen_init_lock_cpu(cpu); + */ break; default: break; diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index e79dbb9..abd69a6 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -521,8 +521,10 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) native_smp_prepare_cpus(max_cpus); WARN_ON(xen_smp_intr_init(0)); + /* FIXME: Disable until final solution is found (lp#838026) xen_init_lock_cpu(0); xen_init_spinlocks(); + */ } static int __cpuinit xen_hvm_cpu_up(unsigned int cpu)