On Mon, Jan 06, 2014 at 09:18:44AM -0800, Dirk Brandewie wrote:
> On 01/03/2014 02:06 PM, Paolo Bonzini wrote:
> >Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
> >>+case MSR_IA32_MPERF:
> >>+case MSR_IA32_APERF:
> >
> OK I will spin the patch to only add MSR_PLATFORM_INFO.
>
> >These
On Mon, Jan 06, 2014 at 09:18:44AM -0800, Dirk Brandewie wrote:
On 01/03/2014 02:06 PM, Paolo Bonzini wrote:
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
+case MSR_IA32_MPERF:
+case MSR_IA32_APERF:
OK I will spin the patch to only add MSR_PLATFORM_INFO.
These should never be
On 01/06/2014 03:37 AM, Rafael J. Wysocki wrote:
On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote:
Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il
On 01/03/2014 02:06 PM, Paolo Bonzini wrote:
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
+case MSR_IA32_MPERF:
+case MSR_IA32_APERF:
OK I will spin the patch to only add MSR_PLATFORM_INFO.
These should never be accessed. A KVM VM will always have
CPUID[06H].ECX = 0, and the
On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote:
> Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
> > On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
> >> On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
> >>> Il 04/01/2014 15:38, Rafael J. Wysocki ha
Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
> On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
>> On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
>>> Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
Well, it's just a sanity check and it makes the problem
Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
Well, it's just a sanity check and it makes the problem go away for
On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote:
Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
On 01/03/2014 02:06 PM, Paolo Bonzini wrote:
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
+case MSR_IA32_MPERF:
+case MSR_IA32_APERF:
OK I will spin the patch to only add MSR_PLATFORM_INFO.
These should never be accessed. A KVM VM will always have
CPUID[06H].ECX = 0, and the
On 01/06/2014 03:37 AM, Rafael J. Wysocki wrote:
On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote:
Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
> On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
> > Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
> > > Well, it's just a sanity check and it makes the problem go away for the
> > > reporter.
> > >
> > >> > Your
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
> Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
> > Well, it's just a sanity check and it makes the problem go away for the
> > reporter.
> >
> >> > Your patch is welcome but perhaps it should have a WARN_ON too.
> > It has been
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
> Well, it's just a sanity check and it makes the problem go away for the
> reporter.
>
>> > Your patch is welcome but perhaps it should have a WARN_ON too.
> It has been pulled in already, so the WARN_ON() can only be added via a
> separate
>
On Saturday, January 04, 2014 09:35:58 AM Paolo Bonzini wrote:
> Il 03/01/2014 23:46, Rafael J. Wysocki ha scritto:
> > Well, fixing the KVM bug is surely welcome.
> >
> > That said, adding checks to ensure that your assumptions are valid is rarely
> > wrong, especially if they are done once per
Il 03/01/2014 23:46, Rafael J. Wysocki ha scritto:
> Well, fixing the KVM bug is surely welcome.
>
> That said, adding checks to ensure that your assumptions are valid is rarely
> wrong, especially if they are done once per kernel boot. And the kernel only
> should panic if it cannot continue to
Il 03/01/2014 23:46, Rafael J. Wysocki ha scritto:
Well, fixing the KVM bug is surely welcome.
That said, adding checks to ensure that your assumptions are valid is rarely
wrong, especially if they are done once per kernel boot. And the kernel only
should panic if it cannot continue to run,
On Saturday, January 04, 2014 09:35:58 AM Paolo Bonzini wrote:
Il 03/01/2014 23:46, Rafael J. Wysocki ha scritto:
Well, fixing the KVM bug is surely welcome.
That said, adding checks to ensure that your assumptions are valid is rarely
wrong, especially if they are done once per kernel
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
Well, it's just a sanity check and it makes the problem go away for the
reporter.
Your patch is welcome but perhaps it should have a WARN_ON too.
It has been pulled in already, so the WARN_ON() can only be added via a
separate
patch
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
Well, it's just a sanity check and it makes the problem go away for the
reporter.
Your patch is welcome but perhaps it should have a WARN_ON too.
It has been pulled in
On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
Well, it's just a sanity check and it makes the problem go away for the
reporter.
Your patch is welcome
On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote:
> On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
> > Hi All,
> >
> > Sorry for being late to the party but I just got back from vacation.
> >
> > There is something deeply wrong here. We should have never gotten to
> >
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
> +case MSR_IA32_MPERF:
> +case MSR_IA32_APERF:
These should never be accessed. A KVM VM will always have
CPUID[06H].ECX = 0, and the Intel manual says that the MSRs are only
present if CPUID returns that value with bit 0 set.
I think the
On 01/03/2014 10:04 AM, Gleb Natapov wrote:
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
> Hi All,
>
> Sorry for being late to the party but I just got back from vacation.
>
> There is something deeply wrong here. We should have never gotten to
> intel_pstate_init_cpu(). The VM had to have returned value from the read
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had to have returned value from the read
of the max pstate at driver init time and 0 when the CPU was being brought
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had to have returned value from the read
of the max pstate at driver init time and 0 when the CPU was being brought
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had to have returned value from the read
of
On 01/03/2014 10:04 AM, Gleb Natapov wrote:
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
+case MSR_IA32_MPERF:
+case MSR_IA32_APERF:
These should never be accessed. A KVM VM will always have
CPUID[06H].ECX = 0, and the Intel manual says that the MSRs are only
present if CPUID returns that value with bit 0 set.
I think the
On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote:
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
On Monday, December 30, 2013 03:58:43 PM Kashyap Chamarthy wrote:
> On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote:
> > On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
> >> [. . .]
> >>
> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
>
>
On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote:
> On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
>> [. . .]
>>
Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
>> Can you ftrace the failure?
Can try, need some time (rest of the day
On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote:
On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
[. . .]
Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
Can you ftrace the failure?
Can try, need some time (rest of the day I'll be away travelling,
On Monday, December 30, 2013 03:58:43 PM Kashyap Chamarthy wrote:
On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote:
On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
[. . .]
Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
Can you ftrace the
On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
> [. . .]
>
> >> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
> >>
> Can you ftrace the failure?
> >>
> >> Can try, need some time (rest of the day I'll be away travelling,
> >> will try to do it
[. . .]
>> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
>>
Can you ftrace the failure?
>>
>> Can try, need some time (rest of the day I'll be away travelling,
>> will try to do it over the weekend, and update the Kernel
>> bugzilla with observations).
>>
>>>
[. . .]
Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
Can you ftrace the failure?
Can try, need some time (rest of the day I'll be away travelling,
will try to do it over the weekend, and update the Kernel
bugzilla with observations).
Ugh, it looks like guest
On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
[. . .]
Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
Can you ftrace the failure?
Can try, need some time (rest of the day I'll be away travelling,
will try to do it over the weekend, and
On Friday, December 27, 2013 06:17:47 PM Kashyap Chamarthy wrote:
> On 12/27/2013 06:01 PM, Gleb Natapov wrote:
> > On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
> >> On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
> >>> [. . .]
> >>>
> > KVM does not emulate
On 12/27/2013 06:01 PM, Gleb Natapov wrote:
> On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
>> On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
>>> [. . .]
>>>
> KVM does not emulate P-states at all. intel_pstate_init() calls
>
On Fri, Dec 27, 2013 at 07:01:48PM +0200, Gleb Natapov wrote:
> On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
> > On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
> > > [. . .]
> > >
> > > >> KVM does not emulate P-states at all. intel_pstate_init() calls
> > >
On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
> On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
> > [. . .]
> >
> > >> KVM does not emulate P-states at all. intel_pstate_init() calls
> > >> intel_pstate_msrs_not_valid() before printing "Intel P-state driver
> >
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
> [. . .]
>
> >> KVM does not emulate P-states at all. intel_pstate_init() calls
> >> intel_pstate_msrs_not_valid() before printing "Intel P-state driver
> >> initializing." which suppose to fail since it checks that two reads of
Probably the qemu command line is more interesting, which is in this
comment and reproduced below.
https://bugzilla.redhat.com/show_bug.cgi?id=1046317#c1
/usr/bin/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-nodefconfig \
-enable-fips \
-nodefaults \
-display none \
On Tuesday, December 24, 2013 09:36:01 PM Viresh Kumar wrote:
> Adding Dirk..
>
> On 24 December 2013 20:06, Josh Boyer wrote:
> > Hi All,
> >
> > We've had a report [1] that the pstate driver causes KVM guests to
> > fail to boot because of a divide error. See the backtrace below.
> >
> >
[. . .]
>> KVM does not emulate P-states at all. intel_pstate_init() calls
>> intel_pstate_msrs_not_valid() before printing "Intel P-state driver
>> initializing." which suppose to fail since it checks that two reads of
>> MSR_IA32_APERF return different values, but KVM does not emulate this msr
On Fri, Dec 27, 2013 at 7:47 AM, Gleb Natapov wrote:
> On Fri, Dec 27, 2013 at 12:24:22PM +, One Thousand Gnomes wrote:
>> On Tue, 24 Dec 2013 21:36:01 +0530
>> Viresh Kumar wrote:
>>
>> > Adding Dirk..
>> >
>> > On 24 December 2013 20:06, Josh Boyer wrote:
>> > > Hi All,
>> > >
>> > >
On Fri, Dec 27, 2013 at 12:24:22PM +, One Thousand Gnomes wrote:
> On Tue, 24 Dec 2013 21:36:01 +0530
> Viresh Kumar wrote:
>
> > Adding Dirk..
> >
> > On 24 December 2013 20:06, Josh Boyer wrote:
> > > Hi All,
> > >
> > > We've had a report [1] that the pstate driver causes KVM guests to
On Tue, 24 Dec 2013 21:36:01 +0530
Viresh Kumar wrote:
> Adding Dirk..
>
> On 24 December 2013 20:06, Josh Boyer wrote:
> > Hi All,
> >
> > We've had a report [1] that the pstate driver causes KVM guests to
> > fail to boot because of a divide error. See the backtrace below.
> >
> >
On Tue, 24 Dec 2013 21:36:01 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi All,
We've had a report [1] that the pstate driver causes KVM guests to
fail to boot because of a divide error. See
On Fri, Dec 27, 2013 at 12:24:22PM +, One Thousand Gnomes wrote:
On Tue, 24 Dec 2013 21:36:01 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi All,
We've had a report [1] that the
On Fri, Dec 27, 2013 at 7:47 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Dec 27, 2013 at 12:24:22PM +, One Thousand Gnomes wrote:
On Tue, 24 Dec 2013 21:36:01 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer
[. . .]
KVM does not emulate P-states at all. intel_pstate_init() calls
intel_pstate_msrs_not_valid() before printing Intel P-state driver
initializing. which suppose to fail since it checks that two reads of
MSR_IA32_APERF return different values, but KVM does not emulate this msr
at all,
On Tuesday, December 24, 2013 09:36:01 PM Viresh Kumar wrote:
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi All,
We've had a report [1] that the pstate driver causes KVM guests to
fail to boot because of a divide error. See the backtrace
Probably the qemu command line is more interesting, which is in this
comment and reproduced below.
https://bugzilla.redhat.com/show_bug.cgi?id=1046317#c1
/usr/bin/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-nodefconfig \
-enable-fips \
-nodefaults \
-display none \
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
[. . .]
KVM does not emulate P-states at all. intel_pstate_init() calls
intel_pstate_msrs_not_valid() before printing Intel P-state driver
initializing. which suppose to fail since it checks that two reads of
On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
[. . .]
KVM does not emulate P-states at all. intel_pstate_init() calls
intel_pstate_msrs_not_valid() before printing Intel P-state driver
initializing.
On Fri, Dec 27, 2013 at 07:01:48PM +0200, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
[. . .]
KVM does not emulate P-states at all. intel_pstate_init() calls
On 12/27/2013 06:01 PM, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
[. . .]
KVM does not emulate P-states at all. intel_pstate_init() calls
intel_pstate_msrs_not_valid() before printing
On Friday, December 27, 2013 06:17:47 PM Kashyap Chamarthy wrote:
On 12/27/2013 06:01 PM, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
[. . .]
KVM does not emulate P-states at all.
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer wrote:
> Hi All,
>
> We've had a report [1] that the pstate driver causes KVM guests to
> fail to boot because of a divide error. See the backtrace below.
>
> 4.839784] Intel P-state driver initializing.
> [4.859972] Intel pstate
Hi All,
We've had a report [1] that the pstate driver causes KVM guests to
fail to boot because of a divide error. See the backtrace below.
4.839784] Intel P-state driver initializing.
[4.859972] Intel pstate controlling: cpu 0
[4.867653] cpufreq: __cpufreq_add_dev: ->get() failed
[
Hi All,
We've had a report [1] that the pstate driver causes KVM guests to
fail to boot because of a divide error. See the backtrace below.
4.839784] Intel P-state driver initializing.
[4.859972] Intel pstate controlling: cpu 0
[4.867653] cpufreq: __cpufreq_add_dev: -get() failed
[
Adding Dirk..
On 24 December 2013 20:06, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi All,
We've had a report [1] that the pstate driver causes KVM guests to
fail to boot because of a divide error. See the backtrace below.
4.839784] Intel P-state driver initializing.
[4.859972]
64 matches
Mail list logo
