Il 11/04/2014 19:40, H. Peter Anvin ha scritto:
On 04/11/2014 10:35 AM, Jet Chen wrote:
As Peter said, QEMU probably should *not* set the hypervisor bit. But based on
my testing, I think KVM works properly in this case.
Either way, unless there is a CPUID interface exposed in CPUID levels
Il 11/04/2014 19:40, H. Peter Anvin ha scritto:
On 04/11/2014 10:35 AM, Jet Chen wrote:
As Peter said, QEMU probably should *not* set the hypervisor bit. But based on
my testing, I think KVM works properly in this case.
Either way, unless there is a CPUID interface exposed in CPUID levels
Should we perhaps CC qemu-devel here for an opinion.
Guys, this mail should explain the issue but in case there are
questions, the whole thread starts here:
http://lkml.kernel.org/r/20140407111725.GC25152@localhost
Thanks.
On Sat, Apr 12, 2014 at 01:35:49AM +0800, Jet Chen wrote:
> On
Should we perhaps CC qemu-devel here for an opinion.
Guys, this mail should explain the issue but in case there are
questions, the whole thread starts here:
http://lkml.kernel.org/r/20140407111725.GC25152@localhost
Thanks.
On Sat, Apr 12, 2014 at 01:35:49AM +0800, Jet Chen wrote:
On
On Sat, 2014-04-12 at 01:35 +0800, Jet Chen wrote:
> Hi Ben,
>
> I re-tested this case with/without option -enable-kvm.
>
> qemu-system-x86_64 -cpu Haswell,+smep,+smap invalid op
> qemu-system-x86_64 -cpu kvm64 invalid op
> qemu-system-x86_64
On Fri, 2014-04-11 at 10:40 -0700, H. Peter Anvin wrote:
> On 04/11/2014 10:35 AM, Jet Chen wrote:
> >
> > As Peter said, QEMU probably should *not* set the hypervisor bit. But based
> > on my testing, I think KVM works properly in this case.
> >
>
> Either way, unless there is a CPUID
On 04/11/2014 10:35 AM, Jet Chen wrote:
>
> As Peter said, QEMU probably should *not* set the hypervisor bit. But based
> on my testing, I think KVM works properly in this case.
>
Either way, unless there is a CPUID interface exposed in CPUID levels
0x4000+, then relying on the hypervisor
On 04/12/2014 12:33 AM, H. Peter Anvin wrote:
> On 04/11/2014 06:51 AM, Romer, Benjamin M wrote:
>>
>>> I'm still confused where KVM comes into the picture. Are you actually
>>> using KVM (and thus talking about nested virtualization) or are you
>>> using Qemu in JIT mode and running another
On 04/11/2014 06:51 AM, Romer, Benjamin M wrote:
>
>> I'm still confused where KVM comes into the picture. Are you actually
>> using KVM (and thus talking about nested virtualization) or are you
>> using Qemu in JIT mode and running another hypervisor underneath?
>
> The test that Fengguang used
On Thu, 2014-04-10 at 19:28 -0700, H. Peter Anvin wrote:
> On 04/10/2014 06:19 AM, Romer, Benjamin M wrote:
> >
> > I'm confused by the intended behavior of KVM.. Is the intention of the
> > -cpu switch to fully emulate a particular CPU? If that's the case, the
> > Intel documentation says bit 31
On Thu, 2014-04-10 at 19:28 -0700, H. Peter Anvin wrote:
On 04/10/2014 06:19 AM, Romer, Benjamin M wrote:
I'm confused by the intended behavior of KVM.. Is the intention of the
-cpu switch to fully emulate a particular CPU? If that's the case, the
Intel documentation says bit 31 should
On 04/11/2014 06:51 AM, Romer, Benjamin M wrote:
I'm still confused where KVM comes into the picture. Are you actually
using KVM (and thus talking about nested virtualization) or are you
using Qemu in JIT mode and running another hypervisor underneath?
The test that Fengguang used to find
On 04/12/2014 12:33 AM, H. Peter Anvin wrote:
On 04/11/2014 06:51 AM, Romer, Benjamin M wrote:
I'm still confused where KVM comes into the picture. Are you actually
using KVM (and thus talking about nested virtualization) or are you
using Qemu in JIT mode and running another hypervisor
On 04/11/2014 10:35 AM, Jet Chen wrote:
As Peter said, QEMU probably should *not* set the hypervisor bit. But based
on my testing, I think KVM works properly in this case.
Either way, unless there is a CPUID interface exposed in CPUID levels
0x4000+, then relying on the hypervisor bit
On Fri, 2014-04-11 at 10:40 -0700, H. Peter Anvin wrote:
On 04/11/2014 10:35 AM, Jet Chen wrote:
As Peter said, QEMU probably should *not* set the hypervisor bit. But based
on my testing, I think KVM works properly in this case.
Either way, unless there is a CPUID interface exposed
On Sat, 2014-04-12 at 01:35 +0800, Jet Chen wrote:
Hi Ben,
I re-tested this case with/without option -enable-kvm.
qemu-system-x86_64 -cpu Haswell,+smep,+smap invalid op
qemu-system-x86_64 -cpu kvm64 invalid op
qemu-system-x86_64 -cpu
On 04/10/2014 06:19 AM, Romer, Benjamin M wrote:
>
> I'm confused by the intended behavior of KVM.. Is the intention of the
> -cpu switch to fully emulate a particular CPU? If that's the case, the
> Intel documentation says bit 31 should always be 0, so the value
> returned by the cpuid
On Wed, 2014-04-09 at 16:10 -0700, H. Peter Anvin wrote:
> On 04/09/2014 04:01 PM, Fengguang Wu wrote:
> > CC the KVM people: it looks like a KVM problem that can be triggered by
> >
> > qemu-system-x86_64 -cpu Haswell,+smep,+smap
>
> I'm really confused. First of all, is this a KVM
On Wed, 2014-04-09 at 16:10 -0700, H. Peter Anvin wrote:
On 04/09/2014 04:01 PM, Fengguang Wu wrote:
CC the KVM people: it looks like a KVM problem that can be triggered by
qemu-system-x86_64 -cpu Haswell,+smep,+smap
I'm really confused. First of all, is this a KVM problem or
On 04/10/2014 06:19 AM, Romer, Benjamin M wrote:
I'm confused by the intended behavior of KVM.. Is the intention of the
-cpu switch to fully emulate a particular CPU? If that's the case, the
Intel documentation says bit 31 should always be 0, so the value
returned by the cpuid instruction
On 04/09/2014 04:01 PM, Fengguang Wu wrote:
> CC the KVM people: it looks like a KVM problem that can be triggered by
>
> qemu-system-x86_64 -cpu Haswell,+smep,+smap
I'm really confused. First of all, is this a KVM problem or is it a
Qemu JIT problem?
Either seems really wonky. It is
On 04/09/2014 04:01 PM, Fengguang Wu wrote:
> CC the KVM people: it looks like a KVM problem that can be triggered by
>
> qemu-system-x86_64 -cpu Haswell,+smep,+smap
Is it a KVM problem or a Qemu bug? It sounds more like a Qemu JIT bug.
-hpa
> On Thu, Apr 10, 2014 at
CC the KVM people: it looks like a KVM problem that can be triggered by
qemu-system-x86_64 -cpu Haswell,+smep,+smap
On Thu, Apr 10, 2014 at 01:58:18AM +0800, Jet Chen wrote:
> On 04/09/2014 10:44 PM, Romer, Benjamin M wrote:
> > On Wed, 2014-04-09 at 02:38 +0800, Jet Chen wrote:
> >
>
CC the KVM people: it looks like a KVM problem that can be triggered by
qemu-system-x86_64 -cpu Haswell,+smep,+smap
On Thu, Apr 10, 2014 at 01:58:18AM +0800, Jet Chen wrote:
On 04/09/2014 10:44 PM, Romer, Benjamin M wrote:
On Wed, 2014-04-09 at 02:38 +0800, Jet Chen wrote:
Hi
On 04/09/2014 04:01 PM, Fengguang Wu wrote:
CC the KVM people: it looks like a KVM problem that can be triggered by
qemu-system-x86_64 -cpu Haswell,+smep,+smap
Is it a KVM problem or a Qemu bug? It sounds more like a Qemu JIT bug.
-hpa
On Thu, Apr 10, 2014 at 01:58:18AM
On 04/09/2014 04:01 PM, Fengguang Wu wrote:
CC the KVM people: it looks like a KVM problem that can be triggered by
qemu-system-x86_64 -cpu Haswell,+smep,+smap
I'm really confused. First of all, is this a KVM problem or is it a
Qemu JIT problem?
Either seems really wonky. It is
On Tue, 2014-04-08 at 10:53 +0800, Fengguang Wu wrote:
> Hi Benjamin,
>
> > Fengguang,
> >
> > I ran your script against freshly-checked-out source from staging-next, and
> > was not able to reproduce the error with it. My boot log is attached. I
> > noticed that your log did not have
On Tue, 2014-04-08 at 10:53 +0800, Fengguang Wu wrote:
Hi Benjamin,
Fengguang,
I ran your script against freshly-checked-out source from staging-next, and
was not able to reproduce the error with it. My boot log is attached. I
noticed that your log did not have Hypervisor detected:
Hi Benjamin,
> Fengguang,
>
> I ran your script against freshly-checked-out source from staging-next, and
> was not able to reproduce the error with it. My boot log is attached. I
> noticed that your log did not have "Hypervisor detected: KVM" in the trace.
> The KVM options in your script
On Mon, Apr 07, 2014 at 12:23:47PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 07, 2014 at 09:24:37AM -0500, Ken Cox wrote:
> >
> > On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
> > >On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
> > >>Hi Ken,
> > >>
> > >>I got the below
On Mon, Apr 07, 2014 at 09:24:37AM -0500, Ken Cox wrote:
>
> On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
> >On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
> >>Hi Ken,
> >>
> >>I got the below dmesg and the first bad commit is
> >>
>
On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 12e364b9f08aa335dc7716ce74113e834c993765
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
> Hi Ken,
>
> I got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 12e364b9f08aa335dc7716ce74113e834c993765
> Author: Ken Cox
> AuthorDate: Tue
On 04/07/2014 06:17 AM, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 12e364b9f08aa335dc7716ce74113e834c993765
Author: Ken Cox
AuthorDate: Tue Mar 4 07:58:07 2014 -0600
Commit:
On 04/07/2014 06:17 AM, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 12e364b9f08aa335dc7716ce74113e834c993765
Author: Ken Cox j...@redhat.com
AuthorDate: Tue Mar 4 07:58:07
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 12e364b9f08aa335dc7716ce74113e834c993765
Author: Ken Cox j...@redhat.com
On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 12e364b9f08aa335dc7716ce74113e834c993765
On Mon, Apr 07, 2014 at 09:24:37AM -0500, Ken Cox wrote:
On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first bad commit is
On Mon, Apr 07, 2014 at 12:23:47PM -0700, Greg Kroah-Hartman wrote:
On Mon, Apr 07, 2014 at 09:24:37AM -0500, Ken Cox wrote:
On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
Hi Ken,
I got the below dmesg and the first
Hi Benjamin,
Fengguang,
I ran your script against freshly-checked-out source from staging-next, and
was not able to reproduce the error with it. My boot log is attached. I
noticed that your log did not have Hypervisor detected: KVM in the trace.
The KVM options in your script also
40 matches
Mail list logo
