Re: [Xen-devel] libvirtd hang on CentOS6 after latest updates
Thanks, Looping in Michal (impacted by the same matter) to follow up here. I've migrated in the meantime to 4.8 and to xl tools. Karel On 25.7.2018 18:58, Jim Fehlig wrote: On 07/25/2018 10:17 AM, George Dunlap wrote: On Wed, Jul 25, 2018 at 4:42 PM, Jim Fehlig wrote: On 07/22/2018 04:03 PM, Karel Hendrych wrote: Hi, I am seeing frequent libvirtd hangs (clients not responding) after last CentOS6-Xen update : xen-devel is not the best place to seek help with downstream issues, particularly libvirt ones :-). You would have better luck contacting the CentOS6 maintainers. In this case, it looks very much like they're suing the Virt SIG binaries, which are pretty close to being straight-up packing of the upstream tarballs, and the maintainers would be Anthony & I. And I at least know very little about libvirt. If Karel had posted this on centos-devel, I would almost certainly have ended up asking him to repost to xen-devel anyway, at which point I would have cc'd you. :-) Heh, ok :-). Does the error ring any bells? The udev messages are 'debug' level (not fatal) and unrelated IMO. It would be best to attach gdb to the libvirtd process and get a backtrace of all threads. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 125756: all pass - PUSHED
flight 125756 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/125756/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 baseline version: xen 6aaa9fb308171ec58ddf4cf058ad5341f81a65cf Last test of basis 125723 2018-08-01 09:18:49 Z4 days Testing same since 125756 2018-08-05 09:18:24 Z0 days1 attempts People who touched revisions under test: Jan Beulich Marek Marczykowski-Górecki Simon Gaiser Wei Liu jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6aaa9fb308..ed5f8d9ca4 ed5f8d9ca47e69e30221c37ec812f2b38af19d83 -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu option
> From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: Friday, August 3, 2018 5:33 PM > > On Fri, Aug 03, 2018 at 10:14:49AM +0100, Paul Durrant wrote: > > > -Original Message- > > > From: Roger Pau Monne > > > Sent: 03 August 2018 10:09 > > > To: Paul Durrant > > > Cc: Jan Beulich ; Kevin Tian > ; > > > Stefano Stabellini ; Wei Liu > ; > > > George Dunlap ; Andrew Cooper > > > ; Ian Jackson ; > Tim > > > (Xen.org) ; Julien Grall ; Suravee > > > Suthikulpanit ; xen-devel > > de...@lists.xenproject.org>; Brian Woods > > > Subject: Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu > > > option > > > > > > On Fri, Aug 03, 2018 at 10:05:19AM +0100, Paul Durrant wrote: > > > > Actually I wonder whether we should rename 'inclusive' to 'reserved'. > > > Essentially 'none', 'strict' or 'relaxed' are all about mappings of RAM, > and then > > > we need to decide whether to map the E820 reserved regions. So I think > the > > > inclusive map as it stands today is equivalent to 'relaxed' + 'reserved'. > > > > > > Hm, not exactly. inclusive (iommu_inclusive_mapping) right now maps > > > everything except unusable regions. That's way more than just mapping > > > reserved regions. If we want to keep this behaviour while introducing > > > an option to map only reserved regions we need both an inclusive and a > > > reserved option. > > > > > > > Ok, how about: > > > > inclusive -> all E820 ranges except unusable or ram > > inclusive ATM also maps holes. So it would be all memory ranges except > those marked as unusable or in use by Xen. > > > reserved -> all E820 reserved ranges > > > > then > > > > strict -> all ram ranges belonging to dom0 > > relaxed -> all ram ranges > > none -> no ram ranges > > > > The problem then is what does, say, reserved + no-inclusive mean? I > guess we could have a flag for each non ram E820 range type? > > reserved + no-inclusive would make sense for a PV Dom0 running on > Intel hardware in order to map only the reserved regions instead of > mapping almost everything below 4GB by default. > > What about the following description of the options, do you think it's > clear enough? > > > `= List of [ none | strict | relaxed | inclusive | reserved ]` > > * `none`: disables DMA remapping for Dom0. > > The following two options control how RAM regions are mapped in the > iommu for > Dom0: > > * `strict`: sets up DMA remapping only for the memory Dom0 actually got > assigned. > > * `relaxed`: sets DMA remapping for all the host RAM except regions in use > by > Xen. This is the default iommu behaviour. > > Note that all the above options are mutually exclusive. Specifying more > than > one on the `dom0-iommu` command line will result in undefined behavior. > > The following options control whether non-RAM regions are added to the > Dom0 > iommu tables. Note that they can be prefixed with `no-` to effect the > inverse > meaning: > > * `inclusive`: sets up DMA remapping for all the non-RAM memory below > 4GB > except for unusable ranges. Use this to work around firmware issues > providing > incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for > IOMMU > accesses for Dom0, with this option all pages up to 4GB, not marked as > unusable in the E820 table, will get a mapping established. Note that this > option is only applicable to a PV Dom0 and is enabled by default on Intel > hardware. > > * `reserved`: sets up DMA remapping for all the reserved regions in the > memory > map for Dom0. Use this to work around firmware issues providing > incorrect > RMRR or IVMD entries. Rather than only mapping RAM pages for IOMMU > accesses > for Dom0, all memory regions marked as reserved in the memory map > that don't > overlap with any MMIO region from emulated devices will be identity > mapped. > This option maps a subset of the memory that would be mapped when > using the > `inclusive` option. This option is available to a PVH Dom0 and is enabled > by > default on Intel hardware. > above makes it clear now. Just a side question. Is there also value of applying 'reserved' option to PV Dom0? Thanks, Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125757: all pass - PUSHED
flight 125757 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125757/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 baseline version: ovmf 526dd0245bf0db6a01c21943201a4572747bca7f Last test of basis 125755 2018-08-03 22:40:43 Z2 days Testing same since 125757 2018-08-06 02:40:38 Z0 days1 attempts People who touched revisions under test: Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 526dd0245b..81038d50c9 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75047: tolerable FAIL
This run is configured for baseline tests only. flight 75047 ovmf real [real] http://osstest.xensource.com/osstest/logs/75047/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75045 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75045 version targeted for testing: ovmf 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 baseline version: ovmf 526dd0245bf0db6a01c21943201a4572747bca7f Last test of basis75045 2018-08-04 00:50:08 Z2 days Testing same since75047 2018-08-06 04:22:31 Z0 days1 attempts People who touched revisions under test: Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 Author: Ruiyu Ni Date: Fri Aug 3 10:46:34 2018 +0800 ShellPkg/acpi: Code cleanup to pass static code checker Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Hao Wu commit c1f032cd3a95ed74dad27d848526495e5790d4af Author: Ruiyu Ni Date: Fri Aug 3 10:42:45 2018 +0800 MdePkg/BaseLib: Add an additional check within AsciiStriCmp This commit adds an addtional check in AsciiStriCmp. It explicitly checks the end of the sting pointed by 'SecondString' to make the code logic easier for reading and to prevent possible mis-reports by static code checkers. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Hao Wu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125758: all pass - PUSHED
flight 125758 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125758/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c baseline version: ovmf 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 Last test of basis 125757 2018-08-06 02:40:38 Z0 days Testing same since 125758 2018-08-06 04:40:40 Z0 days1 attempts People who touched revisions under test: Kinney, Michael D Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 81038d50c9..cd3a42640a cd3a42640acdb4f5ac14ac19f22ede002124920c -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
