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

Re: [Xen-devel] [PATCH] Improve the current FLR logic


  • To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
  • From: "Neo Jia" <neojia@xxxxxxxxx>
  • Date: Thu, 18 Sep 2008 23:45:36 -0700
  • Cc: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 18 Sep 2008 23:45:59 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=odhPZxLpjNEf8MCy1CkWzsgYoC9CaKOA81txUj0zIukm9stgTNqQXnSwmHivhzySHN 6FtpyRyDbh7SZVj7bcjP5SBpDT637i4ETvihHn5a/HhqfMTJDTdOuHS1IQIrkAyv5Nje KgGBnZHFCO7/iTzdyOT7cY4qR/PSwVACQ7pLc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Dexuan,

May I know the current development stage of FLR in pciback driver?

Thanks,
Neo

On Thu, Jul 24, 2008 at 3:19 AM, Cui, Dexuan <dexuan.cui@xxxxxxxxx> wrote:
> Yuji Shimada wrote:
>>> Yuji Shimada wrote:
>>>> On Wed, 23 Jul 2008 11:16:31 +0800
>>>> "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
>>>>> I think xenstore seems to be a little ugly place to remember the
>>>>> proper values of all or part of registers of all the devices in
>>>>> the system. I agree pciback is a good place.
>>>>> Yes. Now I realize pciback seems to be the best place to do most of
>>>>> the FLR logic. But this needs modify pciback and add interfaces for
>>>>> Control Panel. I'm not sure the changes can be small enought to be
>>>>> in 3.3.
>>>>
>>>> Hi Cui,
>>>>
>>>> What do you think about the following idea?
>>>>   - For 3.3, modify xend to have limited saving/restoring and
>>>> resetting functions.
>>>>   - For 3.4, modify pciback to have proper saving/restoring and
>>>>     resetting functions.
>>> Hi Yuji,
>>> Thanks very much for the suggestions!
>>> I agree.
>>>
>>>> The purpose of saving is to save the values configured by firmware.
>>>> So the best timing of saving the value is when dom0 starts. But if
>>>> saving the values when dom0 starts, pciback is the best place to
>>>> save/restore. If pciback saves/restores the values, we need many
>>>> codings. So it is difficult to achieve it in 3.3.
>>>>
>>>> So for 3.3, there is a way that saving the value just before
>>>> resetting. It is possible xend saves/restores the value, I think. In
>>>
>>> In current code of xend,
>>> The steps are:
>>> 1) save the current values of the configuration space registers 2)
>>> do_FLR 3) restore the values of the registers
>>>
>>> "a way that saving the value just before resetting." -- do you mean
>>> the same thing?
>>>
>>
>> Hi Cui,
>>
>> Yes, I mean the same thing. But in current code of xend, xend saves
>> all Configuration Registers. The only registers I suggested before
>> should be saved. Small modification is needed.
>
> It sounds good. Namely, we need to save/restore the following registers
> for now:
>
>    - Base Address Registers
>    - Cache-line size Register
>    - Latency timer Register
>    - Enable SERR Bit/Enable PERR Bit in Device Control Register
>    - Uncorrectable Error Mask Register
>    - Uncorrectable Error Severity Register
>    - Correctable Error Mask Register
>    - Advanced Error Capabilities and Control Register
>    - Device Control Register
>    - Link Control Register
>    - Secondary Uncorrectable Error Severity Register
>    - Secondary Uncorrectable Error Mask Register
>    - Device Control 2 Register
>    - Link Control 2 Register
>    - The following resister should be configured to "0".
>          - PME Enable Bit/PME Status Bit in PCI Power Management
>            Control/Status Register
>
> However, I think maybe the modification is not small enough because
> 1) we need to save each registers one by one using Python script in
> xend, and later restore each registers respectively one by one;
> 2) we should handle bridge in some cases, so we need to distinguish
> bridges from regular devices since the register layouts are different;
> 3) Some of the registers you listed are inside the extended PCIe space,
> so we need detect if a device/bride has the PCIe capability? And find
> each capability/save the register;
> 4) xend uses the sys filesystem to access the registers. For the case of
> PCIe registers, when Dom0 is configured with/without PCIe support (by
> default, it's "without" now), we should detect and treat it differently?
>
> Acutually looks the save/restore-all-the-256-byte idea (which was in
> hypervisor and is in xend now) works very well for quite a long time,
> and no actual issue is reported as far as I know. Since it looks very
> difficult to do things perfectly for now and we'll improve them by
> changing pciback in the long run, maybe keeping the current simple
> method is acceptable? :-)
>
> Thanks,
> -- Dexuan
>>
>>>> this case, xend don't need saving the values in xenstore. Because
>>>> interval between saving and restoring is small.
>>>>
>>>> My idea is summarized as follows:
>>>>
>>>> Xen    Timing              Where      Difficulty
>>>> 3.3    before resetting    xend       easy
>>>> 3.4    when Dom0 starts    pciback    hard
>>>>
>>> I exactly agree with you.
>>>
>>
>> Thanks.
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>



-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

_______________________________________________
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®.