Gerd Hoffmann writes:
> On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
>> Jan Kiszka writes:
>>
>> > Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
>> >> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
>> >>> Hi,
>> >>>
>> >>> apparently since the latest QEMU updates I'm getting this on
On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
> Jan Kiszka writes:
>
> > Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
> >> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
> >>> Hi,
> >>>
> >>> apparently since the latest QEMU updates I'm getting this once in a
> >>> while:
> >>
> >> h
Jan Kiszka writes:
> Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
>> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
>>> Hi,
>>>
>>> apparently since the latest QEMU updates I'm getting this once in a
>>> while:
>>
>> http://www.seabios.org/pipermail/seabios/2015-March/008897.html
>
> OK...
On Do, 2015-03-12 at 09:14 +0100, Jan Kiszka wrote:
> Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
> > On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
> >> Hi,
> >>
> >> apparently since the latest QEMU updates I'm getting this once in a
> >> while:
> >
> > http://www.seabios.org/pipermail/se
Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
>> Hi,
>>
>> apparently since the latest QEMU updates I'm getting this once in a
>> while:
>
> http://www.seabios.org/pipermail/seabios/2015-March/008897.html
OK... So we are waiting on a stable re
On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
> Hi,
>
> apparently since the latest QEMU updates I'm getting this once in a
> while:
http://www.seabios.org/pipermail/seabios/2015-March/008897.html
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bod
Hi,
apparently since the latest QEMU updates I'm getting this once in a
while:
KVM internal error. Suberror: 1
emulation failure
EAX= EBX= ECX= EDX=000fd2bc
ESI= EDI= EBP= ESP=
EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=
On Tue, Jan 07, 2014 at 09:37:07PM +0100, Guido Winkelmann wrote:
> >Code=7c 68 01 00 68 10 00 b4 42 8a 56 00 8b f4 cd 13 9f 83 c4 10 <9e> eb 14
9e is SAHF instruction. Its emulation was added in 3.13.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kv
On Wednesday 08 January 2014 19:40:10 Marcelo Tosatti wrote:
>On Tue, Jan 07, 2014 at 07:48:41PM +0100, Guido Winkelmann wrote:
>> Hi,
>>
>> When trying to boot a Windows 7 install from a local virtual disks, qemu
>> stops with the messages:
>>
>> KVM i
On Tue, Jan 07, 2014 at 07:48:41PM +0100, Guido Winkelmann wrote:
> Hi,
>
> When trying to boot a Windows 7 install from a local virtual disks, qemu
> stops
> with the messages:
>
> KVM internal error. Suberror: 1
> emulation failure
Can you please enable the follo
rnal error. Suberror: 1
>emulation failure
>
>I've started qemu with libvirt. This is the output from libvirt's logfile:
>
>2014-01-07 18:22:10.988+: starting up
>LC_ALL=C
>PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/b
>in:/usr/
Hi,
When trying to boot a Windows 7 install from a local virtual disks, qemu stops
with the messages:
KVM internal error. Suberror: 1
emulation failure
I've started qemu with libvirt. This is the output from libvirt's logfile:
2014-01-07 18:22:10.988+: starting up
LC_ALL=C
Il 20/08/2013 03:26, Duy Nguyen TN ha scritto:
> Vào T2, ngày 19, 08 năm 2013 lúc 11:27 +0200, Paolo Bonzini viết:
>>> The disassembled code is
>>>
>>>0x1dd10:push %rbx
>>>0x1dd11:mov$0x6e,%eax
>>>0x1dd16:mov%rdi,%rbx
>>>0x1dd19:sub$0x20,%rsp
>>>0x1
Vào T2, ngày 19, 08 năm 2013 lúc 11:27 +0200, Paolo Bonzini viết:
> > The disassembled code is
> >
> >0x1dd10:push %rbx
> >0x1dd11:mov$0x6e,%eax
> >0x1dd16:mov%rdi,%rbx
> >0x1dd19:sub$0x20,%rsp
> >0x1dd1d:test %rdi,%rdi
> >0x1dd20:je
o prepare new kernel.
>
> KVM internal error. Suberror: 1
> emulation failure
> RAX=77ff9000 RBX=77e93608 RCX=75d4d81a
> RDX=0001
> RSI=1000 RDI= RBP=69a07700
> RSP=77e934b0
> R8 =00
Hi,
I got this error with qem-kvm-0.15.1 on kernel 3.1.0-1.2-desktop
(OpenSUSE 12.1). I know I should rerun it with latest kernel/qemu but I
hope maybe this rings a bell or something, because it'll take some time
for me to prepare new kernel.
KVM internal error. Suberror: 1
emulation failur
On Thu, Jul 18, 2013 at 07:58:31AM +0200, Paolo Bonzini wrote:
> Il 17/07/2013 18:16, Dave Hansen ha scritto:
> > I'm causing qemu to spew these emulation failure messages until I kill
> > it. The guest kernel being run has been hacked up pretty heavily and is
> > pro
Il 17/07/2013 18:16, Dave Hansen ha scritto:
> I'm causing qemu to spew these emulation failure messages until I kill
> it. The guest kernel being run has been hacked up pretty heavily and is
> probably either accessing bad physical addresses (above the address
> ranges in t
On Wed, Jul 17, 2013 at 09:16:33AM -0700, Dave Hansen wrote:
> I'm causing qemu to spew these emulation failure messages until I kill
> it. The guest kernel being run has been hacked up pretty heavily and is
> probably either accessing bad physical addresses (above the address
&
I'm causing qemu to spew these emulation failure messages until I kill
it. The guest kernel being run has been hacked up pretty heavily and is
probably either accessing bad physical addresses (above the address
ranges in the e820 table) or trying to DMA to bad addresses.
What I'd r
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
Kevin Wolf writes:
> Good point... The only other thing that I can think of would be
> attaching gdb and setting a breakpoint in vm_stop() or something.
Perfect, that seems to identified what's going on very nicely:
(gdb) break vm_stop
Breakpoint 1 at 0x407d10: file /home/root/packages/qemu-kvm
Am 24.10.2011 13:29, schrieb Chris Webb:
> Kevin Wolf writes:
>
>> In qemu 1.0 we'll have an extended 'info status' that includes the stop
>> reason, but 0.14 doesn't have this yet (was committed to git master only
>> recently).
>
> Right, okay. I might take a look at cherry-picking and back-por
Kevin Wolf writes:
> In qemu 1.0 we'll have an extended 'info status' that includes the stop
> reason, but 0.14 doesn't have this yet (was committed to git master only
> recently).
Right, okay. I might take a look at cherry-picking and back-porting that to
our version of qemu-kvm if it's not too
ed this guest
>>> to stop, e.g. the unsupported instruction if it's an emulation failure?
>>
>> Another common cause for stopped VMs are I/O errors, for example writes
>> to a sparse image when the disk is full.
>
> This guest are backed by LVM LVs so I don't thi
Kevin Wolf writes:
> Am 24.10.2011 12:00, schrieb Chris Webb:
> > I have qemu monitor access and can even strace the relevant qemu process if
> > necessary: is it possible to use this to diagnose what's caused this guest
> > to stop, e.g. the unsupported instruction if
elevant qemu process if
> necessary: is it possible to use this to diagnose what's caused this guest
> to stop, e.g. the unsupported instruction if it's an emulation failure?
Another common cause for stopped VMs are I/O errors, for example writes
to a sparse image when the disk is fu
struction if it's an emulation failure?
Cheers,
Chris.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/07/2011 12:28 PM, Ravi Kumar Kulkarni wrote:
On Mon, Feb 7, 2011 at 3:24 PM, Avi Kivity wrote:
> On 02/07/2011 11:47 AM, Ravi Kumar Kulkarni wrote:
>>
>> >
>> >That is not the same address. And the code you posted doesn't make any
>> >sense.
>> >
>>sorry for the mistake.
avl 1)
ldt (/ p 1
dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt 1f522006/7f
idt 1f9af000/7ff
cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
emulation failure,
check dmesg for details
On 02/07/2011 11:47 AM, Ravi Kumar Kulkarni wrote:
>
> That is not the same address. And the code you posted doesn't make any
> sense.
>
sorry for the mistake. here's the correct one
(qemu) xp /20iw 0x1e2f3f7b
0x1e2f3f7b: (bad)
0x0
On Mon, Feb 7, 2011 at 2:59 PM, Avi Kivity wrote:
> On 02/07/2011 11:24 AM, Ravi Kumar Kulkarni wrote:
>>
>> On Mon, Feb 7, 2011 at 2:19 PM, Avi Kivity wrote:
>> > On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
>> >>
>> >> On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivity wrote:
>> >>>
>> >>>
On 02/07/2011 11:24 AM, Ravi Kumar Kulkarni wrote:
On Mon, Feb 7, 2011 at 2:19 PM, Avi Kivity wrote:
> On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
>>
>> On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivitywrote:
>>>
>>> >On 02/04/2011 03:58 PM, Jan Kiszka wrote:
>>
>
On Mon, Feb 7, 2011 at 2:19 PM, Avi Kivity wrote:
> On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
>>
>> On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivity wrote:
>>>
>>> > On 02/04/2011 03:58 PM, Jan Kiszka wrote:
>>
>
> >> > when i run my kernel image with qemu-kvm it gives
On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivity wrote:
> On 02/04/2011 03:58 PM, Jan Kiszka wrote:
>>
>> > when i run my kernel image with qemu-kvm it gives emulation error
>> > failure
>> >trying to execute the code outside ROM or R
0 s 0 type b l 0 g 0 avl 1)
ldt (/ p 1 dpl 0 db 0 s 0
type 2 l 0 g 0 avl 0)
gdt 1f522006/7f
idt 1f9af000/7ff
cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
emulation failure, check dmesg for
details
On 02/04/2011 03:58 PM, Jan Kiszka wrote:
> when i run my kernel image with qemu-kvm it gives emulation error failure
> trying to execute the code outside ROM or RAM at fec0(IO APIC base
address)
> but the same code runs fine with qemu. can anyone please point me
> where might be the pr
On 2011-02-04 14:35, Ravi Kumar Kulkarni wrote:
> Hi all,
> I'm Initializing the Local and IO APIC for a propeitary operating
> system running in Virtualized Environment .
> Im facing some problem with qemu-kvm but the code runs fine with qemu.
Does it also run fine with qemu-kvm and -no-kvm-i
Hi all,
I'm Initializing the Local and IO APIC for a propeitary operating
system running in Virtualized Environment .
Im facing some problem with qemu-kvm but the code runs fine with qemu.
when i run my kernel image with qemu-kvm it gives emulation error failure
trying to execute the code outs
assumes that this was attempt to do MMIO
and reports emulation failure to userspace since there is no way to fix
the situation. This logic has a race though. If two vcpus tries to write
to the same shadowed page simultaneously both will enter emulator, but
only one of them will find the page in shadow
reports emulation failure to userspace since there is no way to fix
the situation. This logic has a race though. If two vcpus tries to write
to the same shadowed page simultaneously both will enter emulator, but
only one of them will find the page in shadow page hash since the one who
founds it also
On 07/08/2010 12:17 PM, Gleb Natapov wrote:
btw, that will mean another page walk, so better fold into
kvm_mmu_unprotect_page_virt() (which needs a new name, since it does
more than unprotect a page now).
But this code will be taken very rarely and usually on the way to
failure anyway,
. If emulation fails KVM un-shadows the
> >>page and reenter guest to allow vcpu to execute the instruction. If page
> >>is not in shadow page hash KVM assumes that this was attempt to do MMIO
> >>and reports emulation failure to userspace since there is no way to fix
> &g
. If page
is not in shadow page hash KVM assumes that this was attempt to do MMIO
and reports emulation failure to userspace since there is no way to fix
the situation. This logic has a race though. If two vcpus tries to write
to the same shadowed page simultaneously both will enter emulator, but
assumes that this was attempt to do MMIO
and reports emulation failure to userspace since there is no way to fix
the situation. This logic has a race though. If two vcpus tries to write
to the same shadowed page simultaneously both will enter emulator, but
only one of them will find the page in shadow
reports emulation failure to userspace since there is no way to fix
the situation. This logic has a race though. If two vcpus tries to write
to the same shadowed page simultaneously both will enter emulator, but
only one of them will find the page in shadow page hash since the one who
founds it also
Currently emulator returns -1 when emulation failed or IO is needed.
Caller tries to guess whether emulation failed by looking at other
variables. Make it easier for caller to recognise error condition by
always returning -1 in case of failure. For this new emulator
internal return value X86EMUL_IO
If emulation failed return immediately.
Signed-off-by: Gleb Natapov
---
arch/x86/kvm/x86.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 696b34b..445769b 100644
--- a/arch/x86/kvm/x86.c
+++ b
Currently emulator returns -1 when emulation failed or IO is needed.
Caller tries to guess whether emulation failed by looking at other
variables. Make it easier for caller to recognise error condition by
always returning -1 in case of failure. For this new emulator
internal return value X86EMUL_IO
If emulation failed return immediately.
Signed-off-by: Gleb Natapov
---
arch/x86/kvm/x86.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4f0a0a1..f1ebeed 100644
--- a/arch/x86/kvm/x86.c
+++ b
do.
So we remove the emulation failure report in handle_invalid_guest_state(),
and would inspected the guest using userspace tool in the future.
Signed-off-by: Sheng Yang
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/vmx.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --g
On Tue, Jan 19, 2010 at 05:43:58PM +0800, Sheng Yang wrote:
> User can use QEmu to get more information. E.g. using the QEmu built-in
> disassembly to get the failure instruction like(in the monitor):
>
> x /20i $eip
>
> to dump the code at $eip, or using "x /20i $eip-20" to look around.
Applied
ROR_EMULATION)
-fprintf(stderr, "emulation failure, check dmesg for details\n");
+ fprintf(stderr, "emulation failure\n");
vm_stop(0);
return 1;
}
--
1.5.4.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
92c2f9a..27b9905 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3438,7 +3438,6 @@ static int handle_invalid_guest_state(struct kvm_vcpu
*vcpu)
}
if (err != EMULATE_DONE) {
- kvm_report_emulation_failure(vcpu, &
On Tuesday 19 January 2010 15:57:57 Gleb Natapov wrote:
> On Tue, Jan 19, 2010 at 09:54:44AM +0200, Avi Kivity wrote:
> > On 01/19/2010 05:06 AM, Sheng Yang wrote:
> > >>There are two problems with the kernel failure report. First, it
> > >>doesn't report enough data - registers, surrounding instr
On Tue, Jan 19, 2010 at 09:54:44AM +0200, Avi Kivity wrote:
> On 01/19/2010 05:06 AM, Sheng Yang wrote:
> >
> >>There are two problems with the kernel failure report. First, it
> >>doesn't report enough data - registers, surrounding instructions, etc.
> >>that are needed to explain what is going o
On 01/19/2010 05:06 AM, Sheng Yang wrote:
There are two problems with the kernel failure report. First, it
doesn't report enough data - registers, surrounding instructions, etc.
that are needed to explain what is going on. Second, it can flood
dmesg, which is a pretty bad thing to do.
On Monday 18 January 2010 19:32:14 Avi Kivity wrote:
> On 01/18/2010 11:32 AM, Sheng Yang wrote:
> > On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
> >> On 01/15/2010 10:44 AM, Sheng Yang wrote:
> >>> Currently we only have handle_invalid_guest_state() re
On 01/18/2010 11:32 AM, Sheng Yang wrote:
On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
On 01/15/2010 10:44 AM, Sheng Yang wrote:
Currently we only have handle_invalid_guest_state() reported emulation
failure...
This is intentional - instead of spamming dmesg, we exit
On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
> On 01/15/2010 10:44 AM, Sheng Yang wrote:
> > Currently we only have handle_invalid_guest_state() reported emulation
> > failure...
> >
> > Signed-off-by: Sheng Yang
> > ---
> > arch/x86/kvm/mmu.c |
On 01/15/2010 10:44 AM, Sheng Yang wrote:
Currently we only have handle_invalid_guest_state() reported emulation
failure...
Signed-off-by: Sheng Yang
---
arch/x86/kvm/mmu.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index
Currently we only have handle_invalid_guest_state() reported emulation
failure...
Signed-off-by: Sheng Yang
---
arch/x86/kvm/mmu.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 4f5508c..037e52a 100644
--- a/arch/x86/kvm
On Tue, Sep 01, 2009 at 03:13:20PM +0200, Mohammed Gamal wrote:
> Since we return to userspace from KVM on invalid state emulation failure, let
> qemu handle it.
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a m
Since we return to userspace from KVM on invalid state emulation failure, let
qemu handle it.
Signed-off-by: Mohammed Gamal
---
qemu-kvm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index b59e403..090a3ae 100644
--- a/qemu-kvm.c
+++ b
On Tue, Sep 1, 2009 at 2:31 PM, Marcelo Tosatti wrote:
> On Fri, Aug 28, 2009 at 04:48:53PM +0200, Mohammed Gamal wrote:
>> Since we return to userspace from KVM on invalid state emulation failure, let
>> qemu handle it.
>>
>> Signed-off-by: Mohammed Gamal
&
On Fri, Aug 28, 2009 at 04:48:53PM +0200, Mohammed Gamal wrote:
> Since we return to userspace from KVM on invalid state emulation failure, let
> qemu handle it.
>
> Signed-off-by: Mohammed Gamal
> ---
> qemu-kvm.c |8
> 1 files changed, 8 insertions(+), 0 d
Since we return to userspace from KVM on invalid state emulation failure, let
qemu handle it.
Signed-off-by: Mohammed Gamal
---
qemu-kvm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index b59e403..a1648e0 100644
--- a/qemu-kvm.c
+++ b
Since we return to userspace from KVM on invalid state emulation failure, let
qemu handle it.
Signed-off-by: Mohammed Gamal
---
qemu-kvm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index b59e403..a1648e0 100644
--- a/qemu-kvm.c
+++ b
)
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emulation
failure");
+ vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ vcpu->run->internal.suberror =
KVM_IN
; @@ -3337,6 +3337,8 @@ static void handle_invalid_guest_state(struct
>> kvm_vcpu *vcpu)
>>
>> if (err != EMULATE_DONE) {
>> kvm_report_emulation_failure(vcpu, "emulation
>> failure");
>> + vcpu-&
, "emulation failure");
+ vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ vcpu->run->internal.suberror =
KVM_INTERNAL_ERROR_EMULATION;
break;
}
@@ -3607,7 +3609,9 @@ static void vmx_vcpu_run
100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3337,6 +3337,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu)
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emulation failure");
+
100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3341,6 +3341,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emulation failure");
+
b/arch/x86/kvm/vmx.c
index 1ee811c..6030671 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3341,6 +3341,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emul
100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3341,6 +3341,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emulation failure");
+
Instead of mindlessly retrying to execute the instruction, report the
failure to userspace.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/mmu.c |5 +++--
include/linux/kvm.h |7 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
vm_vcpu
> *vcpu,
>
> if (err != EMULATE_DONE) {
> kvm_report_emulation_failure(vcpu, "emulation failure");
> - return;
> + break;
> }
>
> if (signal_pe
/x86/kvm/vmx.c
index 3a75db3..7a8d464 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3335,7 +3335,7 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
if (err != EMULATE_DONE) {
kvm_report_emulation_failure(vcpu, "emul
On Mon, 2009-06-22 at 11:26 +0300, Avi Kivity wrote:
> On 06/22/2009 09:55 AM, Ram Pai wrote:
> > On Mon, 2009-06-22 at 13:12 +0800, Sheng Yang wrote:
> >
> >> On Saturday 20 June 2009 03:23:40 Ram Pai wrote:
> >>
> >>> I see this problem with a x86 sles10 guest running on x86_64 intel ho
On 06/22/2009 09:55 AM, Ram Pai wrote:
On Mon, 2009-06-22 at 13:12 +0800, Sheng Yang wrote:
On Saturday 20 June 2009 03:23:40 Ram Pai wrote:
I see this problem with a x86 sles10 guest running on x86_64 intel host.
If the guest is reset abruptly and rebooted, some where
before grub seq
On Monday 22 June 2009 14:55:46 Ram Pai wrote:
> On Mon, 2009-06-22 at 13:12 +0800, Sheng Yang wrote:
> > On Saturday 20 June 2009 03:23:40 Ram Pai wrote:
> > > I see this problem with a x86 sles10 guest running on x86_64 intel
> > > host. If the guest is reset abruptly and rebooted, some where
> >
On Mon, 2009-06-22 at 13:12 +0800, Sheng Yang wrote:
> On Saturday 20 June 2009 03:23:40 Ram Pai wrote:
> > I see this problem with a x86 sles10 guest running on x86_64 intel host.
> > If the guest is reset abruptly and rebooted, some where
> > before grub sequence it hangs and the following messag
On Saturday 20 June 2009 03:23:40 Ram Pai wrote:
> I see this problem with a x86 sles10 guest running on x86_64 intel host.
> If the guest is reset abruptly and rebooted, some where
> before grub sequence it hangs and the following message is seen in the
> logs
>
> emulation failed (pagetable) rip
I see this problem with a x86 sles10 guest running on x86_64 intel host.
If the guest is reset abruptly and rebooted, some where
before grub sequence it hangs and the following message is seen in the
logs
emulation failed (pagetable) rip 7ed5 66 60 ac 20.
I located this instruction sequence in i
From: Glauber Costa <[EMAIL PROTECTED]>
If we're not gonna do anything (case in which failure is already
reported), we do not need to even bother with calculating the linear rip.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c
Glauber Costa wrote:
I don't think so. It wasn't enough messages to DoS the system.
Just enough messages to annoy me.
If emulation failure messages annoy you, I'm sure you can think of a way
of removing them other than tampering with kvm_report_emulation_failure().
--
On Fri, Jun 13, 2008 at 11:14 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber Costa wrote:
>>>
>>> I've changed it to use printk_ratelimit().
>>>
>>
>> I've tested this option here before sending out the patch, since it
>> would address all issues.
>>
>> But in error cases, it still seemed to g
Glauber Costa wrote:
I've changed it to use printk_ratelimit().
I've tested this option here before sending out the patch, since it
would address all issues.
But in error cases, it still seemed to generate too many messages.
Isn't that a bug in printk_ratelimit(), then?
--
I have
On Fri, Jun 13, 2008 at 4:46 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber Costa wrote:
unsigned long rip = vcpu->arch.rip;
unsigned long rip_linear;
- rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS);
-
if (reported)
Glauber Costa wrote:
unsigned long rip = vcpu->arch.rip;
unsigned long rip_linear;
- rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS);
-
if (reported)
return;
+ rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS);
+
emulator_read
On Fri, Jun 13, 2008 at 2:33 PM, Mohammed Gamal <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 4:46 PM, Glauber Costa <[EMAIL PROTECTED]> wrote:
>> If we're not gonna do anything (case in which failure is already
>> reported), we do not need to even bother with calculating the linear rip.
>>
On Tue, Jun 10, 2008 at 4:46 PM, Glauber Costa <[EMAIL PROTECTED]> wrote:
> If we're not gonna do anything (case in which failure is already
> reported), we do not need to even bother with calculating the linear rip.
>
> This is a nitpick, but I saw it while doing some testing, so here's
> the patc
Glauber Costa wrote:
If we're not gonna do anything (case in which failure is already
reported), we do not need to even bother with calculating the linear rip.
This is a nitpick, but I saw it while doing some testing, so here's
the patch.
Applied, thanks.
--
I have a truly marvellous patc
If we're not gonna do anything (case in which failure is already
reported), we do not need to even bother with calculating the linear rip.
This is a nitpick, but I saw it while doing some testing, so here's
the patch.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |4
97 matches
Mail list logo
