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

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

Kouya Shimura wrote:
> Cui, Dexuan writes:
>> Yuji Shimada wrote:
>>> On Fri, 6 Mar 2009 14:23:20 +0900
>>> Kouya Shimura <kouya@xxxxxxxxxxxxxx> 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



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