> On Wed, Nov 15, 2017 at 02:18:55PM +0100, Paolo Bonzini wrote:
> > On 15/11/2017 04:14, Xulei (Stone) wrote:
> > > Hi, guys
> > >
> > > I met a strange problem, with qemu 2.8.1:
> > > qemu consumes too many heap memory after several operations and
Hi, guys
I met a strange problem, with qemu 2.8.1:
qemu consumes too many heap memory after several operations and can not release
them anymore:
hot pulg/unplug disk & net, vnc connect/disconnect, guestOS reboot, etc.
01a7a000-3b4efe000 rw-p 00:00 0 [hea
On 07/17/2017 11:13 AM, Xulei (Stone) wrote:
>> |--virtio_queue_empty
>>
>> Then, kmod falls in infinite loop in handle EPT_MISCONFIG.
>> As far as i know, when kvm enters guest after handling EPT_MISCONFIG,
>> seabios should return
&
Hello all,
Recently, I met a werid question when i run a VM in the following platfrom:
Vmware Vsphere 6.0/6.5
|-- centos 7.3 nested VM (with qemu 2.8, kmod 4.4.11, seabios 1.10)
|-- VM (with virtio-scsi controller, modern mode)
VM MUST hang in seabios when try to mmio write during virt
>
> Hi
>
> - Original Message -
> > Hi, all
> > Recently, I have a VM with a vhost-user network card created by qemu 2.6.0.
> > Once, I restart OpenVSwitch service
> > and start this VM in the same time. I found qemu may probably crash
> > with following stack:
> >
> > (gdb) bt
> > #0 0
Hi, all
Recently, I have a VM with a vhost-user network card created by qemu 2.6.0.
Once, I restart OpenVSwitch service
and start this VM in the same time. I found qemu may probably crash with
following stack:
(gdb) bt
#0 0x7f0f9179a5d7 in raise () from /usr/lib64/libc.so.6
#1 0x7f0f91
> On 11/08/2016 04:13, Xulei (Stone) wrote:
> > Following your suggestion, I found this problem may be caused by the
> > flag of HF_SMM_MASK. I'm now sure QEMU is sending the KVM_SMI ioctl,
> > and kmod already handles this ioctl.
> >
> > I add print
> On 09/08/2016 10:04, Xulei (Stone) wrote:
> > Following your suggestion, i'm now sure it is caused by missing SMI.
> > I have tried adding dprintf() like this:
> >
> > --- a/roms/seabios/src/fw/smm.c
> > +++ b/roms/seabios/src/fw/smm.c
> > @@ -65,7
>On Tue, Aug 02, 2016 at 04:18:30AM +0000, Xulei (Stone) wrote:
>> >On Fri, Jul 29, 2016 at 04:04:59AM +0000, Xulei (Stone) wrote:
>> >> After one day, the vm is stuck. Looking from the following seabios
>> >> log, it seems seabios stops at "PCI: Using 00
>
>
>On 03/08/2016 11:43, Xulei (Stone) wrote:
>> Hi, all:
>> Recently I use a shell script to continuously reset a vm to see what may
>> happen.
>> After one day, the vm is stuck. Looking from the following seabios log and
>> kvm trace log, it seems like l
08-03 16:23:15before SMI
2016-08-03 16:23:15after SMI= <always stuck here, unless i destroy
it
As above, it is obviously that if bios doesn't handle_smi, PORT_SMI_STATUS is
always 0x01. smm_relocate_and_restore() will always in the while loop.
Why does bios handle_smi at thi
.
--
Xulei (Stone)
> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, March 29, 2016 6:37 PM
> To: Xulei (Stone)
> Cc: qemu-devel@nongnu.org; kra...@redhat.com; Gonglei (Arei); Wulizhen
> (Pss)
> Subject: Re: [Qemu-devel] [Question]Ctrl_R or
Is there anyone can give me some information? I would be very grateful.
I have met several times that the right ctrl key or right alt key is in a
pressed status and
never released until I inject a sendkey qmp command.
I use noVNC, a web-based vnc, as my vnc client. What confused me is that, noVN
e_hwpic1 irq=0
[2015-12-17 12:37:35] handle_hwpic1 irq=0
... always hanle_hwpic1 irq=0, never ends anymore...
>> -Original Message-
>> From: Kevin O'Connor [mailto:ke...@koconnor.net]
>> Sent: Tuesday, December 22, 2015 2:47 AM
>> To: Gonglei (Arei)
>> Cc: Xulei (Stone)
>On Thu, Nov 19, 2015 at 12:42:50PM +0000, Xulei (Stone) wrote:
>> Kevin,
>>
>> After deeply analyzing, i think there may be 3 possible reasons:
>> 1)wrong CountCPUs value. It seems CountCPUs++ in handle_smp() has no
>> lock to protect. So, sometimes, 2 or more
init bdf=00:0f.0 id=1af4:1001
>[2015-11-13 18:46:00] PCI: init bdf=00:10.0 id=1af4:1110
>[2015-11-13 18:46:00] PCI: init bdf=00:1f.0 id=1af4:
>[2015-11-13 18:46:00] PCI: Using 00:02.0 for primary VGA
>[2015-11-13 18:46:00] handle_smp: apic_id=1
>[2015-11-13 18:46:00] handle_smp: a
7;Connor wrote:
>> On Mon, Nov 09, 2015 at 08:32:53AM -0500, Kevin O'Connor wrote:
>> > On Fri, Nov 06, 2015 at 09:12:34AM +, Xulei (Stone) wrote:
>> > > >On Wed, Nov 04, 2015 at 08:48:20AM +0800, Gonglei wrote:
>> > > >I'm surprised you would
>On Wed, Nov 04, 2015 at 08:48:20AM +0800, Gonglei wrote:
>> On 2015/11/3 14:58, Xulei (Stone, Euler) wrote:
>> > On qemu-kvm platform, when I reset a VM through "virsh reset", and
>> > coincidently
>> > the VM is in process of internal rebooting at
On qemu-kvm platform, when I reset a VM through "virsh reset", and coincidently
the VM is in process of internal rebooting at the same time. Then the VM will
not be successfully reseted any more due to the reset reentrancy. I found:
(1)SeaBios try to shutdown the VM after reseting it failed by apm_
On qemu-kvm platform, when I reset a VM through "virsh reset", and coincidently
the VM is in process of internal rebooting at the same time. Then the VM will
not be successfully reseted any more due to the reset reentrancy. I found:
(1)SeaBios try to shutdown the VM after reseting it failed by apm_
On qemu-kvm platform, when I reset a VM through "virsh reset", and coincidently
the VM is in process of internal rebooting at the same time. Then the VM will
not be successfully reseted any more due to the reset reentrancy. I found:
(1)SeaBios try to shutdown the VM after reseting it failed by ap
22 matches
Mail list logo
