On Tue, Sep 11, 2012 at 7:37 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
>> > Yes, I can verify that a plain upstream kernel has problems in the first
>> > place, which is why we are carrying a patch to simply disable xsave all
>> > together in t
On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
> On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> > On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > >
> > > All of this still doesn't provide evidence that a plain upstream
> > > kernel is actually having an
On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> >
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippl
On Fri, Sep 07, 2012 at 10:54:33AM -0400, Konrad Rzeszutek Wilk wrote:
>
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.
>
Il 07/09/2012 18:13, Stefan Bader ha scritto:
> This would make it save again _if_ the HV failing to handle the writes to CR4
> (which iirc the kernel code still does when the cpuid bit is set) does have at
> least the patch to mask off the cpuid bits (the one Ian mentioned)
Given how old it is, t
Il 07/09/2012 17:47, Stefan Bader ha scritto:
>
> Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
> cr4 gracefully. If a guest attempts to write a bit of cr4 that is
> unsupported, then the HV is so offended it crashes the domain. While
> later guest kernels (such as RHEL6
Il 07/09/2012 16:54, Konrad Rzeszutek Wilk ha scritto:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
>> currently carrying is not upstream bec
On 07.09.2012 17:52, Jan Beulich wrote:
On 07.09.12 at 17:47, Stefan Bader wrote:
>> On 07.09.2012 17:44, Jan Beulich wrote:
>>> All of this still doesn't provide evidence that a plain upstream
>>> kernel is actually having any problems in the first place. Further,
>>> if you say EC2 has a cr
On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
> > On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 15:21, Stefan Bader wrote:
> >> > On 07.09.2012 14:33, Jan Beulich wrote:
> >> > On 07.09.12 at
On Fri, Sep 07, 2012 at 04:52:59PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:47, Stefan Bader wrote:
> > On 07.09.2012 17:44, Jan Beulich wrote:
> >> All of this still doesn't provide evidence that a plain upstream
> >> kernel is actually having any problems in the first place. Further,
>
On Fri, 2012-09-07 at 16:47 +0100, Stefan Bader wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
> On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
> >> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >> On 07.09.12 at 15:21, Stefan Bader wrote:
> On 07.09.2012 14:33,
>>> On 07.09.12 at 17:47, Stefan Bader wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
>> All of this still doesn't provide evidence that a plain upstream
>> kernel is actually having any problems in the first place. Further,
>> if you say EC2 has a crippled hypervisor patch - is that patch
>> av
On 07.09.2012 17:44, Jan Beulich wrote:
On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
>> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>> On 07.09.12 at 15:21, Stefan Bader wrote:
On 07.09.2012 14:33, Jan Beulich wrote:
On 07.09.12 at 13:40, Stefan Bader w
>>> On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 15:21, Stefan Bader wrote:
>> > On 07.09.2012 14:33, Jan Beulich wrote:
>> > On 07.09.12 at 13:40, Stefan Bader wrote:
>> >>> When writing unsupported flag
> > But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> > something upstream that isn't upstream)?
> >
> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> currently carrying is not upstream because:
>
> a) It's crap, it cripples upstream xen users,
On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:21, Stefan Bader wrote:
> > On 07.09.2012 14:33, Jan Beulich wrote:
> > On 07.09.12 at 13:40, Stefan Bader wrote:
> >>> When writing unsupported flags into CR4 (for some time the
> >>> xen_write_cr4 function
>>> On 07.09.12 at 15:21, Stefan Bader wrote:
> On 07.09.2012 14:33, Jan Beulich wrote:
> On 07.09.12 at 13:40, Stefan Bader wrote:
>>> When writing unsupported flags into CR4 (for some time the
>>> xen_write_cr4 function would refuse to do anything at all)
>>> older Xen hypervisors (and patc
On 07.09.2012 14:33, Jan Beulich wrote:
On 07.09.12 at 13:40, Stefan Bader wrote:
>> When writing unsupported flags into CR4 (for some time the
>> xen_write_cr4 function would refuse to do anything at all)
>> older Xen hypervisors (and patch can potentially be improved
>> by finding out what
>>> On 07.09.12 at 13:40, Stefan Bader wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash
19 matches
Mail list logo
