hi, Did the current Xen in unstable branch already support the secondary bus reset for VT-d devices? Thanks, Neo -- 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@lists.xensource.com http://lists.xensource.com/xen-devel
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. -- Dexuan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Neo Jia Sent: 2008年8月29日 12:34 To: xen-devel@lists.xensource.com Cc: Han, Weidong Subject: [Xen-devel] Secondary bus reset for VT-d device hi, Did the current Xen in unstable branch already support the secondary bus reset for VT-d devices? Thanks, Neo -- 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@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks! But, how to trigger it? Is there a separate command I can issue or it is done automatically after reboot/shutdown guest? Neo 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>:> 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. > > -- Dexuan > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Neo Jia > Sent: 2008年8月29日 12:34 > To: xen-devel@lists.xensource.com > Cc: Han, Weidong > Subject: [Xen-devel] Secondary bus reset for VT-d device > > hi, > > Did the current Xen in unstable branch already support the secondary > bus reset for VT-d devices? > > Thanks, > Neo > -- > 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@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Now the FLR is done automatically when a domain is destroyed (such as "xm destroy/reboot/shutdown" a domain, or the domain shutdowns normally or crashes) . -- Dexuan -----Original Message----- From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年8月29日 12:45 To: Cui, Dexuan Cc: xen-devel@lists.xensource.com; Han, Weidong Subject: Re: [Xen-devel] Secondary bus reset for VT-d device Thanks! But, how to trigger it? Is there a separate command I can issue or it is done automatically after reboot/shutdown guest? Neo 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>:> 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. > > -- Dexuan > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Neo Jia > Sent: 2008年8月29日 12:34 > To: xen-devel@lists.xensource.com > Cc: Han, Weidong > Subject: [Xen-devel] Secondary bus reset for VT-d device > > hi, > > Did the current Xen in unstable branch already support the secondary > bus reset for VT-d devices? > > Thanks, > Neo > -- > 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@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Can I trigger it manually? What happens if I just use setpci to do a "secondary bus reset"? Will Xen be able to check if the host BARs are enabled for the device before putting it into the guest? Thanks, Neo On Thu, Aug 28, 2008 at 10:11 PM, Cui, Dexuan <dexuan.cui@intel.com> wrote:> Now the FLR is done automatically when a domain is destroyed (such as "xm destroy/reboot/shutdown" a domain, or the domain shutdowns normally or crashes) . > > -- Dexuan > > > -----Original Message----- > From: Neo Jia [mailto:neojia@gmail.com] > Sent: 2008年8月29日 12:45 > To: Cui, Dexuan > Cc: xen-devel@lists.xensource.com; Han, Weidong > Subject: Re: [Xen-devel] Secondary bus reset for VT-d device > > Thanks! But, how to trigger it? Is there a separate command I can > issue or it is done automatically after reboot/shutdown guest? > > Neo > > 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>: >> 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. >> >> -- Dexuan >> >> >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Neo Jia >> Sent: 2008年8月29日 12:34 >> To: xen-devel@lists.xensource.com >> Cc: Han, Weidong >> Subject: [Xen-devel] Secondary bus reset for VT-d device >> >> hi, >> >> Did the current Xen in unstable branch already support the secondary >> bus reset for VT-d devices? >> >> Thanks, >> Neo >> -- >> 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@lists.xensource.com >> 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@lists.xensource.com http://lists.xensource.com/xen-devel
I think we should not trigger it manually. What''s the purpose? If you use setpci to do SecondaryBusReset directly, all the devices behind the bridge are reset suddenly while xend/Dom0/Xen don''t know that... We don''t check if "the host BARs are enabled" or not. -- Dexuan -----Original Message----- From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年8月29日 13:16 To: Cui, Dexuan Cc: xen-devel@lists.xensource.com; Han, Weidong Subject: Re: [Xen-devel] Secondary bus reset for VT-d device Can I trigger it manually? What happens if I just use setpci to do a "secondary bus reset"? Will Xen be able to check if the host BARs are enabled for the device before putting it into the guest? Thanks, Neo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Just want to get some flexibility for testing. If Xen do it automatically, is there any log for this? Thanks, Neo 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>:> I think we should not trigger it manually. What's the purpose? > If you use setpci to do SecondaryBusReset directly, all the devices behind the bridge are reset suddenly while xend/Dom0/Xen don't know that... > We don't check if "the host BARs are enabled" or not. > > -- Dexuan > > > -----Original Message----- > From: Neo Jia [mailto:neojia@gmail.com] > Sent: 2008年8月29日 13:16 > To: Cui, Dexuan > Cc: xen-devel@lists.xensource.com; Han, Weidong > Subject: Re: [Xen-devel] Secondary bus reset for VT-d device > > Can I trigger it manually? What happens if I just use setpci to do a > "secondary bus reset"? Will Xen be able to check if the host BARs are > enabled for the device before putting it into the guest? > > Thanks, > Neo >-- 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@lists.xensource.com http://lists.xensource.com/xen-devel
So, Xen will call the function "do_secondary_bus_reset" in pci.py automatically after it detects reboot/shutdown/crashes, right? Thanks, Neo 2008/8/28 Neo Jia <neojia@gmail.com>:> Just want to get some flexibility for testing. > > If Xen do it automatically, is there any log for this? > > Thanks, > Neo > > 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>: >> I think we should not trigger it manually. What's the purpose? >> If you use setpci to do SecondaryBusReset directly, all the devices behind the bridge are reset suddenly while xend/Dom0/Xen don't know that... >> We don't check if "the host BARs are enabled" or not. >> >> -- Dexuan >> >> >> -----Original Message----- >> From: Neo Jia [mailto:neojia@gmail.com] >> Sent: 2008年8月29日 13:16 >> To: Cui, Dexuan >> Cc: xen-devel@lists.xensource.com; Han, Weidong >> Subject: Re: [Xen-devel] Secondary bus reset for VT-d device >> >> Can I trigger it manually? What happens if I just use setpci to do a >> "secondary bus reset"? Will Xen be able to check if the host BARs are >> enabled for the device before putting it into the guest? >> >> Thanks, >> Neo >> > > > > -- > 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@lists.xensource.com http://lists.xensource.com/xen-devel
When a guest died due to various reasons, finally xend will know this and invokes xc.domain_destroy() -- it''s xend (not xen) that invokes. Now there is a do_FLR() before xc.domain_destroy(). You can refer to "tools/python/xen/xend/XendDomainInfo.py": do_FLR() for the details. You can also add log messages as you like. -- Dexuan -----Original Message----- From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年8月29日 14:10 To: Cui, Dexuan Cc: xen-devel@lists.xensource.com; Han, Weidong Subject: Re: [Xen-devel] Secondary bus reset for VT-d device So, Xen will call the function "do_secondary_bus_reset" in pci.py automatically after it detects reboot/shutdown/crashes, right? Thanks, Neo 2008/8/28 Neo Jia <neojia@gmail.com>:> Just want to get some flexibility for testing. > > If Xen do it automatically, is there any log for this? > > Thanks, > Neo > > 2008/8/28 Cui, Dexuan <dexuan.cui@intel.com>: >> I think we should not trigger it manually. What''s the purpose? >> If you use setpci to do SecondaryBusReset directly, all the devices behind the bridge are reset suddenly while xend/Dom0/Xen don''t know that... >> We don''t check if "the host BARs are enabled" or not. >> >> -- Dexuan >> >> >> -----Original Message----- >> From: Neo Jia [mailto:neojia@gmail.com] >> Sent: 2008年8月29日 13:16 >> To: Cui, Dexuan >> Cc: xen-devel@lists.xensource.com; Han, Weidong >> Subject: Re: [Xen-devel] Secondary bus reset for VT-d device >> >> Can I trigger it manually? What happens if I just use setpci to do a >> "secondary bus reset"? Will Xen be able to check if the host BARs are >> enabled for the device before putting it into the guest? >> >> Thanks, >> Neo >> > > > > -- > 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@lists.xensource.com http://lists.xensource.com/xen-devel
> 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> -- Dexuan > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Neo Jia > Sent: 2008年8月29日 12:34 > To: xen-devel@lists.xensource.com > Cc: Han, Weidong > Subject: [Xen-devel] Secondary bus reset for VT-d device > > hi, > > Did the current Xen in unstable branch already support the secondary > bus reset for VT-d devices? > > Thanks, > Neo > -- > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Ian, Yes, I''m moving it to the pciback driver. Thanks, -- Dexuan -----Original Message----- From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] Sent: 2008年8月29日 16:15 To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 tipchangeset: 18387:6c50c7d089d9 tag: tip user: Keir Fraser <keir.fraser@citrix.com> 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@intel.com>:> Hi Ian, > Yes, I'm moving it to the pciback driver. > > Thanks, > -- Dexuan > > > -----Original Message----- > From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] > Sent: 2008年8月29日 16:15 > To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@gmail.com] Sent: 2008年8月30日 7:26 To: Cui, Dexuan Cc: Ian Pratt; xen-devel@lists.xensource.com; 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 tipchangeset: 18387:6c50c7d089d9 tag: tip user: Keir Fraser <keir.fraser@citrix.com> 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@intel.com>:> Hi Ian, > Yes, I''m moving it to the pciback driver. > > Thanks, > -- Dexuan > > > -----Original Message----- > From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] > Sent: 2008年8月29日 16:15 > To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com> 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@gmail.com] > Sent: 2008年8月30日 7:26 > To: Cui, Dexuan > Cc: Ian Pratt; xen-devel@lists.xensource.com; 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@citrix.com> > 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@intel.com>: >> Hi Ian, >> Yes, I'm moving it to the pciback driver. >> >> Thanks, >> -- Dexuan >> >> >> -----Original Message----- >> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] >> Sent: 2008年8月29日 16:15 >> To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com >> 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! >-- 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@lists.xensource.com http://lists.xensource.com/xen-devel
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/../../../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/posix
-isystem
/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../tools/xenstore
-isystem
/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/x86
-isystem
/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/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@intel.com>
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@gmail.com]
> Sent: 2008年8月30日 7:26
> To: Cui, Dexuan
> Cc: Ian Pratt; xen-devel@lists.xensource.com; 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@citrix.com>
> 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@intel.com>:
>> Hi Ian,
>> Yes, I'm moving it to the pciback driver.
>>
>> Thanks,
>> -- Dexuan
>>
>>
>> -----Original Message-----
>> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com]
>> Sent: 2008年8月29日 16:15
>> To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com
>> 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!
>
--
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@lists.xensource.com
http://lists.xensource.com/xen-devel
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@intel.com> > 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@gmail.com] >> Sent: 2008年8月30日 7:26 >> To: Cui, Dexuan >> Cc: Ian Pratt; xen-devel@lists.xensource.com; 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@citrix.com> >> 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@intel.com>: >>> Hi Ian, >>> Yes, I''m moving it to the pciback driver. >>> >>> Thanks, >>> -- Dexuan >>> >>> >>> -----Original Message----- >>> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] >>> Sent: 2008年8月29日 16:15 >>> To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com >>> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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/../../../extras/mini-os/include > -D__MINIOS__ -DHAVE_LIBC -isystem > /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/posix > -isystem > /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../tools/xenstore > -isystem > /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/x86 > -isystem > /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/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@intel.com> > 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@gmail.com] >> Sent: 2008年8月30日 7:26 >> To: Cui, Dexuan >> Cc: Ian Pratt; xen-devel@lists.xensource.com; 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@citrix.com> >> 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@intel.com>: >>> Hi Ian, >>> Yes, I'm moving it to the pciback driver. >>> >>> Thanks, >>> -- Dexuan >>> >>> >>> -----Original Message----- >>> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] >>> Sent: 2008年8月29日 16:15 >>> To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com >>> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com> 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/../../../extras/mini-os/include >> -D__MINIOS__ -DHAVE_LIBC -isystem >> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/posix >> -isystem >> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../tools/xenstore >> -isystem >> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/x86 >> -isystem >> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/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@intel.com> >> 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@gmail.com] >>> Sent: 2008年8月30日 7:26 >>> To: Cui, Dexuan >>> Cc: Ian Pratt; xen-devel@lists.xensource.com; 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@citrix.com> >>> 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@intel.com>: >>>> Hi Ian, >>>> Yes, I'm moving it to the pciback driver. >>>> >>>> Thanks, >>>> -- Dexuan >>>> >>>> >>>> -----Original Message----- >>>> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] >>>> Sent: 2008年8月29日 16:15 >>>> To: Cui, Dexuan; Neo Jia; xen-devel@lists.xensource.com >>>> 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@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Hopefully I''ve fixed this as of changeset 18409. -- Keir On 30/8/08 07:56, "Neo Jia" <neojia@gmail.com> wrote:> But this will break the build, right? And the stubdomain can''t bebuilt even> just running make stubdomain.On Fri, Aug 29, 2008 at 11:45 PM, Cui, Dexuan> <dexuan.cui@intel.com> 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@intel.com> >> 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@gmail.com] >>> Sent: 2008年8月30日 > 7:26 >>> To: Cui, Dexuan >>> Cc: Ian Pratt; xen-devel@lists.xensource.com; > 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@citrix.com> >>> 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@intel.com>: >>>> Hi Ian, >>>> Yes, I''m moving it to the pciback > driver. >>>> >>>> Thanks, >>>> -- Dexuan >>>> >>>> >>>> -----Original > Message----- >>>> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com] >>>> Sent: > 2008年8月29日 16:15 >>>> To: Cui, Dexuan; Neo Jia; > xen-devel@lists.xensource.com >>>> 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > >-- I would remember that if> researchers were not ambitiousprobably today we haven''t the technology we are> using!> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel