Re: [Xen-devel] [PATCH] build: remove tboot make targets
On Mon, Aug 20, 2018 at 1:38 AM, Wei Liu wrote: > On Sat, Aug 18, 2018 at 09:22:05PM -0500, Doug Goldstein wrote: >> The tboot targets are woefully out of date. These should really be >> retired because setting up tboot is more complex than the build process >> for it. >> >> Signed-off-by: Doug Goldstein > > Acked-by: Wei Liu Code reviewed and standard (non-tboot related) build tested with the patch applied: looks good. No references to any of the following remain in the tree afterwards: * TBOOT_TARFILE * TBOOT_BASE_URL * build-tboot, install-tboot, dist-tboot, clean-tboot, distclean-tboot * download_tboot The README section about tboot, just above the chunk removed, contains a stale URL for the tboot hg repository, which has apparently now moved to: http://hg.code.sf.net/p/tboot/code I don't use uninstall (ever) but since Doug's patch touches it, I just tested it with this applied. Uninstall failed, but it's not a fault of this patch: | make[6]: Entering directory './git/tools/tests/x86_emulator' | make[6]: *** No rule to make target 'uninstall'. Stop. | make[6]: Leaving directory './git/tools/tests/x86_emulator' | | make[6]: *** No rule to make target 'uninstall'. Stop. | make[6]: Leaving directory '/./git/tools/tests/x86_emulator' | ./git/tools/tests/../../tools/Rules.mk:249: recipe for target 'subdir-uninstall-x86_emulator' failed | make[5]: *** [subdir-uninstall-x86_emulator] Error 2 | make[5]: Leaving directory './git/tools/tests' | | ./git/tools/tests/../../tools/Rules.mk:249: recipe for target 'subdir-uninstall-x86_emulator' failed so I've just posted a patch that fixes this and another defect in the Linux hotplug uninstall logic to make it actually remove what it installed. Reviewed-by: Christopher Clark Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RESEND] x86/xen: enable early use of set_fixmap in 32-bit Xen PV guest
Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
init_hypervisor_platform()") moved the mapping of the shared info area
before pagetable_init(). This breaks booting as 32-bit PV guest as the
use of set_fixmap isn't possible at this time on 32-bit.
This can be worked around by populating the needed PMD on 32-bit
kernel earlier.
In order not to reimplement populate_extra_pte() using extend_brk()
for allocating new page tables extend alloc_low_pages() to do that in
case the early page table pool is not yet available.
Fixes: 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
init_hypervisor_platform()")
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
Resending with corrected Fixes: tag
Boris, please take this via the Xen tree (Thomas asked us to do so)
---
arch/x86/mm/init.c | 17 -
arch/x86/xen/enlighten_pv.c | 2 ++
arch/x86/xen/mmu_pv.c | 2 ++
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index acfab322fbe0..5c32a7665492 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -99,15 +99,22 @@ __ref void *alloc_low_pages(unsigned int num)
}
if ((pgt_buf_end + num) > pgt_buf_top || !can_use_brk_pgt) {
- unsigned long ret;
- if (min_pfn_mapped >= max_pfn_mapped)
- panic("alloc_low_pages: ran out of memory");
- ret = memblock_find_in_range(min_pfn_mapped << PAGE_SHIFT,
+ unsigned long ret = 0;
+
+ if (min_pfn_mapped < max_pfn_mapped) {
+ ret = memblock_find_in_range(
+ min_pfn_mapped << PAGE_SHIFT,
max_pfn_mapped << PAGE_SHIFT,
PAGE_SIZE * num , PAGE_SIZE);
+ }
+ if (ret)
+ memblock_reserve(ret, PAGE_SIZE * num);
+ else if (can_use_brk_pgt)
+ ret = __pa(extend_brk(PAGE_SIZE * num, PAGE_SIZE));
+
if (!ret)
panic("alloc_low_pages: can not alloc memory");
- memblock_reserve(ret, PAGE_SIZE * num);
+
pfn = ret >> PAGE_SHIFT;
} else {
pfn = pgt_buf_end;
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ee3b00c7acda..d7b2022ee301 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -122,6 +122,8 @@ static void __init xen_banner(void)
static void __init xen_pv_init_platform(void)
{
+ populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
+
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
HYPERVISOR_shared_info = (void *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 52206ad81e4b..9e7012858420 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2171,6 +2171,8 @@ void __init xen_relocate_p2m(void)
#else /* !CONFIG_X86_64 */
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);
+RESERVE_BRK(fixup_kernel_pmd, PAGE_SIZE);
+RESERVE_BRK(fixup_kernel_pte, PAGE_SIZE);
static void __init xen_write_cr3_init(unsigned long cr3)
{
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] MAINTAINERS: add myself as a reviewer for x86 patches
Signed-off-by: Wei Liu --- Since I'm changing x86 code all over the place, I'd better keep up with what's going on. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index f28d0e1ee0..1970100b37 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -440,6 +440,7 @@ F: docs/misc/vtpm-platforms.txt X86 ARCHITECTURE M: Jan Beulich M: Andrew Cooper +R: Wei Liu S: Supported L: xen-devel@lists.xenproject.org F: xen/arch/x86/ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Future of 32-bit PV support
On Thu, Aug 16, 2018 at 08:17:13AM +0200, Juergen Gross wrote: > In the Xen x86 community call we have been discussing whether anyone > really is depending on 32-bit PV guests. We'd like to evaluate whether > anyone would see problems with: > > - deprecating 32-bit PV guest support in Xen, meaning that we'd > eventually switch to support 32-bit PV guests only via PV-shim from > Xen 4.12 or 4.13 > > - dropping 32-bit PV support from upstream Linux kernel, resulting in > current 32-bit PV guests no longer being able to upgrade to the newest > kernel version any longer > > And related to that: > > - is there any Linux distribution still shipping 32-bit PV-capable > systems? > > - what about BSD? Is 32-bit PV support important there? Hello, Actually, NetBSD only supports PV (there is work toward PV drivers for HVM, and PVH, but this is making slow progress). 32-bit PV is faster than 64-bit PV so all my domUs are 32bits these days. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 126184: regressions - trouble: broken/fail/pass
flight 126184 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/126184/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xen-xsm-freebsd broken build-amd64-xen-xsm-freebsd 5 host-install(5)broken REGR. vs. 126012 test-xtf-amd64-amd64-46 xen-install fail REGR. vs. 126012 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 126012 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126012 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 126012 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126012 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126012 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 126012 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 126012 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126012 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 126012 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 126012 build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen b8f33431f3dd23fb43a879f4bdb4283fdc9465ad baseline version: xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391 Last test of basis 126012 2018-08-16 22:09:11 Z3 days Testing same since 126184 2018-08-18 23:45:48 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Daniel De Graaf Gopalasetty, Manoj Ian Jackson Jan Beulich Julien Grall Paul Durrant Roger Pau Monné Wei Liu Zhenzhong Duan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-amd64-xen-freebsd fail build-amd64-xen-xsm-freebsd broken build-i386 pass
[Xen-devel] [linux-3.18 baseline-only test] 75092: regressions - FAIL
This run is configured for baseline tests only. flight 75092 linux-3.18 real [real] http://osstest.xensource.com/osstest/logs/75092/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 75027 test-amd64-amd64-rumprun-amd64 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 75027 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 75027 test-amd64-amd64-i386-pvgrub 10 debian-di-install fail REGR. vs. 75027 test-amd64-amd64-amd64-pvgrub 10 debian-di-installfail REGR. vs. 75027 test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 75027 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-installfail REGR. vs. 75027 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 75027 test-amd64-i386-xl 12 guest-start fail REGR. vs. 75027 test-amd64-i386-libvirt-pair 21 guest-start/debianfail REGR. vs. 75027 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-qcow210 debian-di-install fail REGR. vs. 75027 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 75027 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail REGR. vs. 75027 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-xl-qemut-win7-amd64 10 windows-installfail REGR. vs. 75027 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 75027 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 75027 test-armhf-armhf-xl-midway 12 guest-start fail REGR. vs. 75027 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 75027 test-armhf-armhf-xl-credit2 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 75027 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 75027 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 75027 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 75027 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 75027 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-installfail REGR. vs. 75027 test-armhf-armhf-xl 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 75027 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 75027 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 75027 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-installfail REGR. vs. 75027 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-pair21 guest-start/debianfail REGR. vs. 75027 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 75027 test-amd64-i386-xl-qemut-win10-i386 10 windows-installfail REGR. vs. 75027 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-installfail REGR. vs. 75027 test-amd64-i386-pair 21 guest-start/debianfail REGR. vs. 75027 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 75027 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 75027 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 12 guest-start fail REGR. vs. 75027 test-armhf-armhf-xl-rtds 12
[Xen-devel] [PATCH] MAINTAINERS: add myself as a reviewer for x86 patches
Signed-off-by: Wei Liu --- Since I'm changing x86 code all over the place, I'd better keep up with what's going on. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index f28d0e1ee0..1970100b37 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -440,6 +440,7 @@ F: docs/misc/vtpm-platforms.txt X86 ARCHITECTURE M: Jan Beulich M: Andrew Cooper +R: Wei Liu S: Supported L: xen-devel@lists.xenproject.org F: xen/arch/x86/ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: add myself as a reviewer for x86 patches
>>> On 20.08.18 at 17:25, wrote: > Signed-off-by: Wei Liu Acked-by: Jan Beulich And thanks for all the help you've provided here already, plus all the reviews to come. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 126189: regressions - FAIL
flight 126189 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/126189/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 126042 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 126042 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 126042 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 126042 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-i386-xl 12 guest-start fail REGR. vs. 126042 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 126042 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 126042 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 126042 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 126042 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 126042 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 126042 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail REGR. vs. 126042 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 126042 test-armhf-armhf-xl-arndale 12 guest-start fail REGR. vs. 126042 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 126042 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 126042 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 126042 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 126042 test-armhf-armhf-xl 12 guest-start fail REGR. vs. 126042 test-armhf-armhf-xl-credit2 12 guest-start
Re: [Xen-devel] Future of 32-bit PV support
On 20/08/18 17:31, Manuel Bouyer wrote: > On Thu, Aug 16, 2018 at 08:17:13AM +0200, Juergen Gross wrote: >> In the Xen x86 community call we have been discussing whether anyone >> really is depending on 32-bit PV guests. We'd like to evaluate whether >> anyone would see problems with: >> >> - deprecating 32-bit PV guest support in Xen, meaning that we'd >> eventually switch to support 32-bit PV guests only via PV-shim from >> Xen 4.12 or 4.13 >> >> - dropping 32-bit PV support from upstream Linux kernel, resulting in >> current 32-bit PV guests no longer being able to upgrade to the newest >> kernel version any longer >> >> And related to that: >> >> - is there any Linux distribution still shipping 32-bit PV-capable >> systems? >> >> - what about BSD? Is 32-bit PV support important there? > > Hello, > Actually, NetBSD only supports PV (there is work toward PV drivers for HVM, > and PVH, but this is making slow progress). 32-bit PV is faster than 64-bit PV > so all my domUs are 32bits these days. Thanks for the feedback. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] Future of 32-bit PV support
On 08/17/2018 06:09 AM, Juergen Gross wrote:
> On 17/08/18 00:33, Andy Smith wrote:
>> Hi Juergen,
>>
>> [...]
>> If so, could the final removal of 32-bit PV in the Linux kernel be
>> held off until there is:
>>
>> 1) a kernel shipping in Debian stable, Ubuntu LTS and CentOS that
>>boots under PVH, and;
>>
>> 2) support in grub2 so I can build a grub image that boots under
>>PVH?
>
> I think this is a reasonable request.
>
>> If grub PVH support is not going to happen, what is the roadmap for
>> user-specified guest kernels under PVH?
>
> I have a patch series lying around for grub2 PVH support. It requires
> some rework and another kernel enhancement. I'll try to resume work on
> the patches soon.
+1, Yes please!
Do I understand correctly ('another kernel enhancement') that you found
more things which need to be done than the 32-bit memory map limitation
issue at the grub side?
>> [...]
Thanks,
Hans
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: cpupool: forbid to split cores among different pools
On a system with hyperthreading, we currently allow putting cpus that
are SMT siblings in different cpupools. This is bad for a number of
reasons.
For instance, the schedulers can't know whether or not a core is fully
idle or not, if the threads of such core are in different pools. This
right now is a load-balancing/resource-efficiency problem. Furthermore,
if at some point we want to implement core-scheduling, that is also
impossible if hyperthreads are split among pools.
Therefore, let's start allowing in a cpupool only cpus that have their
SMT siblings, either:
- in that same pool,
- outside of any pool.
Signed-off-by: Dario Faggioli
---
Cc: Juergen Gross
---
xen/common/cpupool.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 1e8edcbd57..1e52fea5ac 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -264,10 +264,24 @@ int cpupool_move_domain(struct domain *d, struct cpupool
*c)
static int cpupool_assign_cpu_locked(struct cpupool *c, unsigned int cpu)
{
int ret;
+unsigned int s;
struct domain *d;
if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
return -EADDRNOTAVAIL;
+
+/*
+ * If we have SMT, we only allow a new cpu in, if its siblings are either
+ * in this same cpupool too, or outside of any pool.
+ */
+
+for_each_cpu(s, per_cpu(cpu_sibling_mask, cpu))
+{
+if ( !cpumask_test_cpu(s, c->cpu_valid) &&
+ !cpumask_test_cpu(s, _free_cpus) )
+return -EBUSY;
+}
+
ret = schedule_cpu_switch(cpu, c);
if ( ret )
return ret;
@@ -646,18 +660,28 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
cpupool_dprintk("cpupool_assign_cpu(pool=%d,cpu=%d)\n",
op->cpupool_id, cpu);
spin_lock(_lock);
+c = cpupool_find_by_id(op->cpupool_id);
+ret = -ENOENT;
+if ( c == NULL )
+goto addcpu_out;
+/* Pick a cpu from free cores, or from cores with cpus already in c */
if ( cpu == XEN_SYSCTL_CPUPOOL_PAR_ANY )
-cpu = cpumask_first(_free_cpus);
+{
+for_each_cpu(cpu, _free_cpus)
+{
+const cpumask_t *siblings = per_cpu(cpu_sibling_mask, cpu);
+
+if ( cpumask_intersects(siblings, c->cpu_valid) ||
+ cpumask_subset(siblings, _free_cpus) )
+break;
+}
+}
ret = -EINVAL;
if ( cpu >= nr_cpu_ids )
goto addcpu_out;
ret = -ENODEV;
if ( !cpumask_test_cpu(cpu, _free_cpus) )
goto addcpu_out;
-c = cpupool_find_by_id(op->cpupool_id);
-ret = -ENOENT;
-if ( c == NULL )
-goto addcpu_out;
ret = cpupool_assign_cpu_locked(c, cpu);
addcpu_out:
spin_unlock(_lock);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-i386
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-i386 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 5c60a7389d795e001c8748b458eb76e3a5b6008c Bug not present: acb1872577b346bd15ab3a3f8dff780d6cca4b70 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/126265/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-freebsd10-i386.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-freebsd10-i386.xen-boot --summary-out=tmp/126265.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-freebsd10-i386 xen-boot Searching for failure / basis pass: 126069 fail [host=debina1] / 125898 [host=debina0] 125702 [host=baroque1] 125676 ok. Failure / basis pass flights: 126069 / 125676 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 5c60a7389d795e001c8748b458eb76e3a5b6008c c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 1f7574763cbb2c85825b8cc4d81f386e767a476f Basis pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#acb1872577b346bd15ab3a3f8dff780d6cca4b70-5c60a7389d795e001c8748b458eb76e3a5b6008c git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-4f080070a9809bde857851e68a3aeff0c4b9b6a6 git://xenbits.xen.org/xen.git#e3f667bc5f51d0aa44357a64ca134cd952679c81-1f7574763cbb2c85825b8cc4d81f386e767a476f adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 1003 nodes in revision graph Searching for test results: 125167 [host=baroque1] 125242 [host=baroque1] 125285 [host=baroque1] 125401 [host=pinot1] 125501 [host=fiano1] 125551 [host=joubertin0] 125520 [host=baroque0] 125585 [host=chardonnay0] 125648 [host=fiano0] 125639 [host=debina0] 125657 [host=huxelrebe1] 125676 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 125702 [host=baroque1] 125898 [host=debina0] 125921 fail irrelevant 126069 fail 5c60a7389d795e001c8748b458eb76e3a5b6008c c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 1f7574763cbb2c85825b8cc4d81f386e767a476f 126234 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 126239 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 0e96f3d52ec200b8f7764164e22d76eef6151f59 126241 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 173c7803592065d27bf2e60d50e08e197a0efa83 126243 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 318b32fe7ce4ef6cba9d078e2e26040dbdbfb6f8 126237 fail 5c60a7389d795e001c8748b458eb76e3a5b6008c c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60
Re: [Xen-devel] [PATCH RESEND] x86/xen: enable early use of set_fixmap in 32-bit Xen PV guest
On 08/20/2018 11:24 AM, Juergen Gross wrote:
> Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
> init_hypervisor_platform()") moved the mapping of the shared info area
> before pagetable_init(). This breaks booting as 32-bit PV guest as the
> use of set_fixmap isn't possible at this time on 32-bit.
>
> This can be worked around by populating the needed PMD on 32-bit
> kernel earlier.
>
> In order not to reimplement populate_extra_pte() using extend_brk()
> for allocating new page tables extend alloc_low_pages() to do that in
> case the early page table pool is not yet available.
>
> Fixes: 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
> init_hypervisor_platform()")
> Signed-off-by: Juergen Gross
> Reviewed-by: Thomas Gleixner
> ---
> Resending with corrected Fixes: tag
> Boris, please take this via the Xen tree (Thomas asked us to do so)
Sure, but we will need to rebase to the latest bits, so you will have to
explain yourself to Linus ;-)
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] x86/xen: enable early use of set_fixmap in 32-bit Xen PV guest
On 20/08/18 18:56, Boris Ostrovsky wrote:
> On 08/20/2018 11:24 AM, Juergen Gross wrote:
>> Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
>> init_hypervisor_platform()") moved the mapping of the shared info area
>> before pagetable_init(). This breaks booting as 32-bit PV guest as the
>> use of set_fixmap isn't possible at this time on 32-bit.
>>
>> This can be worked around by populating the needed PMD on 32-bit
>> kernel earlier.
>>
>> In order not to reimplement populate_extra_pte() using extend_brk()
>> for allocating new page tables extend alloc_low_pages() to do that in
>> case the early page table pool is not yet available.
>>
>> Fixes: 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
>> init_hypervisor_platform()")
>> Signed-off-by: Juergen Gross
>> Reviewed-by: Thomas Gleixner
>> ---
>> Resending with corrected Fixes: tag
>> Boris, please take this via the Xen tree (Thomas asked us to do so)
>
>
> Sure, but we will need to rebase to the latest bits, so you will have to
> explain yourself to Linus ;-)
NP for me. At least I hope so. :-)
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xenpmd: prevent format-truncation warning with gcc 8.2 + ARM 32-bit
On Mon, Aug 20, 2018 at 7:21 AM, Wei Liu wrote: > On Fri, Aug 17, 2018 at 06:22:16PM -0700, Christopher Clark wrote: >> >> Prior to this change, building fails with the compiler warning: >> >> | xenpmd.c: In function 'write_battery_info_to_xenstore': >> | xenpmd.c:354:23: error: '%02x' directive output may be truncated >> writing between 2 and 8 bytes into a region of size 3 >> [-Werror=format-truncation=] >> | snprintf(val, 3, "%02x", >> |^~~~ >> | xenpmd.c:354:22: note: directive argument in the range [40, 2147483778] >> | snprintf(val, 3, "%02x", >> | ^~ >> | xenpmd.c:354:5: note: 'snprintf' output between 3 and 9 bytes into a >> destination of size 3 >> | snprintf(val, 3, "%02x", >> | ^~~~ >> | (unsigned int)(9*4 + >> | >> | strlen(info->model_number) + >> | >> | strlen(info->serial_number) + >> | ~ >> | strlen(info->battery_type) + >> | >> | strlen(info->oem_info) + 4)); >> | >> | cc1: all warnings being treated as errors >> >> Signed-off-by: Christopher Clark > > Hmm... I just pushed a different fix for this to staging. Can you try if > that works for you? Yep, looks ok and that builds fine. Reviewed-by: Christopher Clark ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126261: tolerable all pass - PUSHED
flight 126261 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/126261/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 37b7c808b3fd68c11425accb53b83c37479a2b51 baseline version: xen 3a2b8525b883baa87fe89b3da58f5c09fa599b99 Last test of basis 126253 2018-08-20 12:00:32 Z0 days Testing same since 126261 2018-08-20 15:00:30 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 3a2b8525b8..37b7c808b3 37b7c808b3fd68c11425accb53b83c37479a2b51 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools: fix uninstall: tests/x86_emulator, Linux hotplug
Fixing top-level "make uninstall": tools/tests/x86_emulator is missing an uninstall target, which causes failure. Trivial to add one since it installs nothing, so do that. Linux hotplug uninstall returns success but doesn't actually remove what it installed. The Makefile variables are obfuscating incorrect logic, so strip them out and match existing code for xen-watchdog which does work. Signed-off-by: Christopher Clark --- These defects were found while reviewing Doug Goldstein's patch to remove tboot, which touches 'uninstall' in the top level Makefile. tools/hotplug/Linux/Makefile | 35 --- tools/tests/x86_emulator/Makefile | 3 +++ 2 files changed, 15 insertions(+), 23 deletions(-) diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile index d4c3cdc..3b51fe4 100644 --- a/tools/hotplug/Linux/Makefile +++ b/tools/hotplug/Linux/Makefile @@ -1,16 +1,6 @@ XEN_ROOT = $(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk -# Init scripts. -XENDOMAINS_INITD = init.d/xendomains -XENDOMAINS_LIBEXEC = xendomains -XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains - -XENCOMMONS_INITD = init.d/xencommons -XENCOMMONS_SYSCONFIG = init.d/sysconfig.xencommons - -XENDRIVERDOMAIN_INITD = init.d/xendriverdomain - # Xen script dir and scripts to go there. XEN_SCRIPTS = vif-bridge XEN_SCRIPTS += vif-route @@ -56,24 +46,23 @@ install-initd: [ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR) [ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR) [ -d $(DESTDIR)$(LIBEXEC_BIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) - $(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN) - $(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR) - $(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains - $(INSTALL_PROG) $(XENCOMMONS_INITD) $(DESTDIR)$(INITD_DIR) - $(INSTALL_DATA) $(XENCOMMONS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xencommons - $(INSTALL_PROG) $(XENDRIVERDOMAIN_INITD) $(DESTDIR)$(INITD_DIR) + $(INSTALL_DATA) init.d/sysconfig.xendomains $(DESTDIR)$(SYSCONFIG_DIR)/xendomains + $(INSTALL_DATA) init.d/sysconfig.xencommons $(DESTDIR)$(SYSCONFIG_DIR)/xencommons + $(INSTALL_PROG) xendomains $(DESTDIR)$(LIBEXEC_BIN) + $(INSTALL_PROG) init.d/xendomains $(DESTDIR)$(INITD_DIR) + $(INSTALL_PROG) init.d/xencommons $(DESTDIR)$(INITD_DIR) + $(INSTALL_PROG) init.d/xendriverdomain $(DESTDIR)$(INITD_DIR) $(INSTALL_PROG) init.d/xen-watchdog $(DESTDIR)$(INITD_DIR) .PHONY: uninstall-initd uninstall-initd: rm -f $(DESTDIR)$(INITD_DIR)/xen-watchdog - rm -f $(addprefix $(DESTDIR)$(INITD_DIR)/, $(XENDRIVERDOMAIN_INITD)) - rm -f $(addprefix $(DESTDIR)$(INITD_DIR)/, $(XENDRIVERDOMAIN_INITD)) - rm -f $(addprefix $(DESTDIR)$(SYSCONFIG_DIR)/xencommons/, $(XENCOMMONS_SYSCONFIG)) - rm -f $(addprefix $(DESTDIR)$(INITD_DIR)/, $(XENCOMMONS_INITD)) - rm -f $(addprefix $(DESTDIR)$(SYSCONFIG_DIR)/xendomains/, $(XENDOMAINS_SYSCONFIG)) - rm -f $(addprefix $(DESTDIR)$(INITD_DIR)/, $(XENDOMAINS_INITD)) - rm -f $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/, $(XENDOMAINS_LIBEXEC)) + rm -f $(DESTDIR)$(INITD_DIR)/xendriverdomain + rm -f $(DESTDIR)$(INITD_DIR)/xencommons + rm -f $(DESTDIR)$(INITD_DIR)/xendomains + rm -f $(DESTDIR)$(LIBEXEC_BIN)/xendomains + rm -f $(DESTDIR)$(SYSCONFIG_DIR)/xencommons + rm -f $(DESTDIR)$(SYSCONFIG_DIR)/xendomains .PHONY: install-scripts install-scripts: diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile index dec81c3..3654e61 100644 --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -126,6 +126,9 @@ distclean: clean .PHONY: install install: +.PHONY: uninstall +uninstall: + x86_emulate: [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/arch/x86/$@ -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/10] xen/arm: add XGENE kconfig
Add a kconfig option for X-Gene platforms. Signed-off-by: Stefano Stabellini CC: psawargaon...@apm.com CC: apa...@apm.com --- xen/arch/arm/platforms/Kconfig | 12 xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 409d3f8..e229f8f 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -36,6 +36,14 @@ config MPSOC ---help--- Enable all the required drivers for Xilinx Ultrascale+ MPSoC +config XGENE + bool "AppliedMicro X-Gene" + depends on ARM_64 + select HAS_NS16550 + ---help--- + Enable all the required drivers for AppliedMicro X-Gene (Mustang + and Storm) + endchoice config ALL64_PLAT @@ -50,3 +58,7 @@ config MPSOC_PLATFORM bool default (ALL64_PLAT || MPSOC) +config XGENE_PLATFORM + bool + default (ALL64_PLAT || XGENE) + diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index a79bdb9..2de0c6a 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -7,5 +7,5 @@ obj-$(CONFIG_ARM_32) += rcar2.o obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o obj-$(CONFIG_ARM_64) += thunderx.o -obj-$(CONFIG_ARM_64) += xgene-storm.o +obj-$(CONFIG_XGENE_PLATFORM) += xgene-storm.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 00/10] arm: add one kconfig option per platform
Hi all, This patch series introduces one kconfig option for each remaing platform under platforms/. Each kconfig option enables the required drivers in Xen. Cheers, Stefano The following changes since commit 37b7c808b3fd68c11425accb53b83c37479a2b51: automation: build with debian unstable (2018-08-20 14:05:11 +0100) are available in the git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git kconfig-plat-1 for you to fetch changes up to ac5864de9886d45ac2248a15083bcf9eb042bf72: xen/arm: add VEXPRESS kconfig (2018-08-20 16:48:34 -0700) Stefano Stabellini (10): xen/arm: add XGENE kconfig xen/arm: add THUNDERX kconfig xen/arm: add SUNXI kconfig xen/arm: add SEATTLE kconfig xen/arm: add RCAR2 kconfig xen/arm: add OMAP5 kconfig xen/arm: add MIDWAY kconfig xen/arm: add EXYNOS5 kconfig xen/arm: add B15 kconfig xen/arm: add VEXPRESS kconfig xen/arch/arm/platforms/Kconfig | 116 xen/arch/arm/platforms/Makefile | 22 2 files changed, 127 insertions(+), 11 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/10] xen/arm: add MIDWAY kconfig
Add a kconfig option for Calxeda Midway platforms. Signed-off-by: Stefano Stabellini CC: andre.przyw...@arm.com --- xen/arch/arm/platforms/Kconfig | 12 xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 3b12254..07990e6 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -84,6 +84,14 @@ config OMAP5 ---help--- Enable all the required drivers for TI OMAP5 based platforms. +config MIDWAY + bool "Calxeda Midway" + depends on ARM_32 + select HAS_PL011 + select ARM_SMMU + ---help--- + Enable all the required drivers for Calxeda Midway. + endchoice config ALL64_PLAT @@ -121,3 +129,7 @@ config RCAR2_PLATFORM config OMAP5_PLATFORM bool default (ALL32_PLAT || OMAP5) + +config MIDWAY_PLATFORM + bool + default (ALL32_PLAT || MIDWAY) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8afe37b..f87311c 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -1,7 +1,7 @@ obj-y += vexpress.o obj-$(CONFIG_ARM_32) += brcm.o obj-$(CONFIG_ARM_32) += exynos5.o -obj-$(CONFIG_ARM_32) += midway.o +obj-$(CONFIG_MIDWAY_PLATFORM) += midway.o obj-$(CONFIG_OMAP5_PLATFORM)+= omap5.o obj-$(CONFIG_RCAR2_PLATFORM)+= rcar2.o obj-$(CONFIG_SEATTLE_PLATFORM) += seattle.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/10] xen/arm: add B15 kconfig
Add a kconfig option for Broadcom B15 platforms. Signed-off-by: Stefano Stabellini CC: jfra...@broadcom.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index a5f8278..d11c9d4 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -99,6 +99,13 @@ config EXYNOS5 ---help--- Enable all the required drivers for Samsung Exynos5 based platforms. +config B15 + bool "Broadcom B15" + depends on ARM_32 + select HAS_NS16550 + ---help--- + Enable all the required drivers for Broadcom B15 platforms. + endchoice config ALL64_PLAT @@ -144,3 +151,7 @@ config MIDWAY_PLATFORM config EXYNOS5_PLATFORM bool default (ALL32_PLAT || EXYNOS5) + +config B15_PLATFORM + bool + default (ALL32_PLAT || B15) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index b35b360..9bc3e48 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -1,5 +1,5 @@ obj-y += vexpress.o -obj-$(CONFIG_ARM_32) += brcm.o +obj-$(CONFIG_B15_PLATFORM) += brcm.o obj-$(CONFIG_EXYNOS5_PLATFORM) += exynos5.o obj-$(CONFIG_MIDWAY_PLATFORM) += midway.o obj-$(CONFIG_OMAP5_PLATFORM)+= omap5.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/10] xen/arm: add OMAP5 kconfig
Add a kconfig option for TI OMAP5 platforms. Signed-off-by: Stefano Stabellini CC: baoz...@gmail.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index a116566..3b12254 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -77,6 +77,13 @@ config RCAR2 ---help--- Enable all the required drivers for Renesas R-Car Gen2. +config OMAP5 + bool "TI OMAP5 platforms" + depends on ARM_32 + select HAS_OMAP + ---help--- + Enable all the required drivers for TI OMAP5 based platforms. + endchoice config ALL64_PLAT @@ -110,3 +117,7 @@ config SEATTLE_PLATFORM config RCAR2_PLATFORM bool default (ALL32_PLAT || RCAR2) + +config OMAP5_PLATFORM + bool + default (ALL32_PLAT || OMAP5) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index f6c03fc..8afe37b 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -2,7 +2,7 @@ obj-y += vexpress.o obj-$(CONFIG_ARM_32) += brcm.o obj-$(CONFIG_ARM_32) += exynos5.o obj-$(CONFIG_ARM_32) += midway.o -obj-$(CONFIG_ARM_32) += omap5.o +obj-$(CONFIG_OMAP5_PLATFORM)+= omap5.o obj-$(CONFIG_RCAR2_PLATFORM)+= rcar2.o obj-$(CONFIG_SEATTLE_PLATFORM) += seattle.o obj-$(CONFIG_SUNXI_PLATFORM)+= sunxi.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/10] xen/arm: add RCAR2 kconfig
Add a kconfig option for Renesas Rcar2 platforms. Signed-off-by: Stefano Stabellini CC: iurii.konovale...@globallogic.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 9515f18..a116566 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -70,6 +70,13 @@ config SEATTLE ---help--- Enable all the required drivers for AMD Seattle. +config RCAR2 + bool "Renesas R-Car Gen2" + depends on ARM_32 + select HAS_SCIF + ---help--- + Enable all the required drivers for Renesas R-Car Gen2. + endchoice config ALL64_PLAT @@ -99,3 +106,7 @@ config SUNXI_PLATFORM config SEATTLE_PLATFORM bool default (ALL64_PLAT || SEATTLE) + +config RCAR2_PLATFORM + bool + default (ALL32_PLAT || RCAR2) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 18f4c80..f6c03fc 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -3,7 +3,7 @@ obj-$(CONFIG_ARM_32) += brcm.o obj-$(CONFIG_ARM_32) += exynos5.o obj-$(CONFIG_ARM_32) += midway.o obj-$(CONFIG_ARM_32) += omap5.o -obj-$(CONFIG_ARM_32) += rcar2.o +obj-$(CONFIG_RCAR2_PLATFORM)+= rcar2.o obj-$(CONFIG_SEATTLE_PLATFORM) += seattle.o obj-$(CONFIG_SUNXI_PLATFORM)+= sunxi.o obj-$(CONFIG_THUNDERX_PLATFORM) += thunderx.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/10] xen/arm: add SEATTLE kconfig
Add a kconfig option for ARM Seattle platforms. Signed-off-by: Stefano Stabellini CC: suravee.suthikulpa...@amd.com --- xen/arch/arm/platforms/Kconfig | 12 xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 8337aa9..9515f18 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -62,6 +62,14 @@ config SUNXI Enable all the required drivers for Allwinnder sunxi platforms, including Pine64, OrangePi, CubieBoard, etc. +config SEATTLE + bool "AMD Seattle" + depends on ARM_64 + select HAS_PL011 + select ARM_SMMU + ---help--- + Enable all the required drivers for AMD Seattle. + endchoice config ALL64_PLAT @@ -87,3 +95,7 @@ config THUNDERX_PLATFORM config SUNXI_PLATFORM bool default (ALL_PLAT || SUNXI) + +config SEATTLE_PLATFORM + bool + default (ALL64_PLAT || SEATTLE) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8e4c2ac..18f4c80 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -4,7 +4,7 @@ obj-$(CONFIG_ARM_32) += exynos5.o obj-$(CONFIG_ARM_32) += midway.o obj-$(CONFIG_ARM_32) += omap5.o obj-$(CONFIG_ARM_32) += rcar2.o -obj-$(CONFIG_ARM_64) += seattle.o +obj-$(CONFIG_SEATTLE_PLATFORM) += seattle.o obj-$(CONFIG_SUNXI_PLATFORM)+= sunxi.o obj-$(CONFIG_THUNDERX_PLATFORM) += thunderx.o obj-$(CONFIG_XGENE_PLATFORM)+= xgene-storm.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/10] xen/arm: add EXYNOS5 kconfig
Add a kconfig option for Samsung Exynos5 platforms. Signed-off-by: Stefano Stabellini CC: julien.gr...@linaro.org CC: casion...@gmail.com CC: suriya...@gmail.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 07990e6..a5f8278 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -92,6 +92,13 @@ config MIDWAY ---help--- Enable all the required drivers for Calxeda Midway. +config EXYNOS5 + bool "Samsung Exynos5" + depends on ARM_32 + select HAS_EXYNOS4210 + ---help--- + Enable all the required drivers for Samsung Exynos5 based platforms. + endchoice config ALL64_PLAT @@ -133,3 +140,7 @@ config OMAP5_PLATFORM config MIDWAY_PLATFORM bool default (ALL32_PLAT || MIDWAY) + +config EXYNOS5_PLATFORM + bool + default (ALL32_PLAT || EXYNOS5) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index f87311c..b35b360 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -1,6 +1,6 @@ obj-y += vexpress.o obj-$(CONFIG_ARM_32) += brcm.o -obj-$(CONFIG_ARM_32) += exynos5.o +obj-$(CONFIG_EXYNOS5_PLATFORM) += exynos5.o obj-$(CONFIG_MIDWAY_PLATFORM) += midway.o obj-$(CONFIG_OMAP5_PLATFORM)+= omap5.o obj-$(CONFIG_RCAR2_PLATFORM)+= rcar2.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/15] xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h
On Mon, 20 Aug 2018, Julien Grall wrote: > Hi Stefano, > > On Thu, 16 Aug 2018, 19:17 Stefano Stabellini, wrote: > On Thu, 16 Aug 2018, Julien Grall wrote: > > Hi Stefano, > > > > On 08/14/2018 10:43 PM, Stefano Stabellini wrote: > > > On Mon, 16 Jul 2018, Julien Grall wrote: > > > > GUEST_BUG_ON may be used in other files doing guest emulation. > > > > > > > > Signed-off-by: Julien Grall > > > > > > Given that GUEST_BUG_ON is not actually used in any other files in > this > > > patch series, I assume you are referring to one of your future > series? > > > > It is going to be used later. However, I don't really refer to any > series in > > particular. It is just that this macros could be helpful in any > emulation code > > to catch what we think is a invalid architectural behavior. > > It is only that a concrete use-case helps. The idea of moving > GUEST_BUG_ON is good, but where to? For instance, wouldn't it be better > to move it to guest_access.h? I am just trying to point to an existing > header which is more widely used across the emulators (vpl011, > vgic-v3-its.c, hvm.c, ...) > > > Definitely not in guest_access.h or any wider in includes. If you look at the > implementation and documentation, it will crash the > hypervisor because the goal is to catch hardware bug or misunderstanding of > the spec. This is not meant to be used in emulation. > We should not crash the guest/hypervisor in bad behavior but inject an > exception. > > So trap.h is the best places for it as hardware trap are now split accros > multiples files. OK ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: remove unused hypercall functions
On 08/20/2018 09:03 AM, Juergen Gross wrote: > Remove Xen hypercall functions which are used nowhere in the kernel. > > Signed-off-by: Juergen Gross > --- Applied to for-linus-19b. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] x86/xen: enable early use of set_fixmap in 32-bit Xen PV guest
On 08/20/2018 11:24 AM, Juergen Gross wrote:
> Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
> init_hypervisor_platform()") moved the mapping of the shared info area
> before pagetable_init(). This breaks booting as 32-bit PV guest as the
> use of set_fixmap isn't possible at this time on 32-bit.
>
> This can be worked around by populating the needed PMD on 32-bit
> kernel earlier.
>
> In order not to reimplement populate_extra_pte() using extend_brk()
> for allocating new page tables extend alloc_low_pages() to do that in
> case the early page table pool is not yet available.
>
> Fixes: 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
> init_hypervisor_platform()")
> Signed-off-by: Juergen Gross
> Reviewed-by: Thomas Gleixner
> ---
> Resending with corrected Fixes: tag
> Boris, please take this via the Xen tree (Thomas asked us to do so)
Applied to for-linus-19b.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: remove unused function xen_auto_xlated_memory_setup()
On 08/20/2018 09:02 AM, Juergen Gross wrote: > xen_auto_xlated_memory_setup() is a leftover from PVH V1. Remove it. > > Signed-off-by: Juergen Gross > Applied to for-linus-19b. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 126195: regressions - FAIL
flight 126195 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/126195/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a version targeted for testing: libvirt 69c20e1090059d8b359fdd435e8ba50db7269be1 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 76 days Failing since123840 2018-06-06 04:19:28 Z 75 days 57 attempts Testing same since 126073 2018-08-17 20:39:06 Z2 days2 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský Vitaly Kuznetsov w00251574 Weilun Zhu xinhua.Cao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked 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
[Xen-devel] [PATCH 03/10] xen/arm: add SUNXI kconfig
Add a kconfig option for SUNXI platforms. Signed-off-by: Stefano Stabellini CC: andre.przyw...@arm.com CC: v1ne...@gmail.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 62b528b..8337aa9 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -55,6 +55,13 @@ config THUNDERX ---help--- Enable all the required drivers for Cavium ThunderX +config SUNXI + bool "Allwinner sunxi platforms" + select HAS_NS16550 + ---help--- + Enable all the required drivers for Allwinnder sunxi platforms, + including Pine64, OrangePi, CubieBoard, etc. + endchoice config ALL64_PLAT @@ -76,3 +83,7 @@ config XGENE_PLATFORM config THUNDERX_PLATFORM bool default (ALL64_PLAT || THUNDERX) + +config SUNXI_PLATFORM + bool + default (ALL_PLAT || SUNXI) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index bc35640..8e4c2ac 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_ARM_32) += midway.o obj-$(CONFIG_ARM_32) += omap5.o obj-$(CONFIG_ARM_32) += rcar2.o obj-$(CONFIG_ARM_64) += seattle.o -obj-y += sunxi.o +obj-$(CONFIG_SUNXI_PLATFORM)+= sunxi.o obj-$(CONFIG_THUNDERX_PLATFORM) += thunderx.o obj-$(CONFIG_XGENE_PLATFORM)+= xgene-storm.o obj-$(CONFIG_MPSOC_PLATFORM)+= xilinx-zynqmp.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/10] xen/arm: add THUNDERX kconfig
Add a kconfig option for Cavium ThunderX platforms. Signed-off-by: Stefano Stabellini CC: mja...@caviumnetworks.com CC: zi@cavium.com --- xen/arch/arm/platforms/Kconfig | 14 ++ xen/arch/arm/platforms/Makefile | 6 +++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index e229f8f..62b528b 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -44,6 +44,17 @@ config XGENE Enable all the required drivers for AppliedMicro X-Gene (Mustang and Storm) +config THUNDERX + bool "Cavium ThunderX" + depends on ARM_64 + select ARM_SMMU + select GICV3 + select HAS_ITS + select HAS_PL011 + select ACPI if EXPERT = "y" + ---help--- + Enable all the required drivers for Cavium ThunderX + endchoice config ALL64_PLAT @@ -62,3 +73,6 @@ config XGENE_PLATFORM bool default (ALL64_PLAT || XGENE) +config THUNDERX_PLATFORM + bool + default (ALL64_PLAT || THUNDERX) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 2de0c6a..bc35640 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -6,6 +6,6 @@ obj-$(CONFIG_ARM_32) += omap5.o obj-$(CONFIG_ARM_32) += rcar2.o obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o -obj-$(CONFIG_ARM_64) += thunderx.o -obj-$(CONFIG_XGENE_PLATFORM) += xgene-storm.o -obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o +obj-$(CONFIG_THUNDERX_PLATFORM) += thunderx.o +obj-$(CONFIG_XGENE_PLATFORM)+= xgene-storm.o +obj-$(CONFIG_MPSOC_PLATFORM)+= xilinx-zynqmp.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/10] xen/arm: add VEXPRESS kconfig
Add a kconfig option for Versatile Express A15 platforms. Signed-off-by: Stefano Stabellini CC: julien.gr...@arm.com --- xen/arch/arm/platforms/Kconfig | 11 +++ xen/arch/arm/platforms/Makefile | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index d11c9d4..5027df3 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -106,6 +106,13 @@ config B15 ---help--- Enable all the required drivers for Broadcom B15 platforms. +config VEXPRESS + bool "ARM Versatile Express" + depends on ARM_32 + select HAS_PL011 + ---help--- + Enable all the required drivers for ARM Versatile Express. + endchoice config ALL64_PLAT @@ -155,3 +162,7 @@ config EXYNOS5_PLATFORM config B15_PLATFORM bool default (ALL32_PLAT || B15) + +config VEXPRESS_PLATFORM + bool + default (ALL32_PLAT || VEXPRESS) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 9bc3e48..d3221ed 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -1,4 +1,4 @@ -obj-y += vexpress.o +obj-$(CONFIG_VEXPRESS_PLATFORM) += vexpress.o obj-$(CONFIG_B15_PLATFORM) += brcm.o obj-$(CONFIG_EXYNOS5_PLATFORM) += exynos5.o obj-$(CONFIG_MIDWAY_PLATFORM) += midway.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 12/16] x86/xen: enable Hygon support to Xen
On 08/19/2018 12:13 PM, Pu Wen wrote: > To make Xen works functionly on Hygon platforms, reuse AMD's Xen support > code path for Hygon. > > There are six core performance events counters per thread, so there are > six MSRs for these counters(0-5). Also there are four legacy PMC MSRs, > they are alias of the counters(0-3). > > In this version of kernel Hygon use the lagacy and safe versions of MSR > access. It works fine when VPMU enabled in Xen on Hygon platforms by > testing with perf. > > Signed-off-by: Pu Wen Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 126214: regressions - FAIL
flight 126214 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/126214/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 125057 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 125057 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126094 pass in 126214 test-armhf-armhf-libvirt 5 host-ping-check-native fail pass in 126094 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126094 like 125057 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 126094 like 125057 test-armhf-armhf-libvirt13 migrate-support-check fail in 126094 never pass test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125057 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125057 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 125057 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125057 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125057 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125057 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125057 test-amd64-amd64-xl-rtds 10 debian-install fail like 125057 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125057 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 7ba1c7df881855422f9a475862565e94c8421b75 baseline version: xen 280a5568939c4a5832be787c8e0c23a19f30935a Last test of basis 125057 2018-07-09 08:36:04 Z 42 days Failing since125685 2018-07-30 12:39:38 Z 21 days 14 attempts Testing same since 125931 2018-08-15 22:51:23 Z5 days3 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf
Re: [Xen-devel] [PATCH 05/10] xen/arm: add RCAR2 kconfig
Hello Stefano, On 21.08.18 02:59, Stefano Stabellini wrote: Add a kconfig option for Renesas Rcar2 platforms. Signed-off-by: Stefano Stabellini CC: iurii.konovale...@globallogic.com Reviewed-by: Andrii Anisov -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75094: tolerable FAIL
This run is configured for baseline tests only. flight 75094 ovmf real [real] http://osstest.xensource.com/osstest/logs/75094/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75087 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75087 version targeted for testing: ovmf 0258ba6256ca193e8fd896a40ceef1bc06a3e0e8 baseline version: ovmf f843a328772a30c11162c281adaf2afc1b4a972f Last test of basis75087 2018-08-18 08:22:54 Z2 days Testing same since75094 2018-08-20 05:27:39 Z0 days1 attempts People who touched revisions under test: Jaben Carsey 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 0258ba6256ca193e8fd896a40ceef1bc06a3e0e8 Author: Jaben Carsey Date: Fri Aug 3 23:11:08 2018 +0800 BaseTools: AutoGen refactor to iterate less Don't iterate over new dictionaries with one item Create the data and then add to dictionary. Note: if you diff ignoring whitespace changes you can more easily see the relevant changes. Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey Reviewed-by: Yonghong Zhu commit 830bf22fa5525263ea10cd2f4a0dc843a4c05122 Author: Jaben Carsey Date: Fri Aug 3 23:11:07 2018 +0800 BaseTools: AutoGen - tag a function as cachable MakeFile generation is once per module, so mark it as such. also move the time stamp creation function inside as it's only called from one place. Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey Reviewed-by: Yonghong Zhu commit b23414f6540d4f336b6f00b44681911d469f9a04 Author: Jaben Carsey Date: Fri Aug 3 23:11:06 2018 +0800 BaseTools: AutoGen refactor ModuleAutoGen caching 1) Add a new file Common/caching.py a. Allows for automated caching of repeated class functions, class properties, and non-class functions b. When called the first time the value is cached and if called a second time, the cached result is called, not the function. c. When used, this saves lots of memory since the actual function pointers are replaced with smaller data elements. d. note that not all features are used yet. 2) Fix AutoGen/GenMake and AutoGen/GetC to not call into private member variables of ModuleAutoGen class a. use the existing accessor properties for the data 3) Change AutoGen classes to remove a exception for duplicate members in __new__ and use ?in? testing to speed up 4) Work on ModuleAutoGen class a. Change all properties that use caching to use @caching_property (see #1 above) b. Change all properties that do not use caching to use standard python decorator "@property" c. Change all cases where a dictionary/set/list/object was created and then immediately updated to use constructor parameters d. Refactor each property function to remove the internal variable that is no longer needed (this helps find items like #2 above) e. Refactor _ApplyBuildRule with optional parameter to work around circular dependency with BinaryFileList. Note that 4e was almost certainly unintended as the functions were acting on incomplete information since they were directly accessing private instance variables at the same time another function on the stack was creating the same private isntance data. This overall changes behavior
[Xen-devel] [xen-4.9-testing test] 126201: regressions - FAIL
flight 126201 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/126201/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 124328 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 5 host-ping-check-native fail in 126075 pass in 126201 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 126075 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 10 debian-install fail REGR. vs. 124328 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail blocked in 124328 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail in 126075 like 124248 test-amd64-i386-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail in 126075 like 124248 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 126075 like 124328 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 126075 like 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124248 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124328 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 6c9d139cdd0289f2b35b5deea4b41b8e3e1b39b7 baseline version: xen 238007d6fae9447bf5e8e73d67ae9fb844e7ff2a Last test of basis 124328 2018-06-17 23:39:07 Z 64 days Failing since124807 2018-06-28 17:38:04 Z 53 days 33 attempts Testing same since 125922 2018-08-15 14:57:13 Z5 days3 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Kevin Tian Lars Kurth Paul Durrant Stefano Stabellini Stewart Hildebrand Wei Liu jobs: build-amd64-xsm
Re: [Xen-devel] [PATCH] tools: fix uninstall: tests/x86_emulator, Linux hotplug
On Mon, Aug 20, 2018 at 11:42:30AM -0700, Christopher Clark wrote: > Fixing top-level "make uninstall": > > tools/tests/x86_emulator is missing an uninstall target, which causes > failure. Trivial to add one since it installs nothing, so do that. > > Linux hotplug uninstall returns success but doesn't actually remove what > it installed. The Makefile variables are obfuscating incorrect logic, so > strip them out and match existing code for xen-watchdog which does work. > > Signed-off-by: Christopher Clark Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 126202: regressions - FAIL
flight 126202 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/126202/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never
Re: [Xen-devel] [PATCH 06/10] xen/arm: add OMAP5 kconfig
Hello Stefano, On 21.08.18 02:59, Stefano Stabellini wrote: Add a kconfig option for TI OMAP5 platforms. Signed-off-by: Stefano Stabellini CC: baoz...@gmail.com -- Reviewed-by: Andrii Anisov *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf
On 08/20/2018 05:40 PM, Wei Liu wrote:
On Mon, Jul 23, 2018 at 03:27:25PM +0300, Oleksandr Andrushchenko wrote:
[...]
diff --git a/tools/libs/gnttab/linux.c b/tools/libs/gnttab/linux.c
index 8347ddd3d9cf..9765146f7eb6 100644
--- a/tools/libs/gnttab/linux.c
+++ b/tools/libs/gnttab/linux.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2007-2008, D G Murray
+ * Copyright (c) 2018, Oleksandr Andrushchenko, EPAM Systems Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -309,6 +310,118 @@ int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
return rc;
}
+int osdep_gnttab_dmabuf_exp_from_refs(xengnttab_handle *xgt, uint32_t domid,
+ uint32_t flags, uint32_t count,
+ const uint32_t *refs,
+ uint32_t *dmabuf_fd)
+{
+struct ioctl_gntdev_dmabuf_exp_from_refs *from_refs;
You can set from_refs to NULL here, then ...
+int rc = 0;
+
+if ( !count )
+{
+errno = EINVAL;
+return -1;
rc = -1;
goto out;
in all exit paths.
I don't like using two error handling styles. So please either change to
use goto only or delete the only goto in this function.
+}
+
+from_refs = malloc(sizeof(*from_refs) +
+ (count - 1) * sizeof(from_refs->refs[0]));
+if ( !from_refs )
+{
+errno = ENOMEM;
+return -1;
+}
+
+from_refs->flags = flags;
+from_refs->count = count;
+from_refs->domid = domid;
+
+memcpy(from_refs->refs, refs, count * sizeof(from_refs->refs[0]));
+
+if ( (rc = ioctl(xgt->fd, IOCTL_GNTDEV_DMABUF_EXP_FROM_REFS, from_refs)) )
+{
+GTERROR(xgt->logger, "ioctl DMABUF_EXP_FROM_REFS failed");
+goto out;
+}
+
+*dmabuf_fd = from_refs->fd;
+
+out:
+free(from_refs);
+return rc;
+}
+
+int osdep_gnttab_dmabuf_exp_wait_released(xengnttab_handle *xgt,
+ uint32_t fd, uint32_t wait_to_ms)
+{
+struct ioctl_gntdev_dmabuf_exp_wait_released wait;
+int rc;
+
+wait.fd = fd;
+wait.wait_to_ms = wait_to_ms;
+
+if ( (rc = ioctl(xgt->fd, IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED, )) )
{
{ should be on a new line.
+if ( errno == ENOENT ) {
Ditto.
+/* The buffer may have already been released. */
+errno = 0;
+rc = 0;
+} else
+GTERROR(xgt->logger, "ioctl DMABUF_EXP_WAIT_RELEASED failed");
+}
+
+return rc;
+}
+
+int osdep_gnttab_dmabuf_imp_to_refs(xengnttab_handle *xgt, uint32_t domid,
+uint32_t fd, uint32_t count, uint32_t
*refs)
+{
+struct ioctl_gntdev_dmabuf_imp_to_refs *to_refs;
+int rc = 0;
+
+if ( !count )
+{
+errno = EINVAL;
+return -1;
Same comments on error handling apply to this function too.
The rest looks fine.
Thank you,
I'll fix the above and send v1
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/1] cameraif: add ABI for para-virtual camera
On 08/14/2018 11:30 AM, Juergen Gross wrote:
On 31/07/18 11:31, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most needed functionality with the
final idea to make it possible to extend the protocol if need be:
1. Provide means for base virtual device configuration:
- pixel formats
- resolutions
- frame rates
2. Support basic camera controls:
- contrast
- brightness
- hue
- saturation
3. Support streaming control
4. Support zero-copying use-cases
Signed-off-by: Oleksandr Andrushchenko
Some style issues below...
Will fix all the below, thank you!
I would like to draw some attention of the Linux/V4L community to this
protocol as the plan is that once it is accepted for Xen we plan to
upstream a Linux camera front-end kernel driver which will be based
on this work and will be a V4L2 device driver (this is why I have sent
this patch not only to Xen, but to the corresponding Linux mailing list
as well)
---
xen/include/public/io/cameraif.h | 981 +++
1 file changed, 981 insertions(+)
create mode 100644 xen/include/public/io/cameraif.h
diff --git a/xen/include/public/io/cameraif.h b/xen/include/public/io/cameraif.h
new file mode 100644
index ..bdc6a1262fcf
--- /dev/null
+++ b/xen/include/public/io/cameraif.h
+struct xencamera_config {
+uint32_t pixel_format;
+uint32_t width;
+uint32_t height;
+uint32_t frame_rate_nom;
+uint32_t frame_rate_denom;
+uint8_t num_bufs;
Add explicit padding?
+};
+struct xencamera_req {
+uint16_t id;
+uint8_t operation;
+uint8_t reserved[5];
+union {
+struct xencamera_config config;
+struct xencamera_buf_create_req buf_create;
+ struct xencamera_buf_destroy_req buf_destroy;
+ struct xencamera_set_ctrl_req set_ctrl;
No tabs, please.
+uint8_t reserved[56];
+} req;
+};
+
+struct xencamera_resp {
+uint16_t id;
+uint8_t operation;
+uint8_t reserved;
+int32_t status;
+union {
+struct xencamera_config config;
+struct xencamera_buf_details_resp buf_details;
+ struct xencamera_get_ctrl_details_resp ctrl_details;
Tab again.
+uint8_t reserved1[56];
+} resp;
+};
Juergen
Thank you,
Oleksandr
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.8-testing baseline-only test] 75093: regressions - FAIL
This run is configured for baseline tests only. flight 75093 xen-4.8-testing real [real] http://osstest.xensource.com/osstest/logs/75093/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail REGR. vs. 75035 test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail REGR. vs. 75035 test-amd64-amd64-i386-pvgrub 19 guest-start/debian.repeat fail REGR. vs. 75035 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 12 guest-start fail like 75035 test-armhf-armhf-xl-credit2 12 guest-start fail like 75035 test-armhf-armhf-xl 12 guest-start fail like 75035 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 75035 test-armhf-armhf-xl-midway 12 guest-start fail like 75035 test-armhf-armhf-xl-rtds 12 guest-start fail like 75035 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 75035 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 75035 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 75035 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 75035 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 75035 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 75035 build-i386-prev 7 xen-build/dist-test fail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen e52ec4b7874cf85041d2d957ed2608946565fe18 baseline version: xen aa450153f2d960c217149b31b68a8b57c5a8e595 Last test of basis75035 2018-08-01 17:46:26 Z 19 days Testing same since75093 2018-08-20 02:52:41 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Jan Beulich Juergen Gross Kevin Tian Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass
Re: [Xen-devel] [PATCH 2/2] osstest: configure git proxy for FreeBSD
On Mon, Aug 20, 2018 at 03:04:37PM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH 2/2] osstest: configure git proxy for
> FreeBSD"):
> > On Mon, Aug 20, 2018 at 11:53:17AM +0100, Ian Jackson wrote:
> > > Roger Pau Monne writes ("[PATCH 2/2] osstest: configure git proxy for
> > > FreeBSD"):
> > > > Signed-off-by: Roger Pau Monné
> > >
> > > Acked-by: Ian Jackson
> > >
> > > Thanks.
> > >
> > > Do you want me to push these to pretest soon ?
> >
> > If you could, yes please. I'm hoping this will unblock the FreeBSD
> > build, or at least get it closer to unblocking :)
>
> mariner:testing.git> ./mg-allocate -l
> Global symbol "$ho" requires explicit package name at Osstest/TestSupport.pm
> line 2922.
> Compilation failed in require at ./mg-allocate line 86.
> BEGIN failed--compilation aborted at ./mg-allocate line 86.
> mariner:testing.git>
>
> And similar things from cron. I have rewound pretest and will await
> updated patches...
Sorry, here is a working branch:
git://xenbits.xen.org/people/royger/osstest.git git-proxy
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf
On Mon, Jul 23, 2018 at 03:27:25PM +0300, Oleksandr Andrushchenko wrote:
[...]
> diff --git a/tools/libs/gnttab/linux.c b/tools/libs/gnttab/linux.c
> index 8347ddd3d9cf..9765146f7eb6 100644
> --- a/tools/libs/gnttab/linux.c
> +++ b/tools/libs/gnttab/linux.c
> @@ -1,5 +1,6 @@
> /*
> * Copyright (c) 2007-2008, D G Murray
> + * Copyright (c) 2018, Oleksandr Andrushchenko, EPAM Systems Inc.
> *
> * This library is free software; you can redistribute it and/or
> * modify it under the terms of the GNU Lesser General Public
> @@ -309,6 +310,118 @@ int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
> return rc;
> }
>
> +int osdep_gnttab_dmabuf_exp_from_refs(xengnttab_handle *xgt, uint32_t domid,
> + uint32_t flags, uint32_t count,
> + const uint32_t *refs,
> + uint32_t *dmabuf_fd)
> +{
> +struct ioctl_gntdev_dmabuf_exp_from_refs *from_refs;
You can set from_refs to NULL here, then ...
> +int rc = 0;
> +
> +if ( !count )
> +{
> +errno = EINVAL;
> +return -1;
rc = -1;
goto out;
in all exit paths.
I don't like using two error handling styles. So please either change to
use goto only or delete the only goto in this function.
> +}
> +
> +from_refs = malloc(sizeof(*from_refs) +
> + (count - 1) * sizeof(from_refs->refs[0]));
> +if ( !from_refs )
> +{
> +errno = ENOMEM;
> +return -1;
> +}
> +
> +from_refs->flags = flags;
> +from_refs->count = count;
> +from_refs->domid = domid;
> +
> +memcpy(from_refs->refs, refs, count * sizeof(from_refs->refs[0]));
> +
> +if ( (rc = ioctl(xgt->fd, IOCTL_GNTDEV_DMABUF_EXP_FROM_REFS, from_refs))
> )
> +{
> +GTERROR(xgt->logger, "ioctl DMABUF_EXP_FROM_REFS failed");
> +goto out;
> +}
> +
> +*dmabuf_fd = from_refs->fd;
> +
> +out:
> +free(from_refs);
> +return rc;
> +}
> +
> +int osdep_gnttab_dmabuf_exp_wait_released(xengnttab_handle *xgt,
> + uint32_t fd, uint32_t wait_to_ms)
> +{
> +struct ioctl_gntdev_dmabuf_exp_wait_released wait;
> +int rc;
> +
> +wait.fd = fd;
> +wait.wait_to_ms = wait_to_ms;
> +
> +if ( (rc = ioctl(xgt->fd, IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED, ))
> ) {
{ should be on a new line.
> +if ( errno == ENOENT ) {
Ditto.
> +/* The buffer may have already been released. */
> +errno = 0;
> +rc = 0;
> +} else
> +GTERROR(xgt->logger, "ioctl DMABUF_EXP_WAIT_RELEASED failed");
> +}
> +
> +return rc;
> +}
> +
> +int osdep_gnttab_dmabuf_imp_to_refs(xengnttab_handle *xgt, uint32_t domid,
> +uint32_t fd, uint32_t count, uint32_t
> *refs)
> +{
> +struct ioctl_gntdev_dmabuf_imp_to_refs *to_refs;
> +int rc = 0;
> +
> +if ( !count )
> +{
> +errno = EINVAL;
> +return -1;
Same comments on error handling apply to this function too.
The rest looks fine.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126253: tolerable all pass - PUSHED
flight 126253 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/126253/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 3a2b8525b883baa87fe89b3da58f5c09fa599b99 baseline version: xen b8f33431f3dd23fb43a879f4bdb4283fdc9465ad Last test of basis 126063 2018-08-17 18:02:46 Z2 days Testing same since 126253 2018-08-20 12:00:32 Z0 days1 attempts People who touched revisions under test: Ian Jackson Tim Deegan Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 b8f33431f3..3a2b8525b8 3a2b8525b883baa87fe89b3da58f5c09fa599b99 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 126187: regressions - FAIL
flight 126187 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/126187/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125183 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 125183 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 125183 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 125183 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125183 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 125183 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 125183 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 125183 test-amd64-i386-xl 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 125183 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125183 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125183 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125183 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 125183 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125183 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 125183 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125183 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125183 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125183 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 125183 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 125183 test-armhf-armhf-xl-cubietruck 12 guest-startfail REGR. vs. 125183 test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125183 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs.
Re: [Xen-devel] [PATCH v4 07/32] libxl_qmp: Move struct sockaddr_un variable to qmp_open()
On Fri, Jul 27, 2018 at 03:05:49PM +0100, Anthony PERARD wrote: > This variable is only used once, no need to keep it in the handler. > > Also fix coding style (remove space after sizeof). > And allow strncpy to use all the space in sun_path. > > Signed-off-by: Anthony PERARD Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 126250: all pass - PUSHED
flight 126250 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/126250/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 131818ba5a83d1e8f3f1b4c041200755fff64abb baseline version: ovmf 43fe4c4052922c6baa36cf4664ce63b8699d9176 Last test of basis 126238 2018-08-20 05:10:43 Z0 days Testing same since 126250 2018-08-20 09:40:41 Z0 days1 attempts People who touched revisions under test: Ruiyu Ni shenglei 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 43fe4c4052..131818ba5a 131818ba5a83d1e8f3f1b4c041200755fff64abb -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 08/32] libxl: Add libxl__prepare_sockaddr_un() helper
On Fri, Jul 27, 2018 at 03:05:50PM +0100, Anthony PERARD wrote: > There is going to be a few more users that want to use UNIX socket, this > helper is to prepare the `struct sockaddr_un` and check that the path > isn't too long. > > Also start to use it in libxl_qmp.c. > > Signed-off-by: Anthony PERARD With Roger's comment fixed: Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear
On 20/08/18 15:26, Thomas Gleixner wrote:
> On Mon, 20 Aug 2018, Juergen Gross wrote:
>> In case adding about 6 cycles for native_ptep_get_and_clear() is believed
>> to be too bad I can modify the patch to add a paravirt function for that
>> purpose in order to add the overhead for Xen guests only (in fact the
>> overhead for Xen guests will be less, as only one instruction writing to
>> the PTE has to be emulated by the hypervisor).
>
> I doubt that its worth the trouble of yet another paravirt thingy.
>
>> ---
>> arch/x86/include/asm/pgtable-3level.h | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/pgtable-3level.h
>> b/arch/x86/include/asm/pgtable-3level.h
>> index a564084c6141..7919ae4e27d8 100644
>> --- a/arch/x86/include/asm/pgtable-3level.h
>> +++ b/arch/x86/include/asm/pgtable-3level.h
>> @@ -2,6 +2,8 @@
>> #ifndef _ASM_X86_PGTABLE_3LEVEL_H
>> #define _ASM_X86_PGTABLE_3LEVEL_H
>>
>> +#include
>> +
>> /*
>> * Intel Physical Address Extension (PAE) Mode - three-level page
>> * tables on PPro+ CPUs.
>> @@ -148,14 +150,14 @@ static inline void pud_clear(pud_t *pudp)
>> #ifdef CONFIG_SMP
>> static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
>> {
>> -pte_t res;
>> +union {
>> +pte_t pte;
>> +long long val;
>> +} res;
>>
>> -/* xchg acts as a barrier before the setting of the high bits */
>> -res.pte_low = xchg(>pte_low, 0);
>> -res.pte_high = ptep->pte_high;
>> -ptep->pte_high = 0;
>> +res.val = arch_atomic64_xchg((atomic64_t *)ptep, 0);
>
> Couldn't you just keep
>
>pte_t res;
>
> and do:
>
> res.pte = (pteval_t) arch_atomic64_xchg((atomic64_t *)ptep, 0);
>
> Hmm?
Yes, got this suggestion already by Jan. I'm waiting with V2 until
tomorrow to see whether someone has other complaints.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/32] libxl_qmp: Remove unused yajl_ctx from handler
On Fri, Jul 27, 2018 at 03:05:51PM +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD > Acked-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 11/32] libxl_dm: Add libxl__qemu_qmp_path()
On Fri, Jul 27, 2018 at 03:05:53PM +0100, Anthony PERARD wrote: > ... which generate the path to a QMP socket that libxl uses. > > Signed-off-by: Anthony PERARD Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: Handle deprecation of QEMU's -usbdevice
On Mon, Aug 20, 2018 at 03:32:58PM +0100, Wei Liu wrote: > On Wed, Jul 25, 2018 at 11:43:29AM +0100, Anthony PERARD wrote: > > On Wed, Jul 25, 2018 at 09:38:20AM +0100, Wei Liu wrote: > > > How does libvirt handle QEMU option deprecation? > > > > I don't think they handle it very well. I think it's basicaly when the > > deprecated option is removed from QEMU that they notice libvirt need to > > be fixed (That's what I got from reading a thread on qemu-devel). > > How do they fix this sort of things? Do they reject removed options or > try (as best effort) to translate? I don't think those questions make senses. What "sort of things" ? Which "options", qemu command line/qmp options or user facing options? In anycase, I don't think I know enough about libvirt (even as a user) to be able to respond to those questions, but they would probably not have exposed -usbdevice to users, like we do. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/5] x86: use PDEP for PTE flags insertion when available
>>> On 18.08.18 at 03:08, wrote: > On Aug 17, 2018, at 03:24, Jan Beulich wrote: >> >> This replaces 5 instructions by a single one, further reducing code size, >> cache, and TLB footprint (in particular on systems supporting BMI2). > > This link claims that BMI2 may be less performant/consistent on AMD Ryzen > than Intel: > https://www.reddit.com/r/Amd/comments/60i6er/ryzen_and_bmi2_strange_behavior > _and_high_latencies/ Hmm, interesting. Brian - any word as to whether we'd better avoid using PDEP/PEXT for now on AMD? > Would this patch series have any benefit to L0 hypervisors/rootkits (e.g. > Bromium, Bareflank or similar hypervisors) which could be monitoring L1 Xen? > Or Xen as L0 hypervisor and Hyper-V as L1 hypervisor? The insns aren't used on any secrets, so I don't see the connection. But then again I'm not an expert here at all. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling acpi_parse_dmar()
>>> On 20.08.18 at 05:38, wrote: > On 2018/8/17 20:28, Jan Beulich wrote: > On 17.08.18 at 09:01, wrote: >>> pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments >>> system such as HPE Superdome-Flex. >>> >>> Move acpi_mmcfg_init() call in acpi_boot_init() before calling >>> acpi_parse_dmar() so that when pci_conf_read8() is called in >>> acpi_parse_dev_scope(), we already have the mapping set up. >>> >>> acpi_mmcfg_init() only setup mmcfg mapping and has some global variables >>> initialized so there is no hazard to move it ahead. >> >> I'm afraid this is a gross understatement. "Setup mappings" >> alone is already putting such movement under question. Have >> you checked explicitly that the initialization needed for this >> setting up of mappings, if any, has actually occurred before >> the new point the function gets called? >> >> In particular, mmio_ro_ranges looks to get set up only after >> the call to acpi_boot_init(). I guess you didn't see a crash >> solely because you also move the invocation across the call >> to zap_low_mappings(). >> >> Similary pci_mmcfg_check_hostbridge() doesn't look all that >> trivial. >> >> Please may I ask that you be quite a bit more careful here, >> even more so when you've been warned already? >> >>> Meanwhile from its >>> name, acpi_boot_init() is a proper place to call it. >>> >>> The alternative is moving the acpi_parse_dev_scope() call to a later point >>> after acpi_mmcfg_init(). But acpi_parse_one_drhd(), acpi_parse_one_rmrr() >>> and acpi_parse_one_atsr() all called acpi_parse_dev_scope() as their main >>> job. Splitting those functions to two pieces looks less optimal and >>> meaningless. >> >> Certainly not meaningless; I'm also not sure why you consider >> the device scope parsing their main job. It's perhaps their >> most involved part, but the fact alone that for the purposes >> here we could probably get away without that part already >> suggests to me that this is a secondary (yet necessary) aspect. >> >> Furthermore MMCFG will continue to not work this early (or >> more precisely not at all until Dom0 boot has progressed far >> enough) if the range(s) isn't/aren't marked reserved in E820. >> It would be worthwhile saying half a sentence to this effect >> in the description. > > I meet some difficulty moving dev scope parsing to later point. Please > suggest. > > First, acpi_parse_dev_scope() may fail and disable_all_dmar_units() is > called to free all dmar related allocations which is already used by > iommu_supports_eim(). Hmm, right - iommu_supports_eim() indeed requires device scope parsing to have happened. > I'm thinking about moving below piece of code earlier too, and I checked > pci_mmcfg_check_hostbridge() carefully, it's secure, what do you think > about that? > > mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >RANGESETF_prettyprint_hex); > That's a reasonable thing to do, and is (as pointed out) a necessary prereq. But to be very clear - you'll also have to prove it's sufficient, and for that it doesn't suffice to consider pci_mmcfg_check_hostbridge() alone. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 126165: tolerable FAIL - PUSHED
flight 126165 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/126165/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen fe50b33b07fd447949284fb820eebdce9264ca17 baseline version: xen 87c83af333e0248ada2e6560965aca6096ec7f2b Last test of basis 125698 2018-07-31 12:47:03 Z 19 days Failing since125908 2018-08-14 17:06:33 Z5 days3 attempts Testing same since 125948 2018-08-16 08:50:07 Z3 days2 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Jan Beulich Juergen Gross Kevin Tian Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass
Re: [Xen-devel] [PATCH v2 2/2] x86/spec-ctrl: add support for modifying SSBD VIA LS_CFG MSR
>>> On 17.08.18 at 20:45, wrote:
> On Fri, Aug 17, 2018 at 12:59:28AM -0600, Jan Beulich wrote:
>> >>> On 16.08.18 at 22:02, wrote:
>> > On Wed, Aug 15, 2018 at 10:00:48AM -0600, Jan Beulich wrote:
>> >> > +bool __read_mostly ssbd_amd_smt_en = false;
>> >> > +bool __read_mostly default_xen_ssbd_amd_ls_cfg_en = false;
>> >> > uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
>> >> > +struct ssbd_amd_ls_cfg_smt_status
>> >> > *ssbd_amd_smt_status[SSBD_AMD_MAX_SOCKET] = {NULL};
>> >>
>> >> Several further pointless initializers.
>> >
>> > ssbd_amd_ls_cfg_mask -> needs to be initialized, due to how it gets set
>> > ssbd_amd_ls_cfg_smt_status -> needs to be initialized, unless xalloc
>> > sets it as NULL on failure to alloc
>> > default_xen_ssbd_amd_ls_cfg_en -> needs to be initialized of an else
>> > added to an if statement
>> > ssbd_amd_smt_en -> like the above
>> >
>> > If you want default_xen_ssbd_amd_ls_cfg_en and ssbd_amd_smt_en to be
>> > not be initialized, I can add code to do that.
>>
>> I don't understand: Add code? The initializers here are all pointless
>> because the values you supply are what the variables would be
>> initialized with anyway if you omitted the initializers. That's what
>> the C standard specifies.
>
> Leaving values which determine the behavior of the hypervisor to
> defaults of the compiler's implementation of the standard seems like it
> would be a possible source of subtle bugs when the compiler doesn't do
> something just right. I'd much rather have an initialized value or
> have it set in the code before use.
>
> If you strongly feel that they shouldn't be initialized or set in code,
> I'll change them though.
Yes, I do feel strongly about this: We omit pointless initializers
elsewhere, and the comment I've given here is a pretty common one
to be made in reviews. If we were to write code being prepared for
compiler bugs (which standards-non-conformance is), we could as
well stop writing any code in the first place. Workarounds are
acceptable only for _known_ compiler defects.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 4/8] mm: introduce a helper to get the memory type of a page
>>> On 17.08.18 at 18:37, wrote:
> On Fri, Aug 17, 2018 at 04:31:21AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 12:17, wrote:
>> On 14.08.18 at 15:43, wrote:
>> >> +switch ( e820.map[i].type )
>> >> +{
>> >> +case E820_RAM:
>> >> +return RAM_TYPE_CONVENTIONAL;
>> >> +
>> >> +case E820_RESERVED:
>> >> +return RAM_TYPE_RESERVED;
>> >> +
>> >> +case E820_UNUSABLE:
>> >> +return RAM_TYPE_UNUSABLE;
>> >> +
>> >> +case E820_ACPI:
>> >> +case E820_NVS:
>> >> +return RAM_TYPE_ACPI;
>> >> +
>> >> +default:
>> >> +ASSERT_UNREACHABLE();
>> >> +return -1;
>> >> +}
>> >> +}
>> >> +
>> >> +return -1;
>> >> +}
>> >
>> > One more case to consider: What about a page part of which is
>> > a given type, and the other part of which is simply missing from
>> > the E820 table? I'm uncertain whether in that case it might be a
>> > good idea in general to report it as having the given type; for the
>> > specific purpose you want the function for, that would imo be
>> > quite helpful.
>>
>> Considering RAM_TYPE_* are bit masks - perhaps the function
>> should OR together all types found for the requested page, and
>> let the caller go from there? And to account for my earlier remark,
>> add a separate RAM_TYPE_UNKNOWN (and never have the function
>> return -1 or some such; its return type then would better be
>> unsigned int)?
>
> I can do something along this lines, but then the functionality of the
> existing inclusive option is likely to change on boxes having memory
> types not aligned to a page boundary.
That's an expected consequence, yes, and given this is a workaround
option anyway I'm afraid we'll have to live with it being unclear whether
this would be a change to the better or to the worse.
> Also, we should likely discuss what to do with a page that for example
> has both unusable and reserved regions. I would map it in the
> inclusive case because it has a reserved region, but would like to
> hear your opinion.
Not page-aligned unusable regions are pretty suspicious imo. Along
the lines of the above response, I think I'd be fine going either of the
two possible routes - we simply can't tell ahead of time which one
might be better.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xenpmd: make 32 bit gcc 8.1 non-debug build work
Wei Liu writes ("[PATCH 2/2] xenpmd: make 32 bit gcc 8.1 non-debug build work"):
> 32 bit gcc 8.1 non-debug build yields:
...
> /* write 9 dwords (so 9*4) + length of 4 strings + 4 null terminators */
> -snprintf(val, 3, "%02x",
> - (unsigned int)(9*4 +
> -strlen(info->model_number) +
> -strlen(info->serial_number) +
> -strlen(info->battery_type) +
> -strlen(info->oem_info) + 4));
This is pretty unpleasant!
> +len = 9 * 4 + strlen(info->model_number) + strlen(info->serial_number) +
> + strlen(info->battery_type) + strlen(info->oem_info) + 4;
> +assert(len < 255);
> +snprintf(val, 3, "%02x", len);
This is slightly less unpleasant, I guess...
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools: update ipxe changeset
Wei Liu writes ("[PATCH 1/2] tools: update ipxe changeset"):
> This placates gcc 8.1. The commit comes from ipxe master branch as of
> July 25, 2018.
Fine, whatever. FTR, I don't think it is useful to ask for an ack of
this kind of patch, assuming the commit is indeed from ipxe master.
(And if some kind of review were needed, we would need much more
information in the commit message about what changed.)
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/tests: fix an xs-test.c issue
Wei Liu writes ("[PATCH] tools/tests: fix an xs-test.c issue"):
> The ret variable can be used uninitialised when iters is 0. Initialise
> ret at the beginning to fix this issue.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] osstest: setup git proxy for FreeBSD
Roger Pau Monne writes ("[PATCH] osstest: setup git proxy for FreeBSD"):
> Make the git proxy setup common by moving it into TestSupport and use
> it for both Linux and FreeBSD.
Can you please split the code motion from the functional change ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] osstest: configure git proxy for FreeBSD
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
---
ts-build-prep-freebsd | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-build-prep-freebsd b/ts-build-prep-freebsd
index e3220fa8..0ed30be4 100755
--- a/ts-build-prep-freebsd
+++ b/ts-build-prep-freebsd
@@ -38,6 +38,7 @@ sub install_deps () {
}
install_deps();
+gitcache_setup();
our $path_prefix = $r{"freebsd_distpath"} ||
get_stashed("path_freebsddist", $r{"freebsdbuildjob"});
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] osstest: make git proxy setup common
By moving it into TestSupport. No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
---
Osstest/TestSupport.pm | 20
ts-xen-build-prep | 19 ---
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ea546011..f8ef8233 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -138,6 +138,7 @@ BEGIN {
host_install_postboot_complete
target_core_dump_setup
sha256file host_shared_mark_ready
+ gitcache_setup
);
%EXPORT_TAGS = ( );
@@ -2903,4 +2904,23 @@ sub host_shared_mark_ready($$) {
$sharetype);
}
+sub gitcache_setup () {
+my $proxy = $c{GitCacheProxy};
+return unless $proxy;
+
+logm("setting up git cacheing proxy $proxy");
+
+my $gitcfg = '';
+foreach my $urlprefix (qw(git:// http:// https://)) {
+$gitcfg .= <{Flags}{'no-reinstall'}) {
determine_vg_lv();
lvcreate();
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
>>> On 20.08.18 at 11:59, wrote:
> On Fri, Aug 17, 2018 at 12:42:31AM -0600, Jan Beulich wrote:
>> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
>> uniformly invoked from outside of them. They're no longer getting called
>> for non-present PTEs. This way the slightly odd three-way return value
>> meaning of the higher level ones can also be got rid of.
>>
>> Introduce local variables holding the page table entries processed, and
>> use them throughout the loop bodies instead of re-reading them from the
>> page table several times.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -900,8 +900,11 @@ get_page_from_l1e(
>> struct domain *real_pg_owner;
>> bool write;
>>
>> -if ( !(l1f & _PAGE_PRESENT) )
>> +if ( unlikely(!(l1f & _PAGE_PRESENT)) )
>> +{
>> +ASSERT_UNREACHABLE();
>> return 0;
>> +}
>
> Why is this needed here? According to commit message get_page_from_l1e
> shouldn't be called with non-present l1e.
Correct, hence the assertion. Othe than its higher-level siblings,
this function is non-static, and hence I felt it warranted to have
such an assertion.
> Going through the code, both of the shadow path and (post-modification)
> pv mm path won't call get_page_from_l1e with non-present l1e AFAICT.
Correct, or else the assertion would be wrong. I'm putting it there
just to make sure new violations of the assumption won't be
introduced.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] osstest: configure git proxy for FreeBSD
Roger Pau Monné writes ("Re: [PATCH 2/2] osstest: configure git proxy for
FreeBSD"):
> On Mon, Aug 20, 2018 at 11:53:17AM +0100, Ian Jackson wrote:
> > Do you want me to push these to pretest soon ?
>
> If you could, yes please. I'm hoping this will unblock the FreeBSD
> build, or at least get it closer to unblocking :)
Right, done.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools: libxl/xl: run NUMA placement even when an hard-affinity is set
On Fri, Aug 17, 2018 at 07:03:03PM +0200, Dario Faggioli wrote:
> Right now, if either an hard or soft-affinity are explicitly specified
> in a domain's config file, automatic NUMA placement is skipped. However,
> automatic NUMA placement affects only the soft-affinity of the domain
> which is being created.
>
> Therefore, it is ok to let it run if an hard-affinity is specified. The
> semantics will be that the best placement candidate would be found,
> respecting the specified hard-affinity, i.e., using only the nodes that
> contain the pcpus in the hard-affinity mask.
The reasoning sound plausible. I have some questions below.
>
> This is particularly helpful if global xl pinning masks are defined, as
> made possible by commit aa67b97ed34279c43 ("xl.conf: Add global affinity
> masks"). In fact, without this commit, defining a global affinity mask
> would also mean disabling automatic placement, but that does not
> necessarily have to be the case (especially in large systems).
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: George Dunlap
> ---
> tools/libxl/libxl_dom.c | 46 --
> tools/xl/xl_parse.c |6 --
> 2 files changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index eb401cf1d6..e30e2dca9a 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -27,6 +27,8 @@
>
> #include "_paths.h"
>
> +//#define DEBUG 1
> +
Stray changes here?
You can use NDEBUG instead.
> libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
> {
> libxl_ctx *ctx = libxl__gc_owner(gc);
> @@ -142,12 +144,13 @@ static int numa_place_domain(libxl__gc *gc, uint32_t
> domid,
> {
> int found;
> libxl__numa_candidate candidate;
> -libxl_bitmap cpupool_nodemap;
> +libxl_bitmap cpumap, cpupool_nodemap, *map;
> libxl_cpupoolinfo cpupool_info;
> int i, cpupool, rc = 0;
> uint64_t memkb;
>
> libxl__numa_candidate_init();
> +libxl_bitmap_init();
> libxl_bitmap_init(_nodemap);
> libxl_cpupoolinfo_init(_info);
>
> @@ -162,6 +165,38 @@ static int numa_place_domain(libxl__gc *gc, uint32_t
> domid,
> rc = libxl_cpupool_info(CTX, _info, cpupool);
> if (rc)
> goto out;
> +map = _info.cpumap;
> +
> +/*
> + * If there's a well defined hard affinity mask (i.e., the same one for
> all
> + * the vcpus), we can try to run the placement considering only the pcpus
> + * within such mask.
> + */
> +if (info->num_vcpu_hard_affinity)
> +{
Placement of "{" is wrong.
> +#ifdef DEBUG
#ifndef NDEBUG ?
> +int j;
> +
> +for (j = 0; j < info->num_vcpu_hard_affinity; j++)
> +assert(libxl_bitmap_equal(>vcpu_hard_affinity[0],
> + >vcpu_hard_affinity[j], 0));
> +#endif /* DEBUG */
But why should the above be debug only? The assumption doesn't seem to
always hold.
> +
> +rc = libxl_bitmap_and(CTX, , >vcpu_hard_affinity[0],
> + _info.cpumap);
> +if (rc)
> +goto out;
> +
> +/*
> + * Hard affinity should _really_ contain cpus that are inside our
> + * cpupool. Anyway, if it does not, log a warning and only use the
> + * cpupool's cpus for placement.
> + */
> +if (!libxl_bitmap_is_empty())
> +map =
> +else
> +LOG(WARN, "Hard affinity completely outside of domain's
> cpupool?");
Should this be an error?
What is the expected interaction for hard affinity and cpupool?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/2] dmar: iommu mem leak fix
Release memory allocated for drhd iommu in error path.
-v2: fixup wrong parameter hiden due to my removing -Werror
Signed-off-by: Zhenzhong Duan
---
xen/drivers/passthrough/vtd/dmar.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 46decd4..8c5fa80 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -100,6 +100,7 @@ static void __init disable_all_dmar_units(void)
{
list_del(>list);
scope_devices_free(>scope);
+iommu_free(drhd);
xfree(drhd);
}
list_for_each_entry_safe ( rmrr, _rmrr, _rmrr_units, list )
--
1.7.3
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] osstest: configure git proxy for FreeBSD
On Mon, Aug 20, 2018 at 11:53:17AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 2/2] osstest: configure git proxy for
> FreeBSD"):
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Ian Jackson
>
> Thanks.
>
> Do you want me to push these to pretest soon ?
If you could, yes please. I'm hoping this will unblock the FreeBSD
build, or at least get it closer to unblocking :)
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 04/34] x86/mm: don't reference hvm_funcs directly
On Mon, Aug 20, 2018 at 10:28:21AM +0100, Andrew Cooper wrote: > On 17/08/2018 16:12, Wei Liu wrote: > > diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h > > index 4f720ad..146720c 100644 > > --- a/xen/include/asm-x86/hvm/hvm.h > > +++ b/xen/include/asm-x86/hvm/hvm.h > > @@ -454,6 +454,11 @@ static inline int hvm_event_pending(struct vcpu *v) > > return hvm_funcs.event_pending(v); > > } > > > > +static inline void hvm_invlpg(struct vcpu *v, unsigned long va) > > Please s/va/linear/ while making this addition (or do a general va => > linear cleanup for invlpg). Sadly, the terminology has been incorrect I will make another patch to clean it up. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/kdd: work around gcc 8.1 bug
Wei Liu writes ("[PATCH] tools/kdd: work around gcc 8.1 bug"):
> Gcc 8.1 has a bug that causes kdd fail to build. Rewrite the code to
> work around that bug.
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather than the real table, so make it controled by config option based on the fact that we already have done the real zapping in tboot_parse_dmar_table(). As said above, acpi_parse_dmar() doesn't zaps APCI DMAR signature in real TXT heap table, fix the stale comments. This is osmetic change, it's unnecessory to zap a copy of DMAR table which is freed later. -v2: Add some description per Jan. Signed-off-by: Zhenzhong Duan --- xen/arch/x86/tboot.c |3 +-- xen/drivers/passthrough/vtd/dmar.c |2 ++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c index d5a5292..f22fa24 100644 --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -490,8 +490,7 @@ int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler) rc = dmar_handler(dmar_table); xfree(dmar_table); -/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */ -/* but dom0 will read real table, so must zap it there too */ +/* Dom0 will read real DMAR table, so must zap it there */ acpi_dmar_zap(); return rc; diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c index 8c5fa80..ed4c04e 100644 --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -866,8 +866,10 @@ static int __init acpi_parse_dmar(struct acpi_table_header *table) } out: +#ifndef CONFIG_TBOOT /* Zap ACPI DMAR signature to prevent dom0 using vt-d HW. */ acpi_dmar_zap(); +#endif return ret; } -- 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] osstest: make git proxy setup common
Roger Pau Monne writes ("[PATCH 1/2] osstest: make git proxy setup common"):
> By moving it into TestSupport. No functional change.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] osstest: configure git proxy for FreeBSD
Roger Pau Monne writes ("[PATCH 2/2] osstest: configure git proxy for FreeBSD"):
> Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
Thanks.
Do you want me to push these to pretest soon ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] 答复: [PATCH v2 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
Please ignore this patch, looks description is wrong, I'll resend, sorry for noise. Zhenzhong - zhenzhong.d...@oracle.com wrote： > When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather > than the real table, so make it controled by config option based on > the > fact that we already have done the real zapping in > tboot_parse_dmar_table(). > > As said above, acpi_parse_dmar() doesn't zaps APCI DMAR signature in > real TXT heap table, fix the stale comments. > > This is osmetic change, it's unnecessory to zap a copy of DMAR table > which > is freed later. > > -v2: Add some description per Jan. > > Signed-off-by: Zhenzhong Duan > --- > xen/arch/x86/tboot.c |3 +-- > xen/drivers/passthrough/vtd/dmar.c |2 ++ > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c > index d5a5292..f22fa24 100644 > --- a/xen/arch/x86/tboot.c > +++ b/xen/arch/x86/tboot.c > @@ -490,8 +490,7 @@ int __init > tboot_parse_dmar_table(acpi_table_handler dmar_handler) > rc = dmar_handler(dmar_table); > xfree(dmar_table); > > -/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table > */ > -/* but dom0 will read real table, so must zap it there too */ > +/* Dom0 will read real DMAR table, so must zap it there */ > acpi_dmar_zap(); > > return rc; > diff --git a/xen/drivers/passthrough/vtd/dmar.c > b/xen/drivers/passthrough/vtd/dmar.c > index 8c5fa80..ed4c04e 100644 > --- a/xen/drivers/passthrough/vtd/dmar.c > +++ b/xen/drivers/passthrough/vtd/dmar.c > @@ -866,8 +866,10 @@ static int __init acpi_parse_dmar(struct > acpi_table_header *table) > } > > out: > +#ifndef CONFIG_TBOOT > /* Zap ACPI DMAR signature to prevent dom0 using vt-d HW. */ > acpi_dmar_zap(); > +#endif > return ret; > } > > -- > 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling acpi_parse_dmar()
>>> On 20.08.18 at 11:38, wrote: > On 2018/8/20 15:45, Jan Beulich wrote: > On 20.08.18 at 05:38, wrote: >>> I'm thinking about moving below piece of code earlier too, and I checked >>> pci_mmcfg_check_hostbridge() carefully, it's secure, what do you think >>> about that? >>> >>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >>> RANGESETF_prettyprint_hex); >>> >> >> That's a reasonable thing to do, and is (as pointed out) a necessary >> prereq. But to be very clear - you'll also have to prove it's sufficient, >> and for that it doesn't suffice to consider pci_mmcfg_check_hostbridge() >> alone. > Not sure how to prove, I checked over acpi_mmcfg_init() carefully, > acpi_disabled and DMI info are used and they are initialized earlier > than acpi_dmar_init() call, I only found mmio_ro_ranges need to be moved. But that's only half of it: Checking just acpi_mmcfg_init() is insufficient. You also need to check everything between the old and new call sites. And the result of this checking wants to be summarized (read: in a brief but nevertheless sufficient form) in the patch description. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
On 2018/8/20 16:44, Andrew Cooper wrote: On 20/08/2018 09:30, Jan Beulich wrote: On 20.08.18 at 05:32, wrote: When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather than the real table, so make it controled by config option based on the fact that we already have done the real zapping in tboot_parse_dmar_table(). Is this just a cosmetic change, or is there any harm done by the extra zapping? Before 123c7793797502b222300eb710cd3873dcca41ee, calling it multiple times would require an equivalent number of reinstate calls for it to work. That change went into Xen 4.6, whereas I guess this is a patch being upstreamed from Oracles 4.4 patchqueue? Not for that reason. Patch is for upstream. tboot_parse_dmar_table() called acpi_dmar_zap() the first time, acpi_parse_dmar called it the second time, I thought it's a dup. Thanks Zhenzhong ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 00/34] Make CONFIG_HVM work
On Mon, Aug 20, 2018 at 10:13:07AM +0100, Andrew Cooper wrote: > On 17/08/2018 16:12, Wei Liu wrote: > > This series goes through x86 code to make CONFIG_HVM work. > > > > With this series, it is possible to build Xen with PV support only. > > > > Running `xl info` on a host with PV only Xen: > > > > root@lcy2-dt108:~# xl info > > host : lcy2-dt108 > > release: 4.17.0-0.bpo.1-amd64 > > version: #1 SMP Debian 4.17.8-1~bpo9+1 (2018-07-23) > > machine: x86_64 > > nr_cpus: 8 > > max_cpu_id : 7 > > nr_nodes : 1 > > cores_per_socket : 4 > > threads_per_core : 2 > > cpu_mhz: 3504.057 > > hw_caps: > > bfebfbff:77faf3ff:2c100800:0121:000f:009c6fbf::0100 > > virt_caps : hvm_directio > > total_memory : 32589 > > free_memory: 4158 > > sharing_freed_memory : 0 > > sharing_used_memory: 0 > > outstanding_claims : 0 > > free_cpus : 0 > > xen_major : 4 > > xen_minor : 12 > > xen_extra : -unstable > > xen_version: 4.12-unstable > > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p > > xen_scheduler : credit > > xen_pagesize : 4096 > > platform_params: virt_start=0x8000 > > xen_changeset : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e > > xen_commandline: placeholder loglvl=all guest_loglvl=all > > com2=115200,8n1 ucode=scan console=com2,vga console_to_ring > > sync_console hvm_fep > > cc_compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > cc_compile_by : wei > > cc_compile_domain : uk.xensource.com > > cc_compile_date: Fri Aug 17 14:41:56 BST 2018 > > build_id : 3989ecb7693aa02f6ecc748a951ed444cc70ba94 > > xend_config_format : 4 > > > > The hvm_directio flag is not accurate. See the last patch for > > discussion. > > > > The major goal at the moment is to get something that works first, > > then refine code structure later. Currently CONFIG_HVM is littered in > > individual files. In the future some of the code could / should be > > moved to files under hvm/ for cleaner split. > > > > I ran some basic PV / PVSHIM VM life cycle tests and XTF PV tests, all > > worked. > > > > $ ls -l xen # PV only, non-debug > > -rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen > > $ ls -l xen # default build, non-debug > > -rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen > > > > The PV only Xen is ~17.8% smaller in size. > > Hmm - only that little? I'm somewhat surprised. I guess it will be > equally telling to see the delta for an HVM-only Xen. There is in fact more code that should be put under CONFIG_HVM, but that's something for later patches. > > Either way, to get this going in the right direction, Patches 1-4 are > trivial. Acked-by: Andrew Cooper Thanks. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support
Hello, > I would prefer if no new alias are added. The same could be achieved with > CONFIG_EARLY_PRINTK=meson,0xc81004c0. > > This could be documented on the wiki. Ok. > I would prefer if we stick with the spec name. So UART_TX_REG should be > renamed UART_WFIFO_REG. Yeah right, got your point. > > Also, it might be worth considering to prefix them with AML_ so it is easy > to find them on lookup. Initially used AML_ as prefix but then I just wanted to be consistent it with other uart drivers in XEN. > Looking at the earlyconsole implementation in Linux, it seems that TX needs > to be enabled first (see meson_uart_enable_tx_engine). > > Is it now done in the firmware? Yes, this has been done in u-boot. shouldn't we trust it? >> + */ >> +.macro early_uart_ready xb c >> +1: >> +ldrh w\c, [\xb, #UART_STATUS_REG] /* status register */ >> +tstw\c, #(1 << 21) /* Check TXFIFO FULL bit */ > > > Please define 1 << 21 rather than hardcoding it. Ok. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
Hi Julien, I tried today with your patch in xen-4.11 Still has secondary cpus problems, Please find below log after that patch in xen-4.11 Loading driver at 0x000B03B5000 EntryPoint=0x000B044907C Loading driver at 0x000B03B5000 EntryPoint=0x000B044907C Using modules provided by bootloader in FDT Xen 4.11.1-pre (c/s Mon Jul 30 11:30:09 2018 +0200 git:33ced72-dirty) EFI loader - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: - 1abf (XEN) RAM: 1ad88000 - 31ff (XEN) RAM: 32101000 - 3dff (XEN) RAM: 4000 - 4cfa3fff (XEN) RAM: 89cc - b03a3fff (XEN) RAM: b1af - b9af0fff (XEN) RAM: b9af1000 - b9af8fff (XEN) RAM: b9b09000 - b9bc (XEN) RAM: b9c7 - b9c71fff (XEN) RAM: b9c74000 - b9d5 (XEN) RAM: ba125000 - ba12bfff (XEN) RAM: ba12c000 - bd9b7fff (XEN) RAM: bd9b8000 - bd9b9fff (XEN) RAM: bd9ba000 - bd9c3fff (XEN) RAM: bd9c4000 - bef5 (XEN) RAM: bef6 - bf0e (XEN) RAM: bf0f - bf13 (XEN) RAM: bf19 - bf193fff (XEN) RAM: bf194000 - bfff (XEN) RAM: c000 - dfff (XEN) RAM: 0002 - 00021fff (XEN) (XEN) MODULE[0]: b03a4000 - b03b5000 Device Tree (XEN) MODULE[1]: b04be000 - b1975a00 Kernel console=tty0 console=hvc0 root=/dev/sdd10 rootwait rw rootfstype=ext4 efi=noruntime video=HDMI-A -1:1280x720@60 (XEN) (XEN) Command line: loglvl=all console=dtuart dtuart=/soc/serial@fff32000 dom0_mem=2048M efi=no-rs (XEN) parameter "efi" unknown! (XEN) Placing Xen at 0xdfe0-0xe000 (XEN) Update BOOTMOD_XEN from b03b5000-b04bdd81 => dfe0-dff08d81 (XEN) Domain heap initialised (XEN) Booting using Device Tree (XEN) Platform: Generic System (XEN) Looking for dtuart at "/soc/serial@fff32000", options "" Xen 4.11.1-pre (XEN) Xen version 4.11.1-pre (omkar.bolla@) (aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.05) 7.1.1 20170510) debug=n Mon Aug 20 15:11:16 IST 2018 (XEN) Latest ChangeSet: Mon Jul 30 11:30:09 2018 +0200 git:33ced72-dirty (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1122 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using SMC Calling Convention v1.1 (XEN) Using PSCI v1.1 (XEN) SMP: Allowing 8 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e82b1000 (XEN) gic_cpu_addr=e82b2000 (XEN) gic_hyp_addr=e82b4000 (XEN) gic_vcpu_addr=e82b6000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -9) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -9) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -9) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -9) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -9) (XEN) Bringing up CPU6 (XEN) Failed to bring up CPU6 (XEN) Failed to bring up CPU 6 (error -9) (XEN) Bringing up CPU7 (XEN) Failed to bring up CPU7 (XEN) Failed to bring up CPU 7 (error -9) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) I/O virtualisation disabled (XEN) build-id: 361a7d1197ce6c845658fa3210780d1751b7103a (XEN) alternatives: Patching with alt table 400acff8 -> 400ad568 (XEN) *** LOADING DOMAIN 0
[Xen-devel] [PATCH] osstest: setup git proxy for FreeBSD
Make the git proxy setup common by moving it into TestSupport and use
it for both Linux and FreeBSD.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
---
Osstest/TestSupport.pm | 20
ts-build-prep-freebsd | 1 +
ts-xen-build-prep | 19 ---
3 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ea546011..f8ef8233 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -138,6 +138,7 @@ BEGIN {
host_install_postboot_complete
target_core_dump_setup
sha256file host_shared_mark_ready
+ gitcache_setup
);
%EXPORT_TAGS = ( );
@@ -2903,4 +2904,23 @@ sub host_shared_mark_ready($$) {
$sharetype);
}
+sub gitcache_setup () {
+my $proxy = $c{GitCacheProxy};
+return unless $proxy;
+
+logm("setting up git cacheing proxy $proxy");
+
+my $gitcfg = '';
+foreach my $urlprefix (qw(git:// http:// https://)) {
+$gitcfg .= <{Flags}{'no-reinstall'}) {
determine_vg_lv();
lvcreate();
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC
Hello,
Thanks for having a look at it.
> The spec does not seems to provide the offset register. Where did you find
> them?
Actually, looked at couple of references from u-boot and Linux. These
headers are picked from there.
> AFAIK, {0} is not necessary.
Ok.
>> +
>> +#define meson_s905_read(uart, off) readl((uart)->regs + off)
>> +#define meson_s905_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>
>
> s/(uart->regs)/(uart)->regs/
>
>> +
>> +static void meson_s905_uart_interrupt(int irq, void *data,
>> +struct cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t st = meson_s905_read(uart, UART_STATUS);
>> +
>> +if ( !(st & UART_RX_EMPTY) )
>> +{
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +if ( !(st & UART_TX_FULL) )
>> +{
>> +if ( st & UART_TX_INT_EN )
>> +serial_tx_interrupt(port, regs);
>> +}
>> +
>
>
> NIT: No need for this newline.
>
>> +}
>> +
>> +static void __init meson_s905_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);
>
>
> I am not sure why you are clearing those bits. AFAIU, init_preirq will reset
> the serials, so you want to set thoses bits. This seems to be confirmed by
> Linux in meson_uart_reset.
Idea here is to set these bits to their default values(which is 0 ) and if you
look at other drivers in XEN, it seems to be done same thing(clear
those bits) with them.
>
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_INT_EN | UART_TX_INT_EN);
>> +meson_s905_write(uart, UART_CONTROL, reg);
>> +}
>> +
>> +static void __init meson_s905_uart_init_postirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +uart->irqaction.handler = meson_s905_uart_interrupt;
>> +uart->irqaction.name= "meson_s905_uart";
>> +uart->irqaction.dev_id = port;
>> +
>> +if ( setup_irq(uart->irq, 0, >irqaction) != 0 )
>> +{
>> +printk("Failed to allocated meson_s905_uart IRQ %d\n",
>> uart->irq);
>> +return;
>> +}
>> +
>> +/* Configure Rx/Tx interrupts based on bytes in FIFO */
>> +reg = meson_s905_read(uart, UART_MISC);
>
>
> You read UART_MISC here but ...
>
>> +reg = (UART_RECV_IRQ_CNT_MASK & 1) |
>
>
> ... override the value here. You either want to drop reading UART_MISC or
> add | here.
Sorry, missed "|" somehow.
>
>> + (UART_XMIT_IRQ_CNT_MASK & ((TX_FIFO_SIZE / 2) << 8));
>
>
> This is a bit difficult to read. It feels like you want to use a macro with
> a parameter that will do the correct masking.
Ok, shall I take it from Linux ?
>> +
>> +static const struct dt_device_match meson_dt_match[] __initconst =
>> +{
>> +DT_MATCH_COMPATIBLE("amlogic,meson-uart"),
>
>
> Looking at Linux, this is considered as a legacy bindings. Would not it be
> better to use stable bindings in Xen?
>
Yeah, I took it from u-boot source and didn't realize that there are
stable binding exists.
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] dmar: iommu mem leak fix
>>> On 20.08.18 at 05:32, wrote:
> Release memory allocated for drhd iommu in error path.
>
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Jan Beulich
But this needs a maintainer ack, and you didn't Cc him (now done).
Jan
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -100,6 +100,7 @@ static void __init disable_all_dmar_units(void)
> {
> list_del(>list);
> scope_devices_free(>scope);
> +iommu_free(drhd->iommu);
> xfree(drhd);
> }
> list_for_each_entry_safe ( rmrr, _rmrr, _rmrr_units, list )
> --
> 1.7.3
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] build: remove tboot make targets
>>> On 19.08.18 at 04:22, wrote: > The tboot targets are woefully out of date. These should really be > retired because setting up tboot is more complex than the build process > for it. > > Signed-off-by: Doug Goldstein Acked-by: Jan Beulich But I think you would better have Cc-ed the TXT/TBOOT maintainers (now done), as it was presumably them having introduced these targets. Even if the chance if high to not see any response, we should at least give them a chance to chime in. Jan > --- > Everyone knows my feeling about the Xen build system being a meta-distro > builder. This just removes something that never really belonged > integrated in the Xen build system. The best option would be > documentation instead of a make target to explain how to setup tboot > along with the necessary ACMs and the policy generation. But then again > tboot has its own docs covering that. The Linux kernel doesn't have a > make target for tboot so why should Xen? This is my rant while I tried > to keep the rant-y bits out of the commit message. > > --- > Makefile | 44 > README | 5 - > 2 files changed, 49 deletions(-) > > diff --git a/Makefile b/Makefile > index 1d43044033..d959cd5b47 100644 > --- a/Makefile > +++ b/Makefile > @@ -291,11 +291,6 @@ help: > @echo ' uninstall - attempt to remove installed Xen tools' > @echo ' (use with extreme care!)' > @echo > - @echo 'Trusted Boot (tboot) targets:' > - @echo ' build-tboot - download and build the tboot module' > - @echo ' install-tboot - download, build, and install the tboot > module' > - @echo ' clean-tboot - clean the tboot module if it exists' > - @echo > @echo 'Package targets:' > @echo ' src-tarball-release - make a source tarball with xen and > qemu > tagged with a release' > @echo ' src-tarball - make a source tarball with xen and > qemu > tagged with git describe' > @@ -324,46 +319,7 @@ uninstall-docs: > .PHONY: uninstall > uninstall: D=$(DESTDIR) > uninstall: uninstall-tools-public-headers $(TARGS_UNINSTALL) > - rm -rf $(D)/boot/tboot* > > .PHONY: xenversion > xenversion: > @$(MAKE) --no-print-directory -C xen xenversion > - > -# > -# tboot targets > -# > - > -TBOOT_TARFILE = tboot-20090330.tar.gz > -#TBOOT_BASE_URL = http://downloads.sourceforge.net/tboot > -TBOOT_BASE_URL = $(XEN_EXTFILES_URL) > - > -.PHONY: build-tboot > -build-tboot: download_tboot > - $(MAKE) -C tboot build > - > -.PHONY: install-tboot > -install-tboot: download_tboot > - $(MAKE) -C tboot install > - > -.PHONY: dist-tboot > -dist-tboot: download_tboot > - $(MAKE) DESTDIR=$(DISTDIR)/install -C tboot dist > - > -.PHONY: clean-tboot > -clean-tboot: > - [ ! -d tboot ] || $(MAKE) -C tboot clean > - > -.PHONY: distclean-tboot > -distclean-tboot: > - [ ! -d tboot ] || $(MAKE) -C tboot distclean > - > -.PHONY: download_tboot > -download_tboot: tboot/Makefile > - > -tboot/Makefile: tboot/$(TBOOT_TARFILE) > - [ -e tboot/Makefile ] || tar -xzf tboot/$(TBOOT_TARFILE) -C tboot/ > --strip-components 1 > - > -tboot/$(TBOOT_TARFILE): > - mkdir -p tboot > - wget -O tboot/$(TBOOT_TARFILE) $(TBOOT_BASE_URL)/$(TBOOT_TARFILE) > diff --git a/README b/README > index 4b95b21c7b..3a497fb064 100644 > --- a/README > +++ b/README > @@ -199,8 +199,3 @@ http://sourceforge.net/projects/tboot. This project > hosts the code in a > mercurial repo at http://tboot.sourceforge.net/hg/tboot.hg and contains > tarballs of the source. Instructions in the tboot README describe how > to modify grub.conf to use tboot to launch Xen. > - > -There are optional targets as part of Xen's top-level makefile that will > -download and build tboot: install-tboot, build-tboot, dist-tboot, > clean-tboot. > -These will download the latest tar file from the SourceForge site using > wget, > -then build/install/dist according to Xen's settings. > -- > 2.16.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear
>>> On 20.08.18 at 07:14, wrote:
> @@ -148,14 +150,14 @@ static inline void pud_clear(pud_t *pudp)
> #ifdef CONFIG_SMP
> static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
> {
> - pte_t res;
> + union {
> + pte_t pte;
> + long long val;
> + } res;
Why the union? pte_t already is one, with the pte field being what
you're after ...
> - /* xchg acts as a barrier before the setting of the high bits */
> - res.pte_low = xchg(>pte_low, 0);
> - res.pte_high = ptep->pte_high;
> - ptep->pte_high = 0;
> + res.val = arch_atomic64_xchg((atomic64_t *)ptep, 0);
... here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
On 2018/8/20 16:30, Jan Beulich wrote: On 20.08.18 at 05:32, wrote: When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather than the real table, so make it controled by config option based on the fact that we already have done the real zapping in tboot_parse_dmar_table(). Is this just a cosmetic change, or is there any harm done by the extra zapping? Cosmetic change, I feel it isn't necessory to zap a copy of DMAR table which is freed later. Thanks Zhenzhong As said above, acpi_parse_dmar() doesn't zaps APCI DMAR signature in real TXT heap table, fix the stale comments. Signed-off-by: Zhenzhong Duan --- xen/arch/x86/tboot.c |3 +-- xen/drivers/passthrough/vtd/dmar.c |2 ++ 2 files changed, 3 insertions(+), 2 deletions(-) You've again failed to Cc maintainers (included now). Jan --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -490,8 +490,7 @@ int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler) rc = dmar_handler(dmar_table); xfree(dmar_table); -/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */ -/* but dom0 will read real table, so must zap it there too */ +/* Dom0 will read real DMAR table, so must zap it there */ acpi_dmar_zap(); return rc; --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -866,8 +866,10 @@ static int __init acpi_parse_dmar(struct acpi_table_header *table) } out: +#ifndef CONFIG_TBOOT /* Zap ACPI DMAR signature to prevent dom0 using vt-d HW. */ acpi_dmar_zap(); +#endif return ret; } ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/15] xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h
Hi Stefano, On Thu, 16 Aug 2018, 19:17 Stefano Stabellini, wrote: > On Thu, 16 Aug 2018, Julien Grall wrote: > > Hi Stefano, > > > > On 08/14/2018 10:43 PM, Stefano Stabellini wrote: > > > On Mon, 16 Jul 2018, Julien Grall wrote: > > > > GUEST_BUG_ON may be used in other files doing guest emulation. > > > > > > > > Signed-off-by: Julien Grall > > > > > > Given that GUEST_BUG_ON is not actually used in any other files in this > > > patch series, I assume you are referring to one of your future series? > > > > It is going to be used later. However, I don't really refer to any > series in > > particular. It is just that this macros could be helpful in any > emulation code > > to catch what we think is a invalid architectural behavior. > > It is only that a concrete use-case helps. The idea of moving > GUEST_BUG_ON is good, but where to? For instance, wouldn't it be better > to move it to guest_access.h? I am just trying to point to an existing > header which is more widely used across the emulators (vpl011, > vgic-v3-its.c, hvm.c, ...) > Definitely not in guest_access.h or any wider in includes. If you look at the implementation and documentation, it will crash the hypervisor because the goal is to catch hardware bug or misunderstanding of the spec. This is not meant to be used in emulation. We should not crash the guest/hypervisor in bad behavior but inject an exception. So trap.h is the best places for it as hardware trap are now split accros multiples files. Cheers, ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 270 v3 (CVE-2018-15471) - Linux netback driver OOB access in hash handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15471 / XSA-270 version 3 Linux netback driver OOB access in hash handling UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Linux's netback driver allows frontends to control mapping of requests to request queues. When processing a request to set or change this mapping, some input validation was missing or flawed. IMPACT == A malicious or buggy frontend may cause the (usually privileged) backend to make out of bounds memory accesses, potentially resulting in one or more of privilege escalation, Denial of Service (DoS), or information leaks. VULNERABLE SYSTEMS == Linux kernel versions from 4.7 onwards are affected. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Felix Wilhelm of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa270.patch Linux 4.7 ... 4.17 $ sha256sum xsa270* 392868c37c1fe0d16c36086208fd0fc045c1baf8ab9b207995bce72681cb8c54 xsa270.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4MAAoJEIP+FMlX6CvZOpsH/34RpIZaTTVsZWCVyNotieFf yLfCqu+9bbRVNEqYDq6NViFrj9I6WwvLpp8s7HZheJvdXlyIO1cYCen4QX8VSPqI VaRD7Jcu99drK1hy/t80AbicS+t9qvew97SzjG+MIIJZK7dnxG/Q0nbHLCg0zdCg 5G+pOTl17DK+4eM7Z1duo2BK1sxCms6I/YJVFfkGjC99vXKYAj2GAWGxVbiEwDWT 4jvf3R3w5athJNR4Lf6FxDz6MzvHaYNFQKikc0AMaTcO5HubumGXQQn5JQelAAno O6ujB25kF1j29A2PwYvBSxBDTD4uWQeWiv9kWML1YmzsQv1cy6Un0vwXtNhhb6s= =SC+y -END PGP SIGNATURE- xsa270.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 272 v3 (CVE-2018-15470) - oxenstored does not apply quota-maxentity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15470 / XSA-272 version 3 oxenstored does not apply quota-maxentity UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual: http://caml.inria.fr/pub/docs/manual-ocaml/expr.html the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. IMPACT == oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS. VULNERABLE SYSTEMS == Xen 4.1 and later are potentially vulnerable. Only systems using the OCaml xenstored implementation are potentially vulnerable. Systems using the C xenstored implementation are not vulnerable. Whether the compiled oxenstored binary is vulnerable depends on which compiler was used. OCaml can be compiled either as bytecode (with ocamlc) or as a native binary (with ocamlopt). The following OCaml program demonstrates the issue, and identifies whether the resulting oxenstored binary will skip the quota enforcement. $ cat order.ml let check () = let flag = ref false in let update _ = flag := true; () in List.iter update [1;2;3], !flag let main () = let _, flag = check () in if flag then print_endline "This code is not vulnerable!" else print_endline "This code is vulnerable!" let () = main () $ ocamlc order.ml -o order.bytecode $ ./order.bytecode This code is vulnerable! $ ocamlopt order.ml -o order.native $ ./order.native This code is not vulnerable! To confirm whether an OCaml binary is bytecode or native, use file. $ file order.bytecode order.bytecode: a /usr/bin/ocamlrun script executable (binary data) $ file order.native order.native: ELF 64-bit LSB executable, ... NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in Debian Jessie. These results are not representative of other versions of OCaml, or of other OS distributions. MITIGATION == There are no mitigations available. CREDITS === This issue was discovered by Christian Lindig of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa272.patch All versions of Xen $ sha256sum xsa272* 0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e xsa272.meta 6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c xsa272.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4OAAoJEIP+FMlX6CvZCO8H/Rj7Z+rFSuQAVEUKXvvV3lvJ rytocZDTAIduyiBundcbdkcxfCuun6Tqw8ScPJXtml82P8YE+R/ix1hMLcQdYblt tj3qftb6KtjFibctoc0sSLsfjhl2oJC2VjQR3HdixfMlSxEzLkCC3I21fteYs9fp ahO7dByNHFTufbb9GpB+DANmIJ5hwMXxCinvts/L2MP/CCRfb4w5+aTARCQ3UHpX 3/r2wJxLnf4sNpBhHNsArROy8wS+ad0i4XC2fef/Bdye+NRbeICJNqof9fcGjWwE fZRyeNVSk33DuuRz2HI4aoEKAQ/v3b3KLXnfVZY5F5z6Z8j9rie42RI8VDO8Mzc= =Y10L -END PGP SIGNATURE- xsa272.meta Description: Binary data xsa272.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 269 v3 (CVE-2018-15468) - x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15468 / XSA-269 version 3 x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The DEBUGCTL MSR contains several debugging features, some of which virtualise cleanly, but some do not. In particular, Branch Trace Store is not virtualised by the processor, and software has to be careful to configure it suitably not to lock up the core. As a result, it must only be available to fully trusted guests. Unfortunately, in the case that vPMU is disabled, all value checking was skipped, allowing the guest to chose any MSR_DEBUGCTL setting it likes. IMPACT == A malicious or buggy guest administrator can lock up the entire host, causing a Denial of Service. VULNERABLE SYSTEMS == Xen versions 4.6 and later are vulnerable. Only systems using Intel CPUs are affected. ARM and AMD systems are unaffected. Only x86 HVM or PVH guests can exploit the vulnerability. x86 PV guests cannot exploit the vulnerability. MITIGATION == Running only x86 PV guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa269.patch xen-unstable xsa269-4.11.patch Xen 4.11 xsa269-4.10.patch 4.10, 4.9 xsa269-4.8.patch Xen 4.8, 4.7, 4.6 $ sha256sum xsa269* 4733d09bb63523744ca2ee172e2fade0c39082c15d9a746144f279cf1359b723 xsa269.meta 5a5fe36f1f876a5029493e7fa191436fd021929aaba2d820636df17f4ed20113 xsa269.patch ea11cef818050bca13d4eb89294627c97e4cdb830124f679e77d37a44a370286 xsa269-4.8.patch 45ba1823530f329dd73088b77098e686b32f5daac0bc5177b2afea09f8c3593a xsa269-4.10.patch e0ca060311fb9ba3247e2fe65bca4806a131644f8894fd08be374904904b1944 xsa269-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4KAAoJEIP+FMlX6CvZfakIAJRgw9LWW7fnr0WX11dt/Rm1 GgBxMWS7DrnBPBjE7GqhtqgFyvIVHBnWEEj1WW1WvHWIV/XIbV8GKOi6ecfF5p3o vK/a/8S0qOSOtOPZZJkZGuZn6pNd9V0Ynx296Hn6DKildBBEkGSXoWo67ViaxrP2 iPzhYukDRYlqjF5pYfPr7Zek+RodtB+rxJEKMpDDIW8aeA3hnsOZNXAmr5n+Q465 rNojqJDV5Zwuli+L0SVzmtkY6dbeXyhMWn3zAj8a5Pq+/VkK3PdcEBVNADLXbh3a lnDmjwsY9ZX64HhXbamFMV1Wykhbjb+Jprj6CJjuz4wcGArKW+lsTV86p8Q5Kzk= =uYjg -END PGP SIGNATURE- xsa269.meta Description: Binary data xsa269.patch Description: Binary data xsa269-4.8.patch Description: Binary data xsa269-4.10.patch Description: Binary data xsa269-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 268 v3 (CVE-2018-15469) - Use of v2 grant tables may cause crash on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15469 / XSA-268 version 3 Use of v2 grant tables may cause crash on ARM UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. IMPACT == An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service. VULNERABLE SYSTEMS == Only ARM systems are vulnerable. All supported versions of Xen are vulnerable. MITIGATION == None. CREDITS === This issue was discovered by 王磊 of Samsung. RESOLUTION == Applying the appropriate attached patch resolves this issue by preventing a guest from switching to grant v2. xsa268.patch xen-unstable xsa268-4.11.patch Xen 4.11.0 xsa268-4.10-?.patchXen 4.10.x xsa268-4.9-?.patch Xen 4.9.x, Xen 4.8.x xsa268-4.7-?.patch Xen 4.7.x xsa268-4.6-?.patch Xen 4.6.x $ sha256sum xsa268* f336b45676e73f8b102e5dddf78af2d1d288f9a254142a8a8e9949db55e1cc3b xsa268.meta ca5f69cb8cfb74fae44a0f39f80ec9ae4d269c4895f36311b50d191be97bbcf0 xsa268.patch 93a68a5b23aedc6adf0aae23303dc8eb2c02dc40a5e1d7eb0a1b497cd66da209 xsa268-4.6-1.patch 5b74afd13d96779a72dc34ba7c63a1735cd267fb9bb643f735ac69b0e6ff54d5 xsa268-4.6-2.patch 820e1018f76ef2828b1cbb33e2966b99f6934a80ab55f11749ff847d375d1b02 xsa268-4.7-1.patch 233f7e69e5fb931d2e5cf03f4407f38ff960c039c9eced957df13d3cc37fa6b1 xsa268-4.7-2.patch 4a0c705f0266185b32daf313e686abc340e2fbb1a1644647500fc405bc180913 xsa268-4.9-1.patch ce16eaab94cd1e64f9c9127b64da7ebb6a7758eb540fecc3bbcc2dbfbcc4d7e2 xsa268-4.9-2.patch f413d41fadefe0e275c8bff16a2061bb325f3900b7ccf214a9e97fabf3ee1a89 xsa268-4.10-1.patch 531654f82908c1aa7b0fcea818c82c4b53d4750a697db3353cc05e9e91e5d639 xsa268-4.10-2.patch baeb6b2c28a9cbe929c9cf34398780002fffe12b928df4d1e5951c0a5b51336a xsa268-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4HAAoJEIP+FMlX6CvZxYMH/R1pB/0Qh+eYJevI0XZCh0TX TlzPkzvTkif3JUfYtms1rVeXdAUoOaZPrMpzZYFWthOHhHR6Y8tiBWxiRGWuEf0a OaAYTebIQN4U69AUXGaXdA1p1Nnix5guOgljM1EHD3LGEBtadzdYdFfpKrEv1F7L f8fwLULljcfwHKI7Yv/CwGdRAt2YrtIFqry916yc0RHk2nQpLvX8V+8YXWla8zGR 1Vkin0WoR31qkcakJGXO8jXD1Wpn4J+2lAyMpAiPpN7d8F7/cEOj7huRuTkYFQha /sTUc5Dy3kniLptJF+2//dLOjwKQKSKd3c8LJjc8IGPCwfpNpVmLaCiB/93AcWk= =yh+i -END PGP SIGNATURE- xsa268.meta Description: Binary data xsa268.patch Description: Binary data xsa268-4.6-1.patch Description: Binary data xsa268-4.6-2.patch Description: Binary data xsa268-4.7-1.patch Description: Binary data xsa268-4.7-2.patch Description: Binary data xsa268-4.9-1.patch Description: Binary data xsa268-4.9-2.patch Description: Binary data xsa268-4.10-1.patch Description: Binary data xsa268-4.10-2.patch Description: Binary data xsa268-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
On Fri, Aug 17, 2018 at 12:42:31AM -0600, Jan Beulich wrote:
> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
> uniformly invoked from outside of them. They're no longer getting called
> for non-present PTEs. This way the slightly odd three-way return value
> meaning of the higher level ones can also be got rid of.
>
> Introduce local variables holding the page table entries processed, and
> use them throughout the loop bodies instead of re-reading them from the
> page table several times.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -900,8 +900,11 @@ get_page_from_l1e(
> struct domain *real_pg_owner;
> bool write;
>
> -if ( !(l1f & _PAGE_PRESENT) )
> +if ( unlikely(!(l1f & _PAGE_PRESENT)) )
> +{
> +ASSERT_UNREACHABLE();
> return 0;
> +}
Why is this needed here? According to commit message get_page_from_l1e
shouldn't be called with non-present l1e.
Going through the code, both of the shadow path and (post-modification)
pv mm path won't call get_page_from_l1e with non-present l1e AFAICT.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
On 20/08/2018 09:30, Jan Beulich wrote: On 20.08.18 at 05:32, wrote: >> When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather >> than the real table, so make it controled by config option based on the >> fact that we already have done the real zapping in tboot_parse_dmar_table(). > Is this just a cosmetic change, or is there any harm done by the extra > zapping? Before 123c7793797502b222300eb710cd3873dcca41ee, calling it multiple times would require an equivalent number of reinstate calls for it to work. That change went into Xen 4.6, whereas I guess this is a patch being upstreamed from Oracles 4.4 patchqueue? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/dmar: zap DMAR signature for dom0 once in TBOOT case
>>> On 20.08.18 at 10:40, wrote: > On 2018/8/20 16:30, Jan Beulich wrote: > On 20.08.18 at 05:32, wrote: >>> When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather >>> than the real table, so make it controled by config option based on the >>> fact that we already have done the real zapping in tboot_parse_dmar_table(). >> >> Is this just a cosmetic change, or is there any harm done by the extra >> zapping? > Cosmetic change, I feel it isn't necessory to zap a copy of DMAR table > which is freed later. In which case please clarify this in the description. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf
ping
On 07/23/2018 03:27 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add support for Linux grant device driver extension which allows
converting existing dma-buf's into an array of grant references
and vise versa. This is only implemented for Linux as other OSes
have no Linux dma-buf support.
Bump gnttab library minor version to 3.
Signed-off-by: Oleksandr Andrushchenko
---
tools/include/xen-sys/Linux/gntdev.h | 106
tools/libs/gnttab/Makefile| 2 +-
tools/libs/gnttab/gnttab_core.c | 26 ++
tools/libs/gnttab/gnttab_unimp.c | 26 ++
tools/libs/gnttab/include/xengnttab.h | 61 ++
tools/libs/gnttab/libxengnttab.map| 8 ++
tools/libs/gnttab/linux.c | 113 ++
tools/libs/gnttab/minios.c| 26 ++
tools/libs/gnttab/private.h | 13 +++
9 files changed, 380 insertions(+), 1 deletion(-)
diff --git a/tools/include/xen-sys/Linux/gntdev.h
b/tools/include/xen-sys/Linux/gntdev.h
index 0ca07c92b21c..d16076044c71 100644
--- a/tools/include/xen-sys/Linux/gntdev.h
+++ b/tools/include/xen-sys/Linux/gntdev.h
@@ -4,6 +4,7 @@
* Interface to /dev/xen/gntdev.
*
* Copyright (c) 2007, D G Murray
+ * Copyright (c) 2018, Oleksandr Andrushchenko, EPAM Systems Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License version 2
@@ -168,4 +169,109 @@ struct ioctl_gntdev_grant_copy {
struct ioctl_gntdev_grant_copy_segment *segments;
};
+/*
+ * Flags to be used while requesting memory mapping's backing storage
+ * to be allocated with DMA API.
+ */
+
+/*
+ * The buffer is backed with memory allocated with dma_alloc_wc.
+ */
+#define GNTDEV_DMA_FLAG_WC (1 << 0)
+
+/*
+ * The buffer is backed with memory allocated with dma_alloc_coherent.
+ */
+#define GNTDEV_DMA_FLAG_COHERENT (1 << 1)
+
+/*
+ * Create a dma-buf [1] from grant references @refs of count @count provided
+ * by the foreign domain @domid with flags @flags.
+ *
+ * By default dma-buf is backed by system memory pages, but by providing
+ * one of the GNTDEV_DMA_FLAG_XXX flags it can also be created as
+ * a DMA write-combine or coherent buffer, e.g. allocated with dma_alloc_wc/
+ * dma_alloc_coherent.
+ *
+ * Returns 0 if dma-buf was successfully created and the corresponding
+ * dma-buf's file descriptor is returned in @fd.
+ *
+ * [1]
https://elixir.bootlin.com/linux/latest/source/Documentation/driver-api/dma-buf.rst
+ */
+
+#define IOCTL_GNTDEV_DMABUF_EXP_FROM_REFS \
+_IOC(_IOC_NONE, 'G', 9, \
+ sizeof(struct ioctl_gntdev_dmabuf_exp_from_refs))
+struct ioctl_gntdev_dmabuf_exp_from_refs {
+/* IN parameters. */
+/* Specific options for this dma-buf: see GNTDEV_DMABUF_FLAG_XXX. */
+uint32_t flags;
+/* Number of grant references in @refs array. */
+uint32_t count;
+/* OUT parameters. */
+/* File descriptor of the dma-buf. */
+uint32_t fd;
+/* The domain ID of the grant references to be mapped. */
+uint32_t domid;
+/* Variable IN parameter. */
+/* Array of grant references of size @count. */
+uint32_t refs[1];
+};
+
+/*
+ * This will block until the dma-buf with the file descriptor @fd is
+ * released. This is only valid for buffers created with
+ * IOCTL_GNTDEV_DMABUF_EXP_FROM_REFS.
+ *
+ * If withing @wait_to_ms milliseconds the buffer is not released
+ * then -ETIMEDOUT error is returned.
+ * If the buffer with file descriptor @fd does not exist or has already
+ * been released, then -ENOENT is returned. For valid file descriptors
+ * this must not be treated as error.
+ */
+#define IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED \
+_IOC(_IOC_NONE, 'G', 10, \
+ sizeof(struct ioctl_gntdev_dmabuf_exp_wait_released))
+struct ioctl_gntdev_dmabuf_exp_wait_released {
+/* IN parameters */
+uint32_t fd;
+uint32_t wait_to_ms;
+};
+
+/*
+ * Import a dma-buf with file descriptor @fd and export granted references
+ * to the pages of that dma-buf into array @refs of size @count.
+ */
+#define IOCTL_GNTDEV_DMABUF_IMP_TO_REFS \
+_IOC(_IOC_NONE, 'G', 11, \
+ sizeof(struct ioctl_gntdev_dmabuf_imp_to_refs))
+struct ioctl_gntdev_dmabuf_imp_to_refs {
+/* IN parameters. */
+/* File descriptor of the dma-buf. */
+uint32_t fd;
+/* Number of grant references in @refs array. */
+uint32_t count;
+/* The domain ID for which references to be granted. */
+uint32_t domid;
+/* Reserved - must be zero. */
+uint32_t reserved;
+/* OUT parameters. */
+/* Array of grant references of size @count. */
+uint32_t refs[1];
+};
+
+/*
+ * This will close all references to an imported buffer, so it can be
+ * released by the owner. This is only valid for buffers created with
+ * IOCTL_GNTDEV_DMABUF_IMP_TO_REFS.
+ */
+#define IOCTL_GNTDEV_DMABUF_IMP_RELEASE \
+_IOC(_IOC_NONE, 'G',
[Xen-devel] [qemu-mainline test] 126174: regressions - FAIL
flight 126174 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/126174/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 6 xen-installfail REGR. vs. 125959 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125959 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125959 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125959 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125959 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125959 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu0abaa41d936becd914a16ee1fe2a981d96d19428 baseline version: qemuuc542a9f9794ec8e0bc3fcf5956d3cc8bce667789 Last test of basis 125959 2018-08-16 09:56:58 Z3 days Testing same since 126174 2018-08-18 17:10:28 Z1 days1 attempts People who touched revisions under test: Aleksandar Markovic Aleksandar Rikalo Alex Bennée Alistair Francis Cédric Le Goater Daniel P. Berrangé Eduardo Habkost Jean-Christophe Dubois Joel Stanley Laurent Desnogues Peter Maydell Richard Henderson Richard W.M. Jones Robert Hoo Stefan Hajnoczi Stefan Markovic Stefan Markovic Su Hang Thomas Huth Trent Piepho Wanpeng Li Yongbok Kim jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm
Re: [Xen-devel] [PATCH 2/2] x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear
On 20/08/18 10:40, Jan Beulich wrote:
On 20.08.18 at 07:14, wrote:
>> @@ -148,14 +150,14 @@ static inline void pud_clear(pud_t *pudp)
>> #ifdef CONFIG_SMP
>> static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
>> {
>> -pte_t res;
>> +union {
>> +pte_t pte;
>> +long long val;
>> +} res;
>
> Why the union? pte_t already is one, with the pte field being what
> you're after ...
>
>> -/* xchg acts as a barrier before the setting of the high bits */
>> -res.pte_low = xchg(>pte_low, 0);
>> -res.pte_high = ptep->pte_high;
>> -ptep->pte_high = 0;
>> +res.val = arch_atomic64_xchg((atomic64_t *)ptep, 0);
>
> ... here.
Uuh, yes.
I'm waiting for more comments, especially regarding the potential need
for a paravirt function.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
