* Re: ata driver loading hang on qemu/kvm intel
2020-04-06 8:13 ` ata driver loading hang on qemu/kvm intel Paolo Bonzini
@ 2020-04-06 15:30 ` Suresh Gumpula
2020-04-06 17:01 ` John Snow
0 siblings, 1 reply; 4+ messages in thread
From: Suresh Gumpula @ 2020-04-06 15:30 UTC (permalink / raw)
To: Paolo Bonzini, kvm, linux-kernel
Hi Paolo,
Thanks much for the quick response.
We are not running nested guest here , just enabled in the host, so the host is capable of running nested, but we are not running nested guests.
The guest kernel(not a nested guest) boot iso. i.e its regular VM on a host is hanging with following errors.
Its consistently reproducible with some load on the host.
Guest serial log:
[ 1.414035] Write protecting the kernel read-only data: 6144k
[ 1.418006] Freeing unused kernel memory: 1080K
[ 1.423033] Freeing unused kernel memory: 1004K
[ 1.466783] scsi host0: ata_piix
[ 1.469539] scsi host1: ata_piix
[ 1.472039] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc300 irq 14
[ 1.475740] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc308 irq 15
Guest vcpu registers:
[root@NTNX-MADMAX01-A ~]# virsh qemu-monitor-command --domain 3014 --hmp --cmd info registers -a |egrep -i ‘eip|rip’
RIP=ffffffff842f9887 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
EIP=000fd0f5 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=1
Qemu trace logs:
cd_read_sector 0.866 pid=68853 lba=0x60f
cd_read_sector_cb 89.730 pid=68853 lba=0x60f ret=0x0
ide_atapi_cmd_reply_end 1.084 pid=68853 s=0x55dd90cde0a8 tx_size=0x800 elem_tx_size=0x0 index=0x0
ide_atapi_cmd_reply_end_bcl 0.342 pid=68853 s=0x55dd90cde0a8 bcl=0x800
ide_atapi_cmd_reply_end_new 0.485 pid=68853 s=0x55dd90cde0a8 status=0x58
ide_atapi_cmd_reply_end 298.203 pid=68853 s=0x55dd90cde0a8 tx_size=0x0 elem_tx_size=0x0 index=0x800
ide_atapi_cmd_reply_end_eot 0.554 pid=68853 s=0x55dd90cde0a8 status=0x50
bmdma_read 1550089.160 pid=68853 addr=0x2 val=0x0
bmdma_read 9.003 pid=68853 addr=0x2 val=0x0
bmdma_read 512.186 pid=68853 addr=0x2 val=0x0
bmdma_write 7.776 pid=68853 addr=0x2 val=0x0
bmdma_read 26.277 pid=68853 addr=0x2 val=0x0
bmdma_write 7.294 pid=68853 addr=0x2 val=0x0
bmdma_read 13917.904 pid=68853 addr=0x2 val=0x0
bmdma_write 7.843 pid=68853 addr=0x2 val=0x0
bmdma_read 382.849 pid=68853 addr=0x2 val=0x0
bmdma_write 7.280 pid=68853 addr=0x2 val=0x0
All the guest vcpus are in halt state(hlt=1) and only one vcpu is in 64 bit and rest all in 32.
I am thinking probably guest missed an interrupt and waiting for ever.
Not sure if this is ide emulation issue in the qemu or a bug in the kvm module.
Thanks,
Suresh
On 4/6/20, 1:13 AM, "Paolo Bonzini" <pbonzini@redhat.com> wrote:
On 05/04/20 01:36, Suresh Gumpula wrote:
> Hi,
>
> I am seeing this old problem with qemu 2.12/kernel 4.19.84(intel kvm
> with nesting enabled) and guest kernel 4.10
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1345964&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=F-ygQ993NOjzeEnzE4m1YQM2dkkoF0uqOdC0cuSJSQc&m=37pz6pqZuAoO_2NHYfODlXoxXpQBcgBrh6axdah6aqc&s=T9ZcI9Rz-PSG6M0tDOf11DnKk_OTKXIAoxWPsKuzRVE&e=
>
> Could you please advise me on this? I am seeing the exact same problem
> where the ata driver load was stuck.
>
> Really appreciate if you could give some pointers?
>
> Is it a known issue with nesting? Or is this bug fixed in latest kvm module?
Hi, that bug was specific to running under Ravello, not on bare metal.
I have not received any other reports.
To clarify you have:
- QEMU 2.12 and kernel 4.19.x on the host
- kernel 4.10.x on the guest
What QEMU version is running in the guest and what kernel version in the
nested guest?
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread