[Xen-devel] [qemu-mainline test] 57872: regressions - FAIL
flight 57872 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57872/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-build fail REGR. vs. 57815 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57815 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 57815 test-amd64-amd64-libvirt 11 guest-start fail like 57815 test-armhf-armhf-libvirt 11 guest-start fail like 57815 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 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-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu42d58e7c6760cb9c55627c28ae538e27dcf2f144 baseline version: qemuu3fc827d591679f3e262b9d1f8b34528eabfca8c0 People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Peter Maydell peter.mayd...@linaro.org Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64-xsm fail 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-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail
[Xen-devel] [seabios test] 57880: tolerable FAIL - PUSHED
flight 57880 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57880/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never
pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never
pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
seabios be050664fdd1699fe7bcf3a9b6faff07172a83d6
baseline version:
seabios 2aff1c10953bfb2f17b0702eb9e2962e1c78f3c9
People who touched revisions under test:
Kevin O'Connor ke...@koconnor.net
Paul Menzel paulepan...@sourceforge.net
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-debianhvm-amd64-xsmfail
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 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.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
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=seabios
+ revision=be050664fdd1699fe7bcf3a9b6faff07172a83d6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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 seabios
be050664fdd1699fe7bcf3a9b6faff07172a83d6
+ branch=seabios
+ revision=be050664fdd1699fe7bcf3a9b6faff07172a83d6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : 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/staging/qemu-xen-unstable.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
Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments
H. Peter Anvin h...@zytor.com writes:
On 06/04/2015 12:55 PM, Rusty Russell wrote:
Yeah, hard cases make bad law.
I'm not too unhappy with this fix; ideally we'd rename save_fl and
restore_fl to save_eflags_if and restore_eflags_if too.
I would be fine with this... but please document what the bloody
semantics of pvops is actually supposed to be.
*cough*.
Lightly compile tested...
Subject: x86: rename save_fl/restore_fl paravirt ops to highlight eflags.
From: Rusty Russell ru...@rustcorp.com.au
As the comment in arch/x86/include/asm/paravirt_types.h says:
* Get/set interrupt state. save_fl and restore_fl are only
* expected to use X86_EFLAGS_IF; all other bits
* returned from save_fl are undefined, and may be ignored by
* restore_fl.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 8957810ad7d1..5ad7b0e62a77 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -801,12 +801,12 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
static inline notrace unsigned long arch_local_save_flags(void)
{
- return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl);
+ return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_eflags_if);
}
static inline notrace void arch_local_irq_restore(unsigned long f)
{
- PVOP_VCALLEE1(pv_irq_ops.restore_fl, f);
+ PVOP_VCALLEE1(pv_irq_ops.restore_eflags_if, f);
}
static inline notrace void arch_local_irq_disable(void)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index f7b0b5c112f2..05425c8544f1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -204,8 +204,8 @@ struct pv_irq_ops {
* NOTE: These functions callers expect the callee to preserve
* more registers than the standard C calling convention.
*/
- struct paravirt_callee_save save_fl;
- struct paravirt_callee_save restore_fl;
+ struct paravirt_callee_save save_eflags_if;
+ struct paravirt_callee_save restore_eflags_if;
struct paravirt_callee_save irq_disable;
struct paravirt_callee_save irq_enable;
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c614dd492f5f..d42e33b66ee6 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -321,8 +321,8 @@ struct pv_time_ops pv_time_ops = {
};
__visible struct pv_irq_ops pv_irq_ops = {
- .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl),
- .restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
+ .save_eflags_if = __PV_IS_CALLEE_SAVE(native_save_fl),
+ .restore_eflags_if = __PV_IS_CALLEE_SAVE(native_restore_fl),
.irq_disable = __PV_IS_CALLEE_SAVE(native_irq_disable),
.irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
.safe_halt = native_safe_halt,
diff --git a/arch/x86/kernel/paravirt_patch_32.c
b/arch/x86/kernel/paravirt_patch_32.c
index d9f32e6d6ab6..cf20c1b37f43 100644
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -2,8 +2,8 @@
DEF_NATIVE(pv_irq_ops, irq_disable, cli);
DEF_NATIVE(pv_irq_ops, irq_enable, sti);
-DEF_NATIVE(pv_irq_ops, restore_fl, push %eax; popf);
-DEF_NATIVE(pv_irq_ops, save_fl, pushf; pop %eax);
+DEF_NATIVE(pv_irq_ops, restore_eflags_if, push %eax; popf);
+DEF_NATIVE(pv_irq_ops, save_eflags_if, pushf; pop %eax);
DEF_NATIVE(pv_cpu_ops, iret, iret);
DEF_NATIVE(pv_cpu_ops, irq_enable_sysexit, sti; sysexit);
DEF_NATIVE(pv_mmu_ops, read_cr2, mov %cr2, %eax);
@@ -38,8 +38,8 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
switch (type) {
PATCH_SITE(pv_irq_ops, irq_disable);
PATCH_SITE(pv_irq_ops, irq_enable);
- PATCH_SITE(pv_irq_ops, restore_fl);
- PATCH_SITE(pv_irq_ops, save_fl);
+ PATCH_SITE(pv_irq_ops, restore_eflags_if);
+ PATCH_SITE(pv_irq_ops, save_eflags_if);
PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
PATCH_SITE(pv_mmu_ops, read_cr2);
diff --git a/arch/x86/kernel/paravirt_patch_64.c
b/arch/x86/kernel/paravirt_patch_64.c
index a1da6737ba5b..24eaaa5f9aa6 100644
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -4,8 +4,8 @@
DEF_NATIVE(pv_irq_ops, irq_disable, cli);
DEF_NATIVE(pv_irq_ops, irq_enable, sti);
-DEF_NATIVE(pv_irq_ops, restore_fl, pushq %rdi; popfq);
-DEF_NATIVE(pv_irq_ops, save_fl, pushfq; popq %rax);
+DEF_NATIVE(pv_irq_ops, restore_eflags_if, pushq %rdi; popfq);
+DEF_NATIVE(pv_irq_ops, save_eflags_if, pushfq; popq %rax);
DEF_NATIVE(pv_mmu_ops, read_cr2, movq %cr2, %rax);
DEF_NATIVE(pv_mmu_ops, read_cr3, movq %cr3, %rax);
DEF_NATIVE(pv_mmu_ops, write_cr3, movq %rdi, %cr3);
@@ -45,8 +45,8 @@ unsigned
Re: [Xen-devel] qemu mainline regression with xen-unstable: unable to start QMP
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (tested many hours) of some days
ago I tried update qemu to latest development version (from git master
commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is
a regression:
xl create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: QMP input object member 'id' is unexpected
libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect
to QMP
This is caused by:
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
DomU is working but operations that require QMP not (for example
save/restore).
Thanks for any reply and sorry for my bad english.
The patch:
From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17 00:00:00 2001
From: Don Slutz dsl...@verizon.com
Date: Thu, 4 Jun 2015 17:04:42 -0400
Subject: [PATCH 01/14] monitor: Allow Xen's (broken) usage of asynchronous
command interface.
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
Breaks Xen. Add a hack un unbreak it.
Xen is only doing synchronous commands, but is including an id.
Signed-off-by: Don Slutz dsl...@verizon.com
---
monitor.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/monitor.c b/monitor.c
index c7baa91..e9a0747 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4955,6 +4955,15 @@ static QDict *qmp_check_input_obj(QObject
*input_obj, Error **errp)
arguments, object);
return NULL;
}
+} else if (!strcmp(arg_name, id)) {
+/*
+ * Fixup Xen's usage. Just ignore the id. See point #5
+ * above. This was an attempt at an asynchronous
+ * command interface. However commit
+ * 65207c59d99f2260c5f1d3b9c491146616a522aa is
+ * wrong. Xen does not expect an error when it passes in
+ * id:1, so just continue to ignore it.
+ */
} else {
error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name);
return NULL;
--
1.7.11.7
fixes things for me
-Don Slutz
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] qemu mainline regression with xen-unstable: unable to start QMP
On 06/04/15 17:59, Don Slutz wrote:
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (tested many hours) of some days
ago I tried update qemu to latest development version (from git master
commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is
a regression:
xl create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: QMP input object member 'id' is unexpected
libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect
to QMP
This is caused by:
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
DomU is working but operations that require QMP not (for example
save/restore).
Thanks for any reply and sorry for my bad english.
I have created a bug -- Bug #1462131 for this.
-Don Slutz
The patch:
From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17 00:00:00 2001
From: Don Slutz dsl...@verizon.com
Date: Thu, 4 Jun 2015 17:04:42 -0400
Subject: [PATCH 01/14] monitor: Allow Xen's (broken) usage of asynchronous
command interface.
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
Breaks Xen. Add a hack un unbreak it.
Xen is only doing synchronous commands, but is including an id.
Signed-off-by: Don Slutz dsl...@verizon.com
---
monitor.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/monitor.c b/monitor.c
index c7baa91..e9a0747 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4955,6 +4955,15 @@ static QDict *qmp_check_input_obj(QObject
*input_obj, Error **errp)
arguments, object);
return NULL;
}
+} else if (!strcmp(arg_name, id)) {
+/*
+ * Fixup Xen's usage. Just ignore the id. See point #5
+ * above. This was an attempt at an asynchronous
+ * command interface. However commit
+ * 65207c59d99f2260c5f1d3b9c491146616a522aa is
+ * wrong. Xen does not expect an error when it passes in
+ * id:1, so just continue to ignore it.
+ */
} else {
error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name);
return NULL;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 57865: regressions - FAIL
flight 57865 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57865/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 06/04/2015 10:56 PM, Jan Beulich wrote: Razvan Cojocaru rcojoc...@bitdefender.com 06/04/15 3:46 PM On 06/04/2015 04:43 PM, Tim Deegan wrote: At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), Razvan Cojocaru wrote: As suggested by Andrew Cooper, this patch attempts to remove some redundancy and allow for an easier time when adding vm_events for new control registers in the future, by having a single VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0, CR3, CR4 and (newly introduced) XCR0. The actual control register will be deduced by the new .index field in vm_event_write_ctrlreg (renamed from vm_event_mov_to_cr). The patch has also modified the xen-access.c test - it is now able to log CR3 events. Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Of course, if Jan (who originally proposed the macro) doesn't have any objections, I'll rename it. While I personally think it's better the way it is now, I don't object to it being renamed, even less so considering that Tim is the maintainer of that code and hence should have the final say. Understood, in that case I'll submit V10 tomorrow with the macro renamed to hvm_event_crX() as Tim has suggested. I am assuming that, since this will be the only change, it's fine to keep all the acks. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] qemu mainline regression with xen-unstable: unable to start QMP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/15 18:10, Eric Blake wrote:
[adding Markus, as author of the regression]
On 06/04/2015 03:59 PM, Don Slutz wrote:
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (tested many hours) of
some days ago I tried update qemu to latest development version
(from git master commit
6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there
is a regression:
xl create /etc/xen/W7.cfg Parsing config from
/etc/xen/W7.cfg libxl: error:
libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: QMP input object member 'id' is
unexpected libxl: error:
libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect to
QMP
This is caused by:
commit 65207c59d99f2260c5f1d3b9c491146616a522aa Author: Markus
Armbruster arm...@redhat.com Date: Thu Mar 5 14:35:26 2015
+0100
monitor: Drop broken, unused asynchronous command interface
The patch:
From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17
00:00:00 2001
From: Don Slutz dsl...@verizon.com Date: Thu, 4 Jun 2015
17:04:42 -0400 Subject: [PATCH 01/14] monitor: Allow Xen's
(broken) usage of asynchronous command interface.
commit 65207c59d99f2260c5f1d3b9c491146616a522aa Author: Markus
Armbruster arm...@redhat.com Date: Thu Mar 5 14:35:26 2015
+0100
monitor: Drop broken, unused asynchronous command interface
Breaks Xen. Add a hack un unbreak it.
s/un /to /
Sigh, will fix.
Xen is only doing synchronous commands, but is including an id.
QMP also uses id, but apparently removes it up front before calling
into this function; so another fix would be having xen remove it up
front.
Hopefully I will get to a change to Xen. However getting the Xen
change back-ported to enough version(s) will not be quick...
Signed-off-by: Don Slutz dsl...@verizon.com --- monitor.c | 9
+ 1 file changed, 9 insertions(+)
diff --git a/monitor.c b/monitor.c index c7baa91..e9a0747 100644
--- a/monitor.c +++ b/monitor.c @@ -4955,6 +4955,15 @@ static
QDict *qmp_check_input_obj(QObject *input_obj, Error **errp)
arguments, object); return NULL; } +} else if
(!strcmp(arg_name, id)) { +/* + * Fixup
Xen's usage. Just ignore the id. See point #5 + *
above. This was an attempt at an asynchronous + *
command interface. However commit + *
65207c59d99f2260c5f1d3b9c491146616a522aa is + *
wrong. Xen does not expect an error when it passes in +
* id:1, so just continue to ignore it. + */
The comment is a bit verbose, particularly since 'id' is a
well-established usage pattern in QMP. Also, we don't need to call
out why it changed in the comment here, the commit message is
sufficient for that.
Ok, will also see if Markus has anything to say.
-Don Slutz
} else { error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name); return
NULL;
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAEBAgAGBQJVcM85AAoJEMH0lYjxq9Kcvd0QAK5H6/2NUvqKCO/zje/8cXsT
ueLOYG4keNWJ3x7XGpOAWqIuYc673uYjApEquSpR2TRyhHwB2ZuShEjtCA5bakOH
VJJ03uLq+vrQo0Hxm8oR5/7C2w0L2GkpzGnqUlmZ6/9RNbDHGmGS6PSUC5xbwICM
6v31k0b89HG4AmAxg3/O5qeBe9m/pL+OeDjKXc6zbr7xhUIq4lxtx0VEy4HAGReS
V8+MLDJ73T6o6FUD6U/EcCmK/6GuMMG0jwZsVgbBvbeGmT1tP8Z9YMjpf3X393ZG
Il9LaUNCzhJRcWVOc4UBM8du3FLcHX4fviYyW5uEXt4aJdSoijd4BAv2znyyndmu
oep7vEc5w/VkXKuXxg1hTokCqvkLEK6WYD4M+i1huiBuNs3qQop6euqYV97tEsl3
h3fjhibkZRbIVsm6vrm41Jr75ZDnbftPMAINc9aYvvstNrxBrR7u7sw6gwAY1n6+
e5gyy5l5P6/R3LS4s41oXSOiCk7pndPp3AilOZ863MS5TJFXLfo1z0wEQ471A2hT
NHvi+o4G2iKZ33MAB9Jq6hmWveJbs8sY+Fm/IWeZn/dDt7ohn8V+rFIX3LEYfDMN
cknhMSRpKD9eRSo4LM4xU9kq1J5spaewDbkGkl7e6pHVTWphLlkk/cT2W9crW3ji
PybnLaIJP2/aljcLfdYK
=lEbh
-END PGP SIGNATURE-
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] qemu mainline regression with xen-unstable: unable to start QMP
[adding Markus, as author of the regression]
On 06/04/2015 03:59 PM, Don Slutz wrote:
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (tested many hours) of some days
ago I tried update qemu to latest development version (from git master
commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is
a regression:
xl create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: QMP input object member 'id' is unexpected
libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect
to QMP
This is caused by:
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
The patch:
From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17 00:00:00 2001
From: Don Slutz dsl...@verizon.com
Date: Thu, 4 Jun 2015 17:04:42 -0400
Subject: [PATCH 01/14] monitor: Allow Xen's (broken) usage of asynchronous
command interface.
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
Breaks Xen. Add a hack un unbreak it.
s/un /to /
Xen is only doing synchronous commands, but is including an id.
QMP also uses id, but apparently removes it up front before calling into
this function; so another fix would be having xen remove it up front.
Signed-off-by: Don Slutz dsl...@verizon.com
---
monitor.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/monitor.c b/monitor.c
index c7baa91..e9a0747 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4955,6 +4955,15 @@ static QDict *qmp_check_input_obj(QObject
*input_obj, Error **errp)
arguments, object);
return NULL;
}
+} else if (!strcmp(arg_name, id)) {
+/*
+ * Fixup Xen's usage. Just ignore the id. See point #5
+ * above. This was an attempt at an asynchronous
+ * command interface. However commit
+ * 65207c59d99f2260c5f1d3b9c491146616a522aa is
+ * wrong. Xen does not expect an error when it passes in
+ * id:1, so just continue to ignore it.
+ */
The comment is a bit verbose, particularly since 'id' is a
well-established usage pattern in QMP. Also, we don't need to call out
why it changed in the comment here, the commit message is sufficient for
that.
} else {
error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name);
return NULL;
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2 linux-next] Revert ufs: fix deadlocks introduced by sb mutex merge
On Thu, Jun 04, 2015 at 06:01:23AM +0100, Al Viro wrote: So we need * per-page exclusion for reallocation time (normal page locks are doing that) * per-fs exclusion for block and fragment allocations (-s_lock?) * per-fs exclusion for inode allocations (-s_lock?) * per-inode exclusion for mapping changes (a-la ext2 truncate_mutex) * per-directory exclusion for contents access (-i_mutex gives that) Looks like we ought to add -truncate_mutex and shove lock_ufs() calls all way down into balloc.c (and ialloc.c for inode allocations)... After looking through that code, that appears to be feasible (and would simplify the hell out of truncate side of things). However, there's a problem with the way we do -write_begin() and -writepage() there - it's quite suboptimal for short files. Suppose we start with an empty file on e.g. a filesystem with 1Kb fragments and 4Kb blocks. We grab page 0 and call -write_begin() on it, offset range 0 to 4095. OK, that'll be block_write_begin(), with ufs_getfrag_block as callback. And it'll proceed to call it 4 times, one for each kilobyte. In ascending order. If we are lucky, it'll allocate the first fragment of an otherwise empty block and then extend it 3 times until we get the full block. If we are *not* that lucky, and the first fragment is grabbed in already partially used block, we'll end up doing reallocations (and copying, while we are at it, hopefully without bogus uptodate flags set anywhere in process). The same if somebody else grabs a fragment in the middle of block we are growing into. A part of that is the lack of prealloc in fs/ufs; that would certainly improve things, but I really wonder if we are doing the handling of partial blocks in the wrong place. As it is, that happens fairly deep in call chain - ufs_write_begin() - block_write_begin() - __block_write_begin() - ufs_getfrag_block() - ufs_inode_getfrag() - ufs_new_fragments() - ufs_change_blocknr()) and we don't notice the partial blocks until we get to ufs_new_fragments(); in reality, we can tell if there's a partial block from the very beginning, just by looking at inode size and checking if the direct pointer in question is not zero. Do we really need it done that deep in chain? Note that there's another long-standing problem - we map the things fragment-by-fragment, which is seriously redundant; within the same logical block we have either * hole - no fragments present, or * partial block at the end of short file - known number of adjacent fragments present, or * full block - all fragments are present and adjacent Trying to map fragments one by one is completely pointless. Which makes the use fs/buffer.c helpers dubious. Besides, we pay for doing it that deep by having to pass the page all way down into block allocator. AFAICS, writepage cares about the partial blocks only when EOF is right inside the page - pages past EOF shouldn't be faulted in and truncate_setsize() should've killed everything off before lowering -i_size. And since truncate and -write_begin are serialized on -i_mutex, we are down to * write_iter starting past the EOF should start with dummy extending truncate (and truncate back to original size if nothing actually gets written) * extending truncate() of a file with partial block should grab the page containing EOF and expand it (with possible reallocation). * truncate() shrinking a file to something with partial block should do nothing special, other than releasing only part of fragments for that block. * write_begin and writepage should check if they are dealing with a page covering a partial block and start with extending it - they know how far to go and they are serialized by page lock. Does anybody see holes in that? This way we can handle the partial blocks higher in the call chain, with a lot less PITA... And with that done, we can have ufs_block_getfrag() just check if the previous bh in the page falls into the same block and is already mapped and map ours to the next fragment if that's the case - allocation would either happen for entire block or page, whichever is smaller, or be already done by caller (UFS blocks can be bigger than a page). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 3/4] libxl: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Mon, 2015-05-25 at 19:09 -0500, Chong Li wrote:
Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set functions to
support
per-VCPU settings for RTDS scheduler.
Add a new data structure (libxl_vcpu_sched_params) to help per-VCPU settings.
Signed-off-by: Chong Li chong...@wustl.edu
Signed-off-by: Meng Xu men...@cis.upenn.edu
Signed-off-by: Sisu Xi xis...@gmail.com
---
For v3, don't forget the summary of what changed between v2 and v3 that
Jan also asked, please. :-)
tools/libxl/libxl.c | 189
++--
tools/libxl/libxl.h | 19 +
tools/libxl/libxl_types.idl | 11 +++
3 files changed, 196 insertions(+), 23 deletions(-)
The subject says 'XL', but then you are only touching libxl. I probably
see what you meant, and in fact, the 'libxl:' prefix is correct. Just
don't mention xl at all... there could be users of libxl different than
xl, and you're enabling all of them to use per-vcpu parameters, not just
xl. :-)
+static int sched_rtds_validate_params(libxl__gc *gc, uint32_t period,
+ uint32_t budget, uint32_t *sdom_period,
+ uint32_t *sdom_budget)
+{
This is better, thanks. One thing I'm not sure about...
+if (period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT) {
+if (period 1) {
+LOG(ERROR, VCPU period is not set or out of range,
+ valid values are larger than 1);
+return ERROR_INVAL;
+}
+*sdom_period = period;
+}
+
... is whether I like it or not for this to have side effects. It's
rather easy to spot that from the prototype, I know, but probably, I'd
prefer if a function called *_validate_* would actually just do the
validation.
+if (budget != LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT) {
+if (budget 1) {
+LOG(ERROR, VCPU budget is not set or out of range,
+ valid values are larger than 1);
+return ERROR_INVAL;
It's a utility function, and you never return its return value directly,
so you can just go with 0==error, 1==ok.
+}
+*sdom_budget = budget;
+}
+
+if (budget period) {
+LOG(ERROR, VCPU budget is larger than VCPU period,
+ VCPU budget should be no larger than VCPU period);
+return ERROR_INVAL;
+}
+
+return 0;
+}
+
+static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t domid,
+ libxl_vcpu_sched_params *scinfo)
+{
+uint16_t num_vcpus;
+int rc, i;
+xc_dominfo_t info;
+
+rc = xc_domain_getinfo(CTX-xch, domid, 1, info);
+if (rc 0) {
+LOGE(ERROR, getting domain info);
+return ERROR_FAIL;
+}
+num_vcpus = info.max_vcpu_id + 1;
+
And as in the hypervisor, get and set are asymmetrical: get reads
everything, set operates on a well defined subset.
Symmetry is a value here too, IMO. So, please, make *both* _get and _set
able to deal with (sparse?) clusters of VCPU.
+struct xen_domctl_sched_rtds_params *sdom = libxl__malloc(NOGC,
+sizeof(struct xen_domctl_sched_rtds_params) * num_vcpus);
As I said already, please, don't mix variable definition and code. This
belongs above, next to all the others, perhaps initialized to NULL, if
you need it.
BTW, do we really need this? I still haven't looked at the libxc patch,
but can't we make things such as this can be done 'in place'?
+rc = xc_sched_rtds_vcpu_get(CTX-xch, domid, sdom, num_vcpus);
+if (rc != 0) {
+LOGE(ERROR, getting vcpu sched rtds);
+return ERROR_FAIL;
+}
+
+libxl_vcpu_sched_params_init(scinfo);
+
+scinfo-sched = LIBXL_SCHEDULER_RTDS;
+scinfo-num_vcpus = num_vcpus;
+scinfo-vcpus = (libxl_rtds_vcpu *)
+libxl__malloc(NOGC, sizeof(libxl_rtds_vcpu) * num_vcpus);
+for(i = 0; i num_vcpus; i++) {
+scinfo-vcpus[i].period = sdom[i].period;
+scinfo-vcpus[i].budget = sdom[i].budget;
+}
+
You're using scinfo for reporting the parameters back, so what about
sdom? It looks to me that you're using it internally and leaking it,
while (provided it's really necessary), you should free it, or let the
automatic garbage collector do so.
+return 0;
+}
+
+static int sched_rtds_vcpu_set(libxl__gc *gc, uint32_t domid,
+ const libxl_vcpu_sched_params *scinfo)
+{
+int rc;
+int i;
+uint16_t num_vcpus;
+int vcpuid;
+uint32_t budget, period;
+xc_dominfo_t info;
+
+rc = xc_domain_getinfo(CTX-xch, domid, 1, info);
+if (rc 0) {
+LOGE(ERROR, getting domain info);
+return ERROR_FAIL;
+}
+num_vcpus = info.max_vcpu_id + 1;
+
Why doing the +1 and translating this from vcpu ID to number-of, if then
all you do with the result is comparing it with IDs?
+struct
Re: [Xen-devel] [edk2] A problem about the memory size of virtual machine(VM) when using OVMF
I have the impression that this is HTML mail. Please don't post HTML mail; it falls apart when it is quoted. That said, On 06/04/15 16:07, Maoming wrote: Hi all： I started a virtual machine(VM) (redhat6.3_64bit) using OVMF in XEN4.6. And the memory of the VM is 64G. But I only got 3.5G inside the VM using free. There is a same problem in KVM too. I don't have a Xen environment to test this. CC'ing Xen devel. I checked on KVM (upstream OVMF, RHEL-7.1.z host, RHEL-6.5 guest with 5GB RAM). I cannot reproduce the issue; free in the guest reports the RAM correctly. Laszlo total used free shared buffers cached Mem: 3715640 4959163219724 0 22060 175136 -/+ buffers/cache: 2987203416920 Swap: 4046840 04046840 in the host using xl list to check: NameID Mem VCPUs State Time(s) Domain-0 0 305516 r- 861.2 redhat 4 65536 2 r- 5.9 Any thought on this? Any help will be appreciated. If you need some other information, please let me know. :) Thanks! -mao -- ___ edk2-devel mailing list edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works
Hi all, Apologies for dropping the ball on this. I've created a doodle poll with an initial set of options at http://doodle.com/596a39y9t9dhah65. The timezone is currently set to London (BST) but can be changed on the link to your local timezone. If there are others who would like to attend this walkthrough where either the suggested meeting times don't match their timezone or can't make any of the suggested dates, let us know. Thanks! Bob -Original Message- From: Bob Ball Sent: 25 March 2015 10:10 To: Ian Campbell; Lars Kurth Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen- devel; Jim Fehlig; Anthony Perard; wg-test-framew...@lists.xenproject.org Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works Unfortunately I'm also on vacation on the 8th - so I don't think that slot won't work very well this time round! Bob From: Ian Campbell [ian.campb...@citrix.com] Sent: 25 March 2015 10:08 To: Lars Kurth Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen- devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test- framew...@lists.xenproject.org Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works FWIW there's the regular technical call slot on the 8th, but a) that's earlier and Easter vac and b) I'm on PTO myself at the time, but if you are interested we could use that (the whole point was to take some of the burden off arranging ad-hoc calls). Ian. On Tue, 2015-03-24 at 18:17 +, Lars Kurth wrote: I propose to set this up for the week of April 14th or the week after. A lot of people are on Easter vacation/holiday before Lars On 18 Mar 2015, at 14:37, Wei Liu wei.l...@citrix.com wrote: On Wed, Mar 18, 2015 at 01:12:50PM +, Lars Kurth wrote: Hi, I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets. I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone. I would be interested in such meeting. My time zone is the same as George's and Anthony's. Wei. Best Regards Lars Begin forwarded message: From: Bob Ball bob.b...@citrix.com To: xen-devel@lists.xen.org xen-devel@lists.xen.org Date: 10 March 2015 12:03:13 GMT Cc: Anthony Perard anthony.per...@citrix.com Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs. We're now in a position where we can share the current status, overview of how it works and next steps. We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration. The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests. Namely this setup is using: - Puppet to deploy the master node - Zuul to watch for code changes uploaded to review.openstack.org - Jenkins job builder to create Jenkins job definitions from a YAML file - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud - Devstack-gate to run Tempest tests in serial More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/ In the background Nodepool provisions virtual machines into a pool of nodes ready to be used. All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available. Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest- xen/da3ff30/index.html I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more! Thanks, Bob ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list
Re: [Xen-devel] [Draft D] Xen on ARM vITS Handling
Hi Ian,
On 04/06/15 14:54, Ian Campbell wrote:
### Device Identifiers
Each device using the ITS is associated with a unique Device
Identifier.
The device IDs are properties of the implementaiton and are typically
implementation
described via system firmware, e.g. the ACPI IORT table or via device
tree.
The number of device ids in a system depends on the implementation and
can be discovered via `GITS_TYPER.Devbits`. This field allows an ITS
to have up to 2^32 devices.
[..]
# Scope
The ITS is rather complicated, especially when combined with
virtualisation. To simplify things we initially omit the following
functionality:
- Interrupt - vCPU - pCPU affinity. The management of physical vs
virtual Collections is a feature of GICv4, thus is omitted in this
design for GICv3. Physical interrupts which occur on a pCPU where
the target vCPU is not already resident will be forwarded (via IPI)
to the correct pCPU for injection via the existing
`vgic_vcpu_inject_irq` mechanism (extended to handle LPI injection
correctly).
- Clearing of the pending state of an LPI under various circumstances
(`MOVI`, `DISCARD`, `CLEAR` commands) is not done. This will result
in guests seeing some perhaps spurious interrupts.
- vITS functionality will only be available on 64-bit ARM hosts,
avoiding the need to worry about fast access to guest owned data
structures (64-bit uses a direct map). (NB: 32-bit guests on 64-bit
hosts can be considered to have access)
XXX Can we assume that `GITS_TYPER.Devbits` will be sane,
i.e. requiring support for the full 2^32 device ids would require a
32GB device table even for native, which is improbable except on
systems with RAM measured in TB. So we can probably assume that
Devbits will be appropriate to the size of the system. _Note_: We
require per guest device tables, so size of the native Device Table is
not the only factor here.
As we control the vBDF we can control the vDevID. If we have a single
PCI bus, the number won't be too high.
XXX Likewise can we assume that `GITS_TYPER.IDbits` will be sane?
The GITS_TYPER.IDbits of who? The physical ITS?
i.e. that the required ITT table size will be reasonable?
# Unresolved Issues
Various parts are marked with XXX. Most are minor, but there s one
more or less major one, which we may or may not be able to live with
for a first implementation:
1. When handling Virtual LPI Configuration Table writes we do not have
a Device ID, so we cannot consult the virtual Device Table, ITT etc
to determine if the LPI is actually mapped. This means that the
physical LPI enable/disable is decoupled from the validity of the
virtual ITT. Possibly resulting in spurious LPIs which must be
ignored.
This issue is discussed further in the relevant places in the text,
marked with `XXX UI1`.
# pITS
## Assumptions
It is assumed that `GITS_TYPER.IDbits` is large enough that there are
sufficient LPIs available to cover the sum of the number of possible
events generated by each device in the system (that is the sum of the
actual events for each bit of hardware, rather than the notional
per-device maximum from `GITS_TYPER.Idbits`).
This assumption avoids the need to do memory allocations and interrupt
routing at run time, e.g. during command processing by allowing us to
setup everything up front.
## Driver
The physical driver will provide functions for enabling, disabling
routing etc a specified interrupt, via the usual Xen APIs for doing
such things.
This will likely involve interacting with the physical ITS command
queue etc. In this document such interactions are considered internal
to the driver (i.e. we care that the API to enable an interrupt
exists, not how it is implemented).
## Device Table
The `pITS` device table will be allocated and given to the pITS at
start of day.
We don't really care about this. This is part of the memory provision at
initialization based on GITS_BASER*
Furthermore, the ITS may already have in the table in-memory and
therefore this allocation is not neccesary.
## Collections
The `pITS` will be configured at start of day with 1 Collection mapped
to each physical processor, using the `MAPC` command on the physical
ITS.
## Per Device Information
Each physical device in the system which can be used together with an
ITS (whether using passthrough or not) will have associated with it a
data structure:
struct its_device {
uintNN_t phys_device_id;
uintNN_t virt_device_id;
unsigned int *events;
unsigned int nr_events;
struct page_info *pitt;
unsigned int nr_pitt_pages
You need to have a pointer to the pITS associated.
};
Where:
- `phys_device_id`: The physical device ID of the physical device
- `virt_device_id`: The virtual device ID if the device is accessible
to a domain
- `events`: An array mapping a per-device
[Xen-devel] [linux-next test] 57861: regressions - FAIL
flight 57861 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/57861/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57740 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 11 guest-start fail like 57740 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 57740 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 57740 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 57740 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57740 test-armhf-armhf-libvirt 11 guest-start fail like 57740 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 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-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: linux0dfc0e41172cd9f50f5f6f0182081fa03c44e0e9 baseline version: linuxc65b99f046843d2455aa231747b5a07a999a9f3d 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm fail test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm fail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64
Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments
On 06/04/2015 12:55 PM, Rusty Russell wrote: Yeah, hard cases make bad law. I'm not too unhappy with this fix; ideally we'd rename save_fl and restore_fl to save_eflags_if and restore_eflags_if too. I would be fine with this... but please document what the bloody semantics of pvops is actually supposed to be. -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 7/9] tools: Add vmware_port support
On Wed, 2015-06-03 at 18:06 +0100, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: This new libxl_domain_create_info field is used to set XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK in the xc_domain_configuration_t for x86. In xen it is is_vmware_port_enabled. If is_vmware_port_enabled then enable a limited support of VMware's hyper-call. VMware's hyper-call is also known as VMware Backdoor I/O Port. if vmware_port is not specified in the config file, let vmware_hwver != 0 be the default value. This means that only vmware_hwver = 7 needs to be specified to enable both features. vmware_hwver = 7 is special because that is what controls the enable of CPUID leaves for VMware (vmware_hwver = 7). Note: vmware_port and nestedhvm cannot be specified at the same time. Signed-off-by: Don Slutz dsl...@verizon.com Ian: So I *think* it may be the case that this patch only depends on patch 5 to apply. I also think that patches 5 and 7 together add another useful chunk of functionality (core vmport functionality for guest OSes). Is there any point in this chunk without 1..3? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On Thu, 2015-06-04 at 16:28 +0100, Wei Liu wrote: An alternative we came up with during our IRL discussion. 1. QEMU writes the size of additional memory in xenstore. Above is orthogonal to below I think. You existing patch could be reimplemented in terms of the below, while the above is potentially a separate piece of work. 2. Libxl record that in toolstack save path. 3. Remote end calls xc_domain_setmaxmem in toolstack restore path. Wei. Wei. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 3/9] tools: Add vmware_hwver support
On 06/04/15 11:17, Ian Campbell wrote:
On Fri, 2015-05-22 at 11:50 -0400, Don Slutz wrote:
[...]
+=item Bvmware_hwver=NUMBER
+
+Turns on or off the exposure of VMware cpuid. The number is
+VMware's hardware version number, where 0 is off. A number = 7
+is needed to enable exposure of VMware cpuid.
+
+The hardware version number (vmware_hwver) come from VMware config files.
comes
Will fix.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 38d065f..4362d5d 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -64,7 +64,7 @@ int xc_domain_create(xc_interface *xch,
memset(config, 0, sizeof(config));
#if defined (__i386) || defined(__x86_64__)
-/* No arch-specific configuration for now */
+/* No arch-specific default configuration for now */
I'm not sure this hunk has anything to do with this patch, nor what the
semantic difference between the old and new text is supposed to be.
I do not have to make this change. However I feel the comment is
misleading, and I changed it. The real change is later:
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 651b338..fd7dafa 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -5,8 +5,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
libxl_domain_config *d_config,
xc_domain_configuration_t *xc_config)
{
-/* Note: will be changed in a later patch */
-xc_config-vmware_hwver = 0;
+xc_config-vmware_hwver = d_config-c_info.vmware_hwver;
return 0;
}
which is where arch-specific configuration is done. This is where the
default arch-specific configuration is done.
-Don Slutz
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
On 06/04/15 10:14, George Dunlap wrote: On 06/04/2015 01:37 PM, Don Slutz wrote: On 06/03/15 12:58, George Dunlap wrote: On 06/03/2015 05:41 PM, Don Slutz wrote: On 06/03/15 12:23, George Dunlap wrote: On 06/03/2015 04:58 PM, Andrew Cooper wrote: On 03/06/15 16:26, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: Summary is that VMware treats in (%dx),%eax (or out %eax,(%dx)) to port 0x5658 specially. Note: since many operations return data in EAX, in (%dx),%eax is the one to use. The other lengths like in (%dx),%al will still do things, only AL part of EAX will be changed. For out %eax,(%dx) of all lengths, EAX will remain unchanged. (As an aside, I think my description does a better job of alerting a reviewer to what's going on in this patch -- you might consider stealing part of it if you end up re-submitting this one.) I would be happy to steal the description part. I normally give credit to the author in the what has changed. I could also add to the commit message: George Dunlap summarized this change as: VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which always return an error. I would take the (we hope) out, since that's really part of the second half (me doubting whether such a patch is wise). Not a good idea to doubt whether a patch is a good idea in the commit message. :-) If you feel like credit is necessary, I'd just put at the bottom somewhere in parentheses something like this: (h/t to George Dunlap for the patch summary.) Ok. Thanks, -Don Slutz -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] net/xen-netfront: Correct printf format in xennet_get_responses
On Thu, 2015-06-04 at 13:52 +0100, Julien Grall wrote:
On 04/06/15 13:46, David Vrabel wrote:
On 04/06/15 13:45, Julien Grall wrote:
On 03/06/15 18:06, Joe Perches wrote:
On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
rx-status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
[]
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
[]
@@ -733,7 +733,7 @@ static int xennet_get_responses(struct
netfront_queue *queue,
if (unlikely(rx-status 0 ||
rx-offset + rx-status PAGE_SIZE)) {
if (net_ratelimit())
-dev_warn(dev, rx-offset: %x, size:
%u\n,
+dev_warn(dev, rx-offset: %x, size:
%d\n,
If you're going to do this, perhaps it'd be sensible to
also change the %x to %#x or 0x%x so that people don't
mistake offset without an [a-f] for decimal.
Good idea. I will resend a version of this series.
David, can I keep you Reviewed-by for this change?#
Can you make the offset %d instead?
If you do, please change similar uses in
drivers/net/xen-netback/ in the same patch.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: arm: Do not expose PMU to domain 0
It uses a PPI which we cannot route to a guest, and will surely need more support than just that anyway. I noticed this on Mustang with UEFI where the built in DTB contains a node of this type. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/domain_build.c |1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 1e545fe..8e87315 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1105,6 +1105,7 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo, DT_MATCH_COMPATIBLE(multiboot,module), DT_MATCH_COMPATIBLE(arm,psci), DT_MATCH_COMPATIBLE(arm,psci-0.2), +DT_MATCH_COMPATIBLE(arm,armv8-pmuv3), DT_MATCH_PATH(/cpus), DT_MATCH_TYPE(memory), /* The memory mapped timer is not supported by Xen. */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 57859: regressions - FAIL
flight 57859 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/57859/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 53854 test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 53854 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 11 guest-start fail like 53854 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass version targeted for testing: libvirt e9507fd41c9c6b73093cc0a4ce568bf0d8204854 baseline version: libvirt fd74e231751334b64af0934b680c5cc62f652453 People who touched revisions under test: Andrea Bolognani abolo...@redhat.com Boris Fiuczynski fiu...@linux.vnet.ibm.com Cole Robinson crobi...@redhat.com Daniel Hansel daniel.han...@linux.vnet.ibm.com Daniel P. Berrange berra...@redhat.com Daniel Veillard veill...@redhat.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Jim Fehlig jfeh...@suse.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Kothapally Madhu Pavan k...@linux.vnet.ibm.com Laine Stump la...@laine.org Lubomir Rintel lkund...@v3.sk Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@parallels.com Michal Privoznik mpriv...@redhat.com Nikolay Shirokovskiy nshirokovs...@parallels.com Pavel Fedin p.fe...@samsung.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Richard W.M. Jones rjo...@redhat.com Roman Bogorodskiy bogorods...@gmail.com Tony Krowiak aekro...@us.ibm.com Tony Krowiak akrow...@linux.vnet.ibm.com Viktor Mihajlovski mihaj...@linux.vnet.ibm.com Wang Yufei james.wangyu...@huawei.com Zhang Bo oscar.zhan...@huawei.com 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-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail 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 Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2745 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: arm: add missing newline to error message.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 376c9f2..2dd43ee 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -417,7 +417,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
/* Only routing to virtual SPIs is supported */
if ( virq NR_LOCAL_IRQS )
{
-printk(XENLOG_G_ERR IRQ can only be routed to an SPI);
+printk(XENLOG_G_ERR IRQ can only be routed to an SPI\n);
return -EINVAL;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/2] net/xen: Clean up
Hi, Those 2 patches was originally part of the Xen 64KB series [1]. They are already acked/reviewed and can go in Linux via the net tree now without waiting the rest of the series. Sincerely yours, Cc: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: David Vrabel david.vra...@citrix.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: net...@vger.kernel.org [1] http://lkml.org/lkml/2015/5/14/533 Julien Grall (2): net/xen-netfront: Correct printf format in xennet_get_responses net/xen-netback: Remove unused code in xenvif_rx_action drivers/net/xen-netback/netback.c | 5 - drivers/net/xen-netfront.c| 2 +- 2 files changed, 1 insertion(+), 6 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm: add missing newline to error message.
Hi Ian,
On 04/06/15 16:31, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 376c9f2..2dd43ee 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -417,7 +417,7 @@ int route_irq_to_guest(struct domain *d, unsigned int
virq,
/* Only routing to virtual SPIs is supported */
if ( virq NR_LOCAL_IRQS )
{
-printk(XENLOG_G_ERR IRQ can only be routed to an SPI);
+printk(XENLOG_G_ERR IRQ can only be routed to an SPI\n);
return -EINVAL;
}
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 7/9] tools: Add vmware_port support
On 06/04/15 11:49, Ian Campbell wrote: On Wed, 2015-06-03 at 18:06 +0100, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: This new libxl_domain_create_info field is used to set XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK in the xc_domain_configuration_t for x86. In xen it is is_vmware_port_enabled. If is_vmware_port_enabled then enable a limited support of VMware's hyper-call. VMware's hyper-call is also known as VMware Backdoor I/O Port. if vmware_port is not specified in the config file, let vmware_hwver != 0 be the default value. This means that only vmware_hwver = 7 needs to be specified to enable both features. vmware_hwver = 7 is special because that is what controls the enable of CPUID leaves for VMware (vmware_hwver = 7). Note: vmware_port and nestedhvm cannot be specified at the same time. Signed-off-by: Don Slutz dsl...@verizon.com Ian: So I *think* it may be the case that this patch only depends on patch 5 to apply. I also think that patches 5 and 7 together add another useful chunk of functionality (core vmport functionality for guest OSes). Is there any point in this chunk without 1..3? There may be. However changes would need to be done if 2 and 3 are not present. Patch #1 is independent. Pacth 2,3 provide CPUID support, which is not always needed. Just 5,7 and 8 may work to provide X windows usage of vmware mouse. I have not tested with just this set. This is because most Xservers run with IOPL set to 3 and so do not need patch #6. My memory also says that CPUID support is not needed (which is what you get for vmware_hwver=3). -Don Slutz ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 57857: regressions - FAIL
flight 57857 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/57857/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass version targeted for testing: ovmf baae777b8e6370ab856ec9088864ab698f5e9b0f baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Ma, Maurice maurice...@intel.com Mudusuru, Giri P giri.p.mudus...@intel.com Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com David Wei david@intel.com David Wei david@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Heyi Guo heyi@linaro.org Jaben Carsey jaben.car...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Jordan Justen jordan.l.jus...@intel.com Laszlo Ersek ler...@redhat.com Liming Gao liming@intel.com Ludovic Rousseau ludovic.rouss...@gmail.com Ma, Maurice maurice...@intel.com Maurice Ma maurice...@intel.com Mudusuru, Giri P giri.p.mudus...@intel.com Olivier Martin olivier.mar...@arm.com Ruiyu Ni ruiyu...@intel.com Shifei Lu shifeix.a...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com Yingke Liu yingke.d@intel.com 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-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 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.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 Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1400 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] toggles user/supervisor privilege level on page entry
Hi
I want to toggle user/sypervisor priviledge bit in page table entry
associated to a given
this page. But I my code does'nt work. I have plenty buggs.
here is the method used to set access to hypervisor level
void remove_access(l1_pgentry_t *pl1e){
l1_pgentry_t ol1e;
l1_pgentry_t nl1e;
unsigned int nmfn;
if(__copy_from_user(ol1e, pl1e, sizeof(ol1e)) == 0){
nl1e = ol1e;
nmfn = l1e_get_pfn(ol1e);
if(!(l1e_get_flags(ol1e)_PAGE_GUEST_KERNEL))
{
l1e_remove_flags(nl1e, _PAGE_USER);
if(__copy_to_guest(pl1e, nl1e,
sizeof(nl1e)) != 0)
printk(entry cannot be copied\n);
flush_tlb_all();
}
}else
printk(copy from user failed\n);
}
I hope that somebody can help me to resolve the issue.
Thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] xen: grant_table: implement grant_table_soft_reset()
At 16:22 +0100 on 04 Jun (1433434934), David Vrabel wrote: On 04/06/15 15:11, Tim Deegan wrote: There has been talk before of an operation along the lines of revoke this grant entry and wait for all users to release it but that would only help with backends that are guaranteed to release grants in a reasonable time. Are you talking about my idea? This would be immediate because the grant mapper would provide a local page to atomically switch the foreign mapping to when the grant is revoked. That's a stronger operation than I remembered, and similar to what's happening here. If this reset operation is to be called from the guest, then all the guest can do is reshuffle its own memory -- it can't expect to have enough spare memory to cover all outstanding granted pages. But TBH this is a bit of a red herring; I ought not to have mentioned it. :) Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 3/9] tools: Add vmware_hwver support
On 06/04/15 11:15, Ian Campbell wrote: On Wed, 2015-06-03 at 15:53 +0100, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: This is used to set xen_arch_domainconfig vmware_hw. It is set to the emulated VMware virtual hardware version. Currently 0, 3-4, 6-11 are good values. However the code only checks for == 0, != 0, or 7. Signed-off-by: Don Slutz dsl...@verizon.com Ian, It looks like you gave a pre-approved Ack to something almost identical to v10. In v9 I indicated that LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE and LIBXL_HAVE_BUILDINFO_HVM_VMWARE_HWVER could be covered by a single ack (introducing vmware support generally). In v11 this seems to have morphed into only LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE being provided, which is clearly not an appropriate umbrella #define. Only in PATCH 1/9 -- Which in v11 is now completely independent. I only kept it in the series since in v10 it was not fully independent. I'm also not sure if there is more stuff later in the series, if so then unless it is all committed together an umbrella option may not work, unless it is added right at the end, in which case I suppose having some unadvertised functionality in the midst of a dev cycle would be ok. Releasing like that would be a mistake though. There is one later in the series 7/9. to which you said (in a different thread): +#define LIBXL_HAVE_CREATEINFO_VMWARE 1 Lets just have a single one of these indicating support for vmware, it should be added at the end of the series after all the baseline vmware functionality is in place. I think that means hwver, vga=vmware and this port stuff. (Future incremental changes will of course require their own flags). If I am reading this correctly, you want PATCH 1/9 to not be completely independent. -Don Slutz Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset
At 16:19 +0100 on 04 Jun (1433434780), David Vrabel wrote: On 04/06/15 15:05, Tim Deegan wrote: At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote: We need to close all event channel so the domain performing soft reset will be able to open them back. Interdomain channels are, however, special. We need to keep track of who opened it as in (the most common) case it was opened by the control domain we won't be able (and allowed) to re-establish it. I'm not sure I understand -- can you give an example of what this is avoiding? I would have thought that the kexec'ing VM needs to tear down _all_ its connections and then restart the ones it wantrs in the new OS. There are some that are in state ECS_UNBOUND (console, xenstore, I think) at start of day that are allocated on behalf of the domain by the toolstack. The kexec'd image will expect them in these same state. I see. But does that not come under tear down all its connections and then restart the ones it wants? I.e. should the guest not reset all its channels and then allocate fresh console xenstore ones? Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset
At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote:
We need to close all event channel so the domain performing soft reset
will be able to open them back. Interdomain channels are, however,
special. We need to keep track of who opened it as in (the most common)
case it was opened by the control domain we won't be able (and allowed) to
re-establish it.
I'm not sure I understand -- can you give an example of what this is
avoiding? I would have thought that the kexec'ing VM needs to tear
down _all_ its connections and then restart the ones it wantrs in the
new OS.
Cheers,
Tim.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
xen/common/event_channel.c | 52
+++---
xen/include/xen/event.h| 3 +++
xen/include/xen/sched.h| 1 +
3 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index fae242d..3204c74 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -274,11 +274,13 @@ static long
evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
lchn-u.interdomain.remote_dom = rd;
lchn-u.interdomain.remote_port = rport;
+lchn-u.interdomain.opened_by = current-domain;
lchn-state = ECS_INTERDOMAIN;
evtchn_port_init(ld, lchn);
rchn-u.interdomain.remote_dom = ld;
rchn-u.interdomain.remote_port = lport;
+rchn-u.interdomain.opened_by = current-domain;
rchn-state = ECS_INTERDOMAIN;
/*
@@ -933,26 +935,30 @@ int evtchn_unmask(unsigned int port)
}
-static long evtchn_reset(evtchn_reset_t *r)
+void evtchn_reset(struct domain *d, bool_t soft_reset)
{
-domid_t dom = r-dom;
-struct domain *d;
-int i, rc;
-
-d = rcu_lock_domain_by_any_id(dom);
-if ( d == NULL )
-return -ESRCH;
-
-rc = xsm_evtchn_reset(XSM_TARGET, current-domain, d);
-if ( rc )
-goto out;
+int i;
+struct evtchn *chn;
+/*
+ * ECS_INTERDOMAIN channels with port number suitable for the 2-level ABI
+ * opened by other domains should remain opened as the domain doing soft
+ * reset won't be able to reopen them.
+ * __evtchn_close() also leaves consumer_is_xen() channels open.
+ */
for ( i = 0; port_is_valid(d, i); i++ )
+{
+chn = evtchn_from_port(d, i);
+if ( !soft_reset ||
+ i = (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d)) ||
+ chn-state != ECS_INTERDOMAIN ||
+ chn-u.interdomain.opened_by == d )
(void)__evtchn_close(d, i);
+}
spin_lock(d-event_lock);
-if ( (dom == DOMID_SELF) d-evtchn_fifo )
+if ( (d == current-domain) d-evtchn_fifo )
{
/*
* Guest domain called EVTCHNOP_reset with DOMID_SELF, destroying
@@ -964,13 +970,6 @@ static long evtchn_reset(evtchn_reset_t *r)
}
spin_unlock(d-event_lock);
-
-rc = 0;
-
-out:
-rcu_unlock_domain(d);
-
-return rc;
}
static long evtchn_set_priority(const struct evtchn_set_priority
*set_priority)
@@ -1097,9 +1096,20 @@ long do_event_channel_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
case EVTCHNOP_reset: {
struct evtchn_reset reset;
+struct domain *d;
+
if ( copy_from_guest(reset, arg, 1) != 0 )
return -EFAULT;
-rc = evtchn_reset(reset);
+
+d = rcu_lock_domain_by_any_id(reset.dom);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_evtchn_reset(XSM_TARGET, current-domain, d);
+if ( !rc )
+evtchn_reset(d, 0);
+
+rcu_unlock_domain(d);
break;
}
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 690f865..d0479a6 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -130,6 +130,9 @@ void evtchn_check_pollers(struct domain *d, unsigned int
port);
void evtchn_2l_init(struct domain *d);
+/* Close all event channels and reset to 2-level ABI */
+void evtchn_reset(struct domain *d, bool_t soft_reset);
+
/*
* Low-level event channel port ops.
*/
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 80c6f62..13b6b86 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -98,6 +98,7 @@ struct evtchn
struct {
evtchn_port_t remote_port;
struct domain *remote_dom;
+struct domain *opened_by;
} interdomain; /* state == ECS_INTERDOMAIN */
struct {
u32irq;
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 0/4] 'reset everything' approach to PVHVM guest kexec
Hi, At 15:35 +0200 on 03 Jun (1433345718), Vitaly Kuznetsov wrote: last week you expressed some concerns about if the toolstack-based approach to PVHVM guest kexec is the best. Here you can see the 'reset everything' approach to the same problem. It is the bare minimum of what should be done to make it possible for the new kernel to boot. Thansk for prototyping this - it's very helpful. Despite the fact that this implementation is much smaller in size and that it doesn't require any toolstack changes I'm personally in favor of the previous toolstack-based approach as it looks more general, less fragile and easier to support to me. Please let me know your thoughts. On the contrary, this looks neater, faster and with fewer special cases (at least in the hypervisor) than the p2m-copying code. I prefer it. (I do appreciate that there may be more things needed to get to a fully working system). Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] qemu mainline regression with xen-unstable: unable to start QMP
Today after trying xen-unstable build (tested many hours) of some days ago I tried update qemu to latest development version (from git master commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is a regression: xl create /etc/xen/W7.cfg Parsing config from /etc/xen/W7.cfg libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: QMP input object member 'id' is unexpected libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect to QMP DomU is working but operations that require QMP not (for example save/restore). Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] xen: grant_table: implement grant_table_soft_reset()
On 04/06/15 15:11, Tim Deegan wrote: There has been talk before of an operation along the lines of revoke this grant entry and wait for all users to release it but that would only help with backends that are guaranteed to release grants in a reasonable time. Are you talking about my idea? This would be immediate because the grant mapper would provide a local page to atomically switch the foreign mapping to when the grant is revoked. But, this isn't something that would be generally applicable to all grants. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset
On 04/06/15 15:05, Tim Deegan wrote: At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote: We need to close all event channel so the domain performing soft reset will be able to open them back. Interdomain channels are, however, special. We need to keep track of who opened it as in (the most common) case it was opened by the control domain we won't be able (and allowed) to re-establish it. I'm not sure I understand -- can you give an example of what this is avoiding? I would have thought that the kexec'ing VM needs to tear down _all_ its connections and then restart the ones it wantrs in the new OS. There are some that are in state ECS_UNBOUND (console, xenstore, I think) at start of day that are allocated on behalf of the domain by the toolstack. The kexec'd image will expect them in these same state. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 3/9] tools: Add vmware_hwver support
On Fri, 2015-05-22 at 11:50 -0400, Don Slutz wrote: [...] +=item Bvmware_hwver=NUMBER + +Turns on or off the exposure of VMware cpuid. The number is +VMware's hardware version number, where 0 is off. A number = 7 +is needed to enable exposure of VMware cpuid. + +The hardware version number (vmware_hwver) come from VMware config files. comes diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index 38d065f..4362d5d 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -64,7 +64,7 @@ int xc_domain_create(xc_interface *xch, memset(config, 0, sizeof(config)); #if defined (__i386) || defined(__x86_64__) -/* No arch-specific configuration for now */ +/* No arch-specific default configuration for now */ I'm not sure this hunk has anything to do with this patch, nor what the semantic difference between the old and new text is supposed to be. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On Tue, Jun 02, 2015 at 06:40:56PM +0100, Wei Liu wrote: On Tue, Jun 02, 2015 at 05:11:02PM +0100, Andrew Cooper wrote: On 02/06/15 16:49, Ian Campbell wrote: On Tue, 2015-06-02 at 15:08 +0100, Wei Liu wrote: [...] So here is a proof of concept patch to record and honour that value during migration. A new field is added in IDL. Note that we don't provide xl level config option for it and mandate it to be default value during domain creation. This is to prevent libxl user from using it to avoid unforeseen repercussions. [...] This field is mandated to be default value during guest creation to avoid unforeseen repercussions. It's only honour when restoring a guest. IMHO this means that the libxl API/IDL is the wrong place for this value. Only user and/or application serviceable parts belong in the API. So while I agree that this value need to be communicated across a migration, the JSON blob is not the right mechanism for doing so. IOW if you go down this general path I think you need a new field/record/whatever in the migration protocol at some layer or other (if not libxc then at the libxl layer). To my mind this actual state vs user configured state is more akin to the sorts of things which is in the hypervisor save blob or something like that (nb: This is not a suggestion that it should go there). IIRC Don also outlined another case, which is xl create -p xl migrate xl unpause Which might need more thought if any bumping can happen after the migrate i.e. on unpause? The problem is qemu using set_max_mem. It should never have done so. Nothing other than libxl should be using such hypercalls, at which point libxls idea of guest memory is accurate and the bug ceases to exist. That would be an ideal solution, but it's not going to materialise any time soon because: 1. Libxl cannot know how much more memory guest needs prior to QEMU start-up. 2. QEMU cannot communicate back the value to libxl because 2.1 there is no communication channel; 2.2 there is no libxld to update the config (maybe we can work around this by waiting for QEMU during guest creation). While we work towards that end, a short term solution might be: 1. Make QEMU not call xc_domain_setmaxmem. 2. Provide a field in IDL and a config option in xl to indicate how much more memory is needed. User can fill in that option as he / she sees fit. After we get to the ideal solution we can then deprecate that field / option. An alternative we came up with during our IRL discussion. 1. QEMU writes the size of additional memory in xenstore. 2. Libxl record that in toolstack save path. 3. Remote end calls xc_domain_setmaxmem in toolstack restore path. Wei. Wei. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V9] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
At 16:19 +0200 on 03 Jun (1433348379), Lengyel, Tamas wrote:
On Wed, Jun 3, 2015 at 3:48 PM, Razvan Cojocaru rcojoc...@bitdefender.com
wrote:
On 06/03/2015 04:29 PM, Lengyel, Tamas wrote:
struct {
-uint16_t mov_to_cr0_enabled : 1;
-uint16_t mov_to_cr0_sync : 1;
-uint16_t mov_to_cr0_onchangeonly : 1;
-uint16_t mov_to_cr3_enabled : 1;
-uint16_t mov_to_cr3_sync : 1;
-uint16_t mov_to_cr3_onchangeonly : 1;
-uint16_t mov_to_cr4_enabled : 1;
-uint16_t mov_to_cr4_sync : 1;
-uint16_t mov_to_cr4_onchangeonly : 1;
+uint16_t write_ctrlreg_enabled : 4;
+uint16_t write_ctrlreg_sync : 4;
+uint16_t write_ctrlreg_onchangeonly : 4;
Just looking at this here again, we will now have a bitmap within a
bitmap, which doesn't seem to be very efficient. IMHO it would be better
to just take the ctrlreg bitmap out as a separate uint8_t within struct
{} monitor.
How is it inefficient? I don't see that at all. And I'm not sure what
you mean about the uint8_t: there are 3 fields there, each 4-bits wide
(write_ctrlreg_enabled, write_ctrlreg_sync, write_ctrlreg_onchangeonly)
and only (at most) two of them would fit into a uint8_t. To put them all
into a new struct would mean wasting an uint16_t for 12-bits.
Right now if you want to access a bit using the index on the ctrlreg
fields, you would for example do (monitor.write_ctrlreg_enabled index).
This is actually going to perform two bitmask operations. First,
monitor.write_ctrlreg_enabled
does a masking operating to get you only the 4 bits corresponding to this
field, then you do another mask with the index.
The compiler can optimize away the first mask operation. E.g., gcc
folds that into a single operation at anything above -O0.
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 4/4] xen: arch-specific hooks for domain_soft_reset()
At 15:35 +0200 on 03 Jun (1433345722), Vitaly Kuznetsov wrote: x86-specific hook cleans up the pirq-emuirq mappings and replaces the shared_info frame with an empty page to support subsequent XENMAPSPACE_shared_info call. That's a bit roundabout. I think we might be better off allocating a new shared-info page and abandoning the old one as an ordinary guest RAM page. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 7/9] tools: Add vmware_port support
On Fri, 2015-05-22 at 11:50 -0400, Don Slutz wrote: diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 86164a7..fcce7c3 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -205,6 +205,11 @@ #define LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE 1 /* + * libxl_domain_create_info has the vmware_hwver and vmware_port field. + */ +#define LIBXL_HAVE_CREATEINFO_VMWARE 1 Lets just have a single one of these indicating support for vmware, it should be added at the end of the series after all the baseline vmware functionality is in place. I think that means hwver, vga=vmware and this port stuff. (Future incremental changes will of course require their own flags). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 57854: regressions - FAIL
flight 57854 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/57854/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 57747 test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 57747 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-winxpsp3 12 guest-localmigrate fail REGR. vs. 57747 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 57676 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 57747 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 57747 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-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass version targeted for testing: xen 0f4362b43fbe2eb87b280f87c1ff89dff623bfdd baseline version: xen 09f76cb8b843ba155229e39f0788e7c5f4a72023 People who touched revisions under test: Jan Beulich jbeul...@suse.com jobs: 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Tue, 2015-06-02 at 17:28 +0100, George Dunlap wrote:
On Tue, May 26, 2015 at 1:05 AM, Chong Li lichong...@gmail.com wrote:
Add two hypercalls(XEN_DOMCTL_SCHEDOP_getvcpuinfo/putvcpuinfo) to get/set a
domain's
per-VCPU parameters. Hypercalls are handled by newly added hook
(.adjust_vcpu) in the
scheduler interface.
Add a new data structure (struct xen_domctl_scheduler_vcpu_op) for
transferring data
between tool and hypervisor.
Signed-off-by: Chong Li chong...@wustl.edu
Signed-off-by: Meng Xu men...@cis.upenn.edu
Signed-off-by: Sisu Xi xis...@gmail.com
One comment that I didn't see addressed already...
+switch ( op-cmd )
+{
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+list_for_each( iter, sdom-vcpu )
+{
+svc = list_entry(iter, struct rt_vcpu, sdom_elem);
+vcpuid = svc-vcpu-vcpu_id;
+
+local_sched.budget = svc-budget / MICROSECS(1);
+local_sched.period = svc-period / MICROSECS(1);
+if ( copy_to_guest_offset(op-u.rtds.vcpus, vcpuid,
+local_sched, 1) )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EFAULT;
+}
+hypercall_preempt_check();
+}
+spin_unlock_irqrestore(prv-lock, flags);
+break;
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+for( i = 0; i op-u.rtds.nr_vcpus; i++ )
+{
+if ( copy_from_guest_offset(local_sched,
+op-u.rtds.vcpus, i, 1) )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EFAULT;
+}
+if ( local_sched.period = 0 || local_sched.budget = 0 )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EINVAL;
+}
+svc = rt_vcpu(d-vcpu[local_sched.vcpuid]);
+svc-period = MICROSECS(local_sched.period);
+svc-budget = MICROSECS(local_sched.budget);
+hypercall_preempt_check();
+}
It looks like the interface here is assymetric. That is, on
putvcpuinfo, you assume there is an array of rtds.nr_vcpus length,
and you read vcpu_id from each one. In getvcpuinfo, you assume that
the array is the number of vcpus in the guest, and you just copy all
the vcpu data into it.
I think it would make more sense for it to work the same both ways --
so either always pass an array of all vcpus of the guest in and out;
or, have an array potentially specifying a subset of cpus in and out.
Thoughts?
It would indeed. And in fact, just FTR, I did say pretty much the same
in 1432904488.5077.30.ca...@citrix.com :-D
Regards,
Dario
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] xen: grant_table: implement grant_table_soft_reset()
At 15:35 +0200 on 03 Jun (1433345720), Vitaly Kuznetsov wrote: When soft reset is being performed we need to replace all actively granted pages with empty pages to prevent possible future memory corruption as the newly started kernel won't be aware of these granted pages. I'm not sure about this one. IMO it's the guest's responsibility to find and disable whatever holds these grants. This is by analogy with a bus-master-capable device in a real PC: until the device is found and reset, the new OS can't use memory outside its guaranteed safe pool. There has been talk before of an operation along the lines of revoke this grant entry and wait for all users to release it but that would only help with backends that are guaranteed to release grants in a reasonable time. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] save restore failed when tmem enabled in Xen 4.1 Xen 4.3
Hi all, Recently, I am testing the TMEM support on Xen. I discovered that when enabled TMEM in ubuntu 14.10 as guest on Xen 4.1 Xen 4.3, xm save xm restore“ failed after there are more than 1000 pages put in persistent pool of TMEM in Xen. My operations are list as follows: In ubuntu guest (8 cores , 8GB): sudo modprobe tmem (than wait for the selfballoon to finish) dd if=/dev/zero of=/tmp/test.img bs=10M count=1000 dd if=/tmp/test.img of=/dev/null bs=10M dd if=/tmp/test.img of=/dev/null bs=10M . (until more than 1000 pages put in persistent pool) In Domain 0: (add tmem in grub.cfg) xm save ubuntu test.save xm restore ubuntu test.save When TMEM is not enabled, save restore success after these operations. But if TMEM is enabled, save restore fail. Does anyone test about save restore when enabled TMEM in Xen?? Is there anything I do wrong? Thanks!! Best Regards, Yunfang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Bug report] Security issue in xl vcpu-set
(redirecting to xen-devel as I originally intended)
On Wed, 2015-06-03 at 13:02 +0800, lwch...@cs.hku.hk wrote:
Hi,
Wonder if there is any follow-ups from the relevant developers:
(1) are you able to reproduce the spinning behavior of xl vcpu-set?
I am with Xen 4.5, but not with xen-unstable AFAICT.
(2) if yes, can you confirm that it is due to looping with
retry_transaction?
I don't think so. You are _supposed_ to retry failed transactions in
this way, it's how they work.
The issue is that the transaction is failing repeatedly in such a
manner. This might be due to a lack of error checking within the loop,
or it could possibly be a bug in the xenstore daemon.
Ian.
Best,
Luwei
Quoting lwch...@cs.hku.hk:
Hi Ian,
Thanks for your reply. Please read my inline reply to your questions.
Quoting Ian Campbell ian.campb...@citrix.com:
Since this was copied to xen-api@ it is now public, so redirecting to
the correct list (xen-devel@). I kept xen-api since oxenstored might be
involved. I dropped Vincent since he is no longer involved in libxl
development.
On Fri, 2015-05-29 at 13:44 +0800, lwch...@cs.hku.hk wrote:
Hi,
xl vcpu-set is commonly used to hotplug/unhotplug vCPUs of an SMP VM.
However, the current implementation of this command makes the driver
domain vulnerable to denial-of-service attack: in certain cases,
this command
consumes too many CPU cycles in dom0, adversely affecting dom0's other
tasks (e.g., IO processing, monitoring, etc.)
[An illustrative example]
Say, with a Linux PV guest called vm01, when vm01 just boots or reboots
(e.g., in its grub period)
Do you mean pygrub or pvgrub here?
My VM uses pygrub: Xen-4.5.0 + Linux 3.14.35 (for both dom0 and domU).
, if dom0 issues xl vcpu-set vm01 xxx at this
moment, the following will happen:
(1) xl vcpu-set hangs, until vm01 has loaded its kernel successfully.
(2) in dom0, oxenstored consumes 100% of a single core.
It's not clear to me why this should relate to the status of the guest,
AFAIK there is no reason for a xenstore transaction to be affected by
whether or not the guest has loaded its kernel.
Certainly if it is spinning forever there is a bug somewhere, but I
don't think it relates to the use of a transaction in this way.
You may check /var/log/xenstored-access.log: when xl vcpu-set hangs,
xenstore keeps writing to /local/domain/xx/cpu/xx/availability,
indicating that it is looping in retry_transaction.
Ian.
So, if a malicious guest purposely stays in its grub period (or other
purposely designed phases, as long as it does not load its kernel),
xl vcpu-set will hang _forever_, and dom0 has to sacrifice one core.
[Affected versions]
This problem has been there since libxl was introduced in Xen 4.1 release.
[Implementation problem]
xl vcpu-set involves a loop as follows (retry_transaction):
--
static int libxl__set_vcpuonline_xenstore(...)
{
... ...
retry_transaction:
t = xs_transaction_start(CTX-xsh);
for (i = 0; i = info.vcpu_max_id; i++)
libxl__xs_write(gc, t,
libxl__sprintf(gc, %s/cpu/%u/availability, dompath, i),
%s, libxl_bitmap_test(cpumap, i) ? online :
offline);
if (!xs_transaction_end(CTX-xsh, t, 0)) {
if (errno == EAGAIN)
goto retry_transaction;
}
... ...
}
--
[Possible solution]
In principle, the correctness of xl vcpu-set should _not_ depend on any
guest's behaviors.
One possible fix might be like this: if xs_transaction_end does
not succeed,
either ignore it or retry for a pre-defined timeout period (rather
than forever).
[Suggestions]
I find that the loop method like retry_transaction is used at
several places
in libxl. You probably want to revisit the potential negative effect
it brings.
Please take a look and help confirm my reported bug. Thanks.
(Cc'd to two authors listed in libxl.c)
Luwei Cheng
Department of Computer Science
The University of Hong Kong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/6] Misc cleanups for libxl
On 06/03/2015 06:51 PM, Andrew Cooper wrote: On 03/06/15 09:01, Yang Hongyang wrote: This patchset mainly focus on libxl save, most of the patches are simply move codes out of libxl_dom.c, except a refactor patch. Please see individual patch for detail. Can get the whole patchset from: https://github.com/macrosheep/xen/tree/misc-libxl-v2 Overall, these look like good changes, although I have not reviewed them in detail. Thank you! hope it won't affect migration v2 too much. ~Andrew v1-v2: - use dsps for suspend_state and dss for save_state. - move resume code to libxl_dom_suspend.c - move toolstatck save/restore code to libxl_dom_save.c - move refactor pacth to the end so that rebase of the patchset easier. Yang Hongyang (6): tools/libxl: rename libxl__domain_suspend to libxl__domain_save tools/libxl: move domain suspend code into libxl_dom_suspend.c tools/libxl: move domain resume code into libxl_dom_suspend.c tools/libxl: move remus code into libxl_remus.c tools/libxl: move save/restore code into libxl_dom_save.c libxl/save: Refactor libxl__domain_suspend_state tools/libxl/Makefile |5 +- tools/libxl/libxl.c | 126 +--- tools/libxl/libxl_dom.c | 1202 -- tools/libxl/libxl_dom_save.c | 672 + tools/libxl/libxl_dom_suspend.c | 465 +++ tools/libxl/libxl_internal.h | 65 ++- tools/libxl/libxl_netbuffer.c|2 +- tools/libxl/libxl_remus.c| 307 ++ tools/libxl/libxl_save_callout.c |2 +- 9 files changed, 1503 insertions(+), 1343 deletions(-) create mode 100644 tools/libxl/libxl_dom_save.c create mode 100644 tools/libxl/libxl_dom_suspend.c create mode 100644 tools/libxl/libxl_remus.c . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Draft D] Xen on ARM vITS Handling
Draft D follows. Also at:
http://xenbits.xen.org/people/ianc/vits/draftD.{pdf,html}
In this iteration I took a step back and tried to simplify a lot of
things, in an attempt to get closer to something we can agree on as a
first cut that is achievable for 4.6, since I felt we were getting
bogged down in the complexity of trying to do everything at once. These
assumptions/short comings can be addressed in future iterations of the
code.
Please let me know what you think.
Perhaps it would be useful to have a short IRC meeting on #xenarm to
iron out the last details? If people could let me know their
availability and timezones I can try and set something up.
If people prefer we could use a slot in the Monthly technical call[0],
which is next week but I think IRC is probably better suited?
[0] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00460.html
Ian.
-8
% Xen on ARM vITS Handling
% Ian Campbell ian.campb...@citrix.com
% Draft D
# Changelog
## Since Draft C
* _Major_ rework, in an attempt to simplify everything into something
more likely to be achievable for 4.6.
* Made some simplifying assumptions.
* Reduced the scope of some support.
* Command emulation is now mostly trivial.
* Expanded detail on host setup, allowing other assumptions to be
made during emulation.
* Many other things lost in the noise of the above.
## Since Draft B
* Details of command translation (thanks to Julien and Vijay)
* Added background on LPI Translation and Pending tables
* Added background on Collections
* Settled on `N:N` scheme for vITS:pat's mapping.
* Rejigged section nesting a bit.
* Since we now thing translation should be cheap, settle on
translation at scheduling time.
* Lazy `INVALL` and `SYNC`
## Since Draft A
* Added discussion of when/where command translation occurs.
* Contention on scheduler lock, suggestion to use SOFTIRQ.
* Handling of domain shutdown.
* More detailed discussion of multiple vs single vits pros/cons.
# Introduction
ARM systems containing a GIC version 3 or later may contain one or
more ITS logical blocks. An ITS is used to route Message Signalled
interrupts from devices into an LPI injection on the processor.
The following summarises the ITS hardware design and serves as a set
of assumptions for the vITS software design. For full details of the
ITS see the GIC Architecture Specification.
## Locality-specific Peripheral Interrupts (`LPI`)
This is a new class of message signalled interrupts introduced in
GICv3. They occupy the interrupt ID space from `8192..(2^32)-1`.
The number of LPIs support by an ITS is exposed via
`GITS_TYPER.IDbits` (as number of bits - 1), it may be up to
2^32. _Note_: This field also contains the number of Event IDs
supported by the ITS.
### LPI Configuration Table
Each LPI has an associated configuration byte in the LPI Configuration
Table (managed via the GIC Redistributor and placed at
`GICR_PROPBASER` or `GICR_VPROPBASER`). This byte configures:
* The LPI's priority;
* Whether the LPI is enabled or disabled.
Software updates the Configuration Table directly but must then issue
an invalidate command (per-device `INV` ITS command, global `INVALL`
ITS command or write `GICR_INVLPIR`) for the affect to be guaranteed
to become visible (possibly requiring an ITS `SYNC` command to ensure
completion of the `INV` or `INVALL`). Note that it is valid for an
implementation to reread the configuration table at any time (IOW it
is _not_ guaranteed that a change to the LPI Configuration Table won't
be visible until an invalidate is issued).
### LPI Pending Table
Each LPI also has an associated bit in the LPI Pending Table (managed
by the GIC redistributor). This bit signals whether the LPI is pending
or not.
This region may contain out of date information and the mechanism to
synchronise is `IMPLEMENTATION DEFINED`.
## Interrupt Translation Service (`ITS`)
### Device Identifiers
Each device using the ITS is associated with a unique Device
Identifier.
The device IDs are properties of the implementaiton and are typically
described via system firmware, e.g. the ACPI IORT table or via device
tree.
The number of device ids in a system depends on the implementation and
can be discovered via `GITS_TYPER.Devbits`. This field allows an ITS
to have up to 2^32 devices.
### Events
Each device can generate Events (called `ID` in the spec) these
correspond to possible interrupt sources in the device (e.g. MSI
offset).
The maximum number of interrupt sources is device specific. It is
usually discovered either from firmware tables (e.g. DT or ACPI) or
from bus specific mechanisms (e.g. PCI config space).
The maximum number of events ids support by an ITS is exposed via
`GITS_TYPER.IDbits` (as number of bits - 1), it may be up to
2^32. _Note_: This field also contains the number of `LPIs` supported
by the ITS.
### Interrupt Collections
Each interrupt is a member of an Interrupt Collection. This allows
software to
Re: [Xen-devel] [PATCH 0/2] xen/mem Common cleanup
At 12:43 +0100 on 03 Jun (145401), Andrew Cooper wrote: Following c/s e758ed14 which describes the current terms used in Xens memory management, introduce some infrastructure so that new code can be written correctly. This is the start of a long potential cleanup. Acked-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
On 06/04/2015 01:37 PM, Don Slutz wrote: On 06/03/15 12:58, George Dunlap wrote: On 06/03/2015 05:41 PM, Don Slutz wrote: On 06/03/15 12:23, George Dunlap wrote: On 06/03/2015 04:58 PM, Andrew Cooper wrote: On 03/06/15 16:26, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: Summary is that VMware treats in (%dx),%eax (or out %eax,(%dx)) to port 0x5658 specially. Note: since many operations return data in EAX, in (%dx),%eax is the one to use. The other lengths like in (%dx),%al will still do things, only AL part of EAX will be changed. For out %eax,(%dx) of all lengths, EAX will remain unchanged. This instruction is allowed to be used from ring 3. To support this the vmexit for GP needs to be enabled. I have not fully tested that nested HVM is doing the right thing for this. Enable no-fault of pio in x86_emulate for VMware port Also adjust the emulation registers after doing a VMware backdoor operation. Add new routine hvm_emulate_one_gp() to be used by the #GP fault handler. Some of the best info is at: https://sites.google.com/site/chitchatvmback/backdoor Signed-off-by: Don Slutz dsl...@verizon.com So let me get this straight. VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which always return an error. Is that about right? That sounds completely insane. It opens up an almost infinite surface of attack onto the Xen emulator. I understand that having the VMWare compatible is a nice tick-box to have, but seriously, I cannot imagine that having unprivileged user-space tools know the real clock frequency without having to involve the OS is anywhere close to worth the risk involved. The attack surface sadly is not enlarged in the slightest by this change. We already trap and emulate all #UD exceptions in an attempt to support migration of VMs between Intel and AMD hardware. See XSA-105. (There is a good argument to be made for not trapping #UD, but that doesn't completely close the hole) So at the moment, an attacker on Intel can force the emulation of any AMD-only instruction (and vice versa), is that right? This would allow an attacker to force the emulation of every #GP condition of every instruction we emulate. Those two sets may be within an order of magnitude of each other, but they will only overlap a little bit. So my guess is that enabling this would double the surface of attack (give or take). I'd be a lot happier with this patch if we could make it so that on a #GP the only instruction that could get emulated would be an IO instruction. You mean like I said in: Message-ID: 54c67d83027800059...@mail.emea.novell.com Yes, pretty much exactly. I didn't notice that particular part of the discussion, but I did go back and skim the comments that people had made on previous revisions, and I certainly noticed that both Jan and Andy reviewed this patch, and that neither one objected to the general idea. So my That sounds insane was as much directed at them as at you. (As an aside, I think my description does a better job of alerting a reviewer to what's going on in this patch -- you might consider stealing part of it if you end up re-submitting this one.) I would be happy to steal the description part. I normally give credit to the author in the what has changed. I could also add to the commit message: George Dunlap summarized this change as: VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Fri, 2015-05-29 at 11:47 -0500, Chong Li wrote:
On Fri, May 29, 2015 at 8:51 AM, Dario Faggioli
dario.faggi...@citrix.com wrote:
On Mon, 2015-05-25 at 19:05 -0500, Chong Li wrote:
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 28aea55..8143c44 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
/* Set or get info? */
#define XEN_DOMCTL_SCHEDOP_putinfo 0
#define XEN_DOMCTL_SCHEDOP_getinfo 1
#define XEN_DOMCTL_SCHEDOP_putvcpuinfo 2
#define XEN_DOMCTL_SCHEDOP_getvcpuinfo 3
struct xen_domctl_scheduler_op {
uint32_t sched_id; /* XEN_SCHEDULER_* */
uint32_t cmd; /* XEN_DOMCTL_SCHEDOP_* */
union {
xen_domctl_schedparam_t d;
struct {
XEN_GUEST_HANDLE_64(xen_domctl_schedparam_vcpu_t) vcpus;
uint16_t nr_vcpus;
} v;
} u;
};
typedef struct xen_domctl_scheduler_op xen_domctl_scheduler_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_scheduler_op_t);
I'm also attaching a (build-tested only) patch to that effect (I'm
killing SEDF in there, so I don't have to care about it, as it's going
away anyway).
Thoughts?
I see. So now we put per-dom params and per-vcpu params into the same
structure (xen_domctl_scheduler_op). This structure will be handled in
sched_adjust and there should be a switch in that function to
distinguish per-dom get/set and per-vcpu get/set. Right?
You're describing correctly what I had in mind and tried to do in the
draft patch, yes. Whether to do it or not, well, it's a proposal. George
says he also thinks the thing makes sense to him too, so I guess you can
go ahead and try doing so in v3.
Of course, others, feel free to chime in.
Regards,
Dario
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 3/9] tools: Add vmware_hwver support
On Wed, 2015-06-03 at 15:53 +0100, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: This is used to set xen_arch_domainconfig vmware_hw. It is set to the emulated VMware virtual hardware version. Currently 0, 3-4, 6-11 are good values. However the code only checks for == 0, != 0, or 7. Signed-off-by: Don Slutz dsl...@verizon.com Ian, It looks like you gave a pre-approved Ack to something almost identical to v10. In v9 I indicated that LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE and LIBXL_HAVE_BUILDINFO_HVM_VMWARE_HWVER could be covered by a single ack (introducing vmware support generally). In v11 this seems to have morphed into only LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE being provided, which is clearly not an appropriate umbrella #define. I'm also not sure if there is more stuff later in the series, if so then unless it is all committed together an umbrella option may not work, unless it is added right at the end, in which case I suppose having some unadvertised functionality in the midst of a dev cycle would be ok. Releasing like that would be a mistake though. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Fri, 2015-05-29 at 14:14 +0100, Jan Beulich wrote:
On 29.05.15 at 15:01, dario.faggi...@citrix.com wrote:
On Wed, 2015-05-27 at 12:41 +0100, Jan Beulich wrote:
On 26.05.15 at 19:18, lichong...@gmail.com wrote:
On Tue, May 26, 2015 at 4:08 AM, Jan Beulich jbeul...@suse.com wrote:
On 26.05.15 at 02:05, lichong...@gmail.com wrote:
+
+switch ( op-cmd )
+{
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+list_for_each( iter, sdom-vcpu )
+{
+svc = list_entry(iter, struct rt_vcpu, sdom_elem);
+vcpuid = svc-vcpu-vcpu_id;
+
+local_sched.budget = svc-budget / MICROSECS(1);
+local_sched.period = svc-period / MICROSECS(1);
+if ( copy_to_guest_offset(op-u.rtds.vcpus, vcpuid,
What makes you think that the caller has provided enough slots?
This code works in a similar way as the one for XEN_SYSCTL_numainfo.
So if there is no enough slot in guest space, en error code is
returned.
I don't think I saw any place you returned an error here. The
only error being returned is -EFAULT when the copy-out fails.
Look again at XEN_SYSCTL_numainfo, in particular, at this part:
if ( ni-num_nodes num_nodes )
{
ret = -ENOBUFS;
i = num_nodes;
}
else
i = 0
Which, as you'll appreciate if you check from where ni-num_nodes and
num_nodes come from, if where the boundary checking we're asking for
happens.
Note how the 'i' variable is used in the rest of the block, and you'll
see what we mean, and can do something similar.
I think this was targeted at Chong rather than me (while I was
listed as To, and Chong only on Cc)?
It was indeed targeted at him. :-)
I replied to your email to re-use and quote the points you made, but did
not think about changing what my MUA does by default when hitting
'Reply'... I never do that, actually, but I now see how it could be a
good idea to do so... I'll try to remember and fit that in my workflow.
+/* Adjust scheduling parameter for the vcpus of a given domain. */
+long sched_adjust_vcpu(
+struct domain *d,
+struct xen_domctl_scheduler_vcpu_op *op)
+{
+long ret;
I see no reason for this and the function return type to be long.
The reason is stated in the begining.
In the beginning of what? I don't see any such, and it would also be
odd for there to be an explanation of why a particular type was chosen.
As Chong he's saying elsewhere, he's moslty following suit. Should we
consider a pre-patch making both sched_adjust() and
sched_adjust_global() retunr int?
Perhaps. But the main point here is that people copying existing code
should sanity check what they copy (so to not spread oddities or even
bugs).
Agreed, but in this case, he'd have ended up with:
long sched_adjust(...)
int sched_adjust_vcpu(...)
long sched_adjust_global(...)
So I think I see why Chong just went with 'long', that was my point.
Then of course, one could have spotted that it's the two existing ones
that are wrong/suboptimal, but that's more our responsibility than
Chong's fault, IMO (which does not mean that we should not point the
thing out and fix/ask to fix).
In any case, as far as this series is concerned, there should be no need
for a new function like this any longer. For fixing _adjust and
_adjust_global, I'll take care of it.
Regards,
Dario
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 57842: regressions - FAIL
flight 57842 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/57842/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xend-winxpsp3 16 guest-stop fail REGR. vs. 53018 test-amd64-i386-xend-qemut-winxpsp3 16 guest-stop fail REGR. vs. 53018 Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 57781 pass in 57842 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 57781 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 57781 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-win7-amd64 16 guest-stop fail in 57781 like 53018 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 53018 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 53018 test-amd64-i386-xl-win7-amd64 16 guest-stop fail like 53018 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 57781 never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 63aeca00c805fa1c47d9f7b1978e83e41ab482d4 baseline version: xen 7e527e2ab6c95ef84035d02e9e50b956a0d469c9 People who touched revisions under test: Ian Jackson ian.jack...@eu.citrix.com Petr Matousek pmato...@redhat.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-qemuu-freebsd10-amd64pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 pass test-amd64-i386-xl-win7-amd64fail test-amd64-amd64-xl-credit2 pass test-i386-i386-xl-credit2pass test-amd64-i386-qemuu-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 blocked test-i386-i386-rumpuserxen-i386 blocked test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass
Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments
On 06/03/2015 02:31 AM, Andrew Cooper wrote: There appears to be no formal statement of what pv_irq_ops.save_fl() is supposed to return precisely. Native returns the full flags, while lguest and Xen only return the Interrupt Flag, and both have comments by the implementations stating that only the Interrupt Flag is looked at. This may have been true when initially implemented, but no longer is. To make matters worse, the Xen PVOP leaves the upper bits undefined, making the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV guests on Broadwell hardware. The BUG_ON() is consistent for an individual build, but not consistent for all builds. It has also been a sitting timebomb since SMAP support was introduced. Use native_save_fl() instead, which will obtain an accurate view of the AC flag. Could we fix the Xen pvops wrapper instead to not do things like this? -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 7/9] x86/intel_pstate: add a booting param to select the driver to load
On 04/06/2015 09:18, Wei Wang wrote
On 03/06/2015 19:51, Jan Beulich wrote
On 03.06.15 at 10:07, wei.w.w...@intel.com wrote:
On 26/05/2015 22:02, Jan Beulich wrote
On 13.05.16 at 09:51, wei.w.w...@intel.com wrote:
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
--- a/xen/arch/x86/acpi/cpufreq/intel_pstate.c
+++ b/xen/arch/x86/acpi/cpufreq/intel_pstate.c
@@ -766,6 +766,8 @@ static struct cpufreq_driver
intel_pstate_driver =
{
.name = intel_pstate,
};
+int __initdata load_intel_pstate = 0;
static bool_t
I think we cannot use static here, since load_intel_pstate is also
used in cpufreq.c to select which driver to load.
Iirc I had also requested to deal with that (as it looks pretty hackish
right
now).
I'm not sure about this. Can you please elaborate it - why it looks hackish by
doing so?
What is your preferred way to do it? Thanks.
The following is your another comment on load_intel_pstate:
@@ -650,9 +650,12 @@ static int __init cpufreq_driver_init(void)
int ret = 0;
if ((cpufreq_controller == FREQCTL_xen)
-(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
-ret = cpufreq_register_driver(acpi_cpufreq_driver);
-else if ((cpufreq_controller == FREQCTL_xen)
+(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) {
+if (load_intel_pstate)
+ret = intel_pstate_init();
+if (!load_intel_pstate)
+ret = cpufreq_register_driver(acpi_cpufreq_driver);
I don't see why you need load_intel_pstate here: Simply call the
original function whenever
intel_pstate_init() returns an error.
I plan to change it to:
if (load_intel_pstate)
ret = intel_pstate_init();
if (ret)
ret = cpufreq_register_driver(acpi_cpufreq_driver);
This allows the case that the machine supports the intel_pstate driver but
people just prefer to use the old driver for their own reasons.
Missed one thing, it should be like this:
if (load_intel_pstate)
ret = intel_pstate_init();
if (ret || ! load_intel_pstate)
ret = cpufreq_register_driver(acpi_cpufreq_driver);
Best,
Wei
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On Thu, 2015-06-04 at 10:14 +0100, Wei Liu wrote: The main objection is that we shouldn't call xc_domain_setmaxmem in the middle of a migration stream. In the middle of an _xc_ migration stream. This seems like the sort of thing it would be OK to have in a (to be introduced) libxl stream (which would itself contain the xc stream as a data item). I think we are expecting such a thing to be introduced as part of the libxl side of migration v2, aren't we? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On Thu, 2015-06-04 at 10:32 +0100, Andrew Cooper wrote: On 04/06/15 10:26, Ian Campbell wrote: On Thu, 2015-06-04 at 10:14 +0100, Wei Liu wrote: The main objection is that we shouldn't call xc_domain_setmaxmem in the middle of a migration stream. In the middle of an _xc_ migration stream. This seems like the sort of thing it would be OK to have in a (to be introduced) libxl stream (which would itself contain the xc stream as a data item). I think we are expecting such a thing to be introduced as part of the libxl side of migration v2, aren't we? No. libxl migration v2 will not be affecting the behaviour here. By such a thing I was referring to a libxl stream format, not this piece of data specifically. This stream format however will be extensible (I hope) and therefore could accommodate state information which differs from the domain configuration. The only reasonable way I see this being fixed is for the libxl json blob For _a_ libxl json blob, not necessarily the existing one, which is the user's domain configuration information. IOW it doesn't have to be the existing libxl_domain_config blob. (Nor does it really need to be json, but whatever) to contain the correct size of the VM, and for libxl_domain_create() to make an appropriately sized VM in the first place. One extension which libxl migration v2 will bring is the ability to send a new json blob later in the stream, but such a fix still requires the json blob to have the correct size in it. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxc: unify handling of vNUMA layout
This patch does the following:
1. Use local variables for dummy vNUMA layout in PV case.
2. Avoid leaking dummy layout back to caller in PV case.
3. Use local variables to reference vNUMA layout (whether it is dummy
or provided by caller) for both PV and HVM.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/xc_dom_x86.c | 49 ---
tools/libxc/xc_hvm_build_x86.c | 52 +-
2 files changed, 56 insertions(+), 45 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 783f749..3d2fbd5 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -762,6 +762,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
int rc;
xen_pfn_t pfn, allocsz, mfn, total, pfn_base;
int i, j;
+xen_vmemrange_t dummy_vmemrange[1];
+unsigned int dummy_vnode_to_pnode[1];
+xen_vmemrange_t *vmemranges;
+unsigned int *vnode_to_pnode;
+unsigned int nr_vmemranges, nr_vnodes;
rc = x86_compat(dom-xch, dom-guest_domid, dom-guest_type);
if ( rc )
@@ -826,27 +831,33 @@ int arch_setup_meminit(struct xc_dom_image *dom)
*/
if ( dom-nr_vmemranges == 0 )
{
-dom-nr_vmemranges = 1;
-dom-vmemranges = xc_dom_malloc(dom, sizeof(*dom-vmemranges));
-dom-vmemranges[0].start = 0;
-dom-vmemranges[0].end = (uint64_t)dom-total_pages
PAGE_SHIFT;
-dom-vmemranges[0].flags = 0;
-dom-vmemranges[0].nid = 0;
-
-dom-nr_vnodes = 1;
-dom-vnode_to_pnode = xc_dom_malloc(dom,
- sizeof(*dom-vnode_to_pnode));
-dom-vnode_to_pnode[0] = XC_NUMA_NO_NODE;
+nr_vmemranges = 1;
+vmemranges = dummy_vmemrange;
+vmemranges[0].start = 0;
+vmemranges[0].end = (uint64_t)dom-total_pages PAGE_SHIFT;
+vmemranges[0].flags = 0;
+vmemranges[0].nid = 0;
+
+nr_vnodes = 1;
+vnode_to_pnode = dummy_vnode_to_pnode;
+vnode_to_pnode[0] = XC_NUMA_NO_NODE;
+}
+else
+{
+nr_vmemranges = dom-nr_vmemranges;
+nr_vnodes = dom-nr_vnodes;
+vmemranges = dom-vmemranges;
+vnode_to_pnode = dom-vnode_to_pnode;
}
total = dom-p2m_size = 0;
-for ( i = 0; i dom-nr_vmemranges; i++ )
+for ( i = 0; i nr_vmemranges; i++ )
{
-total += ((dom-vmemranges[i].end - dom-vmemranges[i].start)
+total += ((vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT);
dom-p2m_size =
-dom-p2m_size (dom-vmemranges[i].end PAGE_SHIFT) ?
-dom-p2m_size : (dom-vmemranges[i].end PAGE_SHIFT);
+dom-p2m_size (vmemranges[i].end PAGE_SHIFT) ?
+dom-p2m_size : (vmemranges[i].end PAGE_SHIFT);
}
if ( total != dom-total_pages )
{
@@ -864,19 +875,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
dom-p2m_host[pfn] = INVALID_P2M_ENTRY;
/* allocate guest memory */
-for ( i = 0; i dom-nr_vmemranges; i++ )
+for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
uint64_t pages;
-unsigned int pnode = dom-vnode_to_pnode[dom-vmemranges[i].nid];
+unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
memflags = 0;
if ( pnode != XC_NUMA_NO_NODE )
memflags |= XENMEMF_exact_node(pnode);
-pages = (dom-vmemranges[i].end - dom-vmemranges[i].start)
+pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
-pfn_base = dom-vmemranges[i].start PAGE_SHIFT;
+pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index 0e98c84..003ea06 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -257,7 +257,9 @@ static int setup_guest(xc_interface *xch,
uint64_t total_pages;
xen_vmemrange_t dummy_vmemrange[2];
unsigned int dummy_vnode_to_pnode[1];
-bool use_dummy = false;
+xen_vmemrange_t *vmemranges;
+unsigned int *vnode_to_pnode;
+unsigned int nr_vmemranges, nr_vnodes;
memset(elf, 0, sizeof(elf));
if ( elf_init(elf, image, image_size) != 0 )
@@ -290,7 +292,7 @@ static int setup_guest(xc_interface *xch,
dummy_vmemrange[0].end = args-lowmem_end;
dummy_vmemrange[0].flags = 0;
dummy_vmemrange[0].nid = 0;
-args-nr_vmemranges = 1;
+nr_vmemranges = 1;
if ( args-highmem_end (1ULL 32) )
{
@@ -299,14 +301,13 @@ static int
Re: [Xen-devel] [PATCH RFC 1/2] libxl: allow /local/domain/0/device-model/$DOMID to be written by $DOMID
On Thu, Jun 04, 2015 at 11:06:39AM +0100, Stefano Stabellini wrote:
On Tue, 2 Jun 2015, Wei Liu wrote:
On Mon, Jun 01, 2015 at 05:01:34PM +0100, Stefano Stabellini wrote:
The device model is going to restrict its xenstore connection to $DOMID
level. Let it access /local/domain/0/device-model/$DOMID, as it is
required by QEMU to read/write the physmap. It doesn't contain any
information the guest is not already fully aware of.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl_dm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97a921f..e74042b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1467,6 +1467,7 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
char **pass_stuff;
const char *dm;
int dm_state_fd = -1;
+struct xs_permissions rwperm[2];
if (libxl_defbool_val(b_info-device_model_stubdomain)) {
abort();
@@ -1509,7 +1510,11 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
}
path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid,
);
-xs_mkdir(ctx-xsh, XBT_NULL, path);
+rwperm[0].id = 0;
Use LIBXL_TOOLSTACK_DOMID?
OK
+rwperm[0].perms = XS_PERM_WRITE;
This is probably not what you mean. This means all other domains have
write access. See tools/xenstore/include/xenstore.h L152.
Right! I'll fix.
And, do you also want to consider stubdom?
I don't think there is much to do for stubdoms here: they are
unaffected.
Oh right, this is the local_dm spawn function. Sorry for the noise.
Wei.
+rwperm[1].id = domid;
+rwperm[1].perms = XS_PERM_WRITE;
+libxl__xs_mkdir(gc, XBT_NULL, path, rwperm, 2);
if (b_info-type == LIBXL_DOMAIN_TYPE_HVM
b_info-device_model_version
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] clarification of xen Wiki article
On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote: Unless the author or someone else in the know speaks up I would propose to remove this text from the wiki. +1 for this. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Draft D] Xen on ARM vITS Handling
On 04/06/2015 18:55, Julien Grall wrote: After reading this draft, I think we can avoid to browse the Device Table and the ITT. As said on the previous paragraph, the pending_irq structure is linked to an irq_desc. In your proposal, you suggested to store the its_device in the irq_guest (part of irq_desc). If we make usage of pending_irq-desc to store the physical descriptor, we can have a mapping vLPI = pLPI. Therefore, this would resolve UI1 and AFAICT, the memory usage would be the same in Xen of the ITT/Device base solution. BTW, I will suggest a pseudo-code based on your draft tomorrow. It may be easier to understand. -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V9] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On Thu, Jun 4, 2015 at 3:53 PM, Tim Deegan t...@xen.org wrote:
At 16:19 +0200 on 03 Jun (1433348379), Lengyel, Tamas wrote:
On Wed, Jun 3, 2015 at 3:48 PM, Razvan Cojocaru
rcojoc...@bitdefender.com
wrote:
On 06/03/2015 04:29 PM, Lengyel, Tamas wrote:
struct {
-uint16_t mov_to_cr0_enabled : 1;
-uint16_t mov_to_cr0_sync : 1;
-uint16_t mov_to_cr0_onchangeonly : 1;
-uint16_t mov_to_cr3_enabled : 1;
-uint16_t mov_to_cr3_sync : 1;
-uint16_t mov_to_cr3_onchangeonly : 1;
-uint16_t mov_to_cr4_enabled : 1;
-uint16_t mov_to_cr4_sync : 1;
-uint16_t mov_to_cr4_onchangeonly : 1;
+uint16_t write_ctrlreg_enabled : 4;
+uint16_t write_ctrlreg_sync : 4;
+uint16_t write_ctrlreg_onchangeonly : 4;
Just looking at this here again, we will now have a bitmap within a
bitmap, which doesn't seem to be very efficient. IMHO it would be
better
to just take the ctrlreg bitmap out as a separate uint8_t within
struct
{} monitor.
How is it inefficient? I don't see that at all. And I'm not sure what
you mean about the uint8_t: there are 3 fields there, each 4-bits wide
(write_ctrlreg_enabled, write_ctrlreg_sync, write_ctrlreg_onchangeonly)
and only (at most) two of them would fit into a uint8_t. To put them
all
into a new struct would mean wasting an uint16_t for 12-bits.
Right now if you want to access a bit using the index on the ctrlreg
fields, you would for example do (monitor.write_ctrlreg_enabled index).
This is actually going to perform two bitmask operations. First,
monitor.write_ctrlreg_enabled
does a masking operating to get you only the 4 bits corresponding to this
field, then you do another mask with the index.
The compiler can optimize away the first mask operation. E.g., gcc
folds that into a single operation at anything above -O0.
Tim.
Good to know, thanks Tim! Sorry for the noise ;)
--
[image: www.novetta.com]
Tamas K Lengyel
Senior Security Researcher
7921 Jones Branch Drive
McLean VA 22102
Email tleng...@novetta.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 8/9] x86/intel_pstate: support the use of intel_pstate in pmstat.c
Wang, Wei W wei.w.w...@intel.com 06/04/15 4:21 AM
On 26/05/2015 22:16, Jan Beulich wrote
On 13.05.16 at 09:51, wei.w.w...@intel.com wrote:
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -261,29 +272,47 @@ static int get_cpufreq_para(struct
xen_sysctl_pm_op *op)
op-u.get_para.cpuinfo_max_freq = policy-cpuinfo.max_freq;
op-u.get_para.cpuinfo_min_freq = policy-cpuinfo.min_freq;
op-u.get_para.scaling_cur_freq = policy-cur;
-op-u.get_para.scaling_max_freq = policy-max;
-op-u.get_para.scaling_min_freq = policy-min;
+if (policy-policy) {
+op-u.get_para.scaling_max.max_perf_pct = policy-max_perf_pct;
+op-u.get_para.scaling_min.min_perf_pct = policy-min_perf_pct;
+op-u.get_para.scaling_turbo_pct = policy-turbo_pct;
+} else {
+op-u.get_para.scaling_max.max_freq = policy-max;
+op-u.get_para.scaling_min.min_freq = policy-min;
+}
How does the caller then know which of the union member meanings
apply?
The end caller is xenpm. It's aware of the running pstate driver, so it knows
the difference between freq and pct.
xenpm is one of the possible callers. We don't make hypercalls with just a
single consumer in mind, excluding any other potential one(s). And hence a
hypercall like this should be kind of self contained, i.e. in the case here the
caller ought to be able to know from its result which of the union fields are in
use.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 7/9] x86/intel_pstate: add a booting param to select the driver to load
Wang, Wei W wei.w.w...@intel.com 06/04/15 3:15 AM
On 03/06/2015 19:51, Jan Beulich wrote
On 03.06.15 at 10:07, wei.w.w...@intel.com wrote:
@@ -650,9 +650,12 @@ static int __init cpufreq_driver_init(void)
int ret = 0;
if ((cpufreq_controller == FREQCTL_xen)
-(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
-ret = cpufreq_register_driver(acpi_cpufreq_driver);
-else if ((cpufreq_controller == FREQCTL_xen)
+(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) {
+if (load_intel_pstate)
+ret = intel_pstate_init();
+if (!load_intel_pstate)
+ret = cpufreq_register_driver(acpi_cpufreq_driver);
I don't see why you need load_intel_pstate here: Simply call the original
function whenever
intel_pstate_init() returns an error.
I plan to change it to:
if (load_intel_pstate)
ret = intel_pstate_init();
if (ret)
ret = cpufreq_register_driver(acpi_cpufreq_driver);
This allows the case that the machine supports the intel_pstate driver but
people
just prefer to use the old driver for their own reasons.
But there's no point in using load_intel_pstate here - it should be a variable
local to
that driver. Simply call the function unconditionally and check the variable
first thing
inside the function.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/sched_rt: Use the correct type for _cpumask_scratch
Hi Dario, On 04/06/2015 09:57, Dario Faggioli wrote: On Tue, 2015-06-02 at 16:07 +0100, Julien Grall wrote: The commit 376bbbabbda607d2039b8f839f15ff02721597d2 sched_rt: print useful affinity info when dumping breaks build on ARM64: sched_rt.c: In function ‘rt_init’: sched_rt.c:442:26: error: assignment from incompatible pointer type [-Werror] _cpumask_scratch = xmalloc_array(cpumask_var_t, nr_cpu_ids); ^ sched_rt.c: In function ‘rt_alloc_pdata’: sched_rt.c:489:29: error: passing argument 1 of ‘alloc_cpumask_var’ from incompatible pointer type [-Werror] if ( !alloc_cpumask_var(_cpumask_scratch[cpu]) ) This is because cpumask_var_t is not a type alias to cpumask_t** when the number of CPU 2 * BITS_PER_LONG. The correct type for _cpumask_scratch should be cpumask_var_t. Oh, right. Sorry for this, I didn't have an ARM build test sat up when working on this patch and, although now I have it, I did not run it through it when resending the patch (although, this is probably not only ARM related!). It's only present on ARM64 build. ARM32 build perfectly fine. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 COLO Pre 03/12] tools/libxc: export xc_bitops.h
On 06/04/2015 04:36 PM, Ian Campbell wrote: On Thu, 2015-06-04 at 09:01 +0800, Yang Hongyang wrote: On 06/02/2015 06:11 PM, Andrew Cooper wrote: On 02/06/15 10:26, Yang Hongyang wrote: When we are under COLO, we will send dirty page bitmap info from secondary to primary at every checkpoint. So we need to get/test the dirty page bitmap. We just expose xc_bitops.h for libxl use. NOTE: Need to make clean and rerun configure to get it compiled. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com I like this change, but lets take the opportunity to fix some of the issues in it. Thanks, will fix in next version. Please do fix and move in two separate patches, probably fix first although I don't mind overall. Sure, will do. Ian. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments
On 04/06/15 07:38, H. Peter Anvin wrote: On 06/03/2015 02:31 AM, Andrew Cooper wrote: There appears to be no formal statement of what pv_irq_ops.save_fl() is supposed to return precisely. Native returns the full flags, while lguest and Xen only return the Interrupt Flag, and both have comments by the implementations stating that only the Interrupt Flag is looked at. This may have been true when initially implemented, but no longer is. To make matters worse, the Xen PVOP leaves the upper bits undefined, making the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV guests on Broadwell hardware. The BUG_ON() is consistent for an individual build, but not consistent for all builds. It has also been a sitting timebomb since SMAP support was introduced. Use native_save_fl() instead, which will obtain an accurate view of the AC flag. Could we fix the Xen pvops wrapper instead to not do things like this? -hpa We could, and I have a patch for that, but the check would still then be broken in lguest, and it makes a hotpath rather longer. Either pv_irq_ops.save_fl() gets defined to handle all flags, and Xen lguest need correcting in this regard, or save_fl() gets defined to handle the interrupt flag only, and this becomes the single problematic caller in the codebase. The problem with expanding save_fl() to handle all flags is that restore_fl() should follow suit, and there are a number of system flags are inapplicable in such a situation. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/sched_rt: Use the correct type for _cpumask_scratch
On Tue, 2015-06-02 at 16:07 +0100, Julien Grall wrote: The commit 376bbbabbda607d2039b8f839f15ff02721597d2 sched_rt: print useful affinity info when dumping breaks build on ARM64: sched_rt.c: In function ‘rt_init’: sched_rt.c:442:26: error: assignment from incompatible pointer type [-Werror] _cpumask_scratch = xmalloc_array(cpumask_var_t, nr_cpu_ids); ^ sched_rt.c: In function ‘rt_alloc_pdata’: sched_rt.c:489:29: error: passing argument 1 of ‘alloc_cpumask_var’ from incompatible pointer type [-Werror] if ( !alloc_cpumask_var(_cpumask_scratch[cpu]) ) This is because cpumask_var_t is not a type alias to cpumask_t** when the number of CPU 2 * BITS_PER_LONG. The correct type for _cpumask_scratch should be cpumask_var_t. Oh, right. Sorry for this, I didn't have an ARM build test sat up when working on this patch and, although now I have it, I did not run it through it when resending the patch (although, this is probably not only ARM related!). Sorry also for not replying to this promptly, I was on leave until today (good that this has been picked already anyway :-)). Dario signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 COLO Pre 03/12] tools/libxc: export xc_bitops.h
On Thu, 2015-06-04 at 09:01 +0800, Yang Hongyang wrote: On 06/02/2015 06:11 PM, Andrew Cooper wrote: On 02/06/15 10:26, Yang Hongyang wrote: When we are under COLO, we will send dirty page bitmap info from secondary to primary at every checkpoint. So we need to get/test the dirty page bitmap. We just expose xc_bitops.h for libxl use. NOTE: Need to make clean and rerun configure to get it compiled. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com I like this change, but lets take the opportunity to fix some of the issues in it. Thanks, will fix in next version. Please do fix and move in two separate patches, probably fix first although I don't mind overall. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] clarification of xen Wiki article
Hi all, I was reading http://wiki.xen.org/wiki/XenBus In the section on Store Organization, there is the statement Information should not be replicated in the store and required to be consistent I'm not sure what that means. Can anybody clarify this for me, please? Thanks. linda ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
On 06/03/15 12:23, George Dunlap wrote: On 06/03/2015 04:58 PM, Andrew Cooper wrote: On 03/06/15 16:26, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: Summary is that VMware treats in (%dx),%eax (or out %eax,(%dx)) to port 0x5658 specially. Note: since many operations return data in EAX, in (%dx),%eax is the one to use. The other lengths like in (%dx),%al will still do things, only AL part of EAX will be changed. For out %eax,(%dx) of all lengths, EAX will remain unchanged. This instruction is allowed to be used from ring 3. To support this the vmexit for GP needs to be enabled. I have not fully tested that nested HVM is doing the right thing for this. Enable no-fault of pio in x86_emulate for VMware port Also adjust the emulation registers after doing a VMware backdoor operation. Add new routine hvm_emulate_one_gp() to be used by the #GP fault handler. Some of the best info is at: https://sites.google.com/site/chitchatvmback/backdoor Signed-off-by: Don Slutz dsl...@verizon.com So let me get this straight. VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which always return an error. Is that about right? That sounds completely insane. It opens up an almost infinite surface of attack onto the Xen emulator. I understand that having the VMWare compatible is a nice tick-box to have, but seriously, I cannot imagine that having unprivileged user-space tools know the real clock frequency without having to involve the OS is anywhere close to worth the risk involved. The attack surface sadly is not enlarged in the slightest by this change. We already trap and emulate all #UD exceptions in an attempt to support migration of VMs between Intel and AMD hardware. See XSA-105. (There is a good argument to be made for not trapping #UD, but that doesn't completely close the hole) So at the moment, an attacker on Intel can force the emulation of any AMD-only instruction (and vice versa), is that right? This would allow an attacker to force the emulation of every #GP condition of every instruction we emulate. Those two sets may be within an order of magnitude of each other, but they will only overlap a little bit. So my guess is that enabling this would double the surface of attack (give or take). I'd be a lot happier with this patch if we could make it so that on a #GP the only instruction that could get emulated would be an IO instruction. You mean like I said in: Message-ID: 54c67d83027800059...@mail.emea.novell.com X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Mon, 26 Jan 2015 16:46:43 + From: Jan Beulich jbeul...@suse.com To: Don Slutz dsl...@verizon.com CC: Suravee Suthikulpanit suravee.suthikulpa...@amd.com, Andrew Cooper andrew.coop...@citrix.com, Ian Campbell ian.campb...@citrix.com, George Dunlap george.dun...@eu.citrix.com, Ian Jackson ian.jack...@eu.citrix.com, Stefano Stabellini stefano.stabell...@eu.citrix.com, Eddie Dong eddie.d...@intel.com, Jun Nakajima jun.nakaj...@intel.com, Kevin Tian kevin.t...@intel.com, xen-devel@lists.xen.org, Boris Ostrovsky boris.ostrov...@oracle.com, Konrad Rzeszutek Wilk konrad.w...@oracle.com, Keir Fraser k...@xen.org, Tim Deegan t...@xen.org Subject: Re: [PATCH for-4.5 v8 4/7] xen: Add vmware_port support References: 1412285417-19180-1-git-send-email-dsl...@verizon.com 1412285417-19180-5-git-send-email-dsl...@verizon.com 542dca92.1030...@terremark.com 542dd44f.6030...@terremark.com 54b8f174027800055...@mail.emea.novell.com 54bfe768.3090...@terremark.com 54c0c39f027800057...@mail.emea.novell.com 54c6643...@terremark.com In-Reply-To: 54c6643...@terremark.com -Don Slutz -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node
Hi Julien, When the property clock-frequency is present in the DT timer node, it means that the bootloader/firmware didn't correctly configured the CNTFRQ/CNTFRQ_EL0 on each processor. I will test this patch, but it doesn't apply cleanly to the version of Xen I'm currently using, so I need to update that first. I also looked at whether it would be possible to set the CNTFRQ register in the other cores when they come up. Eventually, I think we should do this in the (platform-specific) PSCI code. There doesn't seem to be a suitable hook in the platform-specific Xen code - it looks like all the code there related to bringing up secondary cores runs on the primary. Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On Wed, Jun 03, 2015 at 02:22:25PM +0100, George Dunlap wrote: On Tue, Jun 2, 2015 at 3:05 PM, Wei Liu wei.l...@citrix.com wrote: Previous discussion at [0]. For the benefit of discussion, we refer to max_memkb inside hypervisor as hv_max_memkb (name subject to improvement). That's the maximum number of memory a domain can use. Why don't we try to use memory for virtual RAM that we report to the guest, and pages for what exists inside the hypervisor? Pages is the term the hypervisor itself uses internally (i.e., set_max_mem() actually changes a domain's max_pages value). So in this case both guest memory and option roms are created using hypervisor pages. Libxl doesn't know hv_max_memkb for a domain needs prior to QEMU start-up because of optional ROMs etc. So a translation of this using memory/pages terminology would be: QEMU may need extra pages from Xen to implement option ROMS, and so at the moment it calls set_max_mem() to increase max_pages so that it can allocate more pages to the guest. libxl doesn't know what max_pages a domain needs prior to qemu start-up. Libxl doesn't know the hv_max_memkb even after QEMU start-up, because there is no mechanism to community between QEMU and libxl. This is an area that needs improvement, we've encountered problems in this area before. [translating] Libxl doesn't know max_pages even after qemu start-up, because there is no mechanism to communicate between qemu and libxl. QEMU calls xc_domain_setmaxmem to increase hv_max_memkb by N pages. Those pages are only accounted in hypervisor. During migration, libxl (currently) doesn't extract that value from hypervisor. [translating] qemu calls xc_domain_setmaxmem to increase max_pages by N pages. Those pages are only accounted for in the hypervisor. libxl (currently) does not extract that value from the hypervisor. So now the problem is on the remote end: 1. Libxl indicates domain needs X pages. 2. Domain actually needs X + N pages. 3. Remote end tries to write N more pages and fail. This behaviour currently doesn't affect normal migration (that you transfer libxl JSON to remote, construct a domain, then start QEMU) because QEMU won't bump hv_max_memkb again. This is by design and reflected in QEMU code. I don't understand this paragraph -- does the remote domain actually need X+N pages or not? If it does, in what way does this behavior not affect normal migration? I was wrong. I don't recollect how I came to that conclusion. It does affect normal migration. This behaviour affects COLO and becomes a bug in that case, because secondary VM's QEMU doesn't go through the same start-of-day initialisation (Hongyang, correct me if I'm wrong), i.e. no bumping hv_max_memkb inside QEMU. Andrew plans to embed JSON inside migration v2 and COLO is based on migration v2. The bug is fixed if JSON is correct in the first place. As COLO is not yet upstream, so this bug is not a blocker for 4.6. But it should be fixed for the benefit of COLO. So here is a proof of concept patch to record and honour that value during migration. A new field is added in IDL. Note that we don't provide xl level config option for it and mandate it to be default value during domain creation. This is to prevent libxl user from using it to avoid unforeseen repercussions. This patch is compiled test only. If we agree this is the way to go I will test and submit a proper patch. Reading max_pages from Xen and setting it on the far side seems like a reasonable option. Is there a reason we can't add a magic XC_SAVE_ID Yes. That's the correct behaviour we want to have. The question is where should we put that value and when to set it. for v1, like we do for other parameters? The main objection is that we shouldn't call xc_domain_setmaxmem in the middle of a migration stream. Wei. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: QEMU bumping memory limit and domain restore
On 04/06/15 10:26, Ian Campbell wrote: On Thu, 2015-06-04 at 10:14 +0100, Wei Liu wrote: The main objection is that we shouldn't call xc_domain_setmaxmem in the middle of a migration stream. In the middle of an _xc_ migration stream. This seems like the sort of thing it would be OK to have in a (to be introduced) libxl stream (which would itself contain the xc stream as a data item). I think we are expecting such a thing to be introduced as part of the libxl side of migration v2, aren't we? No. libxl migration v2 will not be affecting the behaviour here. The only reasonable way I see this being fixed is for the libxl json blob to contain the correct size of the VM, and for libxl_domain_create() to make an appropriately sized VM in the first place. One extension which libxl migration v2 will bring is the ability to send a new json blob later in the stream, but such a fix still requires the json blob to have the correct size in it. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] clarification of xen Wiki article
On Wed, 2015-06-03 at 09:24 -0600, Linda wrote: Hi all, I was reading http://wiki.xen.org/wiki/XenBus In the section on Store Organization, there is the statement Information should not be replicated in the store and required to be consistent I'm not sure what that means. Can anybody clarify this for me, please? This came from the old wiki, so the history is unclear. I suppose it could mean either: If you replicate information in xenstore then you should not expect it to be consistent or Do not replicate information, do not require information to be consistent. But let me turn the question around: What are you actually trying to achieve? i.e. what is causing this ambiguous and confusing statement to be a concern for you. Unless the author or someone else in the know speaks up I would propose to remove this text from the wiki. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/2] libxl: allow /local/domain/0/device-model/$DOMID to be written by $DOMID
On Tue, 2 Jun 2015, Wei Liu wrote:
On Mon, Jun 01, 2015 at 05:01:34PM +0100, Stefano Stabellini wrote:
The device model is going to restrict its xenstore connection to $DOMID
level. Let it access /local/domain/0/device-model/$DOMID, as it is
required by QEMU to read/write the physmap. It doesn't contain any
information the guest is not already fully aware of.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl_dm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97a921f..e74042b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1467,6 +1467,7 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
char **pass_stuff;
const char *dm;
int dm_state_fd = -1;
+struct xs_permissions rwperm[2];
if (libxl_defbool_val(b_info-device_model_stubdomain)) {
abort();
@@ -1509,7 +1510,11 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
}
path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid,
);
-xs_mkdir(ctx-xsh, XBT_NULL, path);
+rwperm[0].id = 0;
Use LIBXL_TOOLSTACK_DOMID?
OK
+rwperm[0].perms = XS_PERM_WRITE;
This is probably not what you mean. This means all other domains have
write access. See tools/xenstore/include/xenstore.h L152.
Right! I'll fix.
And, do you also want to consider stubdom?
I don't think there is much to do for stubdoms here: they are
unaffected.
+rwperm[1].id = domid;
+rwperm[1].perms = XS_PERM_WRITE;
+libxl__xs_mkdir(gc, XBT_NULL, path, rwperm, 2);
if (b_info-type == LIBXL_DOMAIN_TYPE_HVM
b_info-device_model_version
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/5] libxl: xs_restrict QEMU
Hi all, this patch series changes libxl to start QEMU as device model with the new xsrestrict option (http://marc.info/?l=xen-develm=143341692707358). It also starts a second QEMU to provide PV backends in userspace (qdisk) to HVM guests. Changes in v2: - fix xs permissions to actually do what intended - use LIBXL_TOOLSTACK_DOMID instead of 0 - add libxl: xsrestrict QEMU - add libxl: change xs path for pv qemu - add libxl: spawns two QEMUs for HVM guests Stefano Stabellini (5): libxl: allow /local/domain/0/device-model/$DOMID to be written by $DOMID libxl: do not add a vkb backend to hvm guests libxl: xsrestrict QEMU libxl: change xs path for pv qemu libxl: spawns two QEMUs for HVM guests tools/libxl/libxl.c |2 +- tools/libxl/libxl_create.c | 23 +++--- tools/libxl/libxl_device.c |2 +- tools/libxl/libxl_dm.c | 99 +- tools/libxl/libxl_dom.c | 12 ++--- tools/libxl/libxl_internal.c | 19 ++-- tools/libxl/libxl_internal.h |8 ++-- tools/libxl/libxl_pci.c | 14 +++--- tools/libxl/libxl_utils.c| 10 + 9 files changed, 152 insertions(+), 37 deletions(-) Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 9/9] Add xentrace to vmware_port
On 06/04/15 07:20, George Dunlap wrote:
On 05/22/2015 04:50 PM, Don Slutz wrote:
Also added missing TRAP_DEBUG VLAPIC.
Signed-off-by: Don Slutz dsl...@verizon.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v11:
No change
v10:
Added Acked-by: Ian Campbell
Added back in the trace point calls.
Why is cmd in this patch?
Because the trace points use it.
v9:
Dropped unneed VMPORT_UNHANDLED, VMPORT_DECODE.
v7:
Dropped some of the new traces.
Added HVMTRACE_ND7.
v6:
Dropped the attempt to use svm_nextrip_insn_length via
__get_instruction_length (added in v2). Just always look
at upto 15 bytes on AMD.
v5:
exitinfo1 is used twice.
Fixed.
tools/xentrace/formats | 5 +
xen/arch/x86/hvm/io.c| 3 +++
xen/arch/x86/hvm/vmware/vmport.c | 17 ++---
xen/include/asm-x86/hvm/trace.h | 22 ++
xen/include/public/trace.h | 3 +++
5 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 5d7b72a..eec65f4 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -79,6 +79,11 @@
0x00082020 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) INTR_WINDOW [ value =
0x%(1)08x ]
0x00082021 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) NPF [ gpa =
0x%(2)08x%(1)08x mfn = 0x%(4)08x%(3)08x qual = 0x%(5)04x p2mt = 0x%(6)04x ]
0x00082023 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) TRAP[ vector =
0x%(1)02x ]
+0x00082024 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) TRAP_DEBUG [
exit_qualification = 0x%(1)08x ]
+0x00082025 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VLAPIC
+0x00082026 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_HANDLED [ cmd =
%(1)d eax = 0x%(2)08x ebx = 0x%(3)08x ecx = 0x%(4)08x edx = 0x%(5)08x esi =
0x%(6)08x edi = 0x%(7)08x ]
+0x00082027 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_IGNORED [ port =
%(1)d eax = 0x%(2)08x ebx = 0x%(3)08x ecx = 0x%(4)08x edx = 0x%(5)08x esi =
0x%(6)08x edi = 0x%(7)08x ]
+0x00082028 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_QEMU [ eax =
0x%(1)08x ebx = 0x%(2)08x ecx = 0x%(3)08x edx = 0x%(4)08x esi = 0x%(5)08x
edi = 0x%(6)08x ]
0x0010f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_map [ domid
= %(1)d ]
0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap[ domid
= %(1)d ]
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 7684cf0..6a9cfb0 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -206,6 +206,9 @@ void hvm_io_assist(ioreq_t *p)
regs-_edx = vr-edx;
regs-_esi = vr-esi;
regs-_edi = vr-edi;
+HVMTRACE_ND(VMPORT_QEMU, 0, 1/*cycles*/, 6,
+p-data, regs-_ebx, regs-_ecx,
+regs-_edx, regs-_esi, regs-_edi);
}
}
if ( vio-io_size == 4 ) /* Needs zero extension. */
diff --git a/xen/arch/x86/hvm/vmware/vmport.c
b/xen/arch/x86/hvm/vmware/vmport.c
index 36e3f1b..3c3ccd4 100644
--- a/xen/arch/x86/hvm/vmware/vmport.c
+++ b/xen/arch/x86/hvm/vmware/vmport.c
@@ -16,6 +16,7 @@
#include xen/lib.h
#include asm/hvm/hvm.h
#include asm/hvm/support.h
+#include asm/hvm/trace.h
#include backdoor_def.h
@@ -35,6 +36,7 @@ static int vmport_ioport(int dir, uint32_t port, uint32_t
bytes, uint32_t *val)
if ( port == BDOOR_PORT regs-_eax == BDOOR_MAGIC )
{
uint32_t new_eax = ~0u;
+uint16_t cmd = regs-_ecx;
uint64_t value;
struct vcpu *curr = current;
struct domain *currd = curr-domain;
@@ -45,7 +47,7 @@ static int vmport_ioport(int dir, uint32_t port, uint32_t
bytes, uint32_t *val)
* leaving the high 32-bits unchanged, unlike what one would
* expect to happen.
*/
-switch ( regs-_ecx 0x )
+switch ( cmd )
{
case BDOOR_CMD_GETMHZ:
new_eax = currd-arch.tsc_khz / 1000;
@@ -123,11 +125,20 @@ static int vmport_ioport(int dir, uint32_t port,
uint32_t bytes, uint32_t *val)
/* Let backing DM handle */
return X86EMUL_UNHANDLEABLE;
}
+HVMTRACE_ND7(VMPORT_HANDLED, 0, 0/*cycles*/, 7,
+ cmd, new_eax, regs-_ebx, regs-_ecx,
+ regs-_edx, regs-_esi, regs-_edi);
Do you need to log edi as well? It looks like it's not used.
I guess not, but since there are VMware port commands that do use edi, a
future add might need it. I find it simpler to have this and the QEMU
case above the same but will change it if you want.
if ( dir == IOREQ_READ )
*val = new_eax;
}
-else if ( dir == IOREQ_READ )
-*val = ~0u;
+else
+{
+HVMTRACE_ND7(VMPORT_IGNORED, 0, 0/*cycles*/, 7,
+ port, regs-_eax, regs-_ebx, regs-_ecx,
+
[Xen-devel] Developer Summit Schedule announced + Maintainer/Committer meeting on Aug 19
Hi everyone, the developer summit schedule is now live at http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule and speakers should have gotten an acceptance mails. If not, please do let me know. I did double check whether there are conflicts with Note that * a couple of talk submissions will still need to be modified and second speakers added - this will happen in due course * the talk lengths like in the past are 25 minutes with 5 minutes QA * some sessions will be 45 minutes with QA - in general the sessions which got highly rated by the PMC are longer * we tried to find a good balance between sessions in parallel - this used to be an issue for many of you in the past * if you want to hold a Bof, drop me a line with the desired slot, the title (BoF will be prefixed) and a short description - I CC'ed some people which indicated they wanted to hold a BoF It appears to me that we should have BoF's about xsplice and PVH futures/planning. * On the afternoon of Aug 19th, we are sharing a hackspace with the KVM Forum * On the evening of Aug 19th, we will have a joint social event between the Xen Dev summit and the KVM Forum Developer Meeting We are planning a developer meeting on the morning of Aug 19th (9:30 to 12:00) or if you prefer 10:30 to 13:00. Please let me know of I will know more details in the coming 2 weeks Best Regards Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 9/9] Add xentrace to vmware_port
On 05/22/2015 04:50 PM, Don Slutz wrote:
Also added missing TRAP_DEBUG VLAPIC.
Signed-off-by: Don Slutz dsl...@verizon.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v11:
No change
v10:
Added Acked-by: Ian Campbell
Added back in the trace point calls.
Why is cmd in this patch?
Because the trace points use it.
v9:
Dropped unneed VMPORT_UNHANDLED, VMPORT_DECODE.
v7:
Dropped some of the new traces.
Added HVMTRACE_ND7.
v6:
Dropped the attempt to use svm_nextrip_insn_length via
__get_instruction_length (added in v2). Just always look
at upto 15 bytes on AMD.
v5:
exitinfo1 is used twice.
Fixed.
tools/xentrace/formats | 5 +
xen/arch/x86/hvm/io.c| 3 +++
xen/arch/x86/hvm/vmware/vmport.c | 17 ++---
xen/include/asm-x86/hvm/trace.h | 22 ++
xen/include/public/trace.h | 3 +++
5 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 5d7b72a..eec65f4 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -79,6 +79,11 @@
0x00082020 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) INTR_WINDOW [ value =
0x%(1)08x ]
0x00082021 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) NPF [ gpa =
0x%(2)08x%(1)08x mfn = 0x%(4)08x%(3)08x qual = 0x%(5)04x p2mt = 0x%(6)04x ]
0x00082023 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) TRAP[ vector =
0x%(1)02x ]
+0x00082024 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) TRAP_DEBUG [
exit_qualification = 0x%(1)08x ]
+0x00082025 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VLAPIC
+0x00082026 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_HANDLED [ cmd =
%(1)d eax = 0x%(2)08x ebx = 0x%(3)08x ecx = 0x%(4)08x edx = 0x%(5)08x esi =
0x%(6)08x edi = 0x%(7)08x ]
+0x00082027 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_IGNORED [ port =
%(1)d eax = 0x%(2)08x ebx = 0x%(3)08x ecx = 0x%(4)08x edx = 0x%(5)08x esi =
0x%(6)08x edi = 0x%(7)08x ]
+0x00082028 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMPORT_QEMU [ eax =
0x%(1)08x ebx = 0x%(2)08x ecx = 0x%(3)08x edx = 0x%(4)08x esi = 0x%(5)08x edi
= 0x%(6)08x ]
0x0010f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_map [ domid
= %(1)d ]
0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap[ domid
= %(1)d ]
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 7684cf0..6a9cfb0 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -206,6 +206,9 @@ void hvm_io_assist(ioreq_t *p)
regs-_edx = vr-edx;
regs-_esi = vr-esi;
regs-_edi = vr-edi;
+HVMTRACE_ND(VMPORT_QEMU, 0, 1/*cycles*/, 6,
+p-data, regs-_ebx, regs-_ecx,
+regs-_edx, regs-_esi, regs-_edi);
}
}
if ( vio-io_size == 4 ) /* Needs zero extension. */
diff --git a/xen/arch/x86/hvm/vmware/vmport.c
b/xen/arch/x86/hvm/vmware/vmport.c
index 36e3f1b..3c3ccd4 100644
--- a/xen/arch/x86/hvm/vmware/vmport.c
+++ b/xen/arch/x86/hvm/vmware/vmport.c
@@ -16,6 +16,7 @@
#include xen/lib.h
#include asm/hvm/hvm.h
#include asm/hvm/support.h
+#include asm/hvm/trace.h
#include backdoor_def.h
@@ -35,6 +36,7 @@ static int vmport_ioport(int dir, uint32_t port, uint32_t
bytes, uint32_t *val)
if ( port == BDOOR_PORT regs-_eax == BDOOR_MAGIC )
{
uint32_t new_eax = ~0u;
+uint16_t cmd = regs-_ecx;
uint64_t value;
struct vcpu *curr = current;
struct domain *currd = curr-domain;
@@ -45,7 +47,7 @@ static int vmport_ioport(int dir, uint32_t port, uint32_t
bytes, uint32_t *val)
* leaving the high 32-bits unchanged, unlike what one would
* expect to happen.
*/
-switch ( regs-_ecx 0x )
+switch ( cmd )
{
case BDOOR_CMD_GETMHZ:
new_eax = currd-arch.tsc_khz / 1000;
@@ -123,11 +125,20 @@ static int vmport_ioport(int dir, uint32_t port,
uint32_t bytes, uint32_t *val)
/* Let backing DM handle */
return X86EMUL_UNHANDLEABLE;
}
+HVMTRACE_ND7(VMPORT_HANDLED, 0, 0/*cycles*/, 7,
+ cmd, new_eax, regs-_ebx, regs-_ecx,
+ regs-_edx, regs-_esi, regs-_edi);
Do you need to log edi as well? It looks like it's not used.
if ( dir == IOREQ_READ )
*val = new_eax;
}
-else if ( dir == IOREQ_READ )
-*val = ~0u;
+else
+{
+HVMTRACE_ND7(VMPORT_IGNORED, 0, 0/*cycles*/, 7,
+ port, regs-_eax, regs-_ebx, regs-_ecx,
+ regs-_edx, regs-_esi, regs-_edi);
And do you need to log all the registers here? It seems like port +
regs-_ecx would be enough to tell you why it got ignored.
+if ( dir == IOREQ_READ )
+
[Xen-devel] [PATCH v2 0/2] restrict the privilege of the xenstore connection
Hi all, this patch series introduces a new command line option to restrict the privilege of the xenstore connection. Used together with -runas, can help secure the execution of QEMU in Dom0. Changes in v2: - remove xenstore_record_dm_state and open code the xenstore write instead - change the xenpv machine xenstore path for startup notification to device-model/$DOMID/pv/state Stefano Stabellini (2): xen: separate the xenstore_record_dm_state calls for pv and hvm machines xen: introduce xsrestrict hw/xenpv/xen_machine_pv.c | 10 ++ include/hw/xen/xen.h |2 ++ qemu-options.hx | 15 +++ vl.c |8 xen-common-stub.c |2 ++ xen-common.c | 29 - xen-hvm.c | 44 7 files changed, 73 insertions(+), 37 deletions(-) Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] clarification of xen Wiki article
On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote: On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote: Unless the author or someone else in the know speaks up I would propose to remove this text from the wiki. +1 for this. Ian, I looked at the history of that page. It looks like it was you who created that page. Since you as the original author doesn't have idea what that sentence means I've removed that sentence. Wei. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] clarification of xen Wiki article
On Thu, Jun 04, 2015 at 12:35:22PM +0100, Ian Campbell wrote: On Thu, 2015-06-04 at 12:31 +0100, Wei Liu wrote: On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote: On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote: Unless the author or someone else in the know speaks up I would propose to remove this text from the wiki. +1 for this. Ian, I looked at the history of that page. It looks like it was you who created that page. No, I imported it from the old wiki, for which wee don't have history (AFAIK). This came from the old wiki, so the history is unclear. was in my reply. Ah, OK. My change can be reverted if it turns out to be problematic. Wei. Since you as the original author doesn't have idea what that sentence means I've removed that sentence. Wei. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 57852: regressions - FAIL
flight 57852 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/57852/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57419 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 57419 test-amd64-i386-libvirt 11 guest-start fail like 57419 test-amd64-i386-libvirt-xsm 11 guest-start fail like 57419 test-amd64-amd64-libvirt 11 guest-start fail like 57419 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 57419 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 57419 test-armhf-armhf-libvirt-xsm 11 guest-start fail like 57419 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57419 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-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-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: xen fed56ba0e69b251d0222ef0785cd1c1838f9e51d baseline version: xen d6b6bd8374ac30597495d457829ce7ad6e8b7016 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Dario Faggioli dario.faggi...@citrix.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Kevin Tian kevin.t...@intel.com Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com Tim Deegan t...@xen.org Vitaly Kuznetsov vkuzn...@redhat.com Yang Hongyang yan...@cn.fujitsu.com 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-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm
[Xen-devel] [PATCH v2 1/2] xen: separate the xenstore_record_dm_state calls for pv and hvm machines
The following patch will introduce a new option to restrict the
privilege of the xenstore connection. In that case, we do not want to
use multiple xenstore connections, but just the one, with lower
privileges.
For this reason, split the xenstore_record_dm_state calls for pv and hvm
machines, so that in the hvm case QEMU will reuse the same xenstore
connection. (At the moment it opens two and uses the second one for the
xenstore_record_dm_state call.)
As the xenstore_record_dm_state is not very useful anymore, just remove
it.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- remove xenstore_record_dm_state and open code the xenstore write
instead
---
hw/xenpv/xen_machine_pv.c | 10 ++
xen-common.c | 29 -
xen-hvm.c |7 +++
3 files changed, 17 insertions(+), 29 deletions(-)
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 2e545d2..68758a0 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -45,6 +45,16 @@ static void xen_init_pv(MachineState *machine)
switch (xen_mode) {
case XEN_ATTACH:
/* nothing to do, xend handles everything */
+{
+char path[50];
+/* record state running */
+snprintf(path, sizeof (path), device-model/%u/state, xen_domid);
+if (!xs_write(xenstore, XBT_NULL, path, running,
strlen(running))) {
+fprintf(stderr, error recording state\n);
+exit(1);
+}
+}
+
break;
case XEN_CREATE:
if (xen_domain_build_pv(kernel_filename, initrd_filename,
diff --git a/xen-common.c b/xen-common.c
index 56359ca..5573c9e 100644
--- a/xen-common.c
+++ b/xen-common.c
@@ -83,33 +83,6 @@ void xenstore_store_pv_console_info(int i, CharDriverState
*chr)
}
}
-
-static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
-{
-char path[50];
-
-if (xs == NULL) {
-fprintf(stderr, xenstore connection not initialized\n);
-exit(1);
-}
-
-snprintf(path, sizeof (path), device-model/%u/state, xen_domid);
-if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
-fprintf(stderr, error recording dm state\n);
-exit(1);
-}
-}
-
-
-static void xen_change_state_handler(void *opaque, int running,
- RunState state)
-{
-if (running) {
-/* record state running */
-xenstore_record_dm_state(xenstore, running);
-}
-}
-
static int xen_init(MachineState *ms)
{
xen_xc = xen_xc_interface_open(0, 0, 0);
@@ -117,8 +90,6 @@ static int xen_init(MachineState *ms)
xen_be_printf(NULL, 0, can't open xen interface\n);
return -1;
}
-qemu_add_vm_change_state_handler(xen_change_state_handler, NULL);
-
return 0;
}
diff --git a/xen-hvm.c b/xen-hvm.c
index 315864c..8079b8e 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1107,7 +1107,14 @@ static void xen_hvm_change_state_handler(void *opaque,
int running,
XenIOState *state = opaque;
if (running) {
+char path[50];
xen_main_loop_prepare(state);
+
+snprintf(path, sizeof (path), device-model/%u/state, xen_domid);
+if (!xs_write(state-xenstore, XBT_NULL, path, running,
strlen(running))) {
+fprintf(stderr, error recording state\n);
+exit(1);
+}
}
xen_set_ioreq_server_state(xen_xc, xen_domid,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] xen: introduce xsrestrict
Introduce a new command line option xenopts, with one boolean
suboption xsrestrict. When xsrestrict=on is passed, QEMU will
restrict the xenstore connection calling xs_restrict. Also it won't
initialize the pv backends as they require higher privileges.
Change the xenpv machine xenstore path for startup notification to
/local/domain/0/device-model/$DOMID/pv/state, so that it doesn't get
confused with the device model path.
It requires a toolstack change to allow it to read/write to
/local/domain/0/device-model/$DOMID, and listen to
/local/domain/0/device-model/$DOMID/pv/state for xenpv machines.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- change the xenpv machine xenstore path for startup notification to
device-model/$DOMID/pv/state.
---
hw/xenpv/xen_machine_pv.c |2 +-
include/hw/xen/xen.h |2 ++
qemu-options.hx | 15 +++
vl.c |8
xen-common-stub.c |2 ++
xen-hvm.c | 37 +
6 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 68758a0..262a8ae 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -48,7 +48,7 @@ static void xen_init_pv(MachineState *machine)
{
char path[50];
/* record state running */
-snprintf(path, sizeof (path), device-model/%u/state, xen_domid);
+snprintf(path, sizeof (path), device-model/%u/pv/state,
xen_domid);
if (!xs_write(xenstore, XBT_NULL, path, running,
strlen(running))) {
fprintf(stderr, error recording state\n);
exit(1);
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index b0ed04c..6e864e0 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -52,4 +52,6 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
# define HVM_MAX_VCPUS 32
#endif
+extern QemuOptsList qemu_xen_opts;
+
#endif /* QEMU_HW_XEN_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index 64af16d..104f138 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3057,6 +3057,21 @@ the guest clock runs ahead of the host clock. Typically
this happens
when the shift value is high (how high depends on the host machine).
ETEXI
+DEF(xenopts, HAS_ARG, QEMU_OPTION_xenopts, \
+-xenopts [xsrestrict=on|off]\n \
+Xen Specific Options\n, QEMU_ARCH_ALL)
+STEXI
+@item -xenopts [xsrestrict=on|off]
+@findex -xenopts
+Options for the Xen hypervisor:
+
+@option{xsrestrict=on} will cause QEMU to restrict its xenstore
+connection to the privilege level of the guest it is serving. This will
+cause QEMU not to initialize the Xen PV backends, as they require an higher
+privilege level.
+ETEXI
+
+
DEF(watchdog, HAS_ARG, QEMU_OPTION_watchdog, \
-watchdog i6300esb|ib700\n \
enable virtual hardware watchdog [default=none]\n,
diff --git a/vl.c b/vl.c
index 81d80ae..acd4eea 100644
--- a/vl.c
+++ b/vl.c
@@ -2815,6 +2815,7 @@ int main(int argc, char **argv, char **envp)
qemu_add_opts(qemu_name_opts);
qemu_add_opts(qemu_numa_opts);
qemu_add_opts(qemu_icount_opts);
+qemu_add_opts(qemu_xen_opts);
runstate_init();
@@ -3666,6 +3667,13 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
break;
+case QEMU_OPTION_xenopts:
+opts = qemu_opts_parse(qemu_find_opts(xenopts),
+ optarg, 0);
+if (!opts) {
+exit(1);
+}
+break;
case QEMU_OPTION_incoming:
incoming = optarg;
runstate_set(RUN_STATE_INMIGRATE);
diff --git a/xen-common-stub.c b/xen-common-stub.c
index 906f991..6792c2c 100644
--- a/xen-common-stub.c
+++ b/xen-common-stub.c
@@ -8,6 +8,8 @@
#include qemu-common.h
#include hw/xen/xen.h
+QemuOptsList qemu_xen_opts = { };
+
void xenstore_store_pv_console_info(int i, CharDriverState *chr)
{
}
diff --git a/xen-hvm.c b/xen-hvm.c
index 8079b8e..30fac46 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -36,6 +36,19 @@
do { } while (0)
#endif
+QemuOptsList qemu_xen_opts = {
+.name = xenopts,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_xen_opts.head),
+.merge_lists = true,
+.desc = {
+{
+.name = xsrestrict,
+.type = QEMU_OPT_BOOL,
+},
+{ /* end of list */ }
+},
+};
+
static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
static MemoryRegion *framebuffer;
static bool xen_in_migration;
@@ -1192,6 +1205,7 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size,
ram_addr_t *above_4g_mem_size,
xen_pfn_t bufioreq_pfn;
evtchn_port_t bufioreq_evtchn;
XenIOState *state;
+QemuOpts *opts;
state = g_malloc0(sizeof (XenIOState));
@@ -1310,16
[Xen-devel] [PATCH v2 5/5] libxl: spawns two QEMUs for HVM guests
Starts a second QEMU to provide PV backends in userspace to HVM guests.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl_create.c | 18 ++
tools/libxl/libxl_dm.c |9 -
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a74b340..925738f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -981,6 +981,15 @@ static void domcreate_console_available(libxl__egc *egc,
dcs-aop_console_how.for_event));
}
+static void qdisk_spawn_outcome(libxl__egc *egc, libxl__dm_spawn_state *dmss,
+int rc)
+{
+STATE_AO_GC(dmss-spawn.ao);
+
+LOG(DEBUG, qdisk backend spawn for domain %u %s, dmss-guest_domid,
+ rc ? failed : succeed);
+}
+
static void domcreate_bootloader_done(libxl__egc *egc,
libxl__bootloader_state *bl,
int rc)
@@ -1016,6 +1025,15 @@ static void domcreate_bootloader_done(libxl__egc *egc,
dcs-dmss.dm.callback = domcreate_devmodel_started;
dcs-dmss.callback = domcreate_devmodel_started;
+if (info-type == LIBXL_DOMAIN_TYPE_HVM) {
+libxl__dm_spawn_state *dmss2;
+GCNEW(dmss2);
+dmss2-guest_domid = domid;
+dmss2-spawn.ao = ao;
+dmss2-callback = qdisk_spawn_outcome;
+libxl__spawn_qdisk_backend(egc, dmss2);
+}
+
if ( restore_fd 0 ) {
rc = libxl__domain_build(gc, d_config, domid, state);
domcreate_rebuild_done(egc, dcs, rc);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 29ef8ae..08087ea 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1835,13 +1835,20 @@ out:
int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
{
+int rc;
char *path = libxl__device_model_xs_path(gc, false, LIBXL_TOOLSTACK_DOMID,
domid, );
if (!xs_rm(CTX-xsh, XBT_NULL, path))
LOG(ERROR, xs_rm failed for %s, path);
+
+kill_device_model(gc,
+GCSPRINTF(libxl/%u/qdisk-backend-pid, domid));
+
/* We should try to destroy the device model anyway. */
-return kill_device_model(gc,
+rc = kill_device_model(gc,
GCSPRINTF(/local/domain/%d/image/device-model-pid, domid));
+
+return rc;
}
int libxl__need_xenpv_qemu(libxl__gc *gc,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/5] libxl: allow /local/domain/0/device-model/$DOMID to be written by $DOMID
The device model is going to restrict its xenstore connection to $DOMID
level. Let it access /local/domain/0/device-model/$DOMID, as it is
required by QEMU to read/write the physmap. It doesn't contain any
information the guest is not already fully aware of.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- fix permissions to actually do what intended
- use LIBXL_TOOLSTACK_DOMID instead of 0
---
tools/libxl/libxl_dm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 79a9a22..f4f104f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1461,6 +1461,7 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
char **pass_stuff;
const char *dm;
int dm_state_fd = -1;
+struct xs_permissions rwperm[2];
if (libxl_defbool_val(b_info-device_model_stubdomain)) {
abort();
@@ -1503,7 +1504,11 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
}
path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid, );
-xs_mkdir(ctx-xsh, XBT_NULL, path);
+rwperm[0].id = LIBXL_TOOLSTACK_DOMID;
+rwperm[0].perms = XS_PERM_NONE;
+rwperm[1].id = domid;
+rwperm[1].perms = XS_PERM_WRITE;
+libxl__xs_mkdir(gc, XBT_NULL, path, rwperm, 2);
if (b_info-type == LIBXL_DOMAIN_TYPE_HVM
b_info-device_model_version
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 4/5] libxl: change xs path for pv qemu
If QEMU is ran just to provide PV backends, change the xenstore path to
/local/domain/0/device-model/$DOMID/pv.
Add a parameter to libxl__device_model_xs_path to distinguish the device
model from the pv backends provider.
Store the device model binary path under
/local/domain/$DOMID/device-model on xenstore, so that we can fetch it
later and retrieve the list of supported options from
/local/domain/0/libxl/$device_model_binary, introduce in the previous
path.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl.c |2 +-
tools/libxl/libxl_device.c |2 +-
tools/libxl/libxl_dm.c | 20
tools/libxl/libxl_dom.c | 12 ++--
tools/libxl/libxl_internal.c | 19 +++
tools/libxl/libxl_internal.h |5 ++---
tools/libxl/libxl_pci.c | 14 +++---
7 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 516713e..bca4c88 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1035,7 +1035,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
if (type == LIBXL_DOMAIN_TYPE_HVM) {
uint32_t dm_domid = libxl_get_stubdom_id(ctx, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, /state);
+path = libxl__device_model_xs_path(gc, false, dm_domid, domid,
/state);
state = libxl__xs_read(gc, XBT_NULL, path);
if (state != NULL !strcmp(state, paused)) {
libxl__qemu_traditional_cmd(gc, domid, continue);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 93bb41e..aadcd08 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1190,7 +1190,7 @@ int libxl__wait_for_device_model_deprecated(libxl__gc *gc,
char *path;
uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, /state);
+path = libxl__device_model_xs_path(gc, false, dm_domid, domid, /state);
return libxl__xenstore_child_wait_deprecated(gc, domid,
LIBXL_DEVICE_MODEL_START_TIMEOUT,
Device Model, path, state, spawning,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b37a84a..29ef8ae 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1267,9 +1267,9 @@ void libxl__spawn_stub_dm(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss)
retry_transaction:
t = xs_transaction_start(ctx-xsh);
xs_mkdir(ctx-xsh, t,
- libxl__device_model_xs_path(gc, dm_domid, guest_domid, ));
+ libxl__device_model_xs_path(gc, false, dm_domid, guest_domid,
));
xs_set_permissions(ctx-xsh, t,
- libxl__device_model_xs_path(gc, dm_domid,
+ libxl__device_model_xs_path(gc, false, dm_domid,
guest_domid, ),
perm, ARRAY_SIZE(perm));
if (!xs_transaction_end(ctx-xsh, t, 0))
@@ -1430,7 +1430,7 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
sdss-xswait.what = GCSPRINTF(Stubdom %u for %u startup,
dm_domid, sdss-dm.guest_domid);
sdss-xswait.path =
-libxl__device_model_xs_path(gc, dm_domid, sdss-dm.guest_domid,
+libxl__device_model_xs_path(gc, true, dm_domid, sdss-dm.guest_domid,
/state);
sdss-xswait.timeout_ms = LIBXL_STUBDOM_START_TIMEOUT * 1000;
sdss-xswait.callback = stubdom_xswait_cb;
@@ -1566,7 +1566,8 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
free(path);
}
-path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid, );
+path = libxl__device_model_xs_path(gc, b_info-type ==
LIBXL_DOMAIN_TYPE_PV,
+ LIBXL_TOOLSTACK_DOMID, domid, );
rwperm[0].id = LIBXL_TOOLSTACK_DOMID;
rwperm[0].perms = XS_PERM_NONE;
rwperm[1].id = domid;
@@ -1595,6 +1596,8 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
const char *dom_path = libxl__xs_get_dompath(gc, domid);
spawn-pidpath = GCSPRINTF(%s/%s, dom_path, image/device-model-pid);
+libxl__xs_write(gc, XBT_NULL, GCSPRINTF(%s/%s, dom_path,
device-model), %s, dm);
+
if (vnc vnc-passwd) {
/* This xenstore key will only be used by qemu-xen-traditionnal.
* The code to supply vncpasswd to qemu-xen is later. */
@@ -1619,8 +1622,9 @@ retry_transaction:
LIBXL__LOG(CTX, XTL_DEBUG, %s, *arg);
spawn-what = GCSPRINTF(domain %d device model, domid);
-spawn-xspath = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
-domid, /state);
+spawn-xspath = libxl__device_model_xs_path(gc,
+b_info-type == LIBXL_DOMAIN_TYPE_PV, LIBXL_TOOLSTACK_DOMID,
+domid,
Re: [Xen-devel] [PATCH v11 8/9] Add IOREQ_TYPE_VMWARE_PORT
On 06/03/15 13:09, George Dunlap wrote:
On 05/22/2015 04:50 PM, Don Slutz wrote:
This adds synchronization of the 6 vcpu registers (only 32bits of
them) that vmport.c needs between Xen and QEMU.
This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
fetch and put these 6 vcpu registers used by the code in vmport.c
and vmmouse.c
In the tools, enable usage of QEMU's vmport code.
The currently most useful VMware port support that QEMU has is the
VMware mouse support. Xorg included a VMware mouse support that
uses absolute mode. This make using a mouse in X11 much nicer.
Signed-off-by: Don Slutz dsl...@verizon.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Sorry for coming a bit late to this party. On a high level I think this
is good, but there doesn't seem to be anything in here in particular
that is vmware-specific. Would it make more sense to give this a more
generic name, and have it include all of the general-purpose registers?
I do not know of a more general case. The code here is very VMware in
(%dx),%eax specific. The x86 architecture does not have an in/out case
where registers other then rax get used and/or changed that need to be
sent to QEMU. There already is code to handle ins better then 1 byte at
a time.
There is also a data size issue. The register data sent over is smaller
then the ioreq data. Therefore the number of vCPUs that are supported
is the the same. Changing the amount of data sent would effect this
(like requiring more then 1 page).
-Don Slutz
-George
---
v11:
No change
v10:
These literals should become an enum.
I don't think the invalidate type is needed.
Code handling case X86EMUL_UNHANDLEABLE: in emulate.c
is unclear.
Comment about special' range of 1 is not clear.
v9:
New code was presented as an RFC before this.
Paul Durrant sugested I add support for other IOREQ types
to HVMOP_map_io_range_to_ioreq_server.
I have done this.
tools/libxc/xc_hvm_build_x86.c | 5 +-
tools/libxl/libxl_dm.c | 2 +
xen/arch/x86/hvm/emulate.c | 78 ++---
xen/arch/x86/hvm/hvm.c | 182
++-
xen/arch/x86/hvm/io.c| 16
xen/include/asm-x86/hvm/domain.h | 3 +-
xen/include/asm-x86/hvm/hvm.h| 1 +
xen/include/public/hvm/hvm_op.h | 5 ++
xen/include/public/hvm/ioreq.h | 17
xen/include/public/hvm/params.h | 4 +-
10 files changed, 274 insertions(+), 39 deletions(-)
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index e45ae4a..ffe52eb 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -46,7 +46,8 @@
#define SPECIALPAGE_IOREQ5
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
-#define NR_SPECIAL_PAGES 8
+#define SPECIALPAGE_VMPORT_REGS 8
+#define NR_SPECIAL_PAGES 9
#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
#define NR_IOREQ_SERVER_PAGES 8
@@ -569,6 +570,8 @@ static int setup_guest(xc_interface *xch,
special_pfn(SPECIALPAGE_BUFIOREQ));
xc_hvm_param_set(xch, dom, HVM_PARAM_IOREQ_PFN,
special_pfn(SPECIALPAGE_IOREQ));
+xc_hvm_param_set(xch, dom, HVM_PARAM_VMPORT_REGS_PFN,
+ special_pfn(SPECIALPAGE_VMPORT_REGS));
xc_hvm_param_set(xch, dom, HVM_PARAM_CONSOLE_PFN,
special_pfn(SPECIALPAGE_CONSOLE));
xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ce08461..b68c651 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -814,6 +814,8 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
machinearg, max_ram_below_4g);
}
}
+if (libxl_defbool_val(c_info-vmware_port))
+machinearg = GCSPRINTF(%s,vmport=on, machinearg);
flexarray_append(dm_args, machinearg);
for (i = 0; b_info-extra_hvm b_info-extra_hvm[i] != NULL; i++)
flexarray_append(dm_args, b_info-extra_hvm[i]);
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d5e6468..0a42d18 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -219,27 +219,70 @@ static int hvmemul_do_io(
vio-io_state = HVMIO_handle_mmio_awaiting_completion;
break;
case X86EMUL_UNHANDLEABLE:
-{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr-domain, p);
-
-/* If there is no suitable backing DM, just ignore accesses */
-if ( !s )
+if ( vmport_check_port(p.addr) )
{
-hvm_complete_assist_req(p);
-rc = X86EMUL_OKAY;
-vio-io_state = HVMIO_none;
+struct hvm_ioreq_server *s =
+
[Xen-devel] [PATCH v2 2/5] libxl: do not add a vkb backend to hvm guests
When QEMU restricts its xenstore connection, it cannot provide PV
backends. A separate QEMU instance is required to provide PV backends in
userspace, such as qdisk. With two separate instances, it is not
possible to take advantage of vkb for mouse and keyboard, as the QEMU
that emulates the graphic card (the device model), would be separate
from the QEMU running the vkb backend (PV QEMU).
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl_create.c |5 -
1 file changed, 5 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f0da7dc..a74b340 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1275,17 +1275,12 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
{
libxl__device_console console;
libxl__device device;
-libxl_device_vkb vkb;
init_console_info(gc, console, 0);
console.backend_domid = state-console_domid;
libxl__device_console_add(gc, domid, console, state, device);
libxl__device_console_dispose(console);
-libxl_device_vkb_init(vkb);
-libxl__device_vkb_add(gc, domid, vkb);
-libxl_device_vkb_dispose(vkb);
-
dcs-dmss.dm.guest_domid = domid;
if (libxl_defbool_val(d_config-b_info.device_model_stubdomain))
libxl__spawn_stub_dm(egc, dcs-dmss);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/5] libxl: xsrestrict QEMU
Check whether QEMU supports the xsrestrict option, by parsing its --help
output. Store the result on xenstore for future reference on a per QEMU
binary basis, so that device_model_override still works fine with it.
Replace / with _ in the QEMU binary path before writing it to xenstore,
so that it doesn't get confused with xenstore paths.
If QEMU support xsrestrict, pass it as a command line option to it.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl_dm.c | 63 ++
tools/libxl/libxl_internal.h |3 ++
tools/libxl/libxl_utils.c| 10 +++
3 files changed, 76 insertions(+)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f4f104f..b37a84a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -446,6 +446,65 @@ retry:
return 0;
}
+int libxl__check_qemu_supported(libxl__gc *gc, const char *dm, char *opt)
+{
+libxl_ctx *ctx = libxl__gc_owner(gc);
+pid_t pid;
+int pipefd[2], status;
+FILE *fp;
+char *buf;
+ssize_t buf_size = 512;
+int ret = 0;
+char *s;
+
+s = libxl__strdup(gc, dm);
+libxl__replace_chr(gc, s, '/', '_');
+s = libxl__sprintf(gc, libxl/%s/%s, s, opt);
+buf = libxl__xs_read(gc, XBT_NULL, s);
+if (buf != NULL)
+return !strcmp(buf, 1);
+
+if (access(dm, X_OK) 0) {
+LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+ device model %s is not executable, dm);
+return ERROR_FAIL;
+}
+
+if (libxl_pipe(ctx, pipefd) 0)
+return ERROR_FAIL;
+
+pid = fork();
+if (pid 0)
+return ERROR_FAIL;
+
+/* child spawn QEMU */
+if (!pid) {
+char *args[] = {(char*)dm, --help, NULL};
+close(pipefd[0]);
+libxl__exec(gc, -1, pipefd[1], pipefd[1], dm, args, NULL);
+exit(1);
+}
+
+/* father parses the output */
+close(pipefd[1]);
+fp = fdopen(pipefd[0], r);
+buf = libxl__malloc(gc, buf_size);
+while (fgets(buf, buf_size, fp) != NULL) {
+if (strstr(buf, opt) != NULL) {
+ret = 1;
+goto out;
+}
+}
+out:
+close(pipefd[0]);
+waitpid(pid, status, pid);
+libxl_report_child_exitstatus(ctx, XTL_WARN, dm, pid, status);
+
+ret = libxl__xs_write(gc, XBT_NULL, s, %d, ret);
+
+return ret;
+}
+
static char ** libxl__build_device_model_args_new(libxl__gc *gc,
const char *dm, int guest_domid,
const libxl_domain_config
*guest_config,
@@ -931,6 +990,10 @@ end_search:
if (user) {
flexarray_append(dm_args, -runas);
flexarray_append(dm_args, user);
+if (libxl__check_qemu_supported(gc, dm, xsrestrict)) {
+flexarray_append(dm_args, -xenopts);
+flexarray_append(dm_args, xsrestrict=on);
+}
}
}
flexarray_append(dm_args, NULL);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7d0af40..b11297b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1505,6 +1505,7 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
int nr_vfbs, libxl_device_vfb *vfbs,
int nr_disks, libxl_device_disk *disks,
int nr_channels, libxl_device_channel *channels);
+_hidden int libxl__check_qemu_supported(libxl__gc *gc, const char *dm, char
*opt);
/*
* This function will cause the whole libxl process to hang
@@ -3554,6 +3555,8 @@ int libxl__string_parse_json(libxl__gc *gc, const
libxl__json_object *o,
char **p);
int libxl__random_bytes(libxl__gc *gc, uint8_t *buf, size_t len);
+/* replace all occurrences of old with new inside s */
+void libxl__replace_chr(libxl__gc *gc, char *s, char old, char new);
/*
* Compile time assertion
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67c0b1c..ea08473 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -1158,6 +1158,16 @@ int libxl__random_bytes(libxl__gc *gc, uint8_t *buf,
size_t len)
return ret;
}
+void libxl__replace_chr(libxl__gc *gc, char *s, char old, char new)
+{
+ int i = 0;
+
+ for (i = 0; s[i] != '\0'; i++) {
+ if (s[i] == old)
+ s[i] = new;
+ }
+}
+
/*
* Local variables:
* mode: C
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] clarification of xen Wiki article
On Thu, 2015-06-04 at 12:31 +0100, Wei Liu wrote: On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote: On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote: Unless the author or someone else in the know speaks up I would propose to remove this text from the wiki. +1 for this. Ian, I looked at the history of that page. It looks like it was you who created that page. No, I imported it from the old wiki, for which wee don't have history (AFAIK). This came from the old wiki, so the history is unclear. was in my reply. Since you as the original author doesn't have idea what that sentence means I've removed that sentence. Wei. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 57853: regressions - FAIL
flight 57853 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 57788 REGR. vs. 57312 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 3 host-install(3) broken in 57490 pass in 57853 test-armhf-armhf-xl-cubietruck 3 host-install(3) broken in 57490 pass in 57853 test-armhf-armhf-xl 3 host-install(3) broken in 57490 pass in 57853 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 18 guest-start/win.repeat fail in 57713 pass in 57853 test-amd64-i386-libvirt 11 guest-start fail pass in 57490 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 57490 test-armhf-armhf-xl-sedf-pin 6 xen-bootfail pass in 57713 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 57788 test-amd64-amd64-xl-qemut-win7-amd64 9 windows-install fail pass in 57788 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-xsm 3 host-install(3) broken in 57490 like 57312 test-armhf-armhf-xl-credit2 3 host-install(3) broken in 57490 like 57312 test-armhf-armhf-xl-sedf 6 xen-boot fail REGR. vs. 57312 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail blocked in 57312 test-armhf-armhf-xl-multivcpu 17 leak-check/checkfail blocked in 57312 test-armhf-armhf-libvirt 11 guest-start fail blocked in 57312 test-armhf-armhf-xl-xsm 6 xen-boot fail blocked in 57312 test-amd64-amd64-xl-pvh-intel 11 guest-start fail in 57490 like 57312 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 12 migrate-support-check fail in 57490 never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-check fail in 57490 never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 57788 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 13 guest-saverestorefail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-amd64-i386-libvirt-xsm 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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: linux51af817611f2c0987030d024f24fc7ea95dd33e6 baseline version: linuxb2776bf7149bddd1f4161f14f79520f17fc1d71d 900 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
Razvan Cojocaru rcojoc...@bitdefender.com 06/04/15 3:46 PM On 06/04/2015 04:43 PM, Tim Deegan wrote: At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), Razvan Cojocaru wrote: As suggested by Andrew Cooper, this patch attempts to remove some redundancy and allow for an easier time when adding vm_events for new control registers in the future, by having a single VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0, CR3, CR4 and (newly introduced) XCR0. The actual control register will be deduced by the new .index field in vm_event_write_ctrlreg (renamed from vm_event_mov_to_cr). The patch has also modified the xen-access.c test - it is now able to log CR3 events. Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Of course, if Jan (who originally proposed the macro) doesn't have any objections, I'll rename it. While I personally think it's better the way it is now, I don't object to it being renamed, even less so considering that Tim is the maintainer of that code and hence should have the final say. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
On 06/03/15 12:58, George Dunlap wrote: On 06/03/2015 05:41 PM, Don Slutz wrote: On 06/03/15 12:23, George Dunlap wrote: On 06/03/2015 04:58 PM, Andrew Cooper wrote: On 03/06/15 16:26, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: Summary is that VMware treats in (%dx),%eax (or out %eax,(%dx)) to port 0x5658 specially. Note: since many operations return data in EAX, in (%dx),%eax is the one to use. The other lengths like in (%dx),%al will still do things, only AL part of EAX will be changed. For out %eax,(%dx) of all lengths, EAX will remain unchanged. This instruction is allowed to be used from ring 3. To support this the vmexit for GP needs to be enabled. I have not fully tested that nested HVM is doing the right thing for this. Enable no-fault of pio in x86_emulate for VMware port Also adjust the emulation registers after doing a VMware backdoor operation. Add new routine hvm_emulate_one_gp() to be used by the #GP fault handler. Some of the best info is at: https://sites.google.com/site/chitchatvmback/backdoor Signed-off-by: Don Slutz dsl...@verizon.com So let me get this straight. VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which always return an error. Is that about right? That sounds completely insane. It opens up an almost infinite surface of attack onto the Xen emulator. I understand that having the VMWare compatible is a nice tick-box to have, but seriously, I cannot imagine that having unprivileged user-space tools know the real clock frequency without having to involve the OS is anywhere close to worth the risk involved. The attack surface sadly is not enlarged in the slightest by this change. We already trap and emulate all #UD exceptions in an attempt to support migration of VMs between Intel and AMD hardware. See XSA-105. (There is a good argument to be made for not trapping #UD, but that doesn't completely close the hole) So at the moment, an attacker on Intel can force the emulation of any AMD-only instruction (and vice versa), is that right? This would allow an attacker to force the emulation of every #GP condition of every instruction we emulate. Those two sets may be within an order of magnitude of each other, but they will only overlap a little bit. So my guess is that enabling this would double the surface of attack (give or take). I'd be a lot happier with this patch if we could make it so that on a #GP the only instruction that could get emulated would be an IO instruction. You mean like I said in: Message-ID: 54c67d83027800059...@mail.emea.novell.com Yes, pretty much exactly. I didn't notice that particular part of the discussion, but I did go back and skim the comments that people had made on previous revisions, and I certainly noticed that both Jan and Andy reviewed this patch, and that neither one objected to the general idea. So my That sounds insane was as much directed at them as at you. (As an aside, I think my description does a better job of alerting a reviewer to what's going on in this patch -- you might consider stealing part of it if you end up re-submitting this one.) I would be happy to steal the description part. I normally give credit to the author in the what has changed. I could also add to the commit message: George Dunlap summarized this change as: VMWare allows ring3 to access the magic port regardless of whether the guest OS has enabled access to that IO port or not. In order to emulate this, we need to: * Trap to Xen on #GPs rather than just letting the hardware handle it * Emulate all instructions which cause a #GP, just to see if they might be an IO instruction accessing the magic port. * If it is an IO instruction, and it's accessing the magic port, then we skip the ioport access checks (which will cause the instruction to execute as though it had been given access). * Under all other circumstances (we hope) the emulator in Xen will do exactly what the hardware just did, and deliver a #GP to the guest. In an attempt to make this more safe, emulation ops that write (such as write and cmpxchg) are replaced with stubs which always return an error. -Don Slutz -George
Re: [Xen-devel] [PATCH v2 1/2] net/xen-netfront: Correct printf format in xennet_get_responses
On 04/06/15 13:45, Julien Grall wrote:
On 03/06/15 18:06, Joe Perches wrote:
On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
rx-status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
[]
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
[]
@@ -733,7 +733,7 @@ static int xennet_get_responses(struct netfront_queue
*queue,
if (unlikely(rx-status 0 ||
rx-offset + rx-status PAGE_SIZE)) {
if (net_ratelimit())
- dev_warn(dev, rx-offset: %x, size: %u\n,
+ dev_warn(dev, rx-offset: %x, size: %d\n,
If you're going to do this, perhaps it'd be sensible to
also change the %x to %#x or 0x%x so that people don't
mistake offset without an [a-f] for decimal.
Good idea. I will resend a version of this series.
David, can I keep you Reviewed-by for this change?#
Can you make the offset %d instead?
You can keep the reviewed-by if you do this.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] net/xen-netfront: Correct printf format in xennet_get_responses
On 04/06/15 13:46, David Vrabel wrote:
On 04/06/15 13:45, Julien Grall wrote:
On 03/06/15 18:06, Joe Perches wrote:
On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
rx-status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
[]
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
[]
@@ -733,7 +733,7 @@ static int xennet_get_responses(struct netfront_queue
*queue,
if (unlikely(rx-status 0 ||
rx-offset + rx-status PAGE_SIZE)) {
if (net_ratelimit())
- dev_warn(dev, rx-offset: %x, size: %u\n,
+ dev_warn(dev, rx-offset: %x, size: %d\n,
If you're going to do this, perhaps it'd be sensible to
also change the %x to %#x or 0x%x so that people don't
mistake offset without an [a-f] for decimal.
Good idea. I will resend a version of this series.
David, can I keep you Reviewed-by for this change?#
Can you make the offset %d instead?
Sure.
You can keep the reviewed-by if you do this.
Thank you.
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
