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


RE: [Xen-devel] Secondary bus reset for VT-d device

To: "Neo Jia" <neojia@xxxxxxxxx>
Subject: RE: [Xen-devel] Secondary bus reset for VT-d device
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Sat, 30 Aug 2008 14:41:58 +0800
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Han, Weidong" <weidong.han@xxxxxxxxx>
Delivery-date: Fri, 29 Aug 2008 23:42:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5d649bdb0808292201h51ebe2f4ib38c85cde564aa97@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: <5d649bdb0808282133p2a013669w63ccb399b32a8ec1@xxxxxxxxxxxxxx> <FE7BBCFBB500984A9A7922EBC95F516E019EF3A0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D34E6D8A4@xxxxxxxxxxxxxxxxxxxxxx> <FE7BBCFBB500984A9A7922EBC95F516E019EF597@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <5d649bdb0808291625y3a5408c9h7481d626eabdeaf6@xxxxxxxxxxxxxx> <FE7BBCFBB500984A9A7922EBC95F516E019EF6A3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <5d649bdb0808292201h51ebe2f4ib38c85cde564aa97@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckKXXyZj/tGlZJoSKij5g5ybKFjZAADYu8w
Thread-topic: [Xen-devel] Secondary bus reset for VT-d device
I made some very basic tests manually... :-)
You can check tools/python/xen/xend/XendDomainInfo.py:do_FLR() to see when and 
how the do_secondary_bus_reset() is invoked.

-- Dexuan

Neo Jia wrote:
> Could you show me how to do the unit testing for the python function?
> Should it be called automatically by Xend or pciback driver?
> It looks that I encountered some PCI cfg restore problem after the bus
> reset. BTW, inside the guest, we are still emulating a PCI-X system,
> right?
> Thanks,
> Neo
> On Fri, Aug 29, 2008 at 6:26 PM, Cui, Dexuan <dexuan.cui@xxxxxxxxx>
> wrote: 
>> What issue did you find?
>> I tested the python function do_secondary_bus_reset() on DQ35 and
>> don't find issues. 
>> You may add your log.debug(...) (the output is at
>> /var/log/xen/xend.log) to tools/python/xen/xend/server/pciif.py and
>> tools/python/xen/util/pci.py to debug the issue you found.  
>> BTW, can you try the latest xen-unstable.hg (like 18407:
>> c503269192f2) to see if your issue is still there? 
>> -- Dexuan
>> -----Original Message-----
>> From: Neo Jia [mailto:neojia@xxxxxxxxx]
>> Sent: 2008年8月30日 7:26
>> To: Cui, Dexuan
>> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx; Han, Weidong
>> Subject: Re: [Xen-devel] Secondary bus reset for VT-d device
>> I just tried it on my Q35 board. It looks that there is something
>> wrong with the secondary bus reset, but I can't get log to prove it.
>> So, anybody test it on Q35 board? Or, how to debug it?
>> Here is the tip I am using:
>>> hg tip
>> changeset:   18387:6c50c7d089d9
>> tag:         tip
>> user:        Keir Fraser <keir.fraser@xxxxxxxxxx>
>> date:        Wed Aug 27 15:16:13 2008 +0100
>> summary:     hvmloader: Fix e820_malloc() after bug I introduced in
>> c/s 18383 
>> Thanks,
>> Neo
>> 2008/8/29 Cui, Dexuan <dexuan.cui@xxxxxxxxx>:
>>> Hi Ian,
>>> Yes, I'm moving it to the pciback driver.
>>> Thanks,
>>> -- Dexuan
>>> -----Original Message-----
>>> From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx]
>>> Sent: 2008年8月29日 16:15
>>> To: Cui, Dexuan; Neo Jia; xen-devel@xxxxxxxxxxxxxxxxxxx
>>> Cc: Han, Weidong; Ian Pratt
>>> Subject: RE: [Xen-devel] Secondary bus reset for VT-d device
>>>> Yes. When FLR-ing device, if the device lacks proper FLR capability
>>>> (PCIe FLR, PCI Advanced Capabilities or ssomething), we will try
>>>> SecondaryBusReset. Currently the FLR is done in xend.
>>> Now that 3.3 is out, are we going to move the FLR functionality
>>> from xend to blkback as per the email discussion a couple of months
>>> ago?  
>>> Thanks,
>>> Ian
>> --
>> I would remember that if researchers were not ambitious
>> probably today we haven't the technology we are using!

Xen-devel mailing list