on 22/09/2013 11:17 Gleb Natapov said the following:
> On Sun, Sep 22, 2013 at 11:05:37AM +0300, Andriy Gapon wrote:
>> on 22/09/2013 09:31 Gleb Natapov said the following:
>>> Which kernel version is this? What BSD version?
>>
>> $ uname -a
>> Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00
On Sun, Sep 22, 2013 at 11:05:37AM +0300, Andriy Gapon wrote:
> on 22/09/2013 09:31 Gleb Natapov said the following:
> > Which kernel version is this? What BSD version?
>
> $ uname -a
> Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linux
>
That's
on 22/09/2013 09:31 Gleb Natapov said the following:
> Which kernel version is this? What BSD version?
$ uname -a
Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
FreeBSD is 9.x.
--
Andriy Gapon
On Thu, Sep 19, 2013 at 08:49:51PM +0300, Andriy Gapon wrote:
> on 19/09/2013 19:53 Paolo Bonzini said the following:
> > Il 19/09/2013 16:36, Andriy Gapon ha scritto:
> >> Not sure how the code ends up at 0x9315 after that.
> >
> > Events are dropped, probably corresponding to more emulation.
>
on 19/09/2013 19:53 Paolo Bonzini said the following:
> Il 19/09/2013 16:36, Andriy Gapon ha scritto:
>> Not sure how the code ends up at 0x9315 after that.
>
> Events are dropped, probably corresponding to more emulation.
I've got a trace without dropped events between the last "normal" instruct
on 19/09/2013 20:26 Paolo Bonzini said the following:
> I don't think that's what happens. It's more likely that for some
> reason the emulator mis-parses the instruction.
>
> Please confirm with "info cpus" that QEMU is looping there (just in
> case), and attach the output of "info registers" (y
Il 19/09/2013 16:36, Andriy Gapon ha scritto:
> Not sure how the code ends up at 0x9315 after that.
Events are dropped, probably corresponding to more emulation.
> And here is original assembly code:
> rret_tramp: movw $MEM_ESPR-0x08,%sp # Reset stack pointer
> pushal
on 19/09/2013 19:53 Paolo Bonzini said the following:
> 1) Can you try loading the kvm_intel module with
> emulate_invalid_guest_state=0?
Will do.
> 2) What are the contents of fs and gs? Why are they not zeroed?
> Perhaps that is causing invalid guest state emulation to run, and then
> somethin
Il 19/09/2013 19:18, Andriy Gapon ha scritto:
> on 19/09/2013 19:53 Paolo Bonzini said the following:
>> 1) Can you try loading the kvm_intel module with
>> emulate_invalid_guest_state=0?
>
> Will do.
>
>> 2) What are the contents of fs and gs? Why are they not zeroed?
>> Perhaps that is causing
on 17/09/2013 21:49 Gleb Natapov said the following:
> http://www.linux-kvm.org/page/Tracing
Gleb,
thank you very much!
Here's an interesting snippet from the trace:
qemu-system-x86-4639 [003] 263925.182731: kvm_entry:vcpu 0
qemu-system-x86-4639 [003] 263925.182733: kvm_exit:
On Tue, Sep 17, 2013 at 05:33:57PM +0300, Andriy Gapon wrote:
> on 17/09/2013 15:32 Andreas Färber said the following:
> > Hi,
> >
> > Am 17.09.2013 13:37, schrieb Andriy Gapon:
> >>
> >> It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not
> >> produce anything. At least, wi
on 17/09/2013 15:32 Andreas Färber said the following:
> Hi,
>
> Am 17.09.2013 13:37, schrieb Andriy Gapon:
>>
>> It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not
>> produce anything. At least, with the qemu and kvm that I have access to.
>
> Are you saying that with acc
Hi,
Am 17.09.2013 13:37, schrieb Andriy Gapon:
>
> It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not
> produce anything. At least, with the qemu and kvm that I have access to.
Are you saying that with accel=kvm:tcg when falling back to TCG, -d
in_asm does not work?
For
It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not
produce anything. At least, with the qemu and kvm that I have access to.
Is there any way to obtain equivalent logging in such a configuration?
A note: a host and a guest are both amd64 (x86_64).
Some background. I am try
14 matches
Mail list logo
