WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Improve the current FLR logic
From: "Neo Jia" <neojia@xxxxxxxxx>
Date: Tue, 30 Sep 2008 23:55:58 -0700
Cc: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 30 Sep 2008 23:56:21 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+zPnI1bq7qTwQuBwQd+qI/KRdWlTTFurH0Q063V3A3E=; b=fx8kT8l9hmXmVx9E74T0Tt2/HBGVEUrHrZQw0g2E35Yh0FSiaF4dvGGLsg26hC4jmB uxcRZ8qIwrghLJ6lh0YCctXYa6NkZMxz8McfPQu2NHq/hvrKxPDZQ89zAk8g6DHBt63E YW6doyCoIqBOHmExTj8/M84EIoFMpHFmxZn1E=
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=gs6NNOvM8Tzsbq2qkfWrKDG9HBTIlSLE307TXZnBzGV/O9hUjKz6unB0ysk4lnAAba 06iS+lZSFVl2eYB9t0NAs71JP4Zhp3T97flx1rpB82n1VwBEZmQaQF+kRxUcEow0emrs qd+gOXx3cxEBX8HmdZ1j08aCeRzaMkH0/rqKY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5d649bdb0809182345v38b24b14sc019ca94b4fcbf18@xxxxxxxxxxxxxx>
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>
References: <20080724164711.8C75.SHIMADA-YXB@xxxxxxxxxxxxxxx> <FE7BBCFBB500984A9A7922EBC95F516E0178C213@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080724171449.8C78.SHIMADA-YXB@xxxxxxxxxxxxxxx> <FE7BBCFBB500984A9A7922EBC95F516E0178C2F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <5d649bdb0809182345v38b24b14sc019ca94b4fcbf18@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Dexuan,

Could you give me some pointers about the right implementation of
FLR/PCIe reset on pciback driver? I am looking into it now and would
like to get it done.

Thanks,
Neo

On Thu, Sep 18, 2008 at 11:45 PM, Neo Jia <neojia@xxxxxxxxx> wrote:
> 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!
>



-- 
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