This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] HVM with old kernel(rh5.1) assigned device resume failure be

To: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>
Subject: [Xen-devel] HVM with old kernel(rh5.1) assigned device resume failure because of restore sequence
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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!

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