[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] HVM with old kernel(rh5.1) assigned device resume failure because of restore sequence


  • To: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>
  • From: "Ke, Liping" <liping.ke@xxxxxxxxx>
  • Date: Fri, 17 Apr 2009 10:32:31 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 16 Apr 2009 19:35:14 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acm/BMJZfl4AfAExR+qdaUFomvRSjw==
  • Thread-topic: HVM with old kernel(rh5.1) assigned device resume failure because of restore sequence

Hi, Yuji Shimada
 
Latest, QA reported that on rh5.1, if we enable pci_power_mgmt, after hvm resume,
assigned e1000e 82572EI Gigabit network card could not resume back. (the card has pm cap) 
 
We root cause this bug is caused by the incorrect cooperation of old kernel/qemu pci register
restore sequence during D3hot->D0.
 
Older kernel(before 2.6.18 in rh5.1) cmd register is restored before Bar register,
it will cause qemu passthrough pt_mapping_bars failure.
(In qemu, pt_bar_mappings is done in pt_cmd_reg_write. pt_bar_reg_write is not performed
yet, then pt_bar_mappings can't map the correct address)
Latest kernel (after 2.6.2X) has no such problem. (When do pt_bar_mapping in pt_cmd_reg_write,
pt_bar_reg_write is already done).
 
I pasted corrected Qemu(2.6.29) log (line 660) and uncorrected Qemu(rh5.1) Log (Line 554)
and add [ criping XXX] comments for your reference.
For supporting old kernel, could we consider to change the pt_bar_mappings sequence in Qemu?
We'd like to have your opinions first.
 
Thanks a lot for your help!
Criping
 
 
 
 

Attachment: qemu_2.6.29.log
Description: qemu_2.6.29.log

Attachment: qemu_rh5.1.log
Description: qemu_rh5.1.log

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.