RE: Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional

From: "Cui, Dexuan" <dexuan.cui@intel.com>
To: Kouya Shimura <kouya@jp.fujitsu.com>
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: RE: Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Date: Mon, 9 Mar 2009 13:29:57 +0800	[thread overview]
Message-ID: <EADF0A36011179459010BDF5142A457507A4E168@pdsmsx502.ccr.corp.intel.com> (raw)
In-Reply-To: <7kljrfmsxn.fsf@pingu.sky.yk.fujitsu.co.jp>

Kouya Shimura wrote:
> Cui, Dexuan writes:
>> Yuji Shimada wrote:
>>> On Fri, 6 Mar 2009 14:23:20 +0900
>>> Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>>>> 
>>>> Using D3hot state of PCI devices in xen is not mature yet.
>>>> I met domain destruction/creation troubles in some PCI cards since
>>>> the PCI config registers can't be read with D3hot state. xend.log
>>>> is attached. 
>>>> 
>>>> This patch set makes the management of PCI D-states by guest
>>>> optional. 
>>>> 
>>>> The default is "pci_power_mgmt=0" which disables the guest OS from
>>>> managing D-states because it would be better to avoid the trouble
>>>> than advantage of low power consumption.
>> Is this the only reason to add the guest config parameter?
>> If yes, I don't think it is worthwhile to have two over-200-lines
>> patches. 
> 
> If the answer was yes, I would have proposed to revert the patches
> about PCI D-states. This patch enables individual setting for each PCI
> passthru device and that requires many lines.
> 
> Supposing a PCI device has a hardware bug, that is possible, don't you
> wish to disable *only* it?  Actually, Q-logic FC card which has two
> PCI functions looks ill.
I agree.

> 
> Any way, tool part of this patch is committed.
Now I think it's good. :-)

> 
>> IMO we should fix the code in xend.
> 
> I hope so, too.  After that, turn on "pci_power_mgmt=1".
Looks it's not very easy to fix xend here. :-(
e.g.,  I think the python error you see when guest is destroyed is caused by: xend tries to save the 256-byte pci config space of the assigned device before doing FLR, but at D3hot state, the config space is inaccessible.
So, if we allow guest to program D3/D0, the current "save just before do_FLR, do_FLR, restore" in xend doesn't work at all. We should save config space (into xenstore??) before assigning a deivce to guest, or we can save the proper values of config space into pciback.

Thanks,
 -- Dexuan