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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Hopefully I've fixed this as of changeset 18409.

 -- Keir

On 30/8/08 07:56, "Neo Jia" <neojia@xxxxxxxxx> wrote:

> But this will break the build, right? And the stubdomain can't be
built even
> just running make stubdomain.

On Fri, Aug 29, 2008 at 11:45 PM, Cui, Dexuan
> <dexuan.cui@xxxxxxxxx> wrote:
> I changed the Makefile to not build/install
> stubdomain for now . :-)
> Attach the changes FYI.
>
> -- Dexuan
>
> Neo Jia
> wrote:
>> Got a build error with 18407.
>>
>> Any idea? The file crosstool is
> in the right place, I think
>>
>> gcc -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include
>>
> -D__MINIOS__ -DHAVE_LIBC -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/posix
>
> > -isystem
>> 
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../tools/xenstore
>>  -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/x86
>>
> -isystem
>> 
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/x86/x86
> _64
>> -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/posix
>
> > -isystem
>> 
> /home/franck/xen/xen-unstable-tip.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/
> include
>> -isystem /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/lwip/src/include -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/lwip/src/include/ipv4
>>
> -I/home/franck/xen/xen-unstable-tip.hg/stubdom/include -mno-red-zone
>> -O1
> -fno-omit-frame-pointer -fno-optimize-sibling-calls  -m64
>> -mno-red-zone
> -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64
>> -g
> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
>> -Wno-unused-value
> -Wdeclaration-after-statement   -fno-stack-protector
>>
> -I/home/franck/xen/xen-unstable-tip.hg/extras/mini-os/include -O2
>> -Wall -W
> -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -O1
>>
> -fno-omit-frame-pointer -fno-optimize-sibling-calls  -m64
>> -mno-red-zone
> -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64
>> -g
> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
>> -Wno-unused-value
> -Wdeclaration-after-statement  -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extr
> as/mini-os/include
>> -D__MINIOS__ -DHAVE_LIBC -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extr
> as/mini-os/include/posix
>> -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../tool
> s/xenstore
>>  -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extr
> as/mini-os/include/x86
>> -isystem
>>
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extr
> as/mini-os/include/x86/x86_64
>>  -c -o minios.o minios.c
>> minios.c: In
> function Ã:
>> minios.c:15: warning: unused parameter Ã
>> minios.c: In
> function Ã:
>> minios.c:42: warning: no previous prototype for Ã
>>
> minios.c:41: warning: ISO C90 forbids mixed declarations and code
>> rm -f
> libpci.a
>> ar rcs libpci.a access.o generic.o dump.o names.o filter.o
> minios.o
>> ranlib libpci.a
>> sed <libpci.pc.in >libpci.pc -e
> 's,@PREFIX@,/usr/local,' \
>>                 -e
> 's,@INCDIR@,/usr/local/include,' \
>>                 -e
> 's,@LIBDIR@,/usr/local/lib64,' \
>>                 -e
> 's,@IDSDIR@,/usr/local/share,' \
>>                 -e 's,@VERSION@,2.2.9,'
> \
>>                 -e 's,@LIBZ@,-lz,'
>> make[4]: Leaving directory
>>
> `/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib'
>> make[3]:
> Leaving directory
>>
> `/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64'
>> /bin/sh:
> line 5: ../tools/cross-install: No such file or directory
>> make[2]: ***
> [cross-root-x86_64/x86_64-xen-elf/lib/libpci.a] Error 127
>> make[2]: Leaving
> directory
>> `/home/franck/xen/xen-unstable-tip.hg/stubdom'
>> make[1]: ***
> [install-stubdom] Error 2
>> make[1]: Leaving directory
> `/home/franck/xen/xen-unstable-tip.hg'
>> make: *** [world] Error 2
>>
>>
> 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
> 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



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