[Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area
From: Matt Wilson
... as it is very helpful to diagnose VM entry failures due to MSR
loading.
Signed-off-by: Matt Wilson
---
xen/arch/x86/hvm/vmx/vmcs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 1bd875a..a540d4e 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim)
printk("%s:%08x %016"PRIx64"\n", name, limit, base);
}
+static void vmx_dump_vcpu_msr_area(struct vcpu *v)
+{
+const struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
+unsigned int i, msr_count = v->arch.hvm_vmx.msr_count;
+
+printk(" msr_count = %d\n", v->arch.hvm_vmx.msr_count);
+for ( i = 0; i < msr_count; i++ )
+{
+printk(" msr_area[%d].index=0x%08x .data=0x%016lx\n",
+ i, msr_area[i].index, msr_area[i].data);
+}
+}
+
+
void vmcs_dump_vcpu(struct vcpu *v)
{
struct cpu_user_regs *regs = &v->arch.user_regs;
@@ -1879,6 +1893,13 @@ void vmcs_dump_vcpu(struct vcpu *v)
(SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
+printk("EXIT MSR load count = 0x%04x\n",
+ (uint32_t)vmr(VM_EXIT_MSR_LOAD_COUNT));
+printk("EXIT MSR store count = 0x%04x\n",
+ (uint32_t)vmr(VM_EXIT_MSR_STORE_COUNT));
+printk("ENTRY MSR load count = 0x%04x\n",
+ (uint32_t)vmr(VM_ENTRY_MSR_LOAD_COUNT));
+vmx_dump_vcpu_msr_area(v);
vmx_vmcs_exit(v);
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk
From: Matt Wilson
Systems that support LBR formats that include TSX information but do
not support TSX require special handling when saving and restoring MSR
values. For example, see the Linux kernel quirks[1, 2] in the MSR
context switching code. As a wrmsr with certain values under these
conditions causes a #GP, VM entry will fail due to MSR loading (see
last bullet of SDM 26.4 "Loading MSRS").
This failure can be triggered on a Haswell-EP system with the
following test Linux kernel module:
In domU:
$ cat > lbr.c << EOF
static int __init
lbr_init(void)
{
u64 val;
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
val |= DEBUGCTLMSR_LBR;
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
return 0;
}
static void __exit
lbr_cleanup(void)
{
}
module_init(lbr_init);
module_exit(lbr_cleanup);
MODULE_DESCRIPTION("lbr test");
MODULE_LICENSE("GPL");
EOF
$ echo "obj-m += lbr.o" > Makefile
$ make -C /lib/modules/`uname -r`/build M=`pwd` modules
make: Entering directory `/home/ec2-user/linux'
CC [M] /home/ec2-user/lbr.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/ec2-user/lbr.mod.o
LD [M] /home/ec2-user/lbr.ko
make: Leaving directory `/home/ec2-user/linux'
$ sudo insmod lbr.ko
$ Timeout, server not responding.
In dom0:
[...]
(XEN) Failed vm entry (exit reason 0x8022) caused by MSR entry 1 loading.
[...]
(XEN) EXIT MSR load count = 0x0001
(XEN) EXIT MSR store count = 0x0023
(XEN) ENTRY MSR load count = 0x0023
(XEN) msr_count = 35
(XEN) msr_area[0].index=0x01dd .data=0x1fff811911db
...
This change dynamically disables LBR save/load on systems in the
problematic configuration.
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=71adae99ed18
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19fc9ddd61e0
Signed-off-by: Matt Wilson
---
xen/arch/x86/hvm/vmx/vmx.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..c51cefc 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2576,8 +2576,22 @@ static const struct lbr_info *last_branch_msr_get(void)
/* Haswell */
case 60: case 63: case 69: case 70:
/* Broadwell */
-case 61: case 71: case 79: case 86:
+case 61: case 71: case 79: case 86: {
+u64 caps;
+bool_t tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
+ boot_cpu_has(X86_FEATURE_RTM);
+
+rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+/*
+ * Unimplemented fixups are required if the processor
+ * supports an LBR format that includes TSX information,
+ * but not TSX. Disable LBR save/load on such platforms.
+ */
+if ( !tsx_support && (caps & 4) )
+return NULL;
+
return nh_lbr;
+}
/* Skylake */
case 78: case 94:
/* future */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 100372: regressions - FAIL
flight 100372 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 99832 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 99832 build-amd64-rumpuserxen 6 xen-buildfail like 99832 build-i386-rumpuserxen6 xen-buildfail like 99832 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99832 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99832 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99832 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux6e0f6268e3d1095a1800da36261d40ac53a7100c baseline version: linux0d1097ae44c2566bb8c9eacccd795c456d08c8a5 Last test of basis99832 2016-07-30 16:32:07 Z 10 days Testing same since 100372 2016-08-09 19:20:24 Z0 days1 attempts People who touched revisions under test: Alexey Dobriyan Andrew Morton Andrew Worsley # [MacBookPro10,1] Andrey Ryabinin Awais Belal Bryan Paradis# [MacBookPro9,2] Cameron Gutman Chris Bainbridge # [MacBookPro10,2] David S. Miller Dmitri Epshtein Dmitry Torokhov Florian Westphal Gregory CLEMENT Hui Wang Ilya Dryomov Ingo Molnar James Patrick-Evans Jeff Wu Jiri Slaby Konstantin Khlebnikov Konstantin Simanov # [MacBookPro8,1] Linus Torvalds Lukas Wunner Lukas Wunner # [MacBookPro9,1] Marcin Wojtas Maruthi Bayyavarapu Maruthi Srinivas Bayyavarapu Matt Fleming Maxim Patlasov Miklos Szeredi Pablo Neira Ayuso Peter Wu RafaÅ MiÅecki Rodolfo Giometti Romain Perier Sasha Levin Sinclair Yeh Takashi Iwai Taras Kondratiuk Terry Stockert Thomas Gleixner Thomas Petazzoni Ulf Hansson Vivek Goyal Willy Tarreau Yan, Zheng jobs: build
[Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order for the current vCPU to not get stuck. A consequence of this is that the custom vm_event response handlers will not always see the real vCPU state in v->arch.user_regs. This patch makes sure that the state is always synchronized in vm_event_resume, before any handlers have been called. This problem especially affects vm_event_set_registers(). Signed-off-by: Razvan Cojocaru --- Changes since V1: - Only call sync_vcpu_execstate() when the vCPU is paused. --- xen/common/vm_event.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 941345b..53cab90 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved) v = d->vcpu[rsp.vcpu_id]; /* + * Make sure the vCPU state has been synchronized for the custom + * handlers. + */ +if ( atomic_read(&v->vm_event_pause_count) ) +sync_vcpu_execstate(v); + +/* * In some cases the response type needs extra handling, so here * we call the appropriate handlers. */ -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] xl dump-core fails, j!=nr_pages
With staging-4.7 'xl dump-core hvm.cfg file' fails: root@macintyre-old:~ # xl - create -cdVf hvm.cfg ... wait ... root@macintyre-old:~ # xl dump-core x x.dump xc: info: j (63635) != nr_pages (65709) hvm.cfg: name="x" description="y" uuid="0529a09c-2430-48e5-8c09-085d4e2380a8" memory=1024 memory=256 serial="pty" builder="hvm" boot="cd" disk=[ 'file:/disk0.raw,hda,w', 'file:/Media1.iso,hdc:cdrom,r', ] vif=[ 'bridge=br0' ] keymap="de" vfb = [ 'type=vnc,vncunused=1,keymap=de' ] usb=1 usbdevice='tablet' root@macintyre-old:~ # xl info host : macintyre-old release: 3.12.59-60.45-xen version: #1 SMP Sat Jun 25 06:19:03 UTC 2016 (396c69d) machine: x86_64 nr_cpus: 4 max_cpu_id : 15 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2000 hw_caps: b7ebfbff:009ce3bd:28100800:0001::::0100 virt_caps : hvm total_memory : 6135 free_memory: 0 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 7 xen_extra : .20160726T13082 xen_version: 4.7.20160726T13082 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : 2016-07-26 14:08:29 +0100 git:899495b xen_commandline: console=com1 com1=57600 loglvl=all guest_loglvl=all cc_compiler: gcc (SUSE Linux) 4.8.5 cc_compile_by : abuild cc_compile_domain : cc_compile_date: Tue Jul 26 14:08:29 UTC 2016 build_id : b8d2712feab8b81a845316485f986da952d44f73 xend_config_format : 4 Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 100376: all pass - PUSHED
flight 100376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100376/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
baseline version:
ovmf 1fbd0ca16a997b68ed320340aef18645e71e8a73
Last test of basis 100364 2016-08-09 10:43:23 Z0 days
Testing same since 100376 2016-08-10 02:45:14 Z0 days1 attempts
People who touched revisions under test:
Ruiyu Ni
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ branch=ovmf
+ revision=5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x5aeafb3a254e7cd9e1fb69a0d391388a51c6e210 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419
[Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
flight 100382 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100382/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 100365 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 baseline version: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc Last test of basis 100365 2016-08-09 15:01:57 Z0 days Testing same since 100368 2016-08-09 17:01:23 Z0 days7 attempts People who touched revisions under test: Boris Ostrovsky George Dunlap Jan Beulich jobs: build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt 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 http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 Author: Jan Beulich Date: Tue Aug 9 17:31:46 2016 +0200 common: clean up taint logic Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments. Signed-off-by: Jan Beulich Acked-by: George Dunlap commit bea437908b27c751012abe14c4312dd4d159ff23 Author: Boris Ostrovsky Date: Tue Aug 9 17:31:15 2016 +0200 hvmloader: move passthrough initialization from ACPI code Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read() Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 653d8fb95adc81dc2fbc3594bd63519f68271dc2 Author: Boris Ostrovsky Date: Tue Aug 9 17:30:56 2016 +0200 hvmloader: decide which SSDTs to install in hvmloader With that, xenstore_read() won't need to be done in ACPI code Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 3bb36fe2aa2c590e52578a6ea65ba992178ef82b Author: Boris Ostrovsky Date: Tue Aug 9 17:30:39 2016 +0200 hvmloader: initialize vm_gid data outside ACPI code This way ACPI code won't use xenstore-read() and hvm_param_set() which are private to hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit c15eea2a1e719577af83bddf793a3a5329ce395d Author: Boris Ostrovsky Date: Tue Aug 9 17:28:59 2016 +0200 acpi/hvmloader: allow acpi_build_tables() callers specify acpi_info values By doing this we can move hvmloader-private interfaces (such as uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will help us with allowing to call the builder from places other than hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit edd0028206d14c25ddee2357dca08441ff13cea1 Author: Boris Ostrovsky Date: Tue Aug 9 17:27:39 2016 +0200 hvmloader: provide hvmloader_acpi_build_tables() In preparation for moving out ACPI builder make all BIOSes call hvmloader_acpi_build_tables() instead of calling ACPI code directly. No functional changes. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 66949: tolerable FAIL
This run is configured for baseline tests only. flight 66949 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66949/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66941 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu53279c76cf071fed07a336948d37c72e3613e0b7 baseline version: qemuu51009170d8fc263cfdcd5a60fe3ba213daa3d15b Last test of basis66941 2016-08-08 21:46:46 Z1 days Testing same since66949 2016-08-09 10:47:08 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Cornelia Huck David Gibson John Snow Kevin Wolf Marc-André Lureau Mark Cave-Ayland Markus Armbruster Peter Maydell Richard Henderson Vladimir Sementsov-Ogievskiy Yi Min Zhao jobs: build-amd64-xsm pass build-armhf-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-
[Xen-devel] [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online. As the result, kdump
routines fail to save other CPUs' registers. Additionally for MIPS
OCTEON, it misses to stop the watchdog timer.
To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a
weak function, and it just call smp_send_stop(). Architecture
codes should override it so that kdump can work appropriately.
This patch provides MIPS version.
Reported-by: Daniel Walker
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai
Cc: Ralf Baechle
Cc: David Daney
Cc: Aaro Koskinen
Cc: "Steven J. Hill"
Cc: Corey Minyard
---
I'm not familiar with MIPS, and I don't have a test environment and
just did build tests only. Please don't apply this patch until
someone does enough tests, otherwise simply drop this patch.
---
arch/mips/cavium-octeon/setup.c | 14 ++
arch/mips/include/asm/kexec.h|1 +
arch/mips/kernel/crash.c | 18 +-
arch/mips/kernel/machine_kexec.c |1 +
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index cb16fcc..5537f95 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -267,6 +267,17 @@ static void octeon_crash_shutdown(struct pt_regs *regs)
default_machine_crash_shutdown(regs);
}
+#ifdef CONFIG_SMP
+void octeon_crash_smp_send_stop(void)
+{
+ int cpu;
+
+ /* disable watchdogs */
+ for_each_online_cpu(cpu)
+ cvmx_write_csr(CVMX_CIU_WDOGX(cpu_logical_map(cpu)), 0);
+}
+#endif
+
#endif /* CONFIG_KEXEC */
#ifdef CONFIG_CAVIUM_RESERVE32
@@ -911,6 +922,9 @@ void __init prom_init(void)
_machine_kexec_shutdown = octeon_shutdown;
_machine_crash_shutdown = octeon_crash_shutdown;
_machine_kexec_prepare = octeon_kexec_prepare;
+#ifdef CONFIG_SMP
+ _crash_smp_send_stop = octeon_crash_smp_send_stop;
+#endif
#endif
octeon_user_io_init();
diff --git a/arch/mips/include/asm/kexec.h b/arch/mips/include/asm/kexec.h
index ee25ebb..493a3cc 100644
--- a/arch/mips/include/asm/kexec.h
+++ b/arch/mips/include/asm/kexec.h
@@ -45,6 +45,7 @@ extern const unsigned char kexec_smp_wait[];
extern unsigned long secondary_kexec_args[4];
extern void (*relocated_kexec_smp_wait) (void *);
extern atomic_t kexec_ready_to_reboot;
+extern void (*_crash_smp_send_stop)(void);
#endif
#endif
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c
index 610f0f3..1723b17 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -47,9 +47,14 @@ static void crash_shutdown_secondary(void *passed_regs)
static void crash_kexec_prepare_cpus(void)
{
+ static int cpus_stopped;
unsigned int msecs;
+ unsigned int ncpus;
- unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+ if (cpus_stopped)
+ return;
+
+ ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
dump_send_ipi(crash_shutdown_secondary);
smp_wmb();
@@ -64,6 +69,17 @@ static void crash_kexec_prepare_cpus(void)
cpu_relax();
mdelay(1);
}
+
+ cpus_stopped = 1;
+}
+
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ if (_crash_smp_send_stop)
+ _crash_smp_send_stop();
+
+ crash_kexec_prepare_cpus();
}
#else /* !defined(CONFIG_SMP) */
diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c
index 50980bf3..5972520 100644
--- a/arch/mips/kernel/machine_kexec.c
+++ b/arch/mips/kernel/machine_kexec.c
@@ -25,6 +25,7 @@ void (*_machine_crash_shutdown)(struct pt_regs *regs) = NULL;
#ifdef CONFIG_SMP
void (*relocated_kexec_smp_wait) (void *);
atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
+void (*_crash_smp_send_stop)(void) = NULL;
#endif
int
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [V4 PATCH 0/2] kexec: crash_kexec_post_notifiers boot option related fixes
Daniel Walker reported problems which happens when crash_kexec_post_notifiers kernel option is enabled (https://lkml.org/lkml/2015/6/24/44). In that case, smp_send_stop() is called before entering kdump routines which assume other CPUs are still online. This causes some issues depending on architectures. For example, for x86, kdump routines fail to save other CPUs' registers and disable virtualization extensions. For MIPS OCTEON, it fails to stop the watchdog timer. To fix this problem, call a new kdump friendly function, crash_smp_send_stop(), instead of the smp_send_stop() when crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a weak function, and it just call smp_send_stop(). Architecture codes should override it so that kdump can work appropriately. This patch set supports only x86 and MIPS. NOTE: - Right solution would be to place crash_smp_send_stop() before __crash_kexec() invocation in all cases and remove smp_send_stop(), but we can't do that until all architectures implement own crash_smp_send_stop() - crash_smp_send_stop()-like work is still needed by machine_crash_shutdown() because crash_kexec() can be called without entering panic() Changes in V4: - Keep to use smp_send_stop if crash_kexec_post_notifiers is not set - Rename panic_smp_send_stop to crash_smp_send_stop - Don't change the behavior for Xen's PV kernel - Support MIPS Changes in V3: https://lkml.org/lkml/2016/7/5/221 - Revise comments, description, and symbol names (the logic doesn't change) - Make crash_kexec_post_notifiers boot option modifiable after boot Changes in V2: https://lkml.org/lkml/2015/7/23/864 - Replace smp_send_stop() call with crash_kexec version which saves cpu states and does cleanups instead of changing execution flow - Drop a fix for Problem 1 - Drop other patches because they aren't needed anymore V1: https://lkml.org/lkml/2015/7/10/316 --- Hidehiro Kawai (2): x86/panic: Replace smp_send_stop() with kdump friendly version in panic path mips/panic: Replace smp_send_stop() with kdump friendly version in panic path arch/mips/cavium-octeon/setup.c | 14 +++ arch/mips/include/asm/kexec.h|1 + arch/mips/kernel/crash.c | 18 ++- arch/mips/kernel/machine_kexec.c |1 + arch/x86/include/asm/kexec.h |1 + arch/x86/include/asm/smp.h |1 + arch/x86/kernel/crash.c | 22 +++--- arch/x86/kernel/smp.c|5 kernel/panic.c | 47 -- 9 files changed, 99 insertions(+), 11 deletions(-) -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online. As the result, for x86,
kdump routines fail to save other CPUs' registers and disable
virtualization extensions.
To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a
weak function, and it just call smp_send_stop(). Architecture
codes should override it so that kdump can work appropriately.
This patch only provides x86-specific version.
For Xen's PV kernel, just keep the current behavior.
Changes in V4:
- Keep to use smp_send_stop if crash_kexec_post_notifiers is not set
- Rename panic_smp_send_stop to crash_smp_send_stop
- Don't change the behavior for Xen's PV kernel
Changes in V3:
- Revise comments, description, and symbol names
Changes in V2:
- Replace smp_send_stop() call with crash_kexec version which
saves cpu states and cleans up VMX/SVM
- Drop a fix for Problem 1 at this moment
Reported-by: Daniel Walker
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Eric Biederman
Cc: Masami Hiramatsu
Cc: Daniel Walker
Cc: Xunlei Pang
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Borislav Petkov
Cc: David Vrabel
Cc: Toshi Kani
Cc: Andrew Morton
---
arch/x86/include/asm/kexec.h |1 +
arch/x86/include/asm/smp.h |1 +
arch/x86/kernel/crash.c | 22 +---
arch/x86/kernel/smp.c|5
kernel/panic.c | 47 --
5 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1..282630e 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -210,6 +210,7 @@ struct kexec_entry64_regs {
typedef void crash_vmclear_fn(void);
extern crash_vmclear_fn __rcu *crash_vmclear_loaded_vmcss;
+extern void kdump_nmi_shootdown_cpus(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index ebd0c16..f70989c 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -50,6 +50,7 @@ struct smp_ops {
void (*smp_cpus_done)(unsigned max_cpus);
void (*stop_other_cpus)(int wait);
+ void (*crash_stop_other_cpus)(void);
void (*smp_send_reschedule)(int cpu);
int (*cpu_up)(unsigned cpu, struct task_struct *tidle);
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9616cf7..650830e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -133,15 +133,31 @@ static void kdump_nmi_callback(int cpu, struct pt_regs
*regs)
disable_local_APIC();
}
-static void kdump_nmi_shootdown_cpus(void)
+void kdump_nmi_shootdown_cpus(void)
{
nmi_shootdown_cpus(kdump_nmi_callback);
disable_local_APIC();
}
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ static int cpus_stopped;
+
+ if (cpus_stopped)
+ return;
+
+ if (smp_ops.crash_stop_other_cpus)
+ smp_ops.crash_stop_other_cpus();
+ else
+ smp_send_stop();
+
+ cpus_stopped = 1;
+}
+
#else
-static void kdump_nmi_shootdown_cpus(void)
+void crash_smp_send_stop(void)
{
/* There are no cpus to shootdown */
}
@@ -160,7 +176,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
/* The kernel is broken so disable interrupts */
local_irq_disable();
- kdump_nmi_shootdown_cpus();
+ crash_smp_send_stop();
/*
* VMCLEAR VMCSs loaded on this cpu if needed.
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 658777c..68f8cc2 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+
/*
* Some notes on x86 processor bugs affecting SMP operation:
*
@@ -342,6 +344,9 @@ struct smp_ops smp_ops = {
.smp_cpus_done = native_smp_cpus_done,
.stop_other_cpus= native_stop_other_cpus,
+#if defined(CONFIG_KEXEC_CORE)
+ .crash_stop_other_cpus = kdump_nmi_shootdown_cpus,
+#endif
.smp_send_reschedule= native_smp_send_reschedule,
.cpu_up = native_cpu_up,
diff --git a/kernel/panic.c b/kernel/panic.c
index ca8cea1..e6480e2 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -71,6 +71,32 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
panic_smp_self_stop();
}
+/*
+ * Stop other CPUs in panic. Architecture dependent code may override this
+ * with more suitable version. For example, if the arch
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 8/8/2016 11:40 PM, Jan Beulich wrote:
On 12.07.16 at 11:02, wrote:
@@ -178,8 +179,34 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
Wouldn't it both be more natural and make the logic even easier
to follow if s got set to NULL up front, all the "else"-s dropped,
and a simple
if ( !s )
s = hvm_select_ioreq_server(currd, &p);
be done in the end?
Sorry, Jan. I tried to simplify above code, but found the new code is
still not very
clean, because in some cases the s is supposed to return NULL instead
of to be
set from the hvm_select_ioreq_server().
To keep the same logic, the simplified code looks like this:
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio && dir == IOREQ_WRITE )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);
/* If there is no suitable backing DM, just ignore accesses */
if ( !s )
As you can see, definition of p2mt is moved outside the if ( is_mmio )
judgement,
and is checked against p2m_ioreq_server before we search the ioreq
server's rangeset
in hvm_select_ioreq_server(). So I am not quite satisfied with this
simplification.
Any suggestions?
[snip]
Yu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] xl dump-core fails, j!=nr_pages
On Wed, Aug 10, Olaf Hering wrote: This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work with HVM guests? I think at some point 'xm dump-core' used to work, just crash(1) could not deal with the result. > xc: info: j (63635) != nr_pages (65709) > memory=256 > memory=1024 xc: info: j (260243) != nr_pages (262309) What are those missing 2066 pages? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
On Wed, Aug 10, 2016 at 07:43:38AM +, osstest service owner wrote: > flight 100382 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/100382/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64 5 xen-buildfail REGR. vs. > 100365 The patch: acpi/hvmloader: Initialize vm_gid data outside ACPI code broke Xen build, I think. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] NUMA/x86 related adjustments
1: page-alloc/x86: don't restrict DMA heap to node 0 2: x86/NUMA: cleanup Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
When node zero has no memory, the DMA bit width will end up getting set
to 9, which is obviously not helpful to hold back a reasonable amount
of low enough memory for Dom0 to use for DMA purposes. Find the lowest
node with memory below 4Gb instead.
Introduce arch_get_dma_bitsize() to keep this arch-specific logic out
of common code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
}
}
-EXPORT_SYMBOL(cpu_to_node);
-EXPORT_SYMBOL(node_to_cpumask);
-EXPORT_SYMBOL(memnode_shift);
-EXPORT_SYMBOL(memnodemap);
-EXPORT_SYMBOL(node_data);
+unsigned int __init arch_get_dma_bitsize(void)
+{
+unsigned int node;
+
+for_each_online_node(node)
+if ( node_spanned_pages(node) &&
+ !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
+break;
+if ( node >= MAX_NUMNODES )
+panic("No node with memory below 4Gb");
+
+return min_t(unsigned int,
+ flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 1)
+ + PAGE_SHIFT, 32);
+}
static void dump_numa(unsigned char key)
{
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
init_heap_pages(virt_to_page(bootmem_region_list), 1);
if ( !dma_bitsize && (num_online_nodes() > 1) )
-{
-#ifdef CONFIG_X86
-dma_bitsize = min_t(unsigned int,
-flsl(NODE_DATA(0)->node_spanned_pages) - 1
-+ PAGE_SHIFT - 2,
-32);
-#else
-dma_bitsize = 32;
-#endif
-}
+dma_bitsize = arch_get_dma_bitsize();
printk("Domain heap initialised");
if ( dma_bitsize )
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -17,6 +17,11 @@ static inline __attribute__((pure)) node
#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
#define __node_distance(a, b) (20)
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+return 32;
+}
+
#endif /* __ARCH_ARM_NUMA_H */
/*
* Local variables:
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -86,5 +86,6 @@ extern int valid_numa_range(u64 start, u
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
+unsigned int arch_get_dma_bitsize(void);
#endif
page-alloc/x86: don't restrict DMA heap to node 0
When node zero has no memory, the DMA bit width will end up getting set
to 9, which is obviously not helpful to hold back a reasonable amount
of low enough memory for Dom0 to use for DMA purposes. Find the lowest
node with memory below 4Gb instead.
Introduce arch_get_dma_bitsize() to keep this arch-specific logic out
of common code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
}
}
-EXPORT_SYMBOL(cpu_to_node);
-EXPORT_SYMBOL(node_to_cpumask);
-EXPORT_SYMBOL(memnode_shift);
-EXPORT_SYMBOL(memnodemap);
-EXPORT_SYMBOL(node_data);
+unsigned int __init arch_get_dma_bitsize(void)
+{
+unsigned int node;
+
+for_each_online_node(node)
+if ( node_spanned_pages(node) &&
+ !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
+break;
+if ( node >= MAX_NUMNODES )
+panic("No node with memory below 4Gb");
+
+return min_t(unsigned int,
+ flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 1)
+ + PAGE_SHIFT, 32);
+}
static void dump_numa(unsigned char key)
{
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
init_heap_pages(virt_to_page(bootmem_region_list), 1);
if ( !dma_bitsize && (num_online_nodes() > 1) )
-{
-#ifdef CONFIG_X86
-dma_bitsize = min_t(unsigned int,
-flsl(NODE_DATA(0)->node_spanned_pages) - 1
-+ PAGE_SHIFT - 2,
-32);
-#else
-dma_bitsize = 32;
-#endif
-}
+dma_bitsize = arch_get_dma_bitsize();
printk("Domain heap initialised");
if ( dma_bitsize )
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -17,6 +17,11 @@ static inline __attribute__((pure)) node
#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
#define __node_distance(a, b) (20)
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+return 32;
+}
+
#endif /* __ARCH_ARM_NUMA_H */
/*
* Local variables:
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -86,5 +86,6 @@ extern int valid_numa_range(u64 start, u
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
+unsigned int arch_get_dma_bitsize(void);
#endif
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/NUMA: cleanup
- drop the only left CONFIG_NUMA conditional (this is always true)
- drop struct node_data's node_id field (being always equal to the
node_data[] array index used)
- don't open code node_{start,end}_pfn() nor node_spanned_pages()
except when used as lvalues (those could be converted too, but this
seems a little awkward)
- no longer open code pfn_to_paddr() in an expression being modified
anyway
- make dump less verbose by logging actual vs intended node IDs only
when they don't match
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -179,7 +179,6 @@ void __init setup_node_bootmem(nodeid_t
start_pfn = start >> PAGE_SHIFT;
end_pfn = end >> PAGE_SHIFT;
-NODE_DATA(nodeid)->node_id = nodeid;
NODE_DATA(nodeid)->node_start_pfn = start_pfn;
NODE_DATA(nodeid)->node_spanned_pages = end_pfn - start_pfn;
@@ -386,16 +385,15 @@ static void dump_numa(unsigned char key)
for_each_online_node ( i )
{
-paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n",
- i, NODE_DATA(i)->node_id,
- NODE_DATA(i)->node_start_pfn,
- NODE_DATA(i)->node_spanned_pages,
+paddr_t pa = pfn_to_paddr(node_start_pfn(i) + 1);
+
+printk("NODE%u start->%lu size->%lu free->%lu\n",
+ i, node_start_pfn(i), node_spanned_pages(i),
avail_node_heap_pages(i));
/* sanity check phys_to_nid() */
-printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa,
- phys_to_nid(pa),
- NODE_DATA(i)->node_id);
+if ( phys_to_nid(pa) != i )
+printk("phys_to_nid(%"PRIpaddr") -> %d should be %u\n",
+ pa, phys_to_nid(pa), i);
}
j = cpumask_first(&cpu_online_map);
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1386,21 +1386,21 @@ int memory_add(unsigned long spfn, unsig
goto destroy_directmap;
}
-old_node_start = NODE_DATA(node)->node_start_pfn;
-old_node_span = NODE_DATA(node)->node_spanned_pages;
+old_node_start = node_start_pfn(node);
+old_node_span = node_spanned_pages(node);
orig_online = node_online(node);
if ( !orig_online )
{
dprintk(XENLOG_WARNING, "node %x pxm %x is not online\n",node, pxm);
-NODE_DATA(node)->node_id = node;
NODE_DATA(node)->node_start_pfn = spfn;
NODE_DATA(node)->node_spanned_pages =
epfn - node_start_pfn(node);
node_set_online(node);
-}else
+}
+else
{
-if (NODE_DATA(node)->node_start_pfn > spfn)
+if (node_start_pfn(node) > spfn)
NODE_DATA(node)->node_start_pfn = spfn;
if (node_end_pfn(node) < epfn)
NODE_DATA(node)->node_spanned_pages = epfn - node_start_pfn(node);
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -40,7 +40,6 @@ extern void srat_detect_node(int cpu);
extern void setup_node_bootmem(nodeid_t nodeid, u64 start, u64 end);
extern nodeid_t apicid_to_node[];
-#ifdef CONFIG_NUMA
extern void init_cpu_to_node(void);
static inline void clear_node_cpumask(int cpu)
@@ -56,7 +55,6 @@ extern u8 *memnodemap;
struct node_data {
unsigned long node_start_pfn;
unsigned long node_spanned_pages;
-nodeid_t node_id;
};
extern struct node_data node_data[];
@@ -78,11 +76,6 @@ static inline __attribute__((pure)) node
NODE_DATA(nid)->node_spanned_pages)
extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
-#else
-#define init_cpu_to_node() do {} while (0)
-#define clear_node_cpumask(cpu) do {} while (0)
-#define valid_numa_range(start, end, node) 1
-#endif
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
x86/NUMA: cleanup
- drop the only left CONFIG_NUMA conditional (this is always true)
- drop struct node_data's node_id field (being always equal to the
node_data[] array index used)
- don't open code node_{start,end}_pfn() nor node_spanned_pages()
except when used as lvalues (those could be converted too, but this
seems a little awkward)
- no longer open code pfn_to_paddr() in an expression being modified
anyway
- make dump less verbose by logging actual vs intended node IDs only
when they don't match
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -179,7 +179,6 @@ void __init setup_node_bootmem(nodeid_t
start_pfn = start >> PAGE_SHIFT;
end_pfn = end >> PAGE_SHIFT;
-NODE_DATA(nodeid)->node_id = nodeid;
NODE_DATA(nodeid)->node_start_pfn = start_pfn;
NODE_DATA(nodeid)->node_spanned_pages = end_pfn - start_pfn;
@@ -386,16 +385,15 @@ static void dump_numa(unsigned char key)
for_each_online_node ( i )
{
-paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-p
Re: [Xen-devel] [Qemu-devel] [RFC for 2.8 0/3] Drop support for 64 bit guests on 32 bit hosts
On Di, 2016-08-09 at 16:55 +0100, Alex Bennée wrote: > Hi, > > I'm proposing for the 2.8 cycle we officially drop supporting 64 bit > guests on 32 bit hosts. For most of the KVM targets it doesn't make > any sense anyway and for TCG it makes things harder (e.g. supporting > 64 bit atomics on a 32 bit platform). I'm not actually convinced > things actually work if built or that anyone relies on these > combinations. Consider these patches a way of flushing any such users > out ;-) Adding xen-devel to Cc. 64bit xen hypervisor with 32bit dom0 running 32bit qemu, providing device emulation for 64bit dumUs at least used to be a common setup years ago. I have my doubts this is still the case in recent xen versions, but I guess we better ask the Xen guys ... Can anyone clarify? thanks, Gerd ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Save/Restore is not working properly
On Sun, Aug 7, 2016 at 4:21 PM, Cendrin Sa wrote:
> Hi,
> I was searching a way to clone a machine using both memory and disk
> approach.
> I checked xen save/restore but after restoring, I can only work some seconds
> with my machine and it will crash with the_kernel_task_hang_up.
> using an script* to clone a machine is not working either.
> so is it a bug or something or I'm cloning the wrong way?
Thanks for the bug report -- but you're missing a lot of important
information to help us figure out what's going wrong. You need to let
us know what version of Xen you're running, attach all the relevant
config files, and include the relevant console output.
So to begin with -- just to understand -- if you do a simple save /
restore, does that work?
Also, if you just do a save (without pausing), and then restore with
the alternate VM config, does that work?
Thanks,
-George
>
>
>
> *
> #!/bin/bash
>
> : ${2? "Usage: $0 "}
> echo "$1 is source domain id";
> echo "$2 is the destination file to store the image";
> xl save -p $1 $2 ;
> lvremove -f /dev/vg0/vm-clone-lv;
> lvcreate -L10G -s -n vm-clone-lv /dev/vg0/orig-vm ;
> xl restore -e -p /etc/xen/vm-clone.cfg $2;
> xl unpause $1;
>
> --
> Regards
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 20/25] arm/altp2m: Add altp2m paging mechanism.
Hi Julien,
>>> [...]
>>>
switch ( fsc )
{
+case FSC_FLT_TRANS:
+{
+if ( altp2m_active(d) )
+{
+const struct npfec npfec = {
+.insn_fetch = 1,
+.gla_valid = 1,
+.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
npfec_kind_with_gla
+};
+
+/*
+ * Copy the entire page of the failing instruction
into the
+ * currently active altp2m view.
+ */
+if ( altp2m_lazy_copy(v, gpa, gva, npfec, &p2m) )
+return;
>>>
>>> I forgot to mention that I think there is a race condition here. If
>>> multiple vCPU (let say A and B) use the same altp2m, they may fault
>>> here.
>>>
>>> If vCPU A already fixed the fault, this function will return false and
>>> continue. So this will lead to inject an instruction abort to the
>>> guest.
>>>
I have solved this issue as well:
In altp2m_lazy_copy, we check whether the faulting address is already
mapped in the current altp2m view. The only reason why the current
altp2m should have a valid entry for the apparently faulting address is
that it was previously (almost simultaneously) mapped by another vcpu.
That is, if the mapping for the faulting address is valid in the altp2m,
we return true and hence let the guest retry (without injecting an
instruction/data abort exception) to access the address in question.
Best regards,
~Sergej
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case
>>> On 09.08.16 at 20:01, wrote:
>> >> > @@ -70,7 +71,11 @@ struct payload {
>> >> > unsigned int nsyms; /* Nr of entries in .strtab
>> >> > and
>> >> > symbols. */
>> >> > struct livepatch_build_id id;/*
>> >> > ELFNOTE_DESC(.note.gnu.build-id) of the payload. */
>> >> > struct livepatch_build_id dep; /*
>> >> > ELFNOTE_DESC(.livepatch.depends). */
>> >> > -char name[XEN_LIVEPATCH_NAME_SIZE]; /* Name of it. */
>> >> > +livepatch_loadcall_t **load_funcs; /* The array of funcs to call
>> >> > after */
>> >> > +livepatch_unloadcall_t **unload_funcs;/* load and unload of the
>> >> > payload. */
>> >>
>> >> These both seem like they want a const in the middle.
>> >
>> > I did that initially and found out that the calling ->load_funcs[i]
>> > resulted
>> > in _no_ code being called.
>> >
>> > I did not dig in the assembler output to figure out what happend, let me
>> > do that now.
>>
>> Indeed - I can't see how a const modifier here could alter whether
>> or not the pointed to function gets called.
>
> I did a diff on the pre-assemble part (-S) with and without const on the above
> structs. With 'const' we get:
>
> callspin_debug_disable
> .LVL163:
> - .loc 1 1093 0
> - cmpl$0, 324(%rbx)
> - je .L112
> - movl$0, %r12d
> -.LVL164:
> -.L113:
> - .loc 1 1094 0
> - mov %r12d, %edx
> - movq312(%rbx), %rax
> - call*(%rax,%rdx,8)
> - .loc 1 1093 0
> - addl$1, %r12d
> -.LVL165:
> - cmpl%r12d, 324(%rbx)
> - ja .L113
> -.LVL166:
> -.L112:
>
> being removed.
>
> I thought it may have to do with the function not returning anything. But
> even after making the typedef return it still omitted the call
> data->load_funcs[i]();
Odd. I've tried this simple example:
typedef int fn_t(void);
struct s {
unsigned n;
fn_t**fn;
fn_t*const*fnc;
const fn_t**cfn;
};
int test1(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->fn[i]();
return rc;
}
int test2(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->fnc[i]();
return rc;
}
int test3(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->cfn[i]();
return rc;
}
test1() and test2() get compiled identically. test3(), using the field
with the misplaced const, oddly enough gets compiled slightly
differently (and without a warning despite one would seem
warranted), yet the call doesn't get omitted. If, however, I change
the return type of fn_t to void, the function body of test3() ends
up empty, which is a compiler bug afaict, but which also suggests
that you've tried the variant with the misplaced const.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.
Hello Tamas,
On 09/08/2016 21:16, Tamas K Lengyel wrote:
On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall wrote:
Hello Sergej,
On 01/08/16 18:10, Sergej Proskurin wrote:
This commit moves the altp2m-related code from x86 to ARM. Functions
that are no yet supported notify the caller or print a BUG message
stating their absence.
Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of the
domain.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.
---
xen/arch/arm/hvm.c | 79
xen/include/asm-arm/altp2m.h | 4 +--
xen/include/asm-arm/domain.h | 3 ++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..eb524ae 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,81 @@
#include
+#include
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !d->arch.altp2m_active )
Why not using altp2m_active(d) here?
Also this check looks quite racy. What does prevent another CPU to disable
altp2m at the same time? How the code would behave?
There is a rcu_lock_domain_by_any_id before we get to this check here,
so any other CPU looking to disable altp2m would be waiting there for
the current op to finish up, so there is no race condition AFAICT.
No, rcu_lock_domain_by_any_id only prevents the domain to be fully
destroyed by "locking" the rcu. It does not prevent multiple concurrent
access. You can look at the code if you are not convinced.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()
c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
introduced an assertion which covered the correctness of shifting 1u by an
input parameter.
While all other inputs provide a constants vector, the `int $N` handling path
from do_general_protection() passes any vector.
This path is triggered by XTF, which uses `int 0x20` to facilitate returning
to kernel mode after running specific tests in user mode.
No vectors above 32 have an error code, so adjust the logic to cope.
Reported-by: Wei Liu
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
RFC:
1) Should we start making use of Linux's "Fixes:" tag?
2) I considered using TRAP_nr instead of 32, but "(trapnr < TRAP_nr)" is odd,
and it hides the visual correctness of seeing that 1u is never shifted out of
range.
---
xen/arch/x86/traps.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c228b45..e822719 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -631,11 +631,8 @@ static void do_guest_trap(unsigned int trapnr,
struct vcpu *v = current;
struct trap_bounce *tb;
const struct trap_info *ti;
-bool_t use_error_code;
-
-ASSERT(trapnr < 32);
-
-use_error_code = (TRAP_HAVE_EC & (1u << trapnr));
+const bool use_error_code =
+((trapnr < 32) && (TRAP_HAVE_EC & (1u << trapnr)));
trace_pv_trap(trapnr, regs->eip, use_error_code, regs->error_code);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
> >>> On 03.08.16 at 03:32, wrote: > >> On 25/07/16 07:09, Kang, Luwei wrote: > >> First of all - please don't top post. > >> > >> > What about remove the dependency between AVX2 and AVX512F > >> >> ( AVX2: > >> [AVX512F], ) ? > >> > >> Yes, that's what I think we want, but we need Andrew's agreement here. > >> > >> >>> Hi Andrew, what is your opinion ? > >> >> You are in a better position to answer than me. > >> >> > >> >> For a specific instruction which may be VEX and EVEX encoded, is > >> >> the circuitry for a specific instruction shared, or discrete? Is > >> >> there a plausible future where you might support only the EVEX > >> >> variant of an instruction, and not the VEX variant? > >> >> > >> >> These dependences are about what may be reasonably assumed about > >> >> the way the environment is structured. It doesn't look reasonable > >> >> to advertise an AVX512 environment to guests while at the same > >> >> time stating that AVX2 is not present. If this is correct, then > >> >> the dependency > > should stay. > >> >> If Intel plausibly things it might release hardware with !AVX2 but > >> >> AVX512, then the dependency should be dropped. > >> > Regarding the dependency between AVX2 and AVX512F, I have ask some > >> > hardware > > architecture engineer. > >> > > >> > AVX512 is a superset of AVX2, the most important item being the > >> > state. If > > the state for AVX2 isn't enabled (in XCR0), then AVX512 > >> also can't function. > >> > > >> > So if we want to use AVX512, AVX2 must be supported and enabled. > >> > The > > dependence between AVX512F and AVX2 may need be > >> reserved. > >> > >> Ok, so AVX512 strictly depends on AVX2. > >> > >> In which case, the python code was correct. The meaning of the > >> key/value > > relationship is "if the feature in the key is not present, all > >> features in the value must also be disabled". > > > > Hi jan, what is your opinion? > > There's no opinion to be had here, according to your earlier reply. I do, > however, continue to question that model: State and > instruction set are independent items. Of course YMM state is a prereq to ZMM > state, but I do not buy AVX2 insn support being a > prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature flags solely > represent the instructions, while the XSTATE leaf bits > represent the states. > Hi jan, I get some information from hardware colleague. There is no dependence about AVX512 instructions and AVX2 instructions. It is also not states in the official document. But I want to know the meaning of the dependence "AVX2: [AVX512F]" in "gen-cpuid.py" file. If it is the feature dependence, I think the dependence between AVX512 and AVX2 may need to add. As we talk before, Zmm is part of AVX512 feature. If the state for AVX2 isn't enabled (in XCR0), then AVX512 also can't function. Apart from that, there is no processors with AVX512 without AVX2 currently and it is safe to treat AVX2 as part of the thermometer leading to AVX512. Regarding if will have a cpu support avx512 without avx2 in future, it is really hard to say. If it is the instructions dependence, I have no idea to delete this dependence in "gen-cpuid.py" file. So, I want to know your advice. Thanks, Luwei Kang ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
On 10/08/16 10:23, Jan Beulich wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
> }
> }
>
> -EXPORT_SYMBOL(cpu_to_node);
> -EXPORT_SYMBOL(node_to_cpumask);
> -EXPORT_SYMBOL(memnode_shift);
> -EXPORT_SYMBOL(memnodemap);
> -EXPORT_SYMBOL(node_data);
> +unsigned int __init arch_get_dma_bitsize(void)
> +{
> +unsigned int node;
> +
> +for_each_online_node(node)
> +if ( node_spanned_pages(node) &&
> + !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
> +break;
> +if ( node >= MAX_NUMNODES )
> +panic("No node with memory below 4Gb");
> +
> +return min_t(unsigned int,
> + flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 -
> 1)
> + + PAGE_SHIFT, 32);
You have moved the -1 and -2 inside the flsl() call, which alters its
behaviour quite a bit. Is this intentional or accidental?
~Andrew
> +}
>
> static void dump_numa(unsigned char key)
> {
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
> init_heap_pages(virt_to_page(bootmem_region_list), 1);
>
> if ( !dma_bitsize && (num_online_nodes() > 1) )
> -{
> -#ifdef CONFIG_X86
> -dma_bitsize = min_t(unsigned int,
> -flsl(NODE_DATA(0)->node_spanned_pages) - 1
> -+ PAGE_SHIFT - 2,
> -32);
> -#else
> -dma_bitsize = 32;
> -#endif
> -}
> +dma_bitsize = arch_get_dma_bitsize();
>
> printk("Domain heap initialised");
> if ( dma_bitsize )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
>>> On 10.08.16 at 10:57, wrote: > On Wed, Aug 10, 2016 at 07:43:38AM +, osstest service owner wrote: >> flight 100382 xen-unstable-smoke real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/100382/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-amd64 5 xen-buildfail REGR. vs. > 100365 > > The patch: > >acpi/hvmloader: Initialize vm_gid data outside ACPI code > > broke Xen build, I think. I've pushed Boris' fixes, and I realize I'm guilty of one of the two issues that needed fixing. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()
>>> On 10.08.16 at 11:53, wrote:
> c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
> introduced an assertion which covered the correctness of shifting 1u by an
> input parameter.
>
> While all other inputs provide a constants vector, the `int $N` handling path
> from do_general_protection() passes any vector.
>
> This path is triggered by XTF, which uses `int 0x20` to facilitate returning
> to kernel mode after running specific tests in user mode.
>
> No vectors above 32 have an error code, so adjust the logic to cope.
>
> Reported-by: Wei Liu
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> RFC:
>
> 1) Should we start making use of Linux's "Fixes:" tag?
It wouldn't hurt if someone did, but mentioning the offending commit
in the description would seem enough (and often better) to me. In no
case would I like seeing just a commit ID, without also the title being
quoted, as that will always mean one has to consult the repo for
understanding what exact change was broken (that is, of course,
only for those of us who can't memorize all the commit ID-s and their
respective titles of the last few years).
> 2) I considered using TRAP_nr instead of 32, but "(trapnr < TRAP_nr)" is odd,
> and it hides the visual correctness of seeing that 1u is never shifted out of
> range.
Either variant is fine with me.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
>>> On 10.08.16 at 09:35, wrote: > --- a/xen/common/vm_event.c > +++ b/xen/common/vm_event.c > @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct > vm_event_domain *ved) > v = d->vcpu[rsp.vcpu_id]; > > /* > + * Make sure the vCPU state has been synchronized for the custom > + * handlers. > + */ > +if ( atomic_read(&v->vm_event_pause_count) ) > +sync_vcpu_execstate(v); It seems to me that the latest with this change using a simple atomic_t won't suffice anymore - you'd now really need to make sure the user mode tools can't resume that vCPU behind your back, which aiui can only be achieved by using a suitable lock (perhaps a read/write one if reading the pause count is more common than updating it). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 100387: regressions - FAIL
flight 100387 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 100365 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 baseline version: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc Last test of basis 100365 2016-08-09 15:01:57 Z0 days Testing same since 100368 2016-08-09 17:01:23 Z0 days8 attempts People who touched revisions under test: Boris Ostrovsky George Dunlap Jan Beulich jobs: build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt 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 http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 Author: Jan Beulich Date: Tue Aug 9 17:31:46 2016 +0200 common: clean up taint logic Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments. Signed-off-by: Jan Beulich Acked-by: George Dunlap commit bea437908b27c751012abe14c4312dd4d159ff23 Author: Boris Ostrovsky Date: Tue Aug 9 17:31:15 2016 +0200 hvmloader: move passthrough initialization from ACPI code Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read() Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 653d8fb95adc81dc2fbc3594bd63519f68271dc2 Author: Boris Ostrovsky Date: Tue Aug 9 17:30:56 2016 +0200 hvmloader: decide which SSDTs to install in hvmloader With that, xenstore_read() won't need to be done in ACPI code Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 3bb36fe2aa2c590e52578a6ea65ba992178ef82b Author: Boris Ostrovsky Date: Tue Aug 9 17:30:39 2016 +0200 hvmloader: initialize vm_gid data outside ACPI code This way ACPI code won't use xenstore-read() and hvm_param_set() which are private to hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit c15eea2a1e719577af83bddf793a3a5329ce395d Author: Boris Ostrovsky Date: Tue Aug 9 17:28:59 2016 +0200 acpi/hvmloader: allow acpi_build_tables() callers specify acpi_info values By doing this we can move hvmloader-private interfaces (such as uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will help us with allowing to call the builder from places other than hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit edd0028206d14c25ddee2357dca08441ff13cea1 Author: Boris Ostrovsky Date: Tue Aug 9 17:27:39 2016 +0200 hvmloader: provide hvmloader_acpi_build_tables() In preparation for moving out ACPI builder make all BIOSes call hvmloader_acpi_build_tables() instead of calling ACPI code directly. No functional changes. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
>>> On 10.08.16 at 11:58, wrote:
> On 10/08/16 10:23, Jan Beulich wrote:
>> --- a/xen/arch/x86/numa.c
>> +++ b/xen/arch/x86/numa.c
>> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
>> }
>> }
>>
>> -EXPORT_SYMBOL(cpu_to_node);
>> -EXPORT_SYMBOL(node_to_cpumask);
>> -EXPORT_SYMBOL(memnode_shift);
>> -EXPORT_SYMBOL(memnodemap);
>> -EXPORT_SYMBOL(node_data);
>> +unsigned int __init arch_get_dma_bitsize(void)
>> +{
>> +unsigned int node;
>> +
>> +for_each_online_node(node)
>> +if ( node_spanned_pages(node) &&
>> + !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
>> +break;
>> +if ( node >= MAX_NUMNODES )
>> +panic("No node with memory below 4Gb");
>> +
>> +return min_t(unsigned int,
>> + flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 -
>> 1)
>> + + PAGE_SHIFT, 32);
>
> You have moved the -1 and -2 inside the flsl() call, which alters its
> behaviour quite a bit. Is this intentional or accidental?
This is intentional, and their original placement was only not too
wrong because of the effective use of zero in place of what is
now node_start_pfn(node). (Obviously the division by 4 alone
could have gone in either place, but the "- 1" should have been
inside the flsl() even before imo.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation
On Tue, Aug 09, 2016 at 07:34:14PM +0200, Paulina Szubarczyk wrote:
> On 08/09/2016 06:56 PM, Anthony PERARD wrote:
> > On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote:
> > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> > > index 640c31e..e80c61f 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -25,6 +25,31 @@
> > >*/
> > >
> > > /* Xen 4.2 through 4.6 */
> > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 480
> > > +
> > > +struct xengnttab_grant_copy_segment {
> > > +union xengnttab_copy_ptr {
> > > +void *virt;
> > > +struct {
> > > +uint32_t ref;
> > > +uint16_t offset;
> > > +uint16_t domid;
> > > +} foreign;
> > > +} source, dest;
> > > +uint16_t len;
> > > +uint16_t flags;
> > > +int16_t status;
> > > +};
> >
> > I don't think it's a good idee to define a struct that is not going to
> > be used, and does not belong here. The typedef is OK.
>
> I added it since it is needed to know all the fields of that struct in
> ioreq_copy but if I could replace that function with stubs I will do that.
>
> >
> > In xen_disk.c, you could use "#if CONFIG_XEN_CTRL_INTERFACE_VERSION ..."
> > around free_buffers, ioreq_init_copy_buffers and ioreq_copy, and replace
> > them by stubs when Xen does not support grant copy. I think that would
> > be better.
> >
> > Also, could you try to compile again xen unstable, without your other patch?
> > Right now, it does not compile.
>
> That is true, I am sorry. I need to add the headers that are included in the
> #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 471 */
>
> #include
> #include
> #include
>
> #endif
>
> May I move that part to separate #if CONFIG_XEN_CTRL_INTERFACE_VERSION >=
> 471 in that header?
You could could add your code at the end of xen_common.h instead of the
beginning, I think that would work. (At the end of xen_common.h,
xengnttab_handle should be define, either in the file or via an
include.)
> >
> > > +typedef struct xengnttab_grant_copy_segment
> > > xengnttab_grant_copy_segment_t;
> > > +
> > > +static inline int xengnttab_grant_copy(xengnttab_handle *xgt, uint32_t
> > > count,
> > > + xengnttab_grant_copy_segment_t
> > > *segs)
> > > +{
> > > +return -1;
> >
> > return -ENOSYS would be more appropriate.
> >
> >
> > Otherwise, the patch looks good.
> >
> > Thanks,
> >
> Thank you,
>
> Paulina
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
>>> On 10.08.16 at 11:58, wrote: >> >>> On 03.08.16 at 03:32, wrote: >> >> On 25/07/16 07:09, Kang, Luwei wrote: >> >> First of all - please don't top post. >> >> >> >> > What about remove the dependency between AVX2 and AVX512F >> >> >> ( AVX2: >> >> [AVX512F], ) ? >> >> >> >> Yes, that's what I think we want, but we need Andrew's agreement >> >> here. >> >> >> >> >>> Hi Andrew, what is your opinion ? >> >> >> You are in a better position to answer than me. >> >> >> >> >> >> For a specific instruction which may be VEX and EVEX encoded, is >> >> >> the circuitry for a specific instruction shared, or discrete? Is >> >> >> there a plausible future where you might support only the EVEX >> >> >> variant of an instruction, and not the VEX variant? >> >> >> >> >> >> These dependences are about what may be reasonably assumed about >> >> >> the way the environment is structured. It doesn't look reasonable >> >> >> to advertise an AVX512 environment to guests while at the same >> >> >> time stating that AVX2 is not present. If this is correct, then >> >> >> the dependency >> > should stay. >> >> >> If Intel plausibly things it might release hardware with !AVX2 but >> >> >> AVX512, then the dependency should be dropped. >> >> > Regarding the dependency between AVX2 and AVX512F, I have ask some >> >> > hardware >> > architecture engineer. >> >> > >> >> > AVX512 is a superset of AVX2, the most important item being the >> >> > state. If >> > the state for AVX2 isn't enabled (in XCR0), then AVX512 >> >> also can't function. >> >> > >> >> > So if we want to use AVX512, AVX2 must be supported and enabled. >> >> > The >> > dependence between AVX512F and AVX2 may need be >> >> reserved. >> >> >> >> Ok, so AVX512 strictly depends on AVX2. >> >> >> >> In which case, the python code was correct. The meaning of the >> >> key/value >> > relationship is "if the feature in the key is not present, all >> >> features in the value must also be disabled". >> > >> > Hi jan, what is your opinion? >> >> There's no opinion to be had here, according to your earlier reply. I do, > however, continue to question that model: State and >> instruction set are independent items. Of course YMM state is a prereq to > ZMM state, but I do not buy AVX2 insn support being a >> prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature flags >> solely > represent the instructions, while the XSTATE leaf bits >> represent the states. >> > > Hi jan, > I get some information from hardware colleague. There is no dependence > about AVX512 instructions and AVX2 instructions. It is also not states in the > official document. As I had assumed. >But I want to know the meaning of the dependence "AVX2: [AVX512F]" in > "gen-cpuid.py" file. >If it is the feature dependence, I think the dependence between AVX512 > and AVX2 may need to add. As we talk before, Zmm is part of AVX512 feature. > If the state for AVX2 isn't enabled (in XCR0), then AVX512 also can't > function. Apart from that, there is no processors with AVX512 without AVX2 > currently and it is safe to treat AVX2 as part of the thermometer leading to > AVX512. Regarding if will have a cpu support avx512 without avx2 in future, > it is really hard to say. > If it is the instructions dependence, I have no idea to delete this > dependence in "gen-cpuid.py" file. > So, I want to know your advice. Well, the main issue here is that we have no feature flag representation for the xstate bits. If we had, the relevant parts of the dependencies should look like XSTATE_YMM: [AVX, XSTATE_ZMM] AVX: [AVX2] XSTATE_ZMM: [AVX512F] AVX512F: [AVX512CD, ...] But in their absence I guess keeping the AVX2 dependency as you have it is the only reasonable approach. Just that I'd like it to be accompanied by a comment explaining that this isn't the actual dependency (so that if XSTATE feature flags got introduced later, it would be clear how to adjust those parts). Andrew - I keep forgetting why you think having such XSTATE_* feature flags is not appropriate. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] solve SMAP/SMEP issues with 32-bit pv guests
On Tue, Aug 9, 2016 at 10:13 AM, He Chen wrote: > This patch is going to solve SMAP/SMEP issues with 32-bit pv guests by > adding new xen command line options "xen_smap" and "xen_smep". > > For the details, please see: > https://lists.xen.org/archives/html/xen-devel/2016-06/msg03441.html > > I am sorry that I don't have 32-bit PV environment to test this patch, > I would really appreciate it if someone could help verify this patch :) > > He Chen (1): > xen: enable/disable SMAP/SMEP for Xen itself > > docs/misc/xen-command-line.markdown | 14 ++ > xen/arch/x86/setup.c| 12 ++-- > 2 files changed, 24 insertions(+), 2 deletions(-) > > -- > 1.9.1 There doesn't seem to be any actual content here. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/NUMA: cleanup
On 10/08/16 10:24, Jan Beulich wrote:
> - drop the only left CONFIG_NUMA conditional (this is always true)
I observe that CONFIG_NUMA_EMU is also unconditionally true, which
offers further cleanup opportunities (albeit it probably a separate patch).
> - drop struct node_data's node_id field (being always equal to the
> node_data[] array index used)
> - don't open code node_{start,end}_pfn() nor node_spanned_pages()
> except when used as lvalues (those could be converted too, but this
> seems a little awkward)
> - no longer open code pfn_to_paddr() in an expression being modified
> anyway
> - make dump less verbose by logging actual vs intended node IDs only
> when they don't match
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
>>> On 10.08.16 at 10:09, wrote:
>
> On 8/8/2016 11:40 PM, Jan Beulich wrote:
> On 12.07.16 at 11:02, wrote:
>>> @@ -178,8 +179,34 @@ static int hvmemul_do_io(
>>> break;
>>> case X86EMUL_UNHANDLEABLE:
>>> {
>>> -struct hvm_ioreq_server *s =
>>> -hvm_select_ioreq_server(curr->domain, &p);
>>> +struct hvm_ioreq_server *s;
>>> +
>>> +if ( is_mmio )
>>> +{
>>> +unsigned long gmfn = paddr_to_pfn(addr);
>>> +p2m_type_t p2mt;
>>> +
>>> +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
>>> +
>>> +if ( p2mt == p2m_ioreq_server )
>>> +{
>>> +unsigned int flags;
>>> +
>>> +if ( dir != IOREQ_WRITE )
>>> +s = NULL;
>>> +else
>>> +{
>>> +s = p2m_get_ioreq_server(currd, &flags);
>>> +
>>> +if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
>>> +s = NULL;
>>> +}
>>> +}
>>> +else
>>> +s = hvm_select_ioreq_server(currd, &p);
>>> +}
>>> +else
>>> +s = hvm_select_ioreq_server(currd, &p);
>> Wouldn't it both be more natural and make the logic even easier
>> to follow if s got set to NULL up front, all the "else"-s dropped,
>> and a simple
>>
>> if ( !s )
>> s = hvm_select_ioreq_server(currd, &p);
>>
>> be done in the end?
>>
>
> Sorry, Jan. I tried to simplify above code, but found the new code is
> still not very
> clean, because in some cases the s is supposed to return NULL instead
> of to be
> set from the hvm_select_ioreq_server().
> To keep the same logic, the simplified code looks like this:
>
> case X86EMUL_UNHANDLEABLE:
> {
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, &p);
> +struct hvm_ioreq_server *s = NULL;
> +p2m_type_t p2mt = p2m_invalid;
> +
> +if ( is_mmio && dir == IOREQ_WRITE )
> +{
> +unsigned long gmfn = paddr_to_pfn(addr);
> +
> +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
> +
> +if ( p2mt == p2m_ioreq_server )
> +{
> +unsigned int flags;
> +
> +s = p2m_get_ioreq_server(currd, &flags);
> +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> +s = NULL;
> +}
> +}
> +
> +if ( !s && p2mt != p2m_ioreq_server )
> +s = hvm_select_ioreq_server(currd, &p);
>
> /* If there is no suitable backing DM, just ignore accesses */
> if ( !s )
>
> As you can see, definition of p2mt is moved outside the if ( is_mmio )
> judgement,
> and is checked against p2m_ioreq_server before we search the ioreq
> server's rangeset
> in hvm_select_ioreq_server(). So I am not quite satisfied with this
> simplification.
> Any suggestions?
I think it's better than the code was before, but an implicit part of
my suggestion was that I'm not really convinced the
" && p2mt != p2m_ioreq_server" part of your new conditional is
really needed: Would it indeed be wrong to hand such a request
to the "normal" ioreq server, instead of terminating it right away?
(I guess that's a question to you as much as to Paul.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2016 11:33
> To: Paul Durrant; Yu Zhang
> Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian;
> zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org)
> Subject: Re: [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram
> with p2m_ioreq_server to an ioreq server.
>
> >>> On 10.08.16 at 10:09, wrote:
>
> >
> > On 8/8/2016 11:40 PM, Jan Beulich wrote:
> > On 12.07.16 at 11:02, wrote:
> >>> @@ -178,8 +179,34 @@ static int hvmemul_do_io(
> >>> break;
> >>> case X86EMUL_UNHANDLEABLE:
> >>> {
> >>> -struct hvm_ioreq_server *s =
> >>> -hvm_select_ioreq_server(curr->domain, &p);
> >>> +struct hvm_ioreq_server *s;
> >>> +
> >>> +if ( is_mmio )
> >>> +{
> >>> +unsigned long gmfn = paddr_to_pfn(addr);
> >>> +p2m_type_t p2mt;
> >>> +
> >>> +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
> >>> +
> >>> +if ( p2mt == p2m_ioreq_server )
> >>> +{
> >>> +unsigned int flags;
> >>> +
> >>> +if ( dir != IOREQ_WRITE )
> >>> +s = NULL;
> >>> +else
> >>> +{
> >>> +s = p2m_get_ioreq_server(currd, &flags);
> >>> +
> >>> +if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
> >>> +s = NULL;
> >>> +}
> >>> +}
> >>> +else
> >>> +s = hvm_select_ioreq_server(currd, &p);
> >>> +}
> >>> +else
> >>> +s = hvm_select_ioreq_server(currd, &p);
> >> Wouldn't it both be more natural and make the logic even easier
> >> to follow if s got set to NULL up front, all the "else"-s dropped,
> >> and a simple
> >>
> >> if ( !s )
> >> s = hvm_select_ioreq_server(currd, &p);
> >>
> >> be done in the end?
> >>
> >
> > Sorry, Jan. I tried to simplify above code, but found the new code is
> > still not very
> > clean, because in some cases the s is supposed to return NULL instead
> > of to be
> > set from the hvm_select_ioreq_server().
> > To keep the same logic, the simplified code looks like this:
> >
> > case X86EMUL_UNHANDLEABLE:
> > {
> > -struct hvm_ioreq_server *s =
> > -hvm_select_ioreq_server(curr->domain, &p);
> > +struct hvm_ioreq_server *s = NULL;
> > +p2m_type_t p2mt = p2m_invalid;
> > +
> > +if ( is_mmio && dir == IOREQ_WRITE )
> > +{
> > +unsigned long gmfn = paddr_to_pfn(addr);
> > +
> > +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
> > +
> > +if ( p2mt == p2m_ioreq_server )
> > +{
> > +unsigned int flags;
> > +
> > +s = p2m_get_ioreq_server(currd, &flags);
> > +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> > +s = NULL;
> > +}
> > +}
> > +
> > +if ( !s && p2mt != p2m_ioreq_server )
> > +s = hvm_select_ioreq_server(currd, &p);
> >
> > /* If there is no suitable backing DM, just ignore accesses */
> > if ( !s )
> >
> > As you can see, definition of p2mt is moved outside the if ( is_mmio )
> > judgement,
> > and is checked against p2m_ioreq_server before we search the ioreq
> > server's rangeset
> > in hvm_select_ioreq_server(). So I am not quite satisfied with this
> > simplification.
> > Any suggestions?
>
> I think it's better than the code was before, but an implicit part of
> my suggestion was that I'm not really convinced the
> " && p2mt != p2m_ioreq_server" part of your new conditional is
> really needed: Would it indeed be wrong to hand such a request
> to the "normal" ioreq server, instead of terminating it right away?
> (I guess that's a question to you as much as to Paul.)
>
Well, I thought the correct semantics for p2m_ioreq_server without any
interception are the same as p2m_ram_rw. In which case if we find an ioreq
server, but it does not want to emulate writes, then we should complete the I/O
by writing to guest RAM. But, how are we ever going to hit this code-path
without some form of race with EPT configuration?
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area
>>> On 10.08.16 at 08:59, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim)
> printk("%s:%08x %016"PRIx64"\n", name, limit, base);
> }
>
> +static void vmx_dump_vcpu_msr_area(struct vcpu *v)
const
> +{
> +const struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
> +unsigned int i, msr_count = v->arch.hvm_vmx.msr_count;
> +
> +printk(" msr_count = %d\n", v->arch.hvm_vmx.msr_count);
Please use the local variable you have just latched and %u.
> +for ( i = 0; i < msr_count; i++ )
> +{
> +printk(" msr_area[%d].index=0x%08x .data=0x%016lx\n",
[%u], and I'm not sure the 0x prefixes are really all that helpful
here. I think it would also be beneficial to shorten the logged text
a little, as this may consume quite a bit of serial line bandwidth.
How about " MSR[%08x]=%016lx\n"?
> @@ -1879,6 +1893,13 @@ void vmcs_dump_vcpu(struct vcpu *v)
> (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS)
> )
> printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
> vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
> +printk("EXIT MSR load count = 0x%04x\n",
> + (uint32_t)vmr(VM_EXIT_MSR_LOAD_COUNT));
> +printk("EXIT MSR store count = 0x%04x\n",
> + (uint32_t)vmr(VM_EXIT_MSR_STORE_COUNT));
> +printk("ENTRY MSR load count = 0x%04x\n",
> + (uint32_t)vmr(VM_ENTRY_MSR_LOAD_COUNT));
First - do you really need to make three log lines out of these? And
then, please use vmr32(), as the neighboring vmr16() suggests.
Plus finally - please log all four counts consistently either in hex
or in dec.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
On 08/10/2016 01:12 PM, Jan Beulich wrote: On 10.08.16 at 09:35, wrote: >> --- a/xen/common/vm_event.c >> +++ b/xen/common/vm_event.c >> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct >> vm_event_domain *ved) >> v = d->vcpu[rsp.vcpu_id]; >> >> /* >> + * Make sure the vCPU state has been synchronized for the custom >> + * handlers. >> + */ >> +if ( atomic_read(&v->vm_event_pause_count) ) >> +sync_vcpu_execstate(v); > > It seems to me that the latest with this change using a simple > atomic_t won't suffice anymore - you'd now really need to > make sure the user mode tools can't resume that vCPU behind > your back, which aiui can only be achieved by using a suitable > lock (perhaps a read/write one if reading the pause count is > more common than updating it). I'm not sure how that would happen, vm_event_vcpu_pause() increments v->vm_event_pause_count, and then calls vcpu_pause_nosync(v), which then increments it's own counter. So there doesn't seem to be a possibility of v->vm_event_pause_count being > 0 while the vCPU is unpaused, and there should also be no possibility that vm_event_resume() and vm_event_pause() could happen on the same vCPU at the same time. If there are unbalanced vcpu_pause() / vcpu_unpause() somewhere else in the code, that surely would be bug. Am I missing a scenario? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 8/10/2016 6:33 PM, Jan Beulich wrote:
On 10.08.16 at 10:09, wrote:
On 8/8/2016 11:40 PM, Jan Beulich wrote:
On 12.07.16 at 11:02, wrote:
@@ -178,8 +179,34 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
Wouldn't it both be more natural and make the logic even easier
to follow if s got set to NULL up front, all the "else"-s dropped,
and a simple
if ( !s )
s = hvm_select_ioreq_server(currd, &p);
be done in the end?
Sorry, Jan. I tried to simplify above code, but found the new code is
still not very
clean, because in some cases the s is supposed to return NULL instead
of to be
set from the hvm_select_ioreq_server().
To keep the same logic, the simplified code looks like this:
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio && dir == IOREQ_WRITE )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);
/* If there is no suitable backing DM, just ignore accesses */
if ( !s )
As you can see, definition of p2mt is moved outside the if ( is_mmio )
judgement,
and is checked against p2m_ioreq_server before we search the ioreq
server's rangeset
in hvm_select_ioreq_server(). So I am not quite satisfied with this
simplification.
Any suggestions?
I think it's better than the code was before, but an implicit part of
my suggestion was that I'm not really convinced the
" && p2mt != p2m_ioreq_server" part of your new conditional is
really needed: Would it indeed be wrong to hand such a request
to the "normal" ioreq server, instead of terminating it right away?
(I guess that's a question to you as much as to Paul.)
Thanks for your reply, Jan.
For " && p2mt != p2m_ioreq_server" condition, it is just to guarantee
that if a write
operation is trapped, and at the same period, device model changed the
status of
ioreq server, it should be discarded.
A second thought is, I am now more worried about the " && dir ==
IOREQ_WRITE"
condition, which we used previously to set s to NULL if it is not a
write operation.
However, if HVM uses a read-modify-write instruction to operate on a
write-protected
address, it will be treated as both read and write accesses in
ept_handle_violation(). In
such situation, we need to emulate the read access first(by just
returning the value being
fetched either in hypervisor or in device model), instead of discarding
the read access.
Thanks
Yu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH v2] xtf-runner: use xl create -Fc directly
On Tue, Aug 09, 2016 at 04:37:40PM +0100, Wei Liu wrote: > On Tue, Aug 09, 2016 at 02:11:27PM +0100, Andrew Cooper wrote: > > On 08/08/16 14:13, Wei Liu wrote: > > > On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote: > > >> On 08/08/16 12:24, Wei Liu wrote: > > >>> Now that xl create -c is fixed in xen-unstable, there is no need to keep > > >>> the hack to get guest console output anymore. > > >>> > > >>> Use xl create -Fc directly, then wait for the xl process to exit. Print > > >>> any error as it occurs. > > >>> > > >>> Signed-off-by: Wei Liu > > >> Sadly, now I think about this further, it does re-introduce the > > >> serialisation problem I was trying specifically trying to avoid. > > >> > > > Can you give an example of the race you wanted to avoid? > > > > > > I thought with the xenconsole work in place I had solved all races I was > > > aware of, but maybe I missed something obvious. > > > > It isn't a race. I do not want synchronously wait for the taredown of > > domains to complete, as it adds unnecessary latency when running more > > than a single test. > > > > >> You need to run `xl create -F` so you can sensibly wait on the create > > >> list to avoid tripping up the leak detection. > > >> > > >> However, the guest.communicate() call will wait for the guest process to > > >> terminate, which includes all output. > > >> > > > Is there a problem with that? > > > > It makes your "for child in child_list" useless, as all processes have > > guareteed to exit already. > > > > > > > >> Therefore, I think we still need the `xl create -Fp`, `xl console`, `xl > > >> unpause` dance, where the create process gets put on the create_list, > > There are several issues with this. > > Let's go back to the original `xl create -p`, `xl console` and `xl > unpause` first. This sequence is not race-free. > > xl create -p can race with xl console. That, however, is mitigated by > xl console waiting for 5s for tty node to show up and the use of > subproc_call in runner. > > xl unpause can race with xl console (Popen doesn't wait for process to > finish). The domain can be unpaused and exit before xl console gets a > chance to attach. This would cause random failure in osstest. > > See > > http://osstest.xs.citrite.net/~osstest/testlogs/logs/66926/test-xtf-amd64-amd64-2/info.html > http://osstest.xs.citrite.net/~osstest/testlogs/logs/66926/test-xtf-amd64-amd64-2/gall-mite---var-log-xen-console-guest-test-hvm32-fep.log > > My theory is that the failure in fep test is due to the second race. > Unfortunately I can't reproduce that locally at the moment. > > Then let's look at `xl create -Fp`, `xl console` and `xl unpause` > sequence. `xl create -Fp` doesn't return until the guest vanishes, so > that means we need to use Popen to run it. The leaves us even less clue > to tell when to execute `xl console`. The first race can only become > worse. The second race still exists. > > If you want to retain this trick. I'm afraid what you need is more or > less my very first patch. > > > >> and it is the console process which gets communicated with. > > >> > > >> This also has the advantage that it doesn't cause ./xtf-runner to break > > >> against all non-staging trees. > > >> > > > I thought we decided to grep log file for that? > > > > Right, but until that happens, this patch constitutes a functional > > regression. > > > > Hmm... I think we're talking past each other. Let me clarify. > > There are two distinct use cases: used by a human vs used by an > automated test system like osstest. > > For osstest this is not a functional regression because that function is > not reliable in the first place. We would need grepping log file to fix > the issue. > > For a human, because he or she doesn't care about 1 in 50 random > failure, this is a functional regression. It's still something that > should be fixed (and can be fixed) by grepping log file, but obviously > less important. > > I don't want to mix these two use cases. This patch is indeed biased > towards the automated test system. I think I can retain the original > function and test the version of Xen it runs on to decide which version > to use. > > FAOD my impression is that you have strong opinions on how log grepping > should be implemented. That's why I didn't do it. > And if I were to do it, I would use the simplest approach that I can think of. IIRC you mentioned config file to tell which mode the runner to operate. I think that's a bit overkilled, but I'm not sure I can second-guess what you want to achieve. From 51039110233cabb490c978e7da7dc70d0d30bdcb Mon Sep 17 00:00:00 2001 From: Wei Liu Date: Wed, 10 Aug 2016 11:40:07 +0100 Subject: [XTF PATCH] xtf-runner: skeleton for different modes to get output Signed-off-by: Wei Liu --- xtf-runner | 24 1 file changed, 24 insertions(+) diff --git a/xtf-runner b/xtf-runner index 3bb98e0..694b591 100755 --- a/xtf-runner +++ b/xtf-runner @@ -536,6 +536,19
Re: [Xen-devel] Save/Restore is not working properly
On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: > Hi, > I was searching a way to clone a machine using both memory and disk > approach. > I checked xen save/restore but after restoring, I can only work some > seconds with my machine and it will crash with the_kernel_task_hang_up. > using an script* to clone a machine is not working either. > so is it a bug or something or I'm cloning the wrong way? Hello, I've not tried to perform cloning myself, but I have a little script to perform VM checkpoints (so that you can restore the VM to any given point in time). It's based on FreeBSD so it uses ZFS, but it should work with LVM also if you replace it with the appropriate runes. AFAICT it should be quite easy to expand it to also do VM cloning. This is transparent from a VM point of view. Roger. --- #!/bin/sh -e if [ "$#" -ne 1 ]; then echo "Illegal number of parameters" exit fi stamp=`date +%y-%m-%d-%H:%M.%S` xl save $1 $1.$stamp zfs snapshot tank/$1@$stamp xl restore $1.$stamp ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 100390: all pass - PUSHED
flight 100390 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100390/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 7f5c8075364776eb139bbd421ad443ae9e4465dc
baseline version:
xen 7da483b0236d8974cc97f81780dcf8e559a63175
Last test of basis96924 2016-07-10 09:19:23 Z 31 days
Failing since 97501 2016-07-17 09:26:52 Z 24 days5 attempts
Testing same since 100390 2016-08-10 09:19:20 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Anshul Makkar
Bob Liu
Boris Ostrovsky
Chao Gao
Chris Patterson
Corneliu ZUZU
Daniel De Graaf
Dario Faggioli
David Scott
Doug Goldstein
Elena Ufimtseva
George Dunlap
Ian Jackson
Ian Jackson
Jacob Pan
Jan Beulich
Jim Fehlig
Joao Martins
Jonathan Daugherty
Juergen Gross
Julien Grall
Kevin Tian
Konrad Rzeszutek Wilk
Len Brown
Marek Marczykowski-Górecki
Paul Durrant
Quan Xu
Quan Xu
Rafael J. Wysocki
Razvan Cojocaru
Roger Pau Monne
Roger Pau Monné
Sander Eikelenboom
Shanker Donthineni
Stefano Stabellini
Tamas K Lengyel
Tim Deegan
Vitaly Kuznetsov
Wei Liu
Yu Zhang
jobs:
coverity-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-coverity
+ revision=7f5c8075364776eb139bbd421ad443ae9e4465dc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push
xen-unstable-coverity 7f5c8075364776eb139bbd421ad443ae9e4465dc
+ branch=xen-unstable-coverity
+ revision=7f5c8075364776eb139bbd421ad443ae9e4465dc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' x7f5c8075364776eb139bbd421ad443ae9e4465dc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
Re: [Xen-devel] xl dump-core fails, j!=nr_pages
On Wed, Aug 10, 2016 at 10:25:30AM +0200, Olaf Hering wrote: > On Wed, Aug 10, Olaf Hering wrote: > > This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work > with HVM guests? I think at some point 'xm dump-core' used to work, just > crash(1) could not deal with the result. > > > xc: info: j (63635) != nr_pages (65709) Does xl crash? I think this is only informational. > > memory=256 > > > memory=1024 > > xc: info: j (260243) != nr_pages (262309) > > What are those missing 2066 pages? > Maybe the guest ballooned out some pages? I haven't really checked all the code though. Wei. > Olaf > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file
COPYING file: The motivation of this change is to make it easier for new contributors to conduct a license and patent review, WITHOUT changing any licenses. - Remove references to BSD-style licenses as we have more common license exceptions and replace with "other license stanzas" - List the most common situations under which code is licensed under licenses other than GPLv2 (section "Licensing Exceptions") - List the most common non-GPLv2 licenses that are in use in this repository based on a recent FOSSology scan (section "Licensing Exceptions") - List other license related conventions within the project to make it easier to conduct a license review. - Clarify the incoming license as its omission has confused past contributors (section "Contributions") CONTRIBUTION file: The motivation of this file is to make it easier for contributors to find contribution related resources. Add information on existing license related conventions to avoid unintentional future licensing issues. Provide templates for copyright headers for the most commonly used licenses in this repository. Signed-off-by: Lars Kurth --- CONTRIBUTING | 210 +++ COPYING | 64 ++ 2 files changed, 260 insertions(+), 14 deletions(-) create mode 100644 CONTRIBUTING diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 000..7af13c4 --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,210 @@ + +CONTRIBUTING + + +INBOUND LICENSE +--- + +Contributions are governed by the license that applies to relevant +specific file or by the license specified in the COPYING file, that +governs the license of its containing directory and its subdirectories. + +Most of the Xen Project code is licensed under GPLv2, but a number of +directories are primarily licensed under different licenses. + +Most notably: + - tools/blktap2 : BSD-Modified + - tools/libxc: LGPL v2.1 + - tools/libxl: LGPL v2.1 + - xen/include/public : MIT license + +When creating new components and directories that contain a +significant amount of files that are licensed under licenses other +than GPLv2 or the license specified in the COPYING file, please +create a new COPYING file in that directory containing a copy of the +license text and a rationale for using a different license. This helps +ensure that the license of this new component/directory is maintained +consistently with the original intention. + +When importing code from other upstream projects into this repository, +please create a README.source file in the directory the code is imported +to, listing the original source of the code. An example can be found at +m4/README.source + +The COMMON COPYRIGHT NOTICES section of this document contains +sample copyright notices for the most common licenses used within +this repository. + +Developer's Certificate of Origin +- + +All patches to the Xen Project code base must include the the line +"Signed-off-by: your_name " at the end of the change +description. This is required and indicates that you certify the patch +under the "Developer's Certificate of Origin" which states: + + Developer's Certificate of Origin 1.1 + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + + (b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + + (c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. + +GOVERNANCE AND WORKFLOW +--- + +The following documents provide a general overview of governance and +contribution guidelines for the Xen Project: + - https://xenproject.org/governance.html + - https://xenproject.org/help/contribution-guidelines.html + +For more information on contributing to this repository, see + - CODING_STYLE file in this directory + - https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches + - https://wiki.xenproject.org/wiki/Submitting_Xen_Patches_with_Git + - https://wiki.xenproject.org/wiki/Askin
Re: [Xen-devel] [XTF PATCH v2] xtf-runner: use xl create -Fc directly
On 10/08/16 12:01, Wei Liu wrote: > On Tue, Aug 09, 2016 at 04:37:40PM +0100, Wei Liu wrote: >> On Tue, Aug 09, 2016 at 02:11:27PM +0100, Andrew Cooper wrote: >>> On 08/08/16 14:13, Wei Liu wrote: On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote: > On 08/08/16 12:24, Wei Liu wrote: >> Now that xl create -c is fixed in xen-unstable, there is no need to keep >> the hack to get guest console output anymore. >> >> Use xl create -Fc directly, then wait for the xl process to exit. Print >> any error as it occurs. >> >> Signed-off-by: Wei Liu > Sadly, now I think about this further, it does re-introduce the > serialisation problem I was trying specifically trying to avoid. > Can you give an example of the race you wanted to avoid? I thought with the xenconsole work in place I had solved all races I was aware of, but maybe I missed something obvious. >>> It isn't a race. I do not want synchronously wait for the taredown of >>> domains to complete, as it adds unnecessary latency when running more >>> than a single test. >>> > You need to run `xl create -F` so you can sensibly wait on the create > list to avoid tripping up the leak detection. > > However, the guest.communicate() call will wait for the guest process to > terminate, which includes all output. > Is there a problem with that? >>> It makes your "for child in child_list" useless, as all processes have >>> guareteed to exit already. >>> > Therefore, I think we still need the `xl create -Fp`, `xl console`, `xl > unpause` dance, where the create process gets put on the create_list, >> There are several issues with this. >> >> Let's go back to the original `xl create -p`, `xl console` and `xl >> unpause` first. This sequence is not race-free. >> >> xl create -p can race with xl console. That, however, is mitigated by >> xl console waiting for 5s for tty node to show up and the use of >> subproc_call in runner. >> >> xl unpause can race with xl console (Popen doesn't wait for process to >> finish). The domain can be unpaused and exit before xl console gets a >> chance to attach. This would cause random failure in osstest. >> >> See >> >> http://osstest.xs.citrite.net/~osstest/testlogs/logs/66926/test-xtf-amd64-amd64-2/info.html >> http://osstest.xs.citrite.net/~osstest/testlogs/logs/66926/test-xtf-amd64-amd64-2/gall-mite---var-log-xen-console-guest-test-hvm32-fep.log >> >> My theory is that the failure in fep test is due to the second race. >> Unfortunately I can't reproduce that locally at the moment. >> >> Then let's look at `xl create -Fp`, `xl console` and `xl unpause` >> sequence. `xl create -Fp` doesn't return until the guest vanishes, so >> that means we need to use Popen to run it. The leaves us even less clue >> to tell when to execute `xl console`. The first race can only become >> worse. The second race still exists. >> >> If you want to retain this trick. I'm afraid what you need is more or >> less my very first patch. >> > and it is the console process which gets communicated with. > > This also has the advantage that it doesn't cause ./xtf-runner to break > against all non-staging trees. > I thought we decided to grep log file for that? >>> Right, but until that happens, this patch constitutes a functional >>> regression. >>> >> Hmm... I think we're talking past each other. Let me clarify. >> >> There are two distinct use cases: used by a human vs used by an >> automated test system like osstest. >> >> For osstest this is not a functional regression because that function is >> not reliable in the first place. We would need grepping log file to fix >> the issue. >> >> For a human, because he or she doesn't care about 1 in 50 random >> failure, this is a functional regression. It's still something that >> should be fixed (and can be fixed) by grepping log file, but obviously >> less important. >> >> I don't want to mix these two use cases. This patch is indeed biased >> towards the automated test system. I think I can retain the original >> function and test the version of Xen it runs on to decide which version >> to use. >> >> FAOD my impression is that you have strong opinions on how log grepping >> should be implemented. That's why I didn't do it. >> > And if I were to do it, I would use the simplest approach that I can > think of. IIRC you mentioned config file to tell which mode the runner > to operate. I think that's a bit overkilled, but I'm not sure I can > second-guess what you want to achieve. This is broadly in the right direction. > > > From 51039110233cabb490c978e7da7dc70d0d30bdcb Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Wed, 10 Aug 2016 11:40:07 +0100 > Subject: [XTF PATCH] xtf-runner: skeleton for different modes to get output > > Signed-off-by: Wei Liu > --- > xtf-runner | 24 > 1 file changed, 24 insertions(+) > > diff --git a/xtf-runner b/xtf-runn
Re: [Xen-devel] [PATCH 2/2] x86/NUMA: cleanup
>>> On 10.08.16 at 12:35, wrote: > On 10/08/16 10:24, Jan Beulich wrote: >> - drop the only left CONFIG_NUMA conditional (this is always true) > > I observe that CONFIG_NUMA_EMU is also unconditionally true, which > offers further cleanup opportunities (albeit it probably a separate patch). So I thought, but then wasn't sure eliminating just the conditionals it would actually be the right route - the alternative would be to instead just drop that NUMA emulation code altogether, as no-one should be using it. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
>>> On 10.08.16 at 12:55, wrote: > On 08/10/2016 01:12 PM, Jan Beulich wrote: > On 10.08.16 at 09:35, wrote: >>> --- a/xen/common/vm_event.c >>> +++ b/xen/common/vm_event.c >>> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct > vm_event_domain *ved) >>> v = d->vcpu[rsp.vcpu_id]; >>> >>> /* >>> + * Make sure the vCPU state has been synchronized for the custom >>> + * handlers. >>> + */ >>> +if ( atomic_read(&v->vm_event_pause_count) ) >>> +sync_vcpu_execstate(v); >> >> It seems to me that the latest with this change using a simple >> atomic_t won't suffice anymore - you'd now really need to >> make sure the user mode tools can't resume that vCPU behind >> your back, which aiui can only be achieved by using a suitable >> lock (perhaps a read/write one if reading the pause count is >> more common than updating it). > > I'm not sure how that would happen, vm_event_vcpu_pause() increments > v->vm_event_pause_count, and then calls vcpu_pause_nosync(v), which then > increments it's own counter. > > So there doesn't seem to be a possibility of v->vm_event_pause_count > being > 0 while the vCPU is unpaused, and there should also be no > possibility that vm_event_resume() and vm_event_pause() could happen on > the same vCPU at the same time. Here you say "should", which is exactly what worries me: Is it technically possible or not? If it is, there is the potential for a race (with a buggy or malicious user mode tool). If there isn't, calling out what it is that guarantees that in the commit message (or even a code comment) would be much appreciated. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
On 10/08/16 11:29, Jan Beulich wrote: On 10.08.16 at 11:58, wrote: >> On 03.08.16 at 03:32, wrote: > On 25/07/16 07:09, Kang, Luwei wrote: > First of all - please don't top post. > >> What about remove the dependency between AVX2 and AVX512F >>> ( AVX2: > [AVX512F], ) ? > > Yes, that's what I think we want, but we need Andrew's agreement here. > Hi Andrew, what is your opinion ? >>> You are in a better position to answer than me. >>> >>> For a specific instruction which may be VEX and EVEX encoded, is >>> the circuitry for a specific instruction shared, or discrete? Is >>> there a plausible future where you might support only the EVEX >>> variant of an instruction, and not the VEX variant? >>> >>> These dependences are about what may be reasonably assumed about >>> the way the environment is structured. It doesn't look reasonable >>> to advertise an AVX512 environment to guests while at the same >>> time stating that AVX2 is not present. If this is correct, then >>> the dependency should stay. >>> If Intel plausibly things it might release hardware with !AVX2 but >>> AVX512, then the dependency should be dropped. >> Regarding the dependency between AVX2 and AVX512F, I have ask some >> hardware architecture engineer. >> AVX512 is a superset of AVX2, the most important item being the >> state. If the state for AVX2 isn't enabled (in XCR0), then AVX512 > also can't function. >> So if we want to use AVX512, AVX2 must be supported and enabled. >> The dependence between AVX512F and AVX2 may need be > reserved. > > Ok, so AVX512 strictly depends on AVX2. > > In which case, the python code was correct. The meaning of the > key/value relationship is "if the feature in the key is not present, all > features in the value must also be disabled". Hi jan, what is your opinion? >>> There's no opinion to be had here, according to your earlier reply. I do, >> however, continue to question that model: State and >>> instruction set are independent items. Of course YMM state is a prereq to >> ZMM state, but I do not buy AVX2 insn support being a >>> prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature flags >>> solely >> represent the instructions, while the XSTATE leaf bits >>> represent the states. >>> >> Hi jan, >> I get some information from hardware colleague. There is no dependence >> about AVX512 instructions and AVX2 instructions. It is also not states in >> the >> official document. > As I had assumed. > >>But I want to know the meaning of the dependence "AVX2: [AVX512F]" in >> "gen-cpuid.py" file. >>If it is the feature dependence, I think the dependence between AVX512 >> and AVX2 may need to add. As we talk before, Zmm is part of AVX512 feature. >> If the state for AVX2 isn't enabled (in XCR0), then AVX512 also can't >> function. Apart from that, there is no processors with AVX512 without AVX2 >> currently and it is safe to treat AVX2 as part of the thermometer leading to >> AVX512. Regarding if will have a cpu support avx512 without avx2 in future, >> it is really hard to say. >> If it is the instructions dependence, I have no idea to delete this >> dependence in "gen-cpuid.py" file. >> So, I want to know your advice. > Well, the main issue here is that we have no feature flag representation > for the xstate bits. If we had, the relevant parts of the dependencies > should look like > > XSTATE_YMM: [AVX, XSTATE_ZMM] > AVX: [AVX2] > XSTATE_ZMM: [AVX512F] > AVX512F: [AVX512CD, ...] > > But in their absence I guess keeping the AVX2 dependency as you have > it is the only reasonable approach. Just that I'd like it to be accompanied > by a comment explaining that this isn't the actual dependency (so that if > XSTATE feature flags got introduced later, it would be clear how to > adjust those parts). > > Andrew - I keep forgetting why you think having such XSTATE_* feature > flags is not appropriate. This is all about providing a plausible cpuid layout to a guest. It is not plausible that we will ever see a processor with e.g. AVX512F but not XSTATE_ZMM. Therefore, to avoid that misconfiguration (or the inverse misconfiguration) from ever occurring, the XSTATE is derived from the plain feature flags. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible
On 09/08/16 15:39, Jan Beulich wrote:
On 09.08.16 at 16:27, wrote:
>> On 09/08/16 15:01, Jan Beulich wrote:
>> On 09.08.16 at 14:41, wrote:
The use of -fno-builtin inhibits this automatic transformation. Manually
tranform the callsites. This causes constructs such as strlen("literal")
to
be evaluated at compile time, and certain simple operations to be replaced
with repeated string operations.
>>> Iirc this was specifically avoided in at least older Linux because of
>>> compiler issues. Are you reasonably certain that those issues
>>> predate gcc 4.1.x (and don't exist at all in clang)? Other than that
>>> I'm of course fine with this patch.
>> Do you have any reference to these issues? I cant find any reference.
> This was when I barley started working with Linux, i.e. in late 2.4.x
> or early 2.6.x times. Querying Google seems to indicate that
> someone reported successful use in 2.6.3.
>
>> I notice that Linux doesn't use these builtins, even today, but does
>> have arch specific implementations which are more efficient than our
>> common ones. Still, it doesn't appear to be able to do any compile-time
>> evaluation.
> Isn't it surprising that no-one has submitted Linux patches to
> change that? Anyway, please consider the patch ack-ed. We
> can always revert it in case we run into problems (and once
> my hardware setup will be fully functional again, I will test with
> a reasonably old gcc anyway).
It turns out that in its current form, it breaks the clang build, citing
string.c:45:5: error: definition of builtin function '__builtin_strcasecmp'
int strcasecmp(const char *s1, const char *s2)
^
/local/xen.git/xen/include/asm/string.h:18:28: note: expanded from macro
'strcasecmp'
#define strcasecmp(s1, s2) __builtin_strcasecmp(s1, s2)
^
which is something GCC clearly doesn't mind so much.
I will see about reworking it.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
On 10/08/16 11:21, Jan Beulich wrote:
On 10.08.16 at 11:58, wrote:
>> On 10/08/16 10:23, Jan Beulich wrote:
>>> --- a/xen/arch/x86/numa.c
>>> +++ b/xen/arch/x86/numa.c
>>> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
>>> }
>>> }
>>>
>>> -EXPORT_SYMBOL(cpu_to_node);
>>> -EXPORT_SYMBOL(node_to_cpumask);
>>> -EXPORT_SYMBOL(memnode_shift);
>>> -EXPORT_SYMBOL(memnodemap);
>>> -EXPORT_SYMBOL(node_data);
>>> +unsigned int __init arch_get_dma_bitsize(void)
>>> +{
>>> +unsigned int node;
>>> +
>>> +for_each_online_node(node)
>>> +if ( node_spanned_pages(node) &&
>>> + !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
>>> +break;
>>> +if ( node >= MAX_NUMNODES )
>>> +panic("No node with memory below 4Gb");
>>> +
>>> +return min_t(unsigned int,
>>> + flsl(node_start_pfn(node) + node_spanned_pages(node) / 4
>>> - 1)
>>> + + PAGE_SHIFT, 32);
>> You have moved the -1 and -2 inside the flsl() call, which alters its
>> behaviour quite a bit. Is this intentional or accidental?
> This is intentional, and their original placement was only not too
> wrong because of the effective use of zero in place of what is
> now node_start_pfn(node). (Obviously the division by 4 alone
> could have gone in either place, but the "- 1" should have been
> inside the flsl() even before imo.)
In which case it should be at least mentioned in the commit message.
Finally, do you really mean to only divide the spanned pages by 4?
Either way, it could do with further bracketing.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk
>>> On 10.08.16 at 08:59, wrote:
> Systems that support LBR formats that include TSX information but do
> not support TSX require special handling when saving and restoring MSR
> values. For example, see the Linux kernel quirks[1, 2] in the MSR
> context switching code. As a wrmsr with certain values under these
> conditions causes a #GP, VM entry will fail due to MSR loading (see
> last bullet of SDM 26.4 "Loading MSRS").
I had recently noticed this as an area needing work too, so I'm glad
you (hopefully) eliminate this item from my todo list. However, I'm
sad to see that you really just disable LBR use in the problem case.
I'd prefer to take such a change only as an immediate workaround,
with the understanding that a proper one will be made available not
too much later.
Jun, Kevin - workarounds for hardware quirks like this one are really
what I would think should come out of Intel, and preferably not
after the first problem report on Xen, but soon after the quirk has
got identified in general (which according to the Linux patches must
have been at least 2 months ago).
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2576,8 +2576,22 @@ static const struct lbr_info *last_branch_msr_get(void)
> /* Haswell */
> case 60: case 63: case 69: case 70:
> /* Broadwell */
> -case 61: case 71: case 79: case 86:
> +case 61: case 71: case 79: case 86: {
> +u64 caps;
> +bool_t tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
> + boot_cpu_has(X86_FEATURE_RTM);
> +
> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
This is guarded by a X86_FEATURE_PDCM check in Linux - why
would we not need the same here? Also I think this RDMSR should
be performed once at boot, not every time we come here.
> +/*
> + * Unimplemented fixups are required if the processor
> + * supports an LBR format that includes TSX information,
> + * but not TSX. Disable LBR save/load on such platforms.
> + */
> +if ( !tsx_support && (caps & 4) )
As I understand it the low 6 bits of the MSR contain an enumeration
like value, so just checking bit 2 can't be right (and would wrongly
trigger on already defined format types 5 and 6 - even if those were
known to be impossible on the models currently covered, this would
be a latent trap for someone to fall into when adding further model
values).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711
On 14.07.2016 15:04, Bob Liu wrote:
On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:
On 11.07.2016 15:04, Bob Liu wrote:
On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:
On 06.06.2016 11:42, Dario Faggioli wrote:
Just Cc-ing some Linux, block, and Xen on CentOS people...
Ping.
Any suggestions how to debug this or what might cause the problem?
Obviously, we cannot control Xen on the Amazon's servers. But perhaps there is
something we can do at the kernel's side, is it?
On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:
(Resending this bug report because the message I sent last week did
not
make it to the mailing list somehow.)
Hi,
One of our users gets kernel panics from time to time when he tries
to
use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
happens within minutes from the moment the instance starts. The
problem
does not show up every time, however.
The user first observed the problem with a custom kernel, but it was
found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
CentOS7 was affected as well.
Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc
Regards,
Bob
Unfortunately, it did not help. The same BUG_ON() in blkfront_setup_indirect()
still triggers in our kernel based on RHEL's 3.10.0-327.18.2, where I added the
patch.
As far as I can see, the patch makes sure the indirect pages are added to the list
only if (!info->feature_persistent) holds. I suppose it holds in our case and
the pages are added to the list because the triggered BUG_ON() is here:
if (!info->feature_persistent && info->max_indirect_segments) {
<...>
BUG_ON(!list_empty(&info->indirect_pages));
<...>
}
That's odd.
Could you please try to reproduce this issue with a recent upstream kernel?
Thanks,
Bob
No luck with the upstream kernel 4.7.0 so far due to unrelated issues
(bad initrd, I suppose, so the system does not even boot).
However, the problem reproduced with the stable upstream kernel 3.14.74.
After the system booted the second time with this kernel, that BUG_ON
triggered:
kernel BUG at drivers/block/xen-blkfront.c:1701
So the problem is still out there somewhere, it seems.
Regards,
Evgenii
The part of the system log he was able to retrieve is attached. Here
is
the bug info, for convenience:
[2.246912] kernel BUG at drivers/block/xen-blkfront.c:1711!
[2.246912] invalid opcode: [#1] SMP
[2.246912] Modules linked in: ata_generic pata_acpi
crct10dif_pclmul
crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
xen_netfront xen_blkfront(+) aesni_intel lrw ata_piix gf128mul
glue_helper ablk_helper cryptd libata serio_raw floppy sunrpc
dm_mirror
dm_region_hash dm_log dm_mod scsi_transport_iscsi
[2.246912] CPU: 1 PID: 50 Comm: xenwatch Not tainted
3.10.0-327.18.2.el7.x86_64 #1
[2.246912] Hardware name: Xen HVM domU, BIOS 4.2.amazon
12/07/2015
[2.246912] task: 8800e9fcb980 ti: 8800e98bc000 task.ti:
8800e98bc000
[2.246912] RIP: 0010:[] []
blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
[2.246912] RSP: 0018:8800e98bfcd0 EFLAGS: 00010283
[2.246912] RAX: 8800353e15c0 RBX: 8800e98c52c8 RCX:
0020
[2.246912] RDX: 8800353e15b0 RSI: 8800e98c52b8 RDI:
8800353e15d0
[2.246912] RBP: 8800e98bfd20 R08: 8800353e15b0 R09:
8800eb403c00
[2.246912] R10: a0155532 R11: ffe8 R12:
8800e98c4000
[2.246912] R13: 8800e98c52b8 R14: 0020 R15:
8800353e15c0
[2.246912] FS: () GS:8800efc2()
knlGS:
[2.246912] CS: 0010 DS: ES: CR0: 80050033
[2.246912] CR2: 7f1b615ef000 CR3: e2b44000 CR4:
001406e0
[2.246912] DR0: DR1: DR2:
[2.246912] DR3: DR6: 0ff0 DR7:
0400
[2.246912] Stack:
[2.246912] 0020 0001 0020a0157217
0100e98bfdbc
[2.246912] 27efa3ef 8800e98bfdbc 8800e98ce000
8800e98c4000
[2.246912] 8800e98ce040 0001 8800e98bfe08
a0155d4c
[2.246912] Call Trace:
[2.246912] [] blkback_changed+0x4ec/0xfc8
[xen_blkfront]
[2.246912] [] ? xenbus_gather+0x170/0x190
[2.246912] [] ? __slab_free+0x10e/0x277
[2.246912] []
xenbus_otherend_changed+0xad/0x110
[2.246912] [] ? xenwatch_thread+0x77/0x180
[2.246912] [] backend_changed+0x13/0x20
[2.246912] [] xenwatch_thread+0x66/0x180
[2.246912] [] ? wake_up_atomic_t+0x30/0x30
[2.246912] [] ?
unregister_xenbus_watch+0x1f0/0x1f0
[2.246912] [] kthread+0xcf/0xe0
[2.246912] [] ?
kthread_create_on_node+0x140/0x140
[2.246912] [] ret_from_fork+0x58/0x90
[2.246912]
Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
>>> On 10.08.16 at 14:10, wrote: > On 10/08/16 11:29, Jan Beulich wrote: > On 10.08.16 at 11:58, wrote: >>> On 03.08.16 at 03:32, wrote: >> On 25/07/16 07:09, Kang, Luwei wrote: >> First of all - please don't top post. >> >>> What about remove the dependency between AVX2 and AVX512F ( AVX2: >> [AVX512F], ) ? >> >> Yes, that's what I think we want, but we need Andrew's agreement >> here. >> > Hi Andrew, what is your opinion ? You are in a better position to answer than me. For a specific instruction which may be VEX and EVEX encoded, is the circuitry for a specific instruction shared, or discrete? Is there a plausible future where you might support only the EVEX variant of an instruction, and not the VEX variant? These dependences are about what may be reasonably assumed about the way the environment is structured. It doesn't look reasonable to advertise an AVX512 environment to guests while at the same time stating that AVX2 is not present. If this is correct, then the dependency > should stay. If Intel plausibly things it might release hardware with !AVX2 but AVX512, then the dependency should be dropped. >>> Regarding the dependency between AVX2 and AVX512F, I have ask some >>> hardware > architecture engineer. >>> AVX512 is a superset of AVX2, the most important item being the >>> state. If > the state for AVX2 isn't enabled (in XCR0), then AVX512 >> also can't function. >>> So if we want to use AVX512, AVX2 must be supported and enabled. >>> The > dependence between AVX512F and AVX2 may need be >> reserved. >> >> Ok, so AVX512 strictly depends on AVX2. >> >> In which case, the python code was correct. The meaning of the >> key/value > relationship is "if the feature in the key is not present, all >> features in the value must also be disabled". > Hi jan, what is your opinion? There's no opinion to be had here, according to your earlier reply. I do, >>> however, continue to question that model: State and instruction set are independent items. Of course YMM state is a prereq to >>> ZMM state, but I do not buy AVX2 insn support being a prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature flags solely >>> represent the instructions, while the XSTATE leaf bits represent the states. >>> Hi jan, >>> I get some information from hardware colleague. There is no dependence >>> about AVX512 instructions and AVX2 instructions. It is also not states in > the >>> official document. >> As I had assumed. >> >>>But I want to know the meaning of the dependence "AVX2: [AVX512F]" in >>> "gen-cpuid.py" file. >>>If it is the feature dependence, I think the dependence between AVX512 >>> and AVX2 may need to add. As we talk before, Zmm is part of AVX512 >>> feature. > >>> If the state for AVX2 isn't enabled (in XCR0), then AVX512 also can't >>> function. Apart from that, there is no processors with AVX512 without AVX2 >>> currently and it is safe to treat AVX2 as part of the thermometer leading >>> to > >>> AVX512. Regarding if will have a cpu support avx512 without avx2 in future, >>> it is really hard to say. >>> If it is the instructions dependence, I have no idea to delete this >>> dependence in "gen-cpuid.py" file. >>> So, I want to know your advice. >> Well, the main issue here is that we have no feature flag representation >> for the xstate bits. If we had, the relevant parts of the dependencies >> should look like >> >> XSTATE_YMM: [AVX, XSTATE_ZMM] >> AVX: [AVX2] >> XSTATE_ZMM: [AVX512F] >> AVX512F: [AVX512CD, ...] >> >> But in their absence I guess keeping the AVX2 dependency as you have >> it is the only reasonable approach. Just that I'd like it to be accompanied >> by a comment explaining that this isn't the actual dependency (so that if >> XSTATE feature flags got introduced later, it would be clear how to >> adjust those parts). >> >> Andrew - I keep forgetting why you think having such XSTATE_* feature >> flags is not appropriate. > > This is all about providing a plausible cpuid layout to a guest. > > It is not plausible that we will ever see a processor with e.g. AVX512F > but not XSTATE_ZMM. This is a somewhat bogus argument considering we have FXSR: [FFXSR, SSE], which, as you certainly realize, is slightly wrong nowadays: XSTATE_XMM would suffice as a prereq, without any FXSR. (But I certainly realize that lack of FXSR is unlikely, as that's considered part of the base x86-64 architecture, and I also realize that expressing alternative prereqs would make the deep dependency generation logic more complicated.) Jan ___ Xen-devel mailing list X
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 8/10/2016 6:43 PM, Paul Durrant wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 10 August 2016 11:33
To: Paul Durrant; Yu Zhang
Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian;
zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org)
Subject: Re: [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram
with p2m_ioreq_server to an ioreq server.
On 10.08.16 at 10:09, wrote:
On 8/8/2016 11:40 PM, Jan Beulich wrote:
On 12.07.16 at 11:02, wrote:
@@ -178,8 +179,34 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
Wouldn't it both be more natural and make the logic even easier
to follow if s got set to NULL up front, all the "else"-s dropped,
and a simple
if ( !s )
s = hvm_select_ioreq_server(currd, &p);
be done in the end?
Sorry, Jan. I tried to simplify above code, but found the new code is
still not very
clean, because in some cases the s is supposed to return NULL instead
of to be
set from the hvm_select_ioreq_server().
To keep the same logic, the simplified code looks like this:
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio && dir == IOREQ_WRITE )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);
/* If there is no suitable backing DM, just ignore accesses */
if ( !s )
As you can see, definition of p2mt is moved outside the if ( is_mmio )
judgement,
and is checked against p2m_ioreq_server before we search the ioreq
server's rangeset
in hvm_select_ioreq_server(). So I am not quite satisfied with this
simplification.
Any suggestions?
I think it's better than the code was before, but an implicit part of
my suggestion was that I'm not really convinced the
" && p2mt != p2m_ioreq_server" part of your new conditional is
really needed: Would it indeed be wrong to hand such a request
to the "normal" ioreq server, instead of terminating it right away?
(I guess that's a question to you as much as to Paul.)
Well, I thought the correct semantics for p2m_ioreq_server without any
interception are the same as p2m_ram_rw. In which case if we find an ioreq
server, but it does not want to emulate writes, then we should complete the I/O
by writing to guest RAM. But, how are we ever going to hit this code-path
without some form of race with EPT configuration?
Thanks Paul. I think the p2m type change race condition can be avoided in
hvm_hap_nested_page_fault(), by delaying the call of put_gfn() after the
ioreq is delivered. :)
Otherwise we will need to keep the previous mem_handler, and use
get_gfn_type()
instead of get_gfn_query_unlocked() in hvmemul_do_io() - because,
without a lock,
another race condition can happen when
1> a p2m_ioreq_server gfn is changed to p2m_ram_rw;
2> we got this p2mt with value p2m_ram_rw by get_gfn_query_unlocked();
3> p2m type of this gfn is changed back to p2m_ioreq_server;
4> mem_handler is called instead of deliver the ioreq to device model;
However, the mem_handler may really be helpful for the read-modify-write
case
I mentioned in another mail. So hypervisor do not need to forward the
read ioreq
to the device model.
B.R.
Yu
Yu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 100391: tolerable all pass - PUSHED
flight 100391 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100391/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
baseline version:
xen 7f5c8075364776eb139bbd421ad443ae9e4465dc
Last test of basis 100365 2016-08-09 15:01:57 Z0 days
Failing since100368 2016-08-09 17:01:23 Z0 days9 attempts
Testing same since 100391 2016-08-10 11:01:41 Z0 days1 attempts
People who touched revisions under test:
Boris Ostrovsky
George Dunlap
Jan Beulich
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 :
+ branch=xen-unstable-smoke
+ revision=9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
+ branch=xen-unstable-smoke
+ revision=9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
++
Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
>>> On 10.08.16 at 14:18, wrote:
> On 10/08/16 11:21, Jan Beulich wrote:
> On 10.08.16 at 11:58, wrote:
>>> On 10/08/16 10:23, Jan Beulich wrote:
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
}
}
-EXPORT_SYMBOL(cpu_to_node);
-EXPORT_SYMBOL(node_to_cpumask);
-EXPORT_SYMBOL(memnode_shift);
-EXPORT_SYMBOL(memnodemap);
-EXPORT_SYMBOL(node_data);
+unsigned int __init arch_get_dma_bitsize(void)
+{
+unsigned int node;
+
+for_each_online_node(node)
+if ( node_spanned_pages(node) &&
+ !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
+break;
+if ( node >= MAX_NUMNODES )
+panic("No node with memory below 4Gb");
+
+return min_t(unsigned int,
+ flsl(node_start_pfn(node) + node_spanned_pages(node) / 4
-
> 1)
+ + PAGE_SHIFT, 32);
>>> You have moved the -1 and -2 inside the flsl() call, which alters its
>>> behaviour quite a bit. Is this intentional or accidental?
>> This is intentional, and their original placement was only not too
>> wrong because of the effective use of zero in place of what is
>> now node_start_pfn(node). (Obviously the division by 4 alone
>> could have gone in either place, but the "- 1" should have been
>> inside the flsl() even before imo.)
>
> In which case it should be at least mentioned in the commit message.
"Also adjust the original calculation: I think the subtraction of 1
should have been part of the flsl() argument rather than getting
applied to its result. And while previously the division by 4 was valid
to be done on the flsl() result, this now also needs to be converted,
as is should only be applied to the spanned pages value."
> Finally, do you really mean to only divide the spanned pages by 4?
Hmm, this question reads ambiguous to me: Do you mean the divisor
should be larger than 4? I don't think so, or else the area could end
up rather small. Or do you mean to divide the sum of start address
and spanned pages? That would surely be wrong, as the result could
end up below start address, and hence the area could continue to
remain empty.
> Either way, it could do with further bracketing.
Bracketing of what? Even elementary school maths give precedence
to multiplication and division over addition and subtraction. I know
you like to parenthesize basically every binary expression that's an
operand of another expression, but I think you meanwhile also know
that I think this goes too far.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711
On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote:
> On 14.07.2016 15:04, Bob Liu wrote:
>>
>> On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:
>>> On 11.07.2016 15:04, Bob Liu wrote:
On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:
> On 06.06.2016 11:42, Dario Faggioli wrote:
>> Just Cc-ing some Linux, block, and Xen on CentOS people...
>>
>
> Ping.
>
> Any suggestions how to debug this or what might cause the problem?
>
> Obviously, we cannot control Xen on the Amazon's servers. But perhaps
> there is something we can do at the kernel's side, is it?
>
>> On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:
>>> (Resending this bug report because the message I sent last week did
>>> not
>>> make it to the mailing list somehow.)
>>>
>>> Hi,
>>>
>>> One of our users gets kernel panics from time to time when he tries
>>> to
>>> use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
>>> happens within minutes from the moment the instance starts. The
>>> problem
>>> does not show up every time, however.
>>>
>>> The user first observed the problem with a custom kernel, but it was
>>> found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
>>> CentOS7 was affected as well.
Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc
Regards,
Bob
>>>
>>> Unfortunately, it did not help. The same BUG_ON() in
>>> blkfront_setup_indirect() still triggers in our kernel based on RHEL's
>>> 3.10.0-327.18.2, where I added the patch.
>>>
>>> As far as I can see, the patch makes sure the indirect pages are added to
>>> the list only if (!info->feature_persistent) holds. I suppose it holds in
>>> our case and the pages are added to the list because the triggered BUG_ON()
>>> is here:
>>>
>>> if (!info->feature_persistent && info->max_indirect_segments) {
>>> <...>
>>> BUG_ON(!list_empty(&info->indirect_pages));
>>> <...>
>>> }
>>>
>>
>> That's odd.
>> Could you please try to reproduce this issue with a recent upstream kernel?
>>
>> Thanks,
>> Bob
>
> No luck with the upstream kernel 4.7.0 so far due to unrelated issues (bad
> initrd, I suppose, so the system does not even boot).
>
> However, the problem reproduced with the stable upstream kernel 3.14.74.
> After the system booted the second time with this kernel, that BUG_ON
> triggered:
> kernel BUG at drivers/block/xen-blkfront.c:1701
>
Could you please provide more detail on how to reproduce this bug? I'd like to
have a test.
Thanks!
Bob
>>
>>> So the problem is still out there somewhere, it seems.
>>>
>>> Regards,
>>> Evgenii
>>>
>>>
>>> The part of the system log he was able to retrieve is attached. Here
>>> is
>>> the bug info, for convenience:
>>>
>>>
>>> [2.246912] kernel BUG at drivers/block/xen-blkfront.c:1711!
>>> [2.246912] invalid opcode: [#1] SMP
>>> [2.246912] Modules linked in: ata_generic pata_acpi
>>> crct10dif_pclmul
>>> crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
>>> xen_netfront xen_blkfront(+) aesni_intel lrw ata_piix gf128mul
>>> glue_helper ablk_helper cryptd libata serio_raw floppy sunrpc
>>> dm_mirror
>>> dm_region_hash dm_log dm_mod scsi_transport_iscsi
>>> [2.246912] CPU: 1 PID: 50 Comm: xenwatch Not tainted
>>> 3.10.0-327.18.2.el7.x86_64 #1
>>> [2.246912] Hardware name: Xen HVM domU, BIOS 4.2.amazon
>>> 12/07/2015
>>> [2.246912] task: 8800e9fcb980 ti: 8800e98bc000 task.ti:
>>> 8800e98bc000
>>> [2.246912] RIP: 0010:[] []
>>> blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
>>> [2.246912] RSP: 0018:8800e98bfcd0 EFLAGS: 00010283
>>> [2.246912] RAX: 8800353e15c0 RBX: 8800e98c52c8 RCX:
>>> 0020
>>> [2.246912] RDX: 8800353e15b0 RSI: 8800e98c52b8 RDI:
>>> 8800353e15d0
>>> [2.246912] RBP: 8800e98bfd20 R08: 8800353e15b0 R09:
>>> 8800eb403c00
>>> [2.246912] R10: a0155532 R11: ffe8 R12:
>>> 8800e98c4000
>>> [2.246912] R13: 8800e98c52b8 R14: 0020 R15:
>>> 8800353e15c0
>>> [2.246912] FS: () GS:8800efc2()
>>> knlGS:
>>> [2.246912] CS: 0010 DS: ES: CR0: 80050033
>>> [2.246912] CR2: 7f1b615ef000 CR3: e2b44000 CR4:
>>> 001406e0
>>> [2.246912] DR0: DR1: DR2:
>>>
>>> [2.246912] DR3: DR6: 0ff0 DR7:
>>> 0400
>>> [2.246912] Stack:
>>> [2.246912] 00
Re: [Xen-devel] [PATCH v2 12/23] acpi/hvmloader: Link ACPI object files directly
>>> On 04.08.16 at 23:06, wrote:
> v2:
> * Reordered .gitignore changes alphabetically
> * Dropped trailing slashes
> * Use relative path for ACPI_PATH
> * Use $(addprefix...)
> * Dropped use of 'cd' in rules and instead add $(ACPI_BUILD_DIR)/ to $*
What about the suggested use of $(CURDIR) e.g. ...
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -20,6 +20,7 @@
> XEN_ROOT = $(CURDIR)/../../..
> include $(XEN_ROOT)/tools/firmware/Rules.mk
>
> +export ACPI_BUILD_DIR=$(shell pwd)
... here?
> @@ -72,7 +73,15 @@ all: subdirs-all
> rombios.o: roms.inc
> smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>
> -hvmloader: $(OBJS) acpi/acpi.a
> +ACPI_PATH = ./acpi
Is the leading ./ really needed?
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -15,36 +15,39 @@
> XEN_ROOT = $(CURDIR)/../../../..
> include $(XEN_ROOT)/tools/firmware/Rules.mk
>
> -C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
> dsdt_anycpu_qemu_xen.c
> -OBJS = $(patsubst %.c,%.o,$(C_SRC))
> +MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>
> -CFLAGS += $(CFLAGS_xeninclude)
> +# Sources to be generated
> +C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c
> dsdt_anycpu_qemu_xen.c)
> +H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h
> ssdt_tpm.h)
>
> vpath iasl $(PATH)
> -all: acpi.a
> +all: $(C_SRC) $(H_SRC)
>
> -ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> +$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> + cd $(ACPI_BUILD_DIR)
> iasl -vs -p $* -tc $<
> sed -e 's/AmlCode/$*/g' $*.hex >$@
> rm -f $*.hex $*.aml
> + cd $(CURDIR)
The two "cd" here contradict your list of changes above.
> -mk_dsdt: mk_dsdt.c
> +$(MK_DSDT): mk_dsdt.c
> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>
> -dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
> awk 'NR > 1 {print s} {s=$$0}' $< > $@
> - ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
> + $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
>
> # NB. awk invocation is a portable alternative to 'head -n -1'
> -dsdt_%cpu.asl: dsdt.asl mk_dsdt
> +$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
> awk 'NR > 1 {print s} {s=$$0}' $< > $@
> - ./mk_dsdt --debug=$(debug) --maxcpu $* >> $@
> + $(MK_DSDT) --debug=$(debug) --maxcpu $* >> $@
>
> -$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
> - iasl -vs -p $* -tc $*.asl
> - sed -e 's/AmlCode/$*/g' $*.hex >$@
> +$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
> + iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/$*.asl
> + sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
> echo "int $*_len=sizeof($*);" >>$@
> - rm -f $*.aml $*.hex
> + rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
$(addprefix ...) again?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 100377: tolerable FAIL
flight 100377 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100377/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass in 100367 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100367 build-i386-rumpuserxen6 xen-buildfail like 100367 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100367 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100367 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100367 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 100367 test-amd64-amd64-xl-rtds 9 debian-install fail like 100367 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100367 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc baseline version: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc Last test of basis 100377 2016-08-10 03:02:59 Z0 days Testing same since0 1970-01-01 00:00:00 Z 17023 days0 attempts jobs: build-amd64-xsm pass build-armhf-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-oldkern pass build-i386-oldkern
Re: [Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':
On August 09, 2016 9:02 PM, < jbeul...@suse.com > wrote:
> >>> On 09.08.16 at 14:36, wrote:
> > Hi Jan,
> >
> > A question about ' XENFEAT_auto_translated_physmap':
> >
> > In linux code, in arch/x86/xen/mmu.c,
>
> I assume you know that I'm not a maintainer of the Linux code.
>
> > __xen_pgd_walk()
> > {
> >
> >
> > if (xen_feature(XENFEAT_auto_translated_physmap))
> > return 0;
> >
> > }
> >
> >
> >
> > Why xen_feature(XENFEAT_auto_translated_physmap) is true, then return
> > directly?
> > If not return directly, is there any potential risk?
>
> Well, the function is specifically there for operations (pinning/unpinning)
> which are required only for the not-auto-translated case.
> Why would anyone want to traverse a page table tree just to do nothing on
> each of the entries?
Jan, thank you!!
As I am struggling with a dom0 crash, the kernel is old, 3.0.X..
Now there is a crash in
[] _pin_lock+0x165/0x2a0<*crash*
unable to handle kernel paging request at 8b1021826000
static void _pin_lock(struct mm_struct *mm, int lock)
{
171 pgd_t *pgd = mm->pgd;
172 unsigned g;
173
174 for (g = 0; g <= ((TASK_SIZE_MAX-1) / PGDIR_SIZE); g++,
pgd++) {
175 pud_t *pud;
176 unsigned u;
177
178 if (pgd_none(*pgd))
179 continue;
180 pud = pud_offset(pgd, 0);
181 for (u = 0; u < PTRS_PER_PUD; u++, pud++) {
182 pmd_t *pmd;
183 unsigned m;
184
185 if (pud_none(*pud))
186 continue;
187 pmd = pmd_offset(pud, 0);
188 for (m = 0; m < PTRS_PER_PMD; m++, pmd++) {
189 spinlock_t *ptl;
190
191 if (pmd_none(*pmd))
<-*crash*
192 continue;
193 ptl = pte_lockptr(0, pmd);
194 if (lock)
195 spin_lock(ptl);
196 else
197 spin_unlock(ptl);
198 }
199 }
200 }
201 }
202 #endif
}
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Save/Restore is not working properly
On Wed, Aug 10, 2016 at 12:11 PM, Roger Pau Monné wrote: > On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: >> Hi, >> I was searching a way to clone a machine using both memory and disk >> approach. >> I checked xen save/restore but after restoring, I can only work some >> seconds with my machine and it will crash with the_kernel_task_hang_up. >> using an script* to clone a machine is not working either. >> so is it a bug or something or I'm cloning the wrong way? > > Hello, > > I've not tried to perform cloning myself, but I have a little script to > perform VM checkpoints (so that you can restore the VM to any given point in > time). It's based on FreeBSD so it uses ZFS, but it should work with LVM > also if you replace it with the appropriate runes. AFAICT it should be quite > easy to expand it to also do VM cloning. This is transparent from a VM point > of view. FWIW on a recent version of Xen-unstable, "xl save -c" appears to be broken, at least with me CentOS 6 VM. If I do "xl save" then "xl restore", everything works fine; but if I do "xl save -c", then the save appears to work as normal, and after it's done the guest console has output similar to the output it has when restoring, but processes which access the disk hang, and in 2 minutes I get "hung process" output as Cendrin described. I do get some warning messages though: Using NULL legacy PIC WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! Changing capacity of (202, 0) to 4194288 sectors This is the stock CentOS 6.6 kernel: 2.6.32-504.16.2.el6.x86_64 -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 13/23] acpi/hvmloader: Include file/paths adjustments
>>> On 04.08.16 at 23:06, wrote: > --- a/tools/firmware/hvmloader/acpi/README > +++ b/tools/firmware/hvmloader/acpi/README > @@ -1,11 +1,19 @@ > -ACPI Table for domain firmware > +ACPI builder for domain firmware > > > -INSTALL > +BUILDING ACPI > - > -Simply make is OK. > -# make > +Users of ACPI builder are expected to provide an include file that defines s/defines/makes available/ (since a declaration would fully suffice)? > +the following: > +* strncpy > +* printf > +* NULL > +* test_bit > +* offsetof > > +When compiling build.c, the name of this include file should be given to > +compiler as -DSTDUTILS=\"\". See tools/firmware/hvmloader/Makefile Perhaps worthwhile using LIBACPI_STDUTILS to reduce the chance of a name space conflict? > +#ifndef __ACPI_X86_H__ > +#define __ACPI_X86_H__ > + > +#define IOAPIC_BASE_ADDRESS 0xfec0 This will need re-basing - looks like your submission and my commit happened at about the same time. > --- a/tools/firmware/hvmloader/hvmloader.c > +++ b/tools/firmware/hvmloader/hvmloader.c > @@ -24,8 +24,9 @@ > #include "config.h" > #include "pci_regs.h" > #include "apic_regs.h" > -#include "acpi/acpi2_0.h" > +#include "acpi2_0.h" Could you see to pass a suitable string via -D from the Makefile to prefix to headers like this one? That would clarify to the reader that the file being looked for is not in the current directory. The primary other option that I see would be to use <> instead of "", and keep the -I in the Makefile. Perhaps that would even be the more natural variant. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 100381: tolerable FAIL - PUSHED
flight 100381 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100381/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
version targeted for testing:
libvirt 5b8643099a99dc4ee0dac4bf543a874ffc4c314f
baseline version:
libvirt d5813d72ad2bd8f9735b96bafe2ba350f74b3994
Last test of basis99955 2016-08-05 04:21:10 Z5 days
Failing since 99982 2016-08-06 04:23:44 Z4 days4 attempts
Testing same since 100381 2016-08-10 04:20:25 Z0 days1 attempts
People who touched revisions under test:
Eric Blake
Erik Skultety
Jiri Denemark
John Ferlan
Jovanka Gulicoska
Ján Tomko
Kai Kang
Marc Hartmayer
Michal Privoznik
Nikolay Shirokovskiy
Peter Krempa
jobs:
build-amd64-xsm pass
build-armhf-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-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd 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 :
+ branch=libvirt
+ revision=5b8643099a99dc4ee0dac4bf543a874ffc4c314f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/
Re: [Xen-devel] [PATCH v2 17/23] libacpi: Build DSDT for PVH guests
>>> On 04.08.16 at 23:06, wrote:
> @@ -34,13 +34,15 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> $(MK_DSDT): mk_dsdt.c
> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>
> -$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl
> $(MK_DSDT)
> awk 'NR > 1 {print s} {s=$$0}' $< > $@
> + cat dsdt_acpi_info.asl >> $@
> $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
I understand the problem is pre-existing, but unfortunately you make
it worse: Repeatedly redirecting into the destination file is prone to
problems when someone interrupts a build. There should be a
temporary file created, and as the last step that one should be
mv-ed to the destination.
> @@ -58,7 +71,7 @@ iasl:
> @exit 1
>
> clean:
> - rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
> + rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
> $(ACPI_BUILD_DIR)/dsdt_pvh.c
Isn't this already being taken care of by $(C_SRC)?
> --- /dev/null
> +++ b/tools/libacpi/dsdt_acpi_info.asl
> @@ -0,0 +1,23 @@
> +
> +Scope (\_SB)
> +{
> + /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
> + OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
> + Field(BIOS, ByteAcc, NoLock, Preserve) {
> + UAR1, 1,
> + UAR2, 1,
> + LTP1, 1,
> + HPET, 1,
> + Offset(2),
> + NCPU, 16,
> + PMIN, 32,
> + PLEN, 32,
> + MSUA, 32, /* MADT checksum address */
> + MAPA, 32, /* MADT LAPIC0 address */
> + VGIA, 32, /* VM generation id address */
> + LMIN, 32,
> + HMIN, 32,
> + LLEN, 32,
> + HLEN, 32
> + }
> +}
While moving it, could you please extend the comment to add an
xref note similar to the one ahead of the struct acpi_info declaration
(but pointing in the opposite direction)?
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -98,6 +98,7 @@ static struct option options[] = {
> { "maxcpu", 1, 0, 'c' },
> { "dm-version", 1, 0, 'q' },
> { "debug", 1, 0, 'd' },
> +{ "no-dm", 0, 0, 'n' },
Please, instead of going this route, add support for --dm-version none,
...
> @@ -105,6 +106,7 @@ int main(int argc, char **argv)
> {
> unsigned int slot, dev, intx, link, cpu, max_cpus = HVM_MAX_VCPUS;
> dm_version dm_version = QEMU_XEN_TRADITIONAL;
> +bool no_dm = 0;
... at once extending the dm_version enum (and presumably that
enumerator would preferably become the first one, i.e. with value
zero, so you could - if you want - use an expression like
!dm_version).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':
>>> On 10.08.16 at 15:19, wrote:
> On August 09, 2016 9:02 PM, < jbeul...@suse.com > wrote:
>> >>> On 09.08.16 at 14:36, wrote:
>> > Hi Jan,
>> >
>> > A question about ' XENFEAT_auto_translated_physmap':
>> >
>> > In linux code, in arch/x86/xen/mmu.c,
>>
>> I assume you know that I'm not a maintainer of the Linux code.
>>
>> > __xen_pgd_walk()
>> > {
>> >
>> >
>> > if (xen_feature(XENFEAT_auto_translated_physmap))
>> > return 0;
>> >
>> > }
>> >
>> >
>> >
>> > Why xen_feature(XENFEAT_auto_translated_physmap) is true, then return
>> > directly?
>> > If not return directly, is there any potential risk?
>>
>> Well, the function is specifically there for operations (pinning/unpinning)
> which are required only for the not-auto-translated case.
>> Why would anyone want to traverse a page table tree just to do nothing on
> each of the entries?
>
> Jan, thank you!!
> As I am struggling with a dom0 crash, the kernel is old, 3.0.X..
> Now there is a crash in
>
> [] _pin_lock+0x165/0x2a0<*crash*
>
> unable to handle kernel paging request at 8b1021826000
Which appears to have pretty little to do with the original question,
as here you appear to be dealing with a forward ported XenoLinux
kernel.
> static void _pin_lock(struct mm_struct *mm, int lock)
> {
> 171 pgd_t *pgd = mm->pgd;
> 172 unsigned g;
> 173
> 174 for (g = 0; g <= ((TASK_SIZE_MAX-1) / PGDIR_SIZE); g++,
> pgd++) {
> 175 pud_t *pud;
> 176 unsigned u;
> 177
> 178 if (pgd_none(*pgd))
> 179 continue;
> 180 pud = pud_offset(pgd, 0);
> 181 for (u = 0; u < PTRS_PER_PUD; u++, pud++) {
> 182 pmd_t *pmd;
> 183 unsigned m;
> 184
> 185 if (pud_none(*pud))
> 186 continue;
> 187 pmd = pmd_offset(pud, 0);
> 188 for (m = 0; m < PTRS_PER_PMD; m++, pmd++)
> {
> 189 spinlock_t *ptl;
> 190
> 191 if (pmd_none(*pmd))
> <-*crash*
Well, fine, it crashes here. But without further detail I don't think
you really expect anyone to be able to help (at the first glance
this looks like a follow-on effect from some earlier problem, as
presumably you've hit a ballooned out page, which obviously
shouldn't be referenced by any page tables)? And for this old a
kernel, and a non-upstream one, such a discussion presumably
doesn't belong on this list anyway. If this is a SUSE kernel, and
if the kernel is up-to-date wrt the distro it comes from, then either
open a ticket with our support folks, or (less reasonable, as there
never was an openSUSE version with a 3.0 based kernel) provide
much greater detail on a list like opensuse-virt...@opensuse.org.
Jan
> 192 continue;
> 193 ptl = pte_lockptr(0, pmd);
> 194 if (lock)
> 195 spin_lock(ptl);
> 196 else
> 197 spin_unlock(ptl);
> 198 }
> 199 }
> 200 }
> 201 }
> 202 #endif
> }
>
>
>
> Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 12/23] acpi/hvmloader: Link ACPI object files directly
On 08/10/2016 09:17 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> v2: >> * Reordered .gitignore changes alphabetically >> * Dropped trailing slashes >> * Use relative path for ACPI_PATH >> * Use $(addprefix...) >> * Dropped use of 'cd' in rules and instead add $(ACPI_BUILD_DIR)/ to $* > What about the suggested use of $(CURDIR) e.g. ... I think I fixed this (and some of others that you mention) in the later patch when I moved the Makefile to tools/. I will fix it here first. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 13/23] acpi/hvmloader: Include file/paths adjustments
On 08/10/2016 09:30 AM, Jan Beulich wrote: >> +#ifndef __ACPI_X86_H__ >> +#define __ACPI_X86_H__ >> + >> +#define IOAPIC_BASE_ADDRESS 0xfec0 > This will need re-basing - looks like your submission and my commit > happened at about the same time. Right, I saw that but this series is based on Anthony's tree so I couldn't use it yet. > >> --- a/tools/firmware/hvmloader/hvmloader.c >> +++ b/tools/firmware/hvmloader/hvmloader.c >> @@ -24,8 +24,9 @@ >> #include "config.h" >> #include "pci_regs.h" >> #include "apic_regs.h" >> -#include "acpi/acpi2_0.h" >> +#include "acpi2_0.h" > Could you see to pass a suitable string via -D from the Makefile to > prefix to headers like this one? That would clarify to the reader that > the file being looked for is not in the current directory. The primary > other option that I see would be to use <> instead of "", and keep > the -I in the Makefile. Perhaps that would even be the more natural > variant. Yes, I'll see if that (< >) works. -boris > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area
On Wed, Aug 10, 2016 at 04:44:21AM -0600, Jan Beulich wrote:
> >>> On 10.08.16 at 08:59, wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim)
> > printk("%s:%08x %016"PRIx64"\n", name, limit, base);
> > }
> >
> > +static void vmx_dump_vcpu_msr_area(struct vcpu *v)
>
> const
Ack.
> > +{
> > +const struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
> > +unsigned int i, msr_count = v->arch.hvm_vmx.msr_count;
> > +
> > +printk(" msr_count = %d\n", v->arch.hvm_vmx.msr_count);
>
> Please use the local variable you have just latched and %u.
Ack.
> > +for ( i = 0; i < msr_count; i++ )
> > +{
> > +printk(" msr_area[%d].index=0x%08x .data=0x%016lx\n",
>
> [%u], and I'm not sure the 0x prefixes are really all that helpful
> here. I think it would also be beneficial to shorten the logged text
> a little, as this may consume quite a bit of serial line bandwidth.
> How about " MSR[%08x]=%016lx\n"?
Everyone isn't running at 115,200 baud these days? ;-)
Ack.
> > @@ -1879,6 +1893,13 @@ void vmcs_dump_vcpu(struct vcpu *v)
> > (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS)
> > )
> > printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
> > vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
> > +printk("EXIT MSR load count = 0x%04x\n",
> > + (uint32_t)vmr(VM_EXIT_MSR_LOAD_COUNT));
> > +printk("EXIT MSR store count = 0x%04x\n",
> > + (uint32_t)vmr(VM_EXIT_MSR_STORE_COUNT));
> > +printk("ENTRY MSR load count = 0x%04x\n",
> > + (uint32_t)vmr(VM_ENTRY_MSR_LOAD_COUNT));
>
> First - do you really need to make three log lines out of these? And
> then, please use vmr32(), as the neighboring vmr16() suggests.
> Plus finally - please log all four counts consistently either in hex
> or in dec.
With one line, output might look something like:
(XEN) MSR load/store count ExitLoad=0x0001 ExitStore=0x0023 EntryLoad=0x0023
Spaces around = are inconsistent in the existing output and it seems
that no space is more popular. Does this format seem better to you?
I see three counts here - are you talking about the msr_count above?
For msr_count I was thinking that this is internal Xen state, whereas
the other values are VMCS fields where everything else is dumped in
hex. I think printing msr_count is redundant (one could just count the
lines of output), so I'll just remove it.
--msw
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
On Aug 10, 2016 05:52, "Jan Beulich" wrote: > > >>> On 10.08.16 at 12:55, wrote: > > On 08/10/2016 01:12 PM, Jan Beulich wrote: > > On 10.08.16 at 09:35, wrote: > >>> --- a/xen/common/vm_event.c > >>> +++ b/xen/common/vm_event.c > >>> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct > > vm_event_domain *ved) > >>> v = d->vcpu[rsp.vcpu_id]; > >>> > >>> /* > >>> + * Make sure the vCPU state has been synchronized for the custom > >>> + * handlers. > >>> + */ > >>> +if ( atomic_read(&v->vm_event_pause_count) ) > >>> +sync_vcpu_execstate(v); > >> > >> It seems to me that the latest with this change using a simple > >> atomic_t won't suffice anymore - you'd now really need to > >> make sure the user mode tools can't resume that vCPU behind > >> your back, which aiui can only be achieved by using a suitable > >> lock (perhaps a read/write one if reading the pause count is > >> more common than updating it). > > > > I'm not sure how that would happen, vm_event_vcpu_pause() increments > > v->vm_event_pause_count, and then calls vcpu_pause_nosync(v), which then > > increments it's own counter. > > > > So there doesn't seem to be a possibility of v->vm_event_pause_count > > being > 0 while the vCPU is unpaused, and there should also be no > > possibility that vm_event_resume() and vm_event_pause() could happen on > > the same vCPU at the same time. > > Here you say "should", which is exactly what worries me: Is it > technically possible or not? If it is, there is the potential for a > race (with a buggy or malicious user mode tool). If there isn't, > calling out what it is that guarantees that in the commit > message (or even a code comment) would be much appreciated. > The vm_event pause count is only decremented with vm_event responses. We only have one ring and one consumer of the ring, so even if you have multiple responses placed on the ring only on gets processed at any time. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.
On Aug 10, 2016 03:52, "Julien Grall" wrote:
>
> Hello Tamas,
>
>
> On 09/08/2016 21:16, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall
wrote:
>>>
>>> Hello Sergej,
>>>
>>>
>>> On 01/08/16 18:10, Sergej Proskurin wrote:
This commit moves the altp2m-related code from x86 to ARM. Functions
that are no yet supported notify the caller or print a BUG message
stating their absence.
Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of
the
domain.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.
---
xen/arch/arm/hvm.c | 79
xen/include/asm-arm/altp2m.h | 4 +--
xen/include/asm-arm/domain.h | 3 ++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..eb524ae 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,81 @@
#include
+#include
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) :
rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !d->arch.altp2m_active )
>>>
>>>
>>>
>>> Why not using altp2m_active(d) here?
>>>
>>> Also this check looks quite racy. What does prevent another CPU to
disable
>>> altp2m at the same time? How the code would behave?
>>
>>
>> There is a rcu_lock_domain_by_any_id before we get to this check here,
>> so any other CPU looking to disable altp2m would be waiting there for
>> the current op to finish up, so there is no race condition AFAICT.
>
>
> No, rcu_lock_domain_by_any_id only prevents the domain to be fully
destroyed by "locking" the rcu. It does not prevent multiple concurrent
access. You can look at the code if you are not convinced.
>
Ah thanks for clarifying. Then indeed there could be concurrency issues if
there are multiple tools accessing this interface. Normally that doesn't
happen though but probably a good idea to enforce it anyway.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711
On 10.08.2016 15:49, Bob Liu wrote:
On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote:
On 14.07.2016 15:04, Bob Liu wrote:
On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:
On 11.07.2016 15:04, Bob Liu wrote:
On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:
On 06.06.2016 11:42, Dario Faggioli wrote:
Just Cc-ing some Linux, block, and Xen on CentOS people...
Ping.
Any suggestions how to debug this or what might cause the problem?
Obviously, we cannot control Xen on the Amazon's servers. But perhaps there is
something we can do at the kernel's side, is it?
On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:
(Resending this bug report because the message I sent last week did
not
make it to the mailing list somehow.)
Hi,
One of our users gets kernel panics from time to time when he tries
to
use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
happens within minutes from the moment the instance starts. The
problem
does not show up every time, however.
The user first observed the problem with a custom kernel, but it was
found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
CentOS7 was affected as well.
Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc
Regards,
Bob
Unfortunately, it did not help. The same BUG_ON() in blkfront_setup_indirect()
still triggers in our kernel based on RHEL's 3.10.0-327.18.2, where I added the
patch.
As far as I can see, the patch makes sure the indirect pages are added to the list
only if (!info->feature_persistent) holds. I suppose it holds in our case and
the pages are added to the list because the triggered BUG_ON() is here:
if (!info->feature_persistent && info->max_indirect_segments) {
<...>
BUG_ON(!list_empty(&info->indirect_pages));
<...>
}
That's odd.
Could you please try to reproduce this issue with a recent upstream kernel?
Thanks,
Bob
No luck with the upstream kernel 4.7.0 so far due to unrelated issues (bad
initrd, I suppose, so the system does not even boot).
However, the problem reproduced with the stable upstream kernel 3.14.74. After
the system booted the second time with this kernel, that BUG_ON triggered:
kernel BUG at drivers/block/xen-blkfront.c:1701
Could you please provide more detail on how to reproduce this bug? I'd like to
have a test.
Thanks!
Bob
As the user says, he uses an Amazon EC2 instance. Namely: HVM CentOS7
AMI on a c3.large instance with EBS magnetic storage.
At least 2 LVM partitions are needed:
* /, 20-30 Gb should be enough, ext4
* /vz, 5-10 Gb should be enough, ext4
Kernel 3.14.74 I was talking about:
https://www.dropbox.com/s/bhus3mubza87z86/kernel-3.14.74-1.test.x86_64.rpm?dl=1
Not sure if it is relevant, but the user may have installed additional
packages from
https://download.openvz.org/virtuozzo/releases/7.0-rtm/x86_64/os/
repository. Namely: vzctl, vzmigrate, vzprocps, vztt-lib, vzctcalc,
ploop, prlctl, centos-7-x86_64-ez.
After the kernel and the other mentioned packages have been installed,
the user rebooted the instance to run that kernel 3.14.74.
Then - start the instance, wait 5 minutes, stop the instance, repeat.
2-20 such iterations were usually enough to reproduce the problem. Can
be automated with the help of Amazon's API.
BTW, before the BUG_ON triggered this time, there was the following in
dmesg. Not sure if it is related but still:
--
[2.835034] scsi0 : ata_piix
[2.840317] scsi1 : ata_piix
[2.842267] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[2.845861] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[2.853840] AVX version of gcm_enc/dec engaged.
[2.859963] xen_netfront: Initialising Xen virtual ethernet driver
[2.867156] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[2.885861] blkfront: xvda: barrier or flush: disabled; persistent
grants: disabled; indirect descriptors: enabled;
[2.889046] alg: No test for crc32 (crc32-pclmul)
[2.899290] xvda: xvda1
[2.997751] blkfront: xvdc: flush diskcache: enabled; persistent
grants: disabled; indirect descriptors: enabled;
[3.007401] xvdc: unknown partition table
[3.010465] Setting capacity to 31992832
[3.012922] xvdc: detected capacity change from 0 to 16380329984
[3.017408] blkfront: xvdd: flush diskcache: enabled; persistent
grants: disabled; indirect descriptors: enabled;
[3.023861] xvdd: unknown partition table
[3.026481] Setting capacity to 31992832
[3.029051] xvdd: detected capacity change from 0 to 16380329984
[3.033320] blkfront: xvdf: barrier or flush: disabled; persistent
grants: disabled; indirect descriptors: enabled;
[3.040712] random: nonblocking pool is initialized
[3.057432] xvdf: unknown partition table
[3.060807] Setting capacity to 41943040
[3.063194] xvdf: detected
[Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case
Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropriately restrict
access.
In this patch we deprecate the altp2mhvm domain configuration option and
introduce the altp2m option, which allows specifying if by default the altp2m
interface should be external-only. The information is stored in
HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
If external_only mode is selected, the XSM check is shifted to use XSM_DM_PRIV
type check, thus restricting access to the interface by the guest itself. Note
that we keep the default XSM policy untouched. Users of XSM who wish to enforce
external_only mode for altp2m can do so by adjusting their XSM policy directly,
as this domain config option does not override an active XSM policy.
Also, as part of this patch we adjust the hvmop handler to require
HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has been
previously only required for get/set altp2m domain state, all other options
were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
altp2m domain state, this change introduces no new requirements to the other
ops but makes it more clear that it is required for all ops.
Signed-off-by: Tamas K Lengyel
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel De Graaf
v2: Rename HVMALTP2M_* to XEN_ALTP2M_*
Relax xsm check to XSM_DM_PRIV for external-only mode
---
docs/man/xl.cfg.pod.5.in| 31 +++
tools/libxl/libxl_create.c | 5 ++---
tools/libxl/libxl_dom.c | 2 +-
tools/libxl/libxl_types.idl | 9 -
tools/libxl/xl_cmdimpl.c| 34 +-
xen/arch/x86/hvm/hvm.c | 20 ++--
xen/include/public/hvm/params.h | 10 +-
xen/include/xsm/dummy.h | 14 +++---
xen/include/xsm/xsm.h | 6 +++---
xen/xsm/flask/hooks.c | 2 +-
10 files changed, 109 insertions(+), 24 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 48c9c0d..0044b98 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1268,6 +1268,37 @@ enabled by default and you should usually omit it. It
may be necessary
to disable the HPET in order to improve compatibility with guest
Operating Systems (X86 only)
+=item B
+
+Specifies access mode to the alternate-p2m capability for hvm guests.
+Alternate-p2m allows a guest to manage multiple p2m guest physical
+"memory views" (as opposed to a single p2m). You may want this option
+if you want to access-control/isolate access to specific guest physical
+memory pages accessed by the guest, e.g. for HVM domain memory
+introspection or for isolation/access-control of memory between
+components within a single guest hvm domain.
+
+The valid values are as follows:
+
+=over 4
+
+=item B<"disabled">
+
+Altp2m is disabled for the domain (default).
+
+=item B<"mixed">
+
+The mixed mode allows access to the altp2m interface for both in-guest
+and external tools as well.
+
+=item B<"external_only">
+
+Enables access to the alternate-p2m capability for hvm guests only
+by external privileged tools. Note: if XSM is enabled then the XSM policy
+should be used to specify external-only access to the interface.
+
+=back
+
=item B
Enables or disables hvm guest access to alternate-p2m capability.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 04f8ae9..c9076da 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -319,7 +319,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
-libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
libxl_defbool_setdefault(&b_info->u.hvm.usb,false);
libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
@@ -918,8 +917,8 @@ static void initiate_domain_create(libxl__egc *egc,
if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
(libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
- libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) {
-LOG(ERROR, "nestedhvm and altp2mhvm cannot be used together");
+ d_config->b_info.u.hvm.altp2m != LIBXL_ALTP2M_MODE_DISABLED)) {
+LOG(ERROR, "nestedhvm and altp2m cannot be used together");
goto error_out;
}
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index eef5045..0b8b2a8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -292,
[Xen-devel] [PATCH v2 1/2] x86/altp2m: use __get_gfn_type_access to avoid lock conflicts
From: Tamas K Lengyel
Use __get_gfn_type_access instead of get_gfn_type_access when checking
the hostp2m entries during altp2m mem_access setting and gfn remapping
to avoid a lock conflict which can make dom0 freeze. During mem_access
setting the hp2m is already locked. For gfn remapping we change the flow
to lock the hp2m before locking the ap2m.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Razvan Cojocaru
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
v2: Lock the hp2m during gfn remapping
---
xen/arch/x86/mm/p2m.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 812dbf6..1eeb934 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1787,8 +1787,8 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct
p2m_domain *hp2m,
if ( !mfn_valid(mfn) )
{
-mfn = get_gfn_type_access(hp2m, gfn_l, &t, &old_a,
- P2M_ALLOC | P2M_UNSHARE, &page_order);
+mfn = __get_gfn_type_access(hp2m, gfn_l, &t, &old_a,
+P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
rc = -ESRCH;
if ( !mfn_valid(mfn) || t != p2m_ram_rw )
@@ -2548,6 +2548,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int
idx,
hp2m = p2m_get_hostp2m(d);
ap2m = d->arch.altp2m_p2m[idx];
+p2m_lock(hp2m);
p2m_lock(ap2m);
mfn = ap2m->get_entry(ap2m, gfn_x(old_gfn), &t, &a, 0, NULL, NULL);
@@ -2563,8 +2564,8 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int
idx,
/* Check host p2m if no valid entry in alternate */
if ( !mfn_valid(mfn) )
{
-mfn = get_gfn_type_access(hp2m, gfn_x(old_gfn), &t, &a,
- P2M_ALLOC | P2M_UNSHARE, &page_order);
+mfn = __get_gfn_type_access(hp2m, gfn_x(old_gfn), &t, &a,
+P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
if ( !mfn_valid(mfn) || t != p2m_ram_rw )
goto out;
@@ -2606,6 +2607,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int
idx,
out:
p2m_unlock(ap2m);
+p2m_unlock(hp2m);
return rc;
}
--
2.8.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [XTF PATCH 1/3] xtf-runner: introduce get_xen_version
Signed-off-by: Wei Liu
---
xtf-runner | 13 +
1 file changed, 13 insertions(+)
diff --git a/xtf-runner b/xtf-runner
index c063699..7b69c45 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -151,6 +151,19 @@ def __repr__(self):
return "TestInfo(%s)" % (self.name, )
+def get_xen_version():
+"""Get the version string of Xen"""
+
+for line in check_output(['xl', 'info']).splitlines():
+if not line.startswith("xen_version"):
+continue
+
+version_str = line.split()[2:][0]
+break
+
+return version_str
+
+
def parse_test_instance_string(arg):
"""Parse a test instance string.
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [XTF PATCH 0/3] Support getting output from either console or log file
Wei Liu (3): xtf-runner: introduce get_xen_version xtf-runner: options for different modes to get output xtf-runner: support two modes for getting output xtf-runner | 144 - 1 file changed, 123 insertions(+), 21 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [XTF PATCH 3/3] xtf-runner: support two modes for getting output
We need two modes for getting output:
1. Use console directly with newer (>=4.8) Xen
2. Use log files for older Xen
This patch implements both. The default behaviour is to choose mode
automatically based on Xen version. User can also explicitly specify
which mode to use.
Signed-off-by: Wei Liu
---
xtf-runner | 104 -
1 file changed, 83 insertions(+), 21 deletions(-)
diff --git a/xtf-runner b/xtf-runner
index 73a4e0d..2d4d6db 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -11,6 +11,8 @@
from optparse import OptionParser
from subprocess import Popen, PIPE, call as subproc_call, check_output
+from distutils.version import LooseVersion
+import time
try:
import json
@@ -438,30 +440,19 @@ def list_tests(opts):
for sel in opts.selection:
print sel
+def run_test_console(opts, test):
+""" Run a specific test via xenconsole"""
-def run_test(test):
-""" Run a specific test """
-
-cmd = ['xl', 'create', '-p', test.cfg_path()]
-print "Executing '%s'" % (" ".join(cmd), )
-rc = subproc_call(cmd)
-if rc:
-raise RunnerError("Failed to create VM")
-
-cmd = ['xl', 'console', test.vm_name()]
+cmd = ['xl', 'create', '-Fc', test.cfg_path()]
print "Executing '%s'" % (" ".join(cmd), )
-console = Popen(cmd, stdout = PIPE)
+guest = Popen(cmd, stdout = PIPE, stderr = PIPE)
-cmd = ['xl', 'unpause', test.vm_name()]
-print "Executing '%s'" % (" ".join(cmd), )
-rc = subproc_call(cmd)
-if rc:
-raise RunnerError("Failed to unpause VM")
+# stdout is console output, stderr is xl output
+stdout, stderr = guest.communicate()
-stdout, _ = console.communicate()
-
-if console.returncode:
-raise RunnerError("Failed to obtain VM console")
+if guest.returncode:
+print stderr
+raise RunnerError("Failed to communicate with guest")
lines = stdout.splitlines()
@@ -483,6 +474,64 @@ def run_test(test):
return "ERROR"
+def run_test_logfile(opts, test):
+""" Run a specific test via grepping log file"""
+
+fn = opts.logfile_dir + (opts.logfile_pattern % test)
+local_time = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime())
+
+# Use time to generate unique stamps
+start_stamp = "= XTF TEST START %s =" % local_time
+end_stamp = "= XTF TEST END %s =" % local_time
+
+print "Using %s" % fn
+
+f = open(fn, "ab")
+f.write(start_stamp + "\n")
+f.close()
+
+cmd = ['xl', 'create', '-F', test.cfg_path()]
+print "Executing '%s'" % (" ".join(cmd), )
+rc = subproc_call(cmd)
+if rc:
+raise RunnerError("Failed to run test")
+
+f = open(fn, "ab")
+f.write(end_stamp + "\n")
+f.close()
+
+f = open(fn, "rb")
+output = f.readlines()
+f.close()
+lines = []
+found = False
+for line in output:
+if end_stamp in line:
+break
+if start_stamp in line:
+found = True
+continue
+if not found:
+continue
+lines.append(line)
+
+print "".join(lines)
+
+if len(lines) == 0:
+raise RunnerError("Log file output empty")
+
+test_result = lines[-1]
+if not "Test result:" in test_result:
+return "ERROR"
+
+for res in all_results:
+
+if res in test_result:
+return res
+
+return "ERROR"
+
+
def run_tests(opts):
""" Run tests """
@@ -490,12 +539,25 @@ def run_tests(opts):
if not len(tests):
raise RunnerError("No tests to run")
+if opts.mode == "auto":
+xen_version = LooseVersion(get_xen_version())
+if xen_version < LooseVersion("4.8"):
+run_test = run_test_logfile
+else:
+run_test = run_test_console
+elif opts.mode == "console":
+run_test = run_test_console
+elif opts.mode == "logfile":
+run_test = run_test_logfile
+else:
+raise RunnerError("Unrecognised mode")
+
rc = all_results.index('SUCCESS')
results = []
for test in tests:
-res = run_test(test)
+res = run_test(opts, test)
res_idx = all_results.index(res)
if res_idx > rc:
rc = res_idx
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [XTF PATCH 2/3] xtf-runner: options for different modes to get output
Only options and help text. Implementation will come later.
Signed-off-by: Wei Liu
---
xtf-runner | 27 +++
1 file changed, 27 insertions(+)
diff --git a/xtf-runner b/xtf-runner
index 7b69c45..73a4e0d 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -532,6 +532,20 @@ def main():
" all tests in the selection, printing a summary of their\n"
" results at the end.\n"
"\n"
+ " To determine how runner should get output from Xen, use\n"
+ " --mode option. The default value is \"auto\", which\n"
+ " will choose the mode based on Xen version. Other\n"
+ " supported values are \"console\" and \"logfile\", which\n"
+ " respectively means to get log from xenconsole and\n"
+ " to get log from xencosonsoled output.\n"
+ "\n"
+ " The \"logfile\" mode requires users to configure\n"
+ " xenconsoled to log guest console output. This mode\n"
+ " is useful for Xen version < 4.8. Note that runner will\n"
+ " append a custom string to guest log file before\n"
+ " running each test. Also see --logfile-dir\n"
+ " and --logfile-pattern options.\n"
+ "\n"
"Selections:\n"
" A selection is zero or more of any of the following\n"
" parameters: Categories, Environments and Tests.\n"
@@ -609,6 +623,19 @@ def main():
dest = "host", help = "Restrict selection to applicable"
" tests for the current host",
)
+parser.add_option("-m", "--mode", action = "store",
+ dest = "mode", default = "auto", type = "string",
+ help = "Instruct how runner gets its output (see below)")
+parser.add_option("--logfile-dir", action = "store",
+ dest = "logfile_dir", default = "/var/log/xen/console/",
+ type = "string",
+ help = 'Specify the directory to look for console logs, \
+defaults to "/var/log/xen/console/"')
+parser.add_option("--logfile-pattern", action = "store",
+ dest = "logfile_pattern", default = "guest-%s.log",
+ type = "string",
+ help = 'Specify the log file name pattern, \
+defaults to "guest-%s"')
opts, args = parser.parse_args()
opts.args = args
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 100394: regressions - FAIL
flight 100394 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 100391
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 6480cc6280e955d1245d8dfb2456d2b830240c74
baseline version:
xen 9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
Last test of basis 100391 2016-08-10 11:01:41 Z0 days
Testing same since 100394 2016-08-10 13:02:02 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl fail
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
Not pushing.
commit 6480cc6280e955d1245d8dfb2456d2b830240c74
Author: Andrew Cooper
Date: Wed Aug 10 10:41:28 2016 +0100
x86/traps: Fix failed ASSERT() in do_guest_trap()
c/s 2e426d6 "x86/traps: Drop use_error_code parameter from
do_{,guest_}trap()"
introduced an assertion which covered the correctness of shifting 1u by an
input parameter.
While all other inputs provide a constants vector, the `int $N` handling
path
from do_general_protection() passes any vector.
This path is triggered by XTF, which uses `int 0x20` to facilitate returning
to kernel mode after running specific tests in user mode.
No vectors above 32 have an error code, so adjust the logic to cope.
Reported-by: Wei Liu
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] xl dump-core fails, j!=nr_pages
On Wed, Aug 10, Wei Liu wrote: > On Wed, Aug 10, 2016 at 10:25:30AM +0200, Olaf Hering wrote: > > On Wed, Aug 10, Olaf Hering wrote: > > > > This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work > > with HVM guests? I think at some point 'xm dump-core' used to work, just > > crash(1) could not deal with the result. > > > > > xc: info: j (63635) != nr_pages (65709) > > Does xl crash? I think this is only informational. I dont think it crashes. Will put this on my todo list, since its appearently broken since some time already. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk
On Wed, Aug 10, 2016 at 06:34:10AM -0600, Jan Beulich wrote:
> >>> On 10.08.16 at 08:59, wrote:
> > Systems that support LBR formats that include TSX information but do
> > not support TSX require special handling when saving and restoring MSR
> > values. For example, see the Linux kernel quirks[1, 2] in the MSR
> > context switching code. As a wrmsr with certain values under these
> > conditions causes a #GP, VM entry will fail due to MSR loading (see
> > last bullet of SDM 26.4 "Loading MSRS").
>
> I had recently noticed this as an area needing work too, so I'm glad
> you (hopefully) eliminate this item from my todo list. However, I'm
> sad to see that you really just disable LBR use in the problem case.
> I'd prefer to take such a change only as an immediate workaround,
> with the understanding that a proper one will be made available not
> too much later.
I agree that this is a short term workaround. I spent a while trying
to fix up the values but I wasn't successful.
> Jun, Kevin - workarounds for hardware quirks like this one are really
> what I would think should come out of Intel, and preferably not
> after the first problem report on Xen, but soon after the quirk has
> got identified in general (which according to the Linux patches must
> have been at least 2 months ago).
+1
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2576,8 +2576,22 @@ static const struct lbr_info
> > *last_branch_msr_get(void)
> > /* Haswell */
> > case 60: case 63: case 69: case 70:
> > /* Broadwell */
> > -case 61: case 71: case 79: case 86:
> > +case 61: case 71: case 79: case 86: {
> > +u64 caps;
> > +bool_t tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
> > + boot_cpu_has(X86_FEATURE_RTM);
> > +
> > +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>
> This is guarded by a X86_FEATURE_PDCM check in Linux - why
> would we not need the same here?
You're right, it should be. It also seems to be missing from
core2_vpmu_init().
> Also I think this RDMSR should be performed once at boot, not every
> time we come here.
I thought you might say that. It didn't seem obviously right to put
this in boot_cpu_data -- is that what you suggest?
> > +/*
> > + * Unimplemented fixups are required if the processor
> > + * supports an LBR format that includes TSX information,
> > + * but not TSX. Disable LBR save/load on such platforms.
> > + */
> > +if ( !tsx_support && (caps & 4) )
>
> As I understand it the low 6 bits of the MSR contain an enumeration
> like value, so just checking bit 2 can't be right (and would wrongly
> trigger on already defined format types 5 and 6 - even if those were
> known to be impossible on the models currently covered, this would
> be a latent trap for someone to fall into when adding further model
> values).
Fair point.
--msw
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 100379: tolerable FAIL - PUSHED
flight 100379 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100379/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100363 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100363 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100363 test-amd64-amd64-xl-rtds 9 debian-install fail like 100363 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu2bb15bddf2607110820d5ce5aa43baac27292fb3 baseline version: qemuuab861f3915e8667927cf18ad97f71cae7ccf8818 Last test of basis 100363 2016-08-09 10:23:46 Z1 days Testing same since 100369 2016-08-09 17:12:05 Z0 days2 attempts People who touched revisions under test: John Snow Paolo Bonzini Peter Maydell jobs: build-amd64-xsm pass build-armhf-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-
Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables
On Tue, Aug 09, 2016 at 09:09:07AM -0700, James Bottomley wrote:
> On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote:
> > > table development go under copyleft-next, Rusty recently asked for
> > > code to go in prior to the license tag being added denoting this
> > > license as GPL-compatible [3] -- I had noted in the patch
> > > submission which annotated copyleft-next's compatibility to GPLv2
> > > that copyleft-next is the license of choice for ongoing kernel
> > > development on my end [4]. If this is objectionable I'm happy to
> > > change it to GPLv2 however I'd like a reason provided as I've gone
> > > through all possible channels to ensure this is kosher, including
> > > vetting by 3 attorneys now, 2 at SUSE.
> >
> > You don't need a new tag, you can use "GPL" or "GPL and additional
> > rights". In fact you don't want any other tag because when combined
> > with the kernel it is GPLv2 anyway because the only way the two are
> > fully compatible is for the kernel community to license the derived
> > work under the GPL.
>
> This is the module tag ... it says what licence the module is under,
> not the licence for the module combined with the kernel, which is
> always GPLv2 because the stricter licence rules.
As per Linus' recommendations [0] if I add a module I'll be using
MODULE_LICENSE("GPL") if using copyleft-next. Either way this series
didn't add a module yet so no need for that yet, but it does use
copyleft-next in headers / C code.
[0]
https://lkml.kernel.org/r/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aklsou...@mail.gmail.com
> However, if I
> want my binary only modules to be combined with Linux, I have to follow
> GPLv2 compliance because GPLv2 becomes the ruling licence of the
> combination. The same would apply to this copyleft-next, even after 15
> years.
And this what really matters here.
> The US copyright office defines a copyright work as anything which is
> "an original work of authorship fixed in any tangible medium of
> expression". That means any change to an existing work (i.e. by a
> patch) which contains enough originality to make the changed work
> distinct from the old work is ipso facto a new work. under copyright
> -next this new work has a sunset 15 years from its creation by
> combination, not 15 years from the original. This means a constantly
> updated work never sunsets. Sure, you can go back 15 years and claim
> the code at that time has passed into the public domain but you can't
> do that if you also want the benefit of later changes.
Agreed.
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [seabios baseline-only test] 66956: regressions - FAIL
This run is configured for baseline tests only. flight 66956 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66956/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 4 host-ping-check-native fail REGR. vs. 66866 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 66866 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66866 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66866 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: seabios 8bc6d9f8e9bd1c211660f9ec91c237821d7f4089 baseline version: seabios 09e24ac187d586c6a287927afffefe4da319fd3e Last test of basis66866 2016-07-30 08:49:22 Z 11 days Testing same since66956 2016-08-09 19:20:46 Z0 days1 attempts People who touched revisions under test: Dana Rubin Kevin O'Connor Shmulik Ladkani 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-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-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass 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.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 8bc6d9f8e9bd1c211660f9ec91c237821d7f4089 Author: Dana Rubin Date: Thu Aug 4 14:22:31 2016 +0300 pvscsi: Use high memory for rings Avoid using the scarce ZoneLow memory. This limits max number of pvscsi controllers. As driver runs in 32bit mode, use ZoneHigh allocation instead. Signed-off-by: Dana Rubin Signed-off-by: Shmulik Ladkani commit 85037a91179c04f83e5a4bf5b5b6af8a70a9f517 Author: Dana Rubin Date: Thu Aug 4 14:22:30 2016 +0300 pvscsi: Fix incorrect arguments order in call to memalign_low First argument should be 'align' and second 'size'. Signed-off-by: Signed-off-by: commit 8cdf0c5ab96282d821a024a8a382cb93432219fe Author: Kevin O'Connor Date: Fri Aug 5 13:44:12 2016 -0400 version: Update header files now that version.c is not auto generated Signed-off-by: Kevin O'Connor commit 65bc0a7bc9996b3ca7a65c8e5f1a45abdd4823a4 Author: Kevin O'Connor Date: Fri Aug 5 11:53:32 2016 -0400 vgautil: Move definitions from cbvga.h and clext.h to vgautil.h These files only need to export simple function definitions - move them to vgautil.h. Signed-off-by: Kevin O'Connor commit c682ffe671a0044fa218c1352c19894922e53890 Author: Kevin O'Connor Date: Fri Aug 5 11:48:20 2016 -0400 vgautil: Move generic definitions from stdvga.h to vgautil.h Don't use stdvga.h for function definitions of code in stdvgamodes.c and stdvgaio.c.
[Xen-devel] [xen-unstable-smoke test] 100396: tolerable all pass - PUSHED
flight 100396 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100396/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 6480cc6280e955d1245d8dfb2456d2b830240c74
baseline version:
xen 9b3f9b9c30f8dc121fe1bbf915a31e46cb926e83
Last test of basis 100391 2016-08-10 11:01:41 Z0 days
Testing same since 100394 2016-08-10 13:02:02 Z0 days2 attempts
People who touched revisions under test:
Andrew Cooper
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 :
+ branch=xen-unstable-smoke
+ revision=6480cc6280e955d1245d8dfb2456d2b830240c74
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
6480cc6280e955d1245d8dfb2456d2b830240c74
+ branch=xen-unstable-smoke
+ revision=6480cc6280e955d1245d8dfb2456d2b830240c74
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x6480cc6280e955d1245d8dfb2456d2b830240c74 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://git
[Xen-devel] [ovmf test] 100388: all pass - PUSHED
flight 100388 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100388/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf af90df3cb099ed8e009579b7b55e7142dc0fc410
baseline version:
ovmf 5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
Last test of basis 100376 2016-08-10 02:45:14 Z0 days
Testing same since 100388 2016-08-10 08:15:00 Z0 days1 attempts
People who touched revisions under test:
Shi, Steven
Steven Shi
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 :
+ branch=ovmf
+ revision=af90df3cb099ed8e009579b7b55e7142dc0fc410
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
af90df3cb099ed8e009579b7b55e7142dc0fc410
+ branch=ovmf
+ revision=af90df3cb099ed8e009579b7b55e7142dc0fc410
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xaf90df3cb099ed8e009579b7b55e7142dc0fc410 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
Re: [Xen-devel] [DRAFT v5] PV Calls protocol design document (former XenSock)
Ping? On Thu, 4 Aug 2016, Stefano Stabellini wrote: > Hi all, > > This is the design document of the PV Calls protocol. You can find > prototypes of the Linux frontend and backend drivers here: > > git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-5 > > To use them, make sure to enable CONFIG_PVCALLS in your kernel config > and add "pvcalls=1" to the command line of your DomU Linux kernel. You > also need the toolstack to create the initial xenstore nodes for the > protocol. To do that, please apply the attached patch to libxl (the > patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config > file. > > Note that previous versions of the protocols were named XenSock. It has > been renamed for clarity of scope and to avoid confusion with hv_sock > and vsock, which are used for inter-VMs communications. > > Cheers, > > Stefano > > Changes in v5: > - clarify text > - rename id to req_id > - rename sockid to id > - move id to request and response specific fields > - add version node to xenstore > > Changes in v4: > - rename xensock to pvcalls > > Changes in v3: > - add a dummy element to struct xen_xensock_request to make sure the > size of the struct is the same on both x86_32 and x86_64 > > Changes in v2: > - add max-dataring-page-order > - add "Publish backend features and transport parameters" to backend > xenbus workflow > - update new cmd values > - update xen_xensock_request > - add backlog parameter to listen and binary layout > - add description of new data ring format (interface+data) > - modify connect and accept to reflect new data ring format > - add link to POSIX docs > - add error numbers > - add address format section and relevant numeric definitions > - add explicit mention of unimplemented commands > - add protocol node name > - add xenbus shutdown diagram > - add socket operation > > --- > > # PV Calls Protocol version 1 > > ## Rationale > > PV Calls is a paravirtualized protocol that allows the implementation of > a set of POSIX functions in a different domain. The PV Calls frontend > sends POSIX function calls to the backend, which implements them and > returns a value to the frontend. > > This version of the document covers networking function calls, such as > connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but > the protocol is meant to be easily extended to cover different sets of > calls. Unimplemented commands return ENOTSUPP. > > PV Calls provide the following benefits: > * full visibility of the guest behavior on the backend domain, allowing > for inexpensive filtering and manipulation of any guest calls > * excellent performance > > Specifically, PV Calls for networking offer these advantages: > * guest networking works out of the box with VPNs, wireless networks and > any other complex configurations on the host > * guest services listen on ports bound directly to the backend domain IP > addresses > * localhost becomes a secure namespace for inter-VMs communications > > > ## Design > > ### Xenstore > > The frontend and the backend connect to each other exchanging information via > xenstore. The toolstack creates front and back nodes with state > XenbusStateInitialising. The protocol node name is **pvcalls**. There can only > be one PV Calls frontend per domain. > > Frontend XenBus Nodes > > port > Values: > > The identifier of the Xen event channel used to signal activity > in the ring buffer. > > ring-ref > Values: > > The Xen grant reference granting permission for the backend to map > the sole page in a single page sized ring buffer. > > Backend XenBus Nodes > > version > Values: > > Protocol version supported by the backend. > > max-dataring-page-order > Values: > > The maximum supported size of the data ring in units of lb(machine > pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, etc.). > > State Machine > > Initialization: > > *Front* *Back* > XenbusStateInitialising XenbusStateInitialising > - Query virtual device- Query backend device > properties. identification data. > - Setup OS device instance. - Publish backend features > - Allocate and initialize the and transport parameters > request ring. | > - Publish transport parameters | > that will be in effect during V > this connection.XenbusStateInitWait > | > | > V >XenbusStateInitialised > > - Query frontend transport > parameters. > - Connect to the request ring and >
[Xen-devel] [linux-4.1 test] 100383: tolerable FAIL - PUSHED
flight 100383 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100383/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl 11 guest-start fail like 99847 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeatfail like 99847 test-armhf-armhf-xl-xsm 11 guest-start fail like 99873 build-amd64-rumpuserxen 6 xen-buildfail like 99879 build-i386-rumpuserxen6 xen-buildfail like 99879 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 99879 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99879 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99879 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99879 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 99879 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 99879 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99879 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: linux558ba5fd7d8dbe0b233c309ce89317c1d0858bd7 baseline version: linuxc3ed55b836cff718dd0d654b6daf7c96be2a5ac2 Last test of basis99879 2016-08-01 02:32:34 Z9 days Testing same since 100371 2016-08-09 19:20:23 Z1 days2 attempts People who touched revisions under test: Alexey Dobriyan Andrew Morton Andrew Worsley # [MacBookPro10,1] Andrey Ryabinin Awais Belal Bryan Paradis# [MacBookPro9,2] Cameron Gutman Chris Bainbridge # [MacBookPro10,2] Chris Wilson Daniel Vetter David Rientjes David S. Miller Dmitri Epshtein Dmitry Torokhov Dmitry Vyukov Florian Westphal Greg Kroah-Hartman Gregory CLEMENT Hui Wang Ilya Dryomov Ingo Molnar James Patrick-Evans Jeff Wu Jiri Slaby Joonsoo Kim Konstantin Khlebnikov Konstantin Simanov # [MacBookPro8,1] Linus Torvalds Lukas Wunner Lukas Wunner # [MacBookPro9,1] Marcin Wojtas Matt Fleming Maxim Patlasov Mel Gorman Miklos Szeredi Minchan Kim Pablo Neira Ayuso Peter Wu RafaÅ MiÅecki Rodolfo Giometti Romain Perier Sasha Levin Sinclair Yeh Takashi Iwai Taras Kondratiuk Tejun Heo Terry Stockert Thomas Gleixner Thomas Petazzoni Ulf Hansson Vivek Goyal Vlastimil Babka Wi
Re: [Xen-devel] [PATCH v2 01/18] mini-os: correct first free pfn
Juergen Gross, on Fri 05 Aug 2016 19:35:45 +0200, wrote:
> The first free pfn available for allocation is calculated by adding the
> number of page table frames to the pfn of the first page table and
> then the magic number 3 to account for start info page et al.
>
> As the start info page, xenstore page and console page are allocated
> _before_ the page tables leaving room for these pages behind the page
> tables makes no sense.
Ah, it seems this dates back a very long time ago indeed.
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
> ---
> arch/x86/mm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index 51aa966..ae1036e 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -867,9 +867,8 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned
> long* max_pfn_p)
> printk("stack start: %p(VA)\n", stack);
> printk(" _end: %p(VA)\n", &_end);
>
> -/* First page follows page table pages and 3 more pages (store page etc)
> */
> -start_pfn = PFN_UP(to_phys(start_info.pt_base)) +
> -start_info.nr_pt_frames + 3;
> +/* First page follows page table pages. */
> +start_pfn = PFN_UP(to_phys(start_info.pt_base)) +
> start_info.nr_pt_frames;
> max_pfn = start_info.nr_pages;
>
> /* We need room for demand mapping and heap, clip available memory */
> --
> 2.6.6
>
--
Samuel
hiri, le cri ici, c des marrants
j'ai un rep ".uglyhackdirectorywithoutacls" ds mon home
-+- #ens-mim en stage -+-
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 02/18] mini-os: remove unused alloc_contig_pages() function
Juergen Gross, on Fri 05 Aug 2016 19:35:46 +0200, wrote:
> alloc_contig_pages() is never used anywhere in mini-os. Remove it.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
> ---
> arch/x86/mm.c | 142
> --
> include/mm.h | 1 -
> 2 files changed, 143 deletions(-)
>
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index ae1036e..c59a5d3 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -652,148 +652,6 @@ int unmap_frames(unsigned long va, unsigned long
> num_frames)
> }
>
> /*
> - * Allocate pages which are contiguous in machine memory.
> - * Returns a VA to where they are mapped or 0 on failure.
> - *
> - * addr_bits indicates if the region has restrictions on where it is
> - * located. Typical values are 32 (if for example PCI devices can't access
> - * 64bit memory) or 0 for no restrictions.
> - *
> - * Allocated pages can be freed using the page allocators free_pages()
> - * function.
> - *
> - * based on Linux function xen_create_contiguous_region()
> - */
> -#define MAX_CONTIG_ORDER 9 /* 2MB */
> -unsigned long alloc_contig_pages(int order, unsigned int addr_bits)
> -{
> -unsigned long in_va, va;
> -unsigned long in_frames[1UL << order], out_frames, mfn;
> -multicall_entry_t call[1UL << order];
> -unsigned int i, num_pages = 1UL << order;
> -int ret, exch_success;
> -
> -/* pass in num_pages 'extends' of size 1 and
> - * request 1 extend of size 'order */
> -struct xen_memory_exchange exchange = {
> -.in = {
> -.nr_extents = num_pages,
> -.extent_order = 0,
> -.domid= DOMID_SELF
> -},
> -.out = {
> -.nr_extents = 1,
> -.extent_order = order,
> -.address_bits = addr_bits,
> -.domid= DOMID_SELF
> -},
> -.nr_exchanged = 0
> -};
> -
> -if ( order > MAX_CONTIG_ORDER )
> -{
> -printk("alloc_contig_pages: order too large 0x%x > 0x%x\n",
> - order, MAX_CONTIG_ORDER);
> -return 0;
> -}
> -
> -/* Allocate some potentially discontiguous pages */
> -in_va = alloc_pages(order);
> -if ( !in_va )
> -{
> -printk("alloc_contig_pages: could not get enough pages
> (order=0x%x\n",
> - order);
> -return 0;
> -}
> -
> -/* set up arguments for exchange hyper call */
> -set_xen_guest_handle(exchange.in.extent_start, in_frames);
> -set_xen_guest_handle(exchange.out.extent_start, &out_frames);
> -
> -/* unmap current frames, keep a list of MFNs */
> -for ( i = 0; i < num_pages; i++ )
> -{
> -int arg = 0;
> -
> -va = in_va + (PAGE_SIZE * i);
> -in_frames[i] = virt_to_mfn(va);
> -
> -/* update P2M mapping */
> -phys_to_machine_mapping[virt_to_pfn(va)] = INVALID_P2M_ENTRY;
> -
> -/* build multi call */
> -call[i].op = __HYPERVISOR_update_va_mapping;
> -call[i].args[arg++] = va;
> -call[i].args[arg++] = 0;
> -#ifdef __i386__
> -call[i].args[arg++] = 0;
> -#endif
> -call[i].args[arg++] = UVMF_INVLPG;
> -}
> -
> -ret = HYPERVISOR_multicall(call, i);
> -if ( ret )
> -{
> -printk("Odd, update_va_mapping hypercall failed with rc=%d.\n", ret);
> -return 0;
> -}
> -
> -/* try getting a contig range of MFNs */
> -out_frames = virt_to_pfn(in_va); /* PFNs to populate */
> -ret = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
> -if ( ret ) {
> -printk("mem exchanged order=0x%x failed with rc=%d,
> nr_exchanged=%lu\n",
> - order, ret, exchange.nr_exchanged);
> -/* we still need to return the allocated pages above to the pool
> - * ie. map them back into the 1:1 mapping etc. so we continue but
> - * in the end return the pages to the page allocator and return 0. */
> -exch_success = 0;
> -}
> -else
> -exch_success = 1;
> -
> -/* map frames into 1:1 and update p2m */
> -for ( i = 0; i < num_pages; i++ )
> -{
> -int arg = 0;
> -pte_t pte;
> -
> -va = in_va + (PAGE_SIZE * i);
> -mfn = i < exchange.nr_exchanged ? (out_frames + i) : in_frames[i];
> -pte = __pte(mfn << PAGE_SHIFT | L1_PROT);
> -
> -/* update P2M mapping */
> -phys_to_machine_mapping[virt_to_pfn(va)] = mfn;
> -
> -/* build multi call */
> -call[i].op = __HYPERVISOR_update_va_mapping;
> -call[i].args[arg++] = va;
> -#ifdef __x86_64__
> -call[i].args[arg++] = (pgentry_t)pte.pte;
> -#else
> -call[i].args[arg++] = pte.pte_low;
> -call[i].args[arg++] = pte.pte_high;
> -#endif
> -call[i].args[arg++] = UVMF_INVLPG;
> -}
> -ret = HYPERVISOR_multicall(call, i);
> -if ( ret )
> -{
> -printk("update_va_mapping hypercall no. 2 fail
Re: [Xen-devel] [PATCH v2 03/18] mini-os: remove MM_DEBUG code
Juergen Gross, on Fri 05 Aug 2016 19:35:47 +0200, wrote:
> mm.c contains unused code inside #ifdef MM_DEBUG areas. Its usability
> is rather questionable and some parts are even wrong (e.g.
> print_chunks() called with nr_pages > 1000 will clobber an arbitrary
> stack content with a 0 byte).
>
> Remove this code.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
> ---
> mm.c | 60
> 1 file changed, 60 deletions(-)
>
> diff --git a/mm.c b/mm.c
> index 31aaf83..0dd4862 100644
> --- a/mm.c
> +++ b/mm.c
> @@ -42,13 +42,6 @@
> #include
> #include
>
> -#ifdef MM_DEBUG
> -#define DEBUG(_f, _a...) \
> -printk("MINI_OS(file=mm.c, line=%d) " _f "\n", __LINE__, ## _a)
> -#else
> -#define DEBUG(_f, _a...)((void)0)
> -#endif
> -
> /*
> * ALLOCATION BITMAP
> * One bit per page of memory. Bit set => page is allocated.
> @@ -140,59 +133,6 @@ static chunk_head_t free_tail[FREELIST_SIZE];
> #define round_pgdown(_p) ((_p)&PAGE_MASK)
> #define round_pgup(_p)(((_p)+(PAGE_SIZE-1))&PAGE_MASK)
>
> -#ifdef MM_DEBUG
> -/*
> - * Prints allocation[0/1] for @nr_pages, starting at @start
> - * address (virtual).
> - */
> -USED static void print_allocation(void *start, int nr_pages)
> -{
> -unsigned long pfn_start = virt_to_pfn(start);
> -int count;
> -for(count = 0; count < nr_pages; count++)
> -if(allocated_in_map(pfn_start + count)) printk("1");
> -else printk("0");
> -
> -printk("\n");
> -}
> -
> -/*
> - * Prints chunks (making them with letters) for @nr_pages starting
> - * at @start (virtual).
> - */
> -USED static void print_chunks(void *start, int nr_pages)
> -{
> -char chunks[1001], current='A';
> -int order, count;
> -chunk_head_t *head;
> -unsigned long pfn_start = virt_to_pfn(start);
> -
> -memset(chunks, (int)'_', 1000);
> -if(nr_pages > 1000)
> -{
> -DEBUG("Can only pring 1000 pages. Increase buffer size.");
> -}
> -
> -for(order=0; order < FREELIST_SIZE; order++)
> -{
> -head = free_head[order];
> -while(!FREELIST_EMPTY(head))
> -{
> -for(count = 0; count < 1UL<< head->level; count++)
> -{
> -if(count + virt_to_pfn(head) - pfn_start < 1000)
> -chunks[count + virt_to_pfn(head) - pfn_start] = current;
> -}
> -head = head->next;
> -current++;
> -}
> -}
> -chunks[nr_pages] = '\0';
> -printk("%s\n", chunks);
> -}
> -#endif
> -
> -
> /*
> * Initialise allocator, placing addresses [@min,@max] in free pool.
> * @min and @max are PHYSICAL addresses.
> --
> 2.6.6
>
--
Samuel
Be warned that typing \fBkillall \fIname\fP may not have the desired
effect on non-Linux systems, especially when done by a privileged user.
(From the killall manual page)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/18] mini-os: add description of x86 memory usage
Juergen Gross, on Fri 05 Aug 2016 19:35:48 +0200, wrote: > Add a brief description how the physical and virtual address usage > looks like on x86 to include/x86/arch_mm.h > > Signed-off-by: Juergen Gross > Reviewed-by: Wei Liu Acked-by: Samuel Thibault > --- > include/x86/arch_mm.h | 20 > 1 file changed, 20 insertions(+) > > diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h > index 58f29fc..f756dab 100644 > --- a/include/x86/arch_mm.h > +++ b/include/x86/arch_mm.h > @@ -36,6 +36,26 @@ > #endif > #endif > > +/* > + * Physical address space usage: > + * > + * 0..._edata: kernel text/data > + * *stack: kernel stack (thread 0) > + * hypervisor allocated data: p2m_list, start_info page, xenstore page, > + *console page, initial page tables > + * bitmap of allocated pages > + * pages controlled by the page allocator > + * > + * > + * Virtual address space usage: > + * > + * 1:1 mapping of physical memory starting at VA(0) > + * 1 unallocated page > + * demand map area (32 bits: 2 GB, 64 bits: 128 GB) for virtual allocations > + * 1 unallocated page > + * with libc: heap area (32 bits: 1 GB, 64 bits: 128 GB) > + */ > + > #define L1_FRAME1 > #define L2_FRAME2 > #define L3_FRAME3 > -- > 2.6.6 > -- Samuel l'alim je sais où elle est, elle est juste à côté de la dame qui dort B: clairement faut revoir les priorités dans la vie B: une dame ça se retrouve, un uptime... ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/18] mini-os: add nr_free_pages counter
Juergen Gross, on Fri 05 Aug 2016 19:35:49 +0200, wrote:
> Add a variable holding the number of available memory pages. This will
> aid auto-ballooning later.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
> ---
> include/mm.h | 1 +
> mm.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/include/mm.h b/include/mm.h
> index a48f485..b97b43e 100644
> --- a/include/mm.h
> +++ b/include/mm.h
> @@ -42,6 +42,7 @@
> #define STACK_SIZE_PAGE_ORDER __STACK_SIZE_PAGE_ORDER
> #define STACK_SIZE __STACK_SIZE
>
> +extern unsigned long nr_free_pages;
>
> void init_mm(void);
> unsigned long alloc_pages(int order);
> diff --git a/mm.c b/mm.c
> index 0dd4862..263a356 100644
> --- a/mm.c
> +++ b/mm.c
> @@ -53,6 +53,8 @@ static unsigned long *alloc_bitmap;
> #define allocated_in_map(_pn) \
> (alloc_bitmap[(_pn)/PAGES_PER_MAPWORD] &
> (1UL<<((_pn)&(PAGES_PER_MAPWORD-1
>
> +unsigned long nr_free_pages;
> +
> /*
> * Hint regarding bitwise arithmetic in map_{alloc,free}:
> * -(1<= n.
> @@ -81,6 +83,8 @@ static void map_alloc(unsigned long first_page, unsigned
> long nr_pages)
> while ( ++curr_idx < end_idx ) alloc_bitmap[curr_idx] = ~0UL;
> alloc_bitmap[curr_idx] |= (1UL< }
> +
> +nr_free_pages -= nr_pages;
> }
>
>
> @@ -93,6 +97,8 @@ static void map_free(unsigned long first_page, unsigned
> long nr_pages)
> end_idx = (first_page + nr_pages) / PAGES_PER_MAPWORD;
> end_off = (first_page + nr_pages) & (PAGES_PER_MAPWORD-1);
>
> +nr_free_pages += nr_pages;
> +
> if ( curr_idx == end_idx )
> {
> alloc_bitmap[curr_idx] &= -(1UL< --
> 2.6.6
>
--
Samuel
In mutt, type cthis
Dans mutt, taper cceci
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/18] mini-os: let memory allocation fail if no free page available
Juergen Gross, on Fri 05 Aug 2016 19:35:50 +0200, wrote:
> Instead of panicing when no page can be allocated try to fail the
> memory allocation by returning NULL instead.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
> ---
> V2: fixed minor style issue
> ---
> mm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mm.c b/mm.c
> index 263a356..8cf3210 100644
> --- a/mm.c
> +++ b/mm.c
> @@ -335,6 +335,13 @@ void *sbrk(ptrdiff_t increment)
>
> if (new_brk > heap_mapped) {
> unsigned long n = (new_brk - heap_mapped + PAGE_SIZE - 1) /
> PAGE_SIZE;
> +
> +if ( n > nr_free_pages )
> +{
> +printk("Memory exhausted: want %ld pages, but only %ld are
> left\n",
> + n, nr_free_pages);
> +return NULL;
> +}
> do_map_zero(heap_mapped, n);
> heap_mapped += n * PAGE_SIZE;
> }
> --
> 2.6.6
>
--
Samuel
War doesn't prove who's right, just who's left.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 07/18] mini-os: add ballooning config item
Juergen Gross, on Fri 05 Aug 2016 19:35:51 +0200, wrote: > Add CONFIG_BALLOON defaulting to 'n' as a config item to Mini-OS. > > Add balloon.c, balloon.h and arch/*/balloon.c for future use. > > Signed-off-by: Juergen Gross Not much to be against here :) Acked-by: Samuel Thibault > --- > V2: Added dummy sources and header > --- > Makefile | 3 +++ > arch/arm/balloon.c | 28 > arch/x86/balloon.c | 28 > balloon.c | 24 > include/balloon.h | 32 > 5 files changed, 115 insertions(+) > create mode 100644 arch/arm/balloon.c > create mode 100644 arch/x86/balloon.c > create mode 100644 balloon.c > create mode 100644 include/balloon.h > > diff --git a/Makefile b/Makefile > index 2e4bdba..f5b7011 100644 > --- a/Makefile > +++ b/Makefile > @@ -33,6 +33,7 @@ CONFIG_CONSFRONT ?= y > CONFIG_XENBUS ?= y > CONFIG_XC ?=y > CONFIG_LWIP ?= $(lwip) > +CONFIG_BALLOON ?= n > > # Export config items as compiler directives > flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK > @@ -48,6 +49,7 @@ flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT > flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT > flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT > flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS > +flags-$(CONFIG_BALLOON) += -DCONFIG_BALLOON > > DEF_CFLAGS += $(flags-y) > > @@ -96,6 +98,7 @@ src-$(CONFIG_NETFRONT) += netfront.c > src-$(CONFIG_PCIFRONT) += pcifront.c > src-y += sched.c > src-$(CONFIG_TEST) += test.c > +src-$(CONFIG_BALLOON) += balloon.c > > src-y += lib/ctype.c > src-y += lib/math.c > diff --git a/arch/arm/balloon.c b/arch/arm/balloon.c > new file mode 100644 > index 000..dc6270d > --- /dev/null > +++ b/arch/arm/balloon.c > @@ -0,0 +1,28 @@ > +/* -*- Mode:C; c-basic-offset:4; tab-width:4 -*- > + * > + * (C) 2016 - Juergen Gross, SUSE Linux GmbH > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > + * deal in the Software without restriction, including without limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or > + * sell copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + */ > + > +#include > + > +#ifdef CONFIG_BALLOON > + > +#endif > diff --git a/arch/x86/balloon.c b/arch/x86/balloon.c > new file mode 100644 > index 000..dc6270d > --- /dev/null > +++ b/arch/x86/balloon.c > @@ -0,0 +1,28 @@ > +/* -*- Mode:C; c-basic-offset:4; tab-width:4 -*- > + * > + * (C) 2016 - Juergen Gross, SUSE Linux GmbH > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > + * deal in the Software without restriction, including without limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or > + * sell copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + */ > + > +#include > + > +#ifdef CONFIG_BALLOON > + > +#endif > diff --git a/balloon.c b/balloon.c > new file mode 100644 > index 000..9cabde0 > --- /dev/null > +++ b/balloon.c > @@ -0,0 +1,24 @@ > +/* -*- Mode:C; c-basic-offset:4; tab-width:4 -*- > + * > + * (C) 2016 - Juergen Gross, SUSE Linux GmbH > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and
[Xen-devel] [xen-unstable baseline-only test] 66957: tolerable FAIL
This run is configured for baseline tests only. flight 66957 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66957/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 66945 build-amd64-rumpuserxen 6 xen-buildfail like 66945 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66945 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66945 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 8e370ef503e8df249c3e3dd2ea17b3f100d4f20a baseline version: xen 72798298c751a3df21473a0d86d05ec7bb46e258 Last test of basis66945 2016-08-09 06:15:31 Z1 days Testing same since66957 2016-08-09 20:48:30 Z0 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Ian Jackson Wei Liu jobs: build-amd64-xsm pass build-armhf-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-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev
Re: [Xen-devel] [PATCH v2 08/18] mini-os: get maximum memory size from hypervisor
Juergen Gross, on Fri 05 Aug 2016 19:35:52 +0200, wrote:
> Add support for obtaining the maximum memory size from the hypervisor.
> This will make it possible to support ballooning.
>
> Signed-off-by: Juergen Gross
Acked-by: Samuel Thibault
> diff --git a/mm.c b/mm.c
> index 8cf3210..25ee3da 100644
> --- a/mm.c
> +++ b/mm.c
> @@ -353,7 +354,6 @@ void *sbrk(ptrdiff_t increment)
> #endif
>
>
> -
> void init_mm(void)
> {
>
That one could be dropped from the patch :)
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 09/18] mini-os: modify virtual memory layout for support of ballooning
Juergen Gross, on Fri 05 Aug 2016 19:35:53 +0200, wrote: > In order to be able to support ballooning the virtual memory layout > of Mini-OS has to be modified: instead of a (nearly) consecutive > area used for physical memory mapping, on demand mappings, and heap > we need enough spare place for adding new memory. > > So instead of dynamically place the different regions based on found > memory size locate them statically at fixed virtual addresses: > > area x86-64 x86-32 > > mapped physical memory > kernel virtual mappings80 3f00 > demand mappings 1000 4000 > heap 2000 b000 > > This will enable Mini-OS to support up to 512GB of domain memory with > a 64 bit kernel and nearly 1GB with a 32 bit kernel. > > For a 32 bit Mini-OS we have to avoid a conflict between heap and > m2p table which the hypervisor maps at f560. So the demand mapping > size is reduced by 256MB in order to keep the heap at about 1GB. > > The kernel virtual mappings are a new area needed for being able to > grow the p2m list without having to relocate it in physical memory. > > Modify the placement of the demand mappings and heap and adjust the > memory layout description. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 10/18] mini-os: remove unused mem_test() function
Juergen Gross, on Fri 05 Aug 2016 19:35:54 +0200, wrote:
> mem_test() isn't used anywhere and its value is rather questionable
> with mini-os being in a mature state. Remove the function.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> arch/x86/mm.c | 55 ---
> 1 file changed, 55 deletions(-)
>
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index 6aa4468..e2f026b 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -302,61 +302,6 @@ static void set_readonly(void *text, void *etext)
> }
>
> /*
> - * A useful mem testing function. Write the address to every address in the
> - * range provided and read back the value. If verbose, print page walk to
> - * some VA
> - *
> - * If we get MEM_TEST_MAX_ERRORS we might as well stop
> - */
> -#define MEM_TEST_MAX_ERRORS 10
> -int mem_test(unsigned long *start_va, unsigned long *end_va, int verbose)
> -{
> -unsigned long mask = 0x1;
> -unsigned long *pointer;
> -int error_count = 0;
> -
> -/* write values and print page walks */
> -if ( verbose && (((unsigned long)start_va) & 0xf) )
> -{
> -printk("MemTest Start: 0x%p\n", start_va);
> -page_walk((unsigned long)start_va);
> -}
> -for ( pointer = start_va; pointer < end_va; pointer++ )
> -{
> -if ( verbose && !(((unsigned long)pointer) & 0xf) )
> -{
> -printk("Writing to %p\n", pointer);
> -page_walk((unsigned long)pointer);
> -}
> -*pointer = (unsigned long)pointer & ~mask;
> -}
> -if ( verbose && (((unsigned long)end_va) & 0xf) )
> -{
> -printk("MemTest End: %p\n", end_va-1);
> -page_walk((unsigned long)end_va-1);
> -}
> -
> -/* verify values */
> -for ( pointer = start_va; pointer < end_va; pointer++ )
> -{
> -if ( ((unsigned long)pointer & ~mask) != *pointer )
> -{
> -printk("Read error at 0x%lx. Read: 0x%lx, should read 0x%lx\n",
> - (unsigned long)pointer, *pointer,
> - ((unsigned long)pointer & ~mask));
> -error_count++;
> -if ( error_count >= MEM_TEST_MAX_ERRORS )
> -{
> -printk("mem_test: too many errors\n");
> -return -1;
> -}
> -}
> -}
> -return 0;
> -}
> -
> -
> -/*
> * get the PTE for virtual address va if it exists. Otherwise NULL.
> */
> static pgentry_t *get_pgt(unsigned long va)
> --
> 2.6.6
>
--
Samuel
In mutt, type cthis
Dans mutt, taper cceci
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/18] mini-os: add checks for out of memory
Juergen Gross, on Fri 05 Aug 2016 19:35:55 +0200, wrote:
> There are several core functions in Mini-OS not checking for failed
> memory allocations. Add such checks.
>
> Add do_map_frames() dummy function to arm architecture as it will be
> needed in future for compilations to succeed.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> arch/arm/mm.c | 8
> arch/x86/mm.c | 26 +++---
> include/mm.h | 2 +-
> 3 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mm.c b/arch/arm/mm.c
> index f75888d..fc8d4bc 100644
> --- a/arch/arm/mm.c
> +++ b/arch/arm/mm.c
> @@ -1,6 +1,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -79,6 +80,13 @@ void arch_init_demand_mapping_area(void)
> {
> }
>
> +int do_map_frames(unsigned long addr,
> +const unsigned long *f, unsigned long n, unsigned long stride,
> +unsigned long increment, domid_t id, int *err, unsigned long prot)
> +{
> +return -ENOSYS;
> +}
> +
> /* Get Xen's suggested physical page assignments for the grant table. */
> static paddr_t get_gnttab_base(void)
> {
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index e2f026b..12f7fe4 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -34,6 +34,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -354,6 +355,8 @@ pgentry_t *need_pgt(unsigned long va)
> if ( !(tab[offset] & _PAGE_PRESENT) )
> {
> pt_pfn = virt_to_pfn(alloc_page());
> +if ( !pt_pfn )
> +return NULL;
> new_pt_frame(&pt_pfn, pt_mfn, offset, L3_FRAME);
> }
> ASSERT(tab[offset] & _PAGE_PRESENT);
> @@ -364,6 +367,8 @@ pgentry_t *need_pgt(unsigned long va)
> if ( !(tab[offset] & _PAGE_PRESENT) )
> {
> pt_pfn = virt_to_pfn(alloc_page());
> +if ( !pt_pfn )
> +return NULL;
> new_pt_frame(&pt_pfn, pt_mfn, offset, L2_FRAME);
> }
> ASSERT(tab[offset] & _PAGE_PRESENT);
> @@ -373,6 +378,8 @@ pgentry_t *need_pgt(unsigned long va)
> if ( !(tab[offset] & _PAGE_PRESENT) )
> {
> pt_pfn = virt_to_pfn(alloc_page());
> +if ( !pt_pfn )
> +return NULL;
> new_pt_frame(&pt_pfn, pt_mfn, offset, L1_FRAME);
> }
> ASSERT(tab[offset] & _PAGE_PRESENT);
> @@ -445,10 +452,10 @@ unsigned long allocate_ondemand(unsigned long n,
> unsigned long alignment)
> * va. map f[i*stride]+i*increment for i in 0..n-1.
> */
> #define MAP_BATCH ((STACK_SIZE / 2) / sizeof(mmu_update_t))
> -void do_map_frames(unsigned long va,
> - const unsigned long *mfns, unsigned long n,
> - unsigned long stride, unsigned long incr,
> - domid_t id, int *err, unsigned long prot)
> +int do_map_frames(unsigned long va,
> + const unsigned long *mfns, unsigned long n,
> + unsigned long stride, unsigned long incr,
> + domid_t id, int *err, unsigned long prot)
> {
> pgentry_t *pgt = NULL;
> unsigned long done = 0;
> @@ -458,7 +465,7 @@ void do_map_frames(unsigned long va,
> if ( !mfns )
> {
> printk("do_map_frames: no mfns supplied\n");
> -return;
> +return -EINVAL;
> }
> DEBUG("va=%p n=0x%lx, mfns[0]=0x%lx stride=0x%lx incr=0x%lx
> prot=0x%lx\n",
>va, n, mfns[0], stride, incr, prot);
> @@ -484,7 +491,9 @@ void do_map_frames(unsigned long va,
> {
> if ( !pgt || !(va & L1_MASK) )
> pgt = need_pgt(va);
> -
> +if ( !pgt )
> +return -ENOMEM;
> +
> mmu_updates[i].ptr = virt_to_mach(pgt) |
> MMU_NORMAL_PT_UPDATE;
> mmu_updates[i].val = ((pgentry_t)(mfns[(done + i) * stride] +
>(done + i) * incr)
> @@ -505,6 +514,8 @@ void do_map_frames(unsigned long va,
> }
> done += todo;
> }
> +
> +return 0;
> }
>
> /*
> @@ -521,7 +532,8 @@ void *map_frames_ex(const unsigned long *mfns, unsigned
> long n,
> if ( !va )
> return NULL;
>
> -do_map_frames(va, mfns, n, stride, incr, id, err, prot);
> +if ( do_map_frames(va, mfns, n, stride, incr, id, err, prot) )
> +return NULL;
>
> return (void *)va;
> }
> diff --git a/include/mm.h b/include/mm.h
> index a22dcd1..9244e26 100644
> --- a/include/mm.h
> +++ b/include/mm.h
> @@ -68,7 +68,7 @@ unsigned long allocate_ondemand(unsigned long n, unsigned
> long alignment);
> void *map_frames_ex(const unsigned long *f, unsigned long n, unsigned long
> stride,
> unsigned long increment, unsigned long alignment, domid_t id,
> int *err, unsigned long prot);
> -void do_map_frames(unsigned long addr,
> +int do_map_frames(unsigned long addr,
> const unsigned long *f, unsi
Re: [Xen-devel] [PATCH v2 12/18] mini-os: don't allocate new pages for level 1 p2m tree
Juergen Gross, on Fri 05 Aug 2016 19:35:56 +0200, wrote:
> When constructing the 3 level p2m tree there is no need to allocate
> new pages for the level 1 containing the p2m info for all pages. The
> pages from the linear p2m list constructed by the hypervisor can be
> used for that purpose.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> arch/x86/mm.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index 12f7fe4..e10c2c5 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -625,11 +625,11 @@ void arch_init_p2m(unsigned long max_pfn)
> #define L2_P2M_MASK (L2_P2M_ENTRIES - 1)
> #define L3_P2M_MASK (L3_P2M_ENTRIES - 1)
>
> -unsigned long *l1_list = NULL, *l2_list = NULL, *l3_list;
> +unsigned long *l2_list = NULL, *l3_list;
> unsigned long pfn;
>
> l3_list = (unsigned long *)alloc_page();
> -for ( pfn=0; pfn +for ( pfn = 0; pfn < max_pfn; pfn += L1_P2M_ENTRIES )
> {
> if ( !(pfn % (L1_P2M_ENTRIES * L2_P2M_ENTRIES)) )
> {
> @@ -641,14 +641,8 @@ void arch_init_p2m(unsigned long max_pfn)
> }
> l3_list[(pfn >> L2_P2M_SHIFT)] = virt_to_mfn(l2_list);
> }
> -if ( !(pfn % (L1_P2M_ENTRIES)) )
> -{
> -l1_list = (unsigned long*)alloc_page();
> -l2_list[(pfn >> L1_P2M_SHIFT) & L2_P2M_MASK] =
> -virt_to_mfn(l1_list);
> -}
> -
> -l1_list[pfn & L1_P2M_MASK] = pfn_to_mfn(pfn);
> +l2_list[(pfn >> L1_P2M_SHIFT) & L2_P2M_MASK] =
> +virt_to_mfn(phys_to_machine_mapping + pfn);
> }
> HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list =
> virt_to_mfn(l3_list);
> --
> 2.6.6
>
--
Samuel
>Ever heard of .cshrc?
That's a city in Bosnia. Right?
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
