Re: [Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

[Hao, Xudong]

+Wei

Thanks,
-Xudong


> -Original Message-
> From: Zhang, PengtaoX
> Sent: Friday, May 27, 2016 1:07 PM
> To: Xen-devel 
> Cc: Hao, Xudong ; Zhang, Haozhong
> 
> Subject: [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to
> inject MSR"
> 
> Bug detailed description:
> 
> On haswell-ex and boardwell-ex  server, testing the xen's LLC, MEM, UCNA,
> show error message:"Failed to inject MSR: Invalid argument".
> 
> Environment :
> 
> HW: haswell-ex/boardwell-ex
> Xen: Xen 4.7.0 RC3
> Dom0: Linux 4.6.0
> 
> Reproduce steps:
> 
> 1.Compiling  xen-mceinj in xen : xen/tools/tests/mce-test/tools 2.Run the
> commond:  xen/tools/tests/mce-test/tools/xen-mceinj -t 0
> 
> Current result:
> 
> For step2 show error messages:
> get gaddr of error inject is: 0x180020
> Failed to inject MSR: Invalid argument
> 
> Base error log:
> 
> Xen 4.7 RC3 and Xen RC1 log are same attached rc1 log .
> Console log:
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0x5
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41d <--
> 0xbd208a
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41f <-- 0x86
> 
> 
> Regards,
> Pengtao

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 94808: regressions - FAIL

[osstest service owner]

flight 94808 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94808/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
94743

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94743
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 94743
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94743
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu84cfc756d158a061bd462473d42b0a9f072218de
baseline version:
 qemuu287db79df8af8e31f18e262feb5e05103a09e4d4

Last test of basis94743  2016-05-24 16:40:55 Z2 days
Failing since 94795  2016-05-26 12:49:04 Z0 days2 attempts
Testing same since94808  2016-05-26 22:18:23 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Alexey Kardashevskiy 
  Amit Shah 
  Andreas Färber 
  Andreas Färber 
  Daniel P. Berrange 
  Eric Blake 
  Gerd Hoffmann 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  Max Filippov 
  Max Reitz 
  Paolo Bonzini 
  Peter Maydell 
  Sergey Fedorov 
  Sergey Fedorov 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass

Re: [Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

[Zhang, Haozhong]

On 05/27/16 13:07, Zhang, PengtaoX wrote:
> Bug detailed description:
> 
> On haswell-ex and boardwell-ex  server, testing the xen's LLC, MEM, UCNA, 
> show error message:"Failed to inject MSR: Invalid argument".
> 
> Environment :
> 
> HW: haswell-ex/boardwell-ex 
> Xen: Xen 4.7.0 RC3
> Dom0: Linux 4.6.0
> 
> Reproduce steps:
> 
> 1.Compiling  xen-mceinj in xen : xen/tools/tests/mce-test/tools 
> 2.Run the commond:  xen/tools/tests/mce-test/tools/xen-mceinj -t 0
> 
> Current result:
> 
> For step2 show error messages: 
> get gaddr of error inject is: 0x180020
> Failed to inject MSR: Invalid argument
> 
> Base error log:
> 
> Xen 4.7 RC3 and Xen RC1 log are same attached rc1 log .
> Console log:
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0x5
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41d <-- 
> 0xbd208a
> (XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41f <-- 0x86

Hi Pengtao,

I'll send a v2 patch of 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02534.html
which will fix this bug.

Thanks,
Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

[Peng Fan]

To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate
first level page table, if there is a big chunk memory (ie, >512GB).

So, need to make sure boot pages are ready before setup xenheap mappings.

Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---
 xen/arch/arm/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dcb23b7..24cf9d3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -641,8 +641,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_start = min(ram_start,bank_start);
 ram_end = max(ram_end,bank_end);
 
-setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
-
 s = bank_start;
 while ( s < bank_end )
 {
@@ -663,6 +661,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 dt_unreserved_regions(s, e, init_boot_pages, 0);
 s = n;
 }
+
+setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
 }
 
 total_pages += ram_size >> PAGE_SHIFT;
-- 
2.6.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen/arm: setup: fix typo

[Peng Fan]

Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv

Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---
 xen/arch/arm/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 09ff1ea..dcb23b7 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -185,7 +185,7 @@ void dt_unreserved_regions(paddr_t s, paddr_t e,
 /* If we can't read it, pretend it doesn't exist... */
 continue;
 
-r_e += r_s; /* fdt_get_mem_rsc returns length */
+r_e += r_s; /* fdt_get_mem_rsv returns length */
 
 if ( s < r_e && r_s < e )
 {
-- 
2.6.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94814: trouble: blocked/broken

[osstest service owner]

flight 94814 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94814/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   65 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

[Zhang, PengtaoX]

Bug detailed description:

On haswell-ex and boardwell-ex  server, testing the xen's LLC, MEM, UCNA, show 
error message:"Failed to inject MSR: Invalid argument".

Environment :

HW: haswell-ex/boardwell-ex 
Xen: Xen 4.7.0 RC3
Dom0: Linux 4.6.0

Reproduce steps:

1.Compiling  xen-mceinj in xen : xen/tools/tests/mce-test/tools 
2.Run the commond:  xen/tools/tests/mce-test/tools/xen-mceinj -t 0

Current result:

For step2 show error messages: 
get gaddr of error inject is: 0x180020
Failed to inject MSR: Invalid argument

Base error log:

Xen 4.7 RC3 and Xen RC1 log are same attached rc1 log .
Console log:
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0x5
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41d <-- 0xbd208a
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41f <-- 0x86


Regards,
Pengtao
[root@hsw-ex1 tools]# xl lis
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  409632 r-   3.3
test_guest 633  4096 1 -b  10.6
[root@hsw-ex1 tools]# pwd
/root/fengjuan/xen/tools/tests/mce-test/tools
[root@hsw-ex1 tools]# ./xen-mceinj -t 1
get gaddr of error inject is: 0x180020
Failed to inject MSR: Invalid argument

Putty output
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0x5
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x421 <-- 0xbd400f
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x423 <-- 0x86
[root@hsw-ex1 tools]# xl lis
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  409632 r-   0.6
test_guest 633  4096 1 -b  10.6
[root@hsw-ex1 tools]# pwd
/root/fengjuan/xen/tools/tests/mce-test/tools
[root@hsw-ex1 tools]# ./xen-mceinj -t 0
get gaddr of error inject is: 0x180020
Failed to inject MSR: Invalid argument

Putty output:
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0x5
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41d <-- 0xbd208a
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x41f <-- 0x86
[root@hsw-ex1 tools]# xl lis
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  409632 r-   4.5
test_guest 633  4096 1 -b  10.7
[root@hsw-ex1 tools]# pwd
/root/fengjuan/xen/tools/tests/mce-test/tools
[root@hsw-ex1 tools]# ./xen-mceinj -t 2
get gaddr of error inject is: 0x180020
Failed to inject MSR: Invalid argument
[root@hsw-ex1 tools]# 


Putty output:
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x17a <-- 0
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x425 <-- 
0xbc208136
(XEN) HV MSR INJECT (interpose) target 0 actual 0 MSR 0x427 <-- 0x86


xen4.7_rc1-xen-mce_llc_hpervisor.log
Description: xen4.7_rc1-xen-mce_llc_hpervisor.log


xen4.7_rc1-xen-mce_mem_hpervisor.log
Description: xen4.7_rc1-xen-mce_mem_hpervisor.log


xen4.7_rc1-xen-mce_ucna_hpervisor.log
Description: xen4.7_rc1-xen-mce_ucna_hpervisor.log
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 94802: regressions - FAIL

[osstest service owner]

flight 94802 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94802/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 94789

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94789
 build-amd64-rumpuserxen   6 xen-buildfail   like 94789
 build-i386-rumpuserxen6 xen-buildfail   like 94789
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94789
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94789
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94789
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94789
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94789

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f5610009529628314c9d1d52b00715fe855fcf06
baseline version:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33

Last test of basis94789  2016-05-26 09:35:03 Z0 days
Testing same since94802  2016-05-26 19:43:08 Z0 days1 attempts


People who touched revisions under test:
  Chao Peng 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

[Zheng, Lv]

Hi,

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Friday, May 27, 2016 12:56 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
> bit width support
> 
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
>  Boris Ostrovsky  05/25/16 9:17
> PM >>>
> >> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> >>> +static u8
> >>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
> max_bit_width)
> >>> +{
> >>> +u64 address;
> >>> +
> >>> +if (!reg->access_width) {
> >>> +/*
> >>> + * Detect old register descriptors where only the bit_width field
> >>> + * makes senses. The target address is copied to handle possible
> >>> + * alignment issues.
> >>> + */
> >>> +ACPI_MOVE_64_TO_64(, >address);
> >>> +if (!reg->bit_offset && reg->bit_width &&
> >>> +ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
> >>> +ACPI_IS_ALIGNED(reg->bit_width, 8) &&
> >>> +ACPI_IS_ALIGNED(address, reg->bit_width)) {
> >>> +return (reg->bit_width);
> >>> +} else {
> >>> +if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
> >>> +return (32);
> >> This (together with "... Add access_width/bit_offset support in
> >> acpi_hw_write") breaks Xen guests using older QEMU which doesn't
> support
> >> 4-byte IO accesses.
> >>
> >> Why not return "reg->bit_width?:max_bit_width" ? This will preserve
> >> original behavior.
> > Did you figure out why we get here in the first place, instead of taking
> the
> > first "return"? I.e. isn't the issue the apparently wrong use of the second
> > ACPI_IS_ALIGNED() above? Afaict it ought to be
> > ACPI_IS_ALIGNED(address, reg->bit_width / 8)...
> 
> We are trying to access address 0x...b004 (PM1a control) so yes, fixing
> alignment check would probably resolve the problem that we are seeing
> now.
> 
> However, for compatibility purposes we may consider not doing any
> checks
> and simply return bit_width if access_width is not available.
[Lv Zheng] 

There might be GAS defined with AccessWidth = 0.
And its BitOffset can still make senses.
That's why I put the check here, making it a tuning rather than a regression 
safe check.

Thanks for the information, I'll submit the fix of the address check.
To convert it to:
ACPI_IS_ALIGNED(address, reg->bit_width / 8)
This is my fault.

Thanks
-Lv

> 
> -boris
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky
> Sent: Thursday, May 26, 2016 3:17 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit
> width support
> 
> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> > ACPICA commit c49a751b4dae7baec1790748a2b4b6e8ab599f51
> >
> > For Access Size = 0, it actually can use user expected access bit width.
> > This patch implements this.
> >
> > Besides of the ACPICA upstream commit, this patch also includes a fix fixing
> > the issue reported by the FreeBSD community.
> > The old register descriptors are translated in 
> > acpi_tb_init_generic_address()
> > with access_width being filled with 0. This breaks code in
> > acpi_hw_get_access_bit_width() when the registers are 16-bit IO ports and
> their
> > bit_width fields are filled with 16. The rapid fix is meant to make code
> > written for acpi_hw_get_access_bit_width() regression safer before the issue
> is
> > correctly fixed from acpi_tb_init_generic_address(). Reported by
> > John Baldwin , fixed by Lv Zheng ,
> tested
> > by Jung-uk Kim .
> >
> > Link: https://github.com/acpica/acpica/commit/c49a751b
> > Reported-by: John Baldwin 
> > Tested-by Jung-uk Kim .
> > Signed-off-by: Lv Zheng 
> > Signed-off-by: Bob Moore 
> > ---
> >  drivers/acpi/acpica/hwregs.c |   49
> --
> >  1 file changed, 47 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
> > index 035fb52..892e677 100644
> > --- a/drivers/acpi/acpica/hwregs.c
> > +++ b/drivers/acpi/acpica/hwregs.c
> > @@ -51,6 +51,10 @@ ACPI_MODULE_NAME("hwregs")
> >
> >  #if (!ACPI_REDUCED_HARDWARE)
> >  /* Local Prototypes */
> > +static u8
> > +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg,
> > +u8 max_bit_width);
> > +
> >  static acpi_status
> >  acpi_hw_read_multiple(u32 *value,
> >   struct acpi_generic_address *register_a,
> > @@ -65,6 +69,48 @@ acpi_hw_write_multiple(u32 value,
> >
> >
> /***
> ***
> >   *
> > + * FUNCTION:acpi_hw_get_access_bit_width
> > + *
> > + * PARAMETERS:  reg - GAS register structure
> > + *  max_bit_width   - Max bit_width supported (32 or 64)
> > + *
> > + * RETURN:  Status
> > + *
> > + * DESCRIPTION: Obtain optimal access bit width
> > + *
> > +
> 
> **/
> > +
> > +static u8
> > +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
> max_bit_width)
> > +{
> > +   u64 address;
> > +
> > +   if (!reg->access_width) {
> > +   /*
> > +* Detect old register descriptors where only the bit_width 
> > field
> > +* makes senses. The target address is copied to handle
> possible
> > +* alignment issues.
> > +*/
> > +   ACPI_MOVE_64_TO_64(, >address);
> > +   if (!reg->bit_offset && reg->bit_width &&
> > +   ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
> > +   ACPI_IS_ALIGNED(reg->bit_width, 8) &&
> > +   ACPI_IS_ALIGNED(address, reg->bit_width)) {
> > +   return (reg->bit_width);
> > +   } else {
> > +   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
> > +   return (32);
> 
> This (together with "... Add access_width/bit_offset support in
> acpi_hw_write") breaks Xen guests using older QEMU which doesn't support
> 4-byte IO accesses.
> 
> Why not return "reg->bit_width?:max_bit_width" ? This will preserve
> original behavior.
[Lv Zheng] 

Let me ask 2 questions:

A. Was this a bug of the older qemu?
If so, you only need a quirk mechanism for old qemu to work.
And it would be better to provide the quirk inside of the older qemu.

B. Could you provide the detailed register description?
The case I saw from the freebsd community around the qemu is a bit_width = 16 
case.
Which is a conversion result of acpi_tb_init_generic_address().
Thus:
1. reg->access_width is always 0
2. reg->bit_offset is always 0
3. reg->bit_width is either 8 or 16
So they can be covered by this check:
if (reg->access_width) {
if (!reg->bit_offset && reg->bit_width &&
ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
ACPI_IS_ALIGNED(reg->bit_width, 8))
I just enhanced it with the address check: ACPI_IS_ALIGNED(address, 
reg->bit_width)

For your case, what the values of "address/access_width" are?
Can it be fixed by:
1. Either removing ACPI_IS_ALIGNED(address, reg->bit_width), or
2. moving the entire check out of if (!reg->access_width) to form:
if (!reg->bit_offset && reg->bit_width &&
ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
 

[Xen-devel] How about use different "max_grant_frames" for different domains?

[Dongli Zhang]

Hi,

Because the boosting CPU and memory resources on server, Xen users are allowed
and actually do create lots of vdisk and vnic, e.g., 6 vnic, 20 vdisk and 24
vcpu (the number of vnic queue is proportional to the number of vcpu assigned
to guest), and this requires the administrator to increase the value of
"max_grant_frames" by changing cmdline param or DEFAULT_MAX_NR_GRANT_FRAMES in
Xen hypervisor.  Currently, all Xen guests share the same "max_grant_frames" in
Xen hypervisor, that is, if we increase the grant frame because of one VM, all
other VMs' grant frame limit will increase as well. 

Therefore, please let me know if using an individual "max_grant_frames" instead
of a global variable is reasonable? How about if we relocate this variable to
"struct grant_table" or "struct domain"?

This would require changes in both xen hypervisor and xen tools, e.g.,
1. A new "do_grant_table_op cmd" or "do_domctl cmd" to allow Dom0 to increase
the grant frame number for a specific domain. Dom0 would be able to use this
interface to change the grant frame number for VM initially in
"libxl__build_pre" and libxc or later via new xl command.
2. Change in xen tools "parse_config_data()" to allow administrator to add new
param to vm.cfg, e.g, "max_nr_frame=128".
3. This also requires a lot of changes in xen hypervisor so that all refers to
global "max_grant_frames" should redirect to domain specific variable (e.g.,
domain->max_grant_frames) now.

Please let me know the feedback. If this is reasonable, I will work on patches.

Thank you very much!

Dongli Zhang



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Lan Tianyu]

On 2016年05月26日 16:42, Dong, Eddie wrote:
> If enabling virtual Q35 solves the problem, it has the advantage: When more 
> and more virtual IOMMU feature comes (likely), we can reuse the KVM code for 
> Xen.
> How big is the effort for virtual Q35?

I think the most effort are to rebuild all ACPI tables for Q35 and add
Q35 support in the hvmloader. My concern is about new ACPI tables'
compatibility issue. Especially with Windows guest.

-- 
Best regards
Tianyu Lan

> 
> Thx Eddie
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94806: trouble: blocked/broken

[osstest service owner]

flight 94806 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94806/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   64 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

[Shanker Donthineni]

Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
Dom0 dynamically) causing dead loop inside the spinlock function.
Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
that has already held by calling CPU leads to deadlock. This happens
whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.

The following call trace explains the problem.

DOM0 writes GICD_ISENABLER/GICD_ICENABLER
  vgic_v3_distr_common_mmio_write()
vgic_lock_rank()  -->  acquiring first time
  vgic_enable_irqs()
route_irq_to_guest()
  gic_route_irq_to_guest()
vgic_get_target_vcpu()
  vgic_lock_rank()  -->  attemping acquired lock

The simple fix release spinlock before calling vgic_enable_irqs()
and vgic_disable_irqs().

Signed-off-by: Shanker Donthineni 
---
 xen/arch/arm/vgic-v2.c | 10 +++---
 xen/arch/arm/vgic-v3.c | 10 +++---
 xen/arch/arm/vgic.c|  4 ++--
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 9adb4a9..44cd834 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -415,7 +415,7 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 struct hsr_dabt dabt = info->dabt;
 struct vgic_irq_rank *rank;
 int gicd_reg = (int)(info->gpa - v->domain->arch.vgic.dbase);
-uint32_t tr;
+uint32_t tr, index;
 unsigned long flags;
 
 perfc_incr(vgicd_writes);
@@ -457,8 +457,10 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 vgic_lock_rank(v, rank, flags);
 tr = rank->ienable;
 vgic_reg32_setbits(>ienable, r, info);
-vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index);
+index = rank->index;
+tr = rank->ienable & (~tr);
 vgic_unlock_rank(v, rank, flags);
+vgic_enable_irqs(v, tr, index);
 return 1;
 
 case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
@@ -468,8 +470,10 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 vgic_lock_rank(v, rank, flags);
 tr = rank->ienable;
 vgic_reg32_clearbits(>ienable, r, info);
-vgic_disable_irqs(v, (~rank->ienable) & tr, rank->index);
+index = rank->index;
+tr = (~rank->ienable) & tr;
 vgic_unlock_rank(v, rank, flags);
+vgic_disable_irqs(v, tr, index);
 return 1;
 
 case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b37a7c0..e04e180 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -568,7 +568,7 @@ static int __vgic_v3_distr_common_mmio_write(const char 
*name, struct vcpu *v,
 {
 struct hsr_dabt dabt = info->dabt;
 struct vgic_irq_rank *rank;
-uint32_t tr;
+uint32_t tr, index;
 unsigned long flags;
 
 switch ( reg )
@@ -584,8 +584,10 @@ static int __vgic_v3_distr_common_mmio_write(const char 
*name, struct vcpu *v,
 vgic_lock_rank(v, rank, flags);
 tr = rank->ienable;
 vgic_reg32_setbits(>ienable, r, info);
-vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index);
+index = rank->index;
+tr = rank->ienable & (~tr);
 vgic_unlock_rank(v, rank, flags);
+vgic_enable_irqs(v, tr, index);
 return 1;
 
 case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
@@ -595,8 +597,10 @@ static int __vgic_v3_distr_common_mmio_write(const char 
*name, struct vcpu *v,
 vgic_lock_rank(v, rank, flags);
 tr = rank->ienable;
 vgic_reg32_clearbits(>ienable, r, info);
-vgic_disable_irqs(v, (~rank->ienable) & tr, rank->index);
+index = rank->index;
+tr = (~rank->ienable) & tr;
 vgic_unlock_rank(v, rank, flags);
+vgic_disable_irqs(v, tr, index);
 return 1;
 
 case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index aa420bb..82758d2 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -322,7 +322,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 
 while ( (i = find_next_bit(, 32, i)) < 32 ) {
 irq = i + (32 * n);
-v_target = __vgic_get_target_vcpu(v, irq);
+v_target = vgic_get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
 gic_remove_from_queues(v_target, irq);
@@ -377,7 +377,7 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 gprintk(XENLOG_ERR, "Unable to route IRQ %u to domain %u\n",
 irq, d->domain_id);
 }
-v_target = __vgic_get_target_vcpu(v, irq);
+v_target = vgic_get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, >status);
 spin_lock_irqsave(_target->arch.vgic.lock, flags);
-- 
Qualcomm Technologies, Inc. on behalf of 

[Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

[Shanker Donthineni]

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.

Signed-off-by: Shanker Donthineni 
---
https://silver.arm.com/download/download.tm?pv=2950177
 xen/drivers/char/pl011.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 1212d5c..81d095f 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -226,14 +226,14 @@ static struct uart_driver __read_mostly pl011_driver = {
 .vuart_info   = pl011_vuart,
 };
 
-static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+static int __init pl011_uart_init(int irq, u64 addr, u64 size, int baud)
 {
 struct pl011 *uart;
 
 uart = _com;
 uart->irq   = irq;
 uart->clock_hz  = 0x16e3600;
-uart->baud  = BAUD_AUTO;
+uart->baud  = baud;
 uart->data_bits = 8;
 uart->parity= PARITY_NONE;
 uart->stop_bits = 1;
@@ -285,7 +285,7 @@ static int __init pl011_dt_uart_init(struct dt_device_node 
*dev,
 return -EINVAL;
 }
 
-res = pl011_uart_init(res, addr, size);
+res = pl011_uart_init(res, addr, size, BAUD_AUTO);
 if ( res < 0 )
 {
 printk("pl011: Unable to initialize\n");
@@ -315,6 +315,7 @@ static int __init pl011_acpi_uart_init(const void *data)
 {
 acpi_status status;
 struct acpi_table_spcr *spcr = NULL;
+int baud = BAUD_AUTO;
 int res;
 
 status = acpi_get_table(ACPI_SIG_SPCR, 0,
@@ -326,17 +327,23 @@ static int __init pl011_acpi_uart_init(const void *data)
 return -EINVAL;
 }
 
+if ( (spcr->interface_type == ACPI_DBG2_SBSA_32) ||
+ (spcr->interface_type == ACPI_DBG2_SBSA) )
+baud = 115200;
+
 /* trigger/polarity information is not available in spcr */
 irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
 
 res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
-  PAGE_SIZE);
+  PAGE_SIZE, baud);
 if ( res < 0 )
 {
 printk("pl011: Unable to initialize\n");
 return res;
 }
 
+
+
 return 0;
 }
 
@@ -344,6 +351,16 @@ ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
 .class_type = ACPI_DBG2_PL011,
 .init = pl011_acpi_uart_init,
 ACPI_DEVICE_END
+
+ACPI_DEVICE_START(asbsa_uart, "SBSA UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_SBSA,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
+
+ACPI_DEVICE_START(asbsa32_uart, "SBSA32 UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_SBSA_32,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
 #endif
 
 /*
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94796: regressions - FAIL

[osstest service owner]

flight 94796 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94796/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf db827286e2839102c5b0a45f88a99b8ef94c6d48
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z2 days
Failing since 94750  2016-05-25 03:43:08 Z1 days6 attempts
Testing same since94796  2016-05-26 13:13:36 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Gary Lin 
  Hao Wu 
  Jiaxin Wu 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Michael Zimmermann 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 408 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

[Shanker Donthineni]

The current driver probe fails on hardware which has GICv4 version,
even though it is fully compatible to GICv3. This patch fixes the
issue by registering the same probe function for GICv4 hardware.

Signed-off-by: Shanker Donthineni 
---
 xen/arch/arm/gic-v3.c | 13 +
 xen/include/asm-arm/gic.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..594cf6e 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void *data)
 return 0;
 }
 
+static int __init gicv4_acpi_preinit(const void *data)
+{
+gicv3_info.hw_version = GIC_V4;
+register_gic_ops(_ops);
+
+return 0;
+}
+
 ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
 .class_type = ACPI_MADT_GIC_VERSION_V3,
 .init = gicv3_acpi_preinit,
 ACPI_DEVICE_END
+
+ACPI_DEVICE_START(agicv4, "GICv4", DEVICE_GIC)
+.class_type = ACPI_MADT_GIC_VERSION_V4,
+.init = gicv4_acpi_preinit,
+ACPI_DEVICE_END
 #endif
 
 /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index cd97bb2..5be814a 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -218,6 +218,7 @@ struct gic_lr {
 enum gic_version {
 GIC_V2,
 GIC_V3,
+GIC_V4,
 };
 
 extern enum gic_version gic_hw_version(void);
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-unstable test] 94800: tolerable FAIL - PUSHED

[osstest service owner]

flight 94800 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94800/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start.2 fail REGR. vs. 94765

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu44a072f0de0d57c95c2212bbce0232b7b74f
baseline version:
 qemuuc2092c20d6ad5e26375ec680c504fe584ae5d4b5

Last test of basis94765  2016-05-25 13:11:16 Z1 days
Testing same since94800  2016-05-26 17:40:42 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm  

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

[Boris Ostrovsky]

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote:
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky  05/25/16 9:17 PM >>>
>>> On 05/05/2016 12:58 AM, Lv Zheng wrote:
 +static u8
 +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 
 max_bit_width)
 +{
 +u64 address;
 +
 +if (!reg->access_width) {
 +/*
 + * Detect old register descriptors where only the bit_width field
 + * makes senses. The target address is copied to handle possible
 + * alignment issues.
 + */
 +ACPI_MOVE_64_TO_64(, >address);
 +if (!reg->bit_offset && reg->bit_width &&
 +ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
 +ACPI_IS_ALIGNED(reg->bit_width, 8) &&
 +ACPI_IS_ALIGNED(address, reg->bit_width)) {
 +return (reg->bit_width);
 +} else {
 +if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
 +return (32);
>>> This (together with "... Add access_width/bit_offset support in
>>> acpi_hw_write") breaks Xen guests using older QEMU which doesn't support
>>> 4-byte IO accesses.
>>>
>>> Why not return "reg->bit_width?:max_bit_width" ? This will preserve
>>> original behavior.
>> Did you figure out why we get here in the first place, instead of taking the
>> first "return"? I.e. isn't the issue the apparently wrong use of the second
>> ACPI_IS_ALIGNED() above? Afaict it ought to be
>> ACPI_IS_ALIGNED(address, reg->bit_width / 8)...
> We are trying to access address 0x...b004 (PM1a control) so yes, fixing
> alignment check would probably resolve the problem that we are seeing now.
>
> However, for compatibility purposes we may consider not doing any checks
> and simply return bit_width if access_width is not available.


Interestingly enough I bisected what I thought was a completely
different problem to this patch as well.

Something is messed up with 32-bit dom0 booting (so no QEMU) on one
machine in my pool.  First error that I see is
pcieport :00:02.0: can't find IRQ for PCI INT A; probably buggy
MP table

I'll look at this tomorrow, hopefully.

-boris





___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 94795: regressions - FAIL

[osstest service owner]

flight 94795 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94795/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  15 guest-start.2 fail REGR. vs. 94743

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94743
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94743
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu0533d3de606a74f1b3030e9ecc8f9f2d9b7cb463
baseline version:
 qemuu287db79df8af8e31f18e262feb5e05103a09e4d4

Last test of basis94743  2016-05-24 16:40:55 Z2 days
Testing same since94795  2016-05-26 12:49:04 Z0 days1 attempts


People who touched revisions under test:
  Andreas Färber 
  Andreas Färber 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 

[Xen-devel] [qemu-upstream-4.3-testing test] 94801: trouble: blocked/broken

[osstest service owner]

flight 94801 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94801/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   63 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-unstable test] 94789: tolerable FAIL

[osstest service owner]

flight 94789 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94789/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot   fail in 94780 pass in 94789
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
pass in 94780

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail blocked in 94780
 build-amd64-rumpuserxen   6 xen-buildfail   like 94780
 build-i386-rumpuserxen6 xen-buildfail   like 94780
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94780
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94780
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94780
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94780

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33
baseline version:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33

Last test of basis94789  2016-05-26 09:35:03 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16947 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern  

[Xen-devel] [xen-unstable-smoke test] 94799: tolerable all pass - PUSHED

[osstest service owner]

flight 94799 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94799/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f5610009529628314c9d1d52b00715fe855fcf06
baseline version:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33

Last test of basis94774  2016-05-25 20:02:25 Z0 days
Testing same since94799  2016-05-26 17:01:17 Z0 days1 attempts


People who touched revisions under test:
  Chao Peng 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f5610009529628314c9d1d52b00715fe855fcf06
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f5610009529628314c9d1d52b00715fe855fcf06
+ branch=xen-unstable-smoke
+ revision=f5610009529628314c9d1d52b00715fe855fcf06
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xf5610009529628314c9d1d52b00715fe855fcf06 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} 

[Xen-devel] [qemu-upstream-4.3-testing test] 94797: trouble: blocked/broken

[osstest service owner]

flight 94797 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94797/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   62 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] balloon_mutex lockdep complaint at HVM domain destroy

[Ed Swierk]

On Wed, May 25, 2016 at 9:58 AM, David Vrabel  wrote:
> This occurs in dom0?  Or the guest that's being destroyed?

The lockdep warning comes from dom0 when the HVM guest is being destroyed.

> It's a bug but...
>
>> ==
>> [ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ]
>> 4.4.11-grsec #1 Not tainted
>   
> ...this isn't a vanilla kernel?  Can you try vanilla 4.6?

I tried vanilla 4.4.11, and get the same result. I'm having trouble
booting 4.6.0 at all--must be another regression in the early xen boot
code.

> Because:
>
>>IN-RECLAIM_FS-W at:
>>[<__lock_acquire at lockdep.c:2839>] 810becc5
>>[] 810c0ac9
>>[] 816d1b4c
>>[] 
>> 8143c3d4
>>[] 8143c450
>>[<__mmu_notifier_invalidate_page at 
>> mmu_notifier.c:183>] 8119de42
>>[] 
>> 811840c2
>>[] 81185051
>>[] 81185497
>>[] 811599b7
>>[] 
>> 8115a489
>>[] 8115af3a
>>[] 8115b1bb
>>[] 8115c1e4
>>[] 8108eccc
>>[] 816d706e
>
> We should not be reclaiming pages from a gntdev VMA since it's special
> (marked as VM_IO).

Can you suggest any printks for me to add that might help isolate the issue?

--Ed

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

[Dario Faggioli]

Hi Feng,

On Thu, 2016-05-26 at 21:39 +0800, Feng Wu wrote:
> Feng Wu (4):
>   VMX: Properly handle pi when all the assigned devices are removed
>   VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
>   VMX: Assign the right value to 'NDST' field in a concern case
>   VMX: fixup PI descritpor when cpu is offline
> 
I need some time to carefully look at this series, and I don't have
such amount of time right now. I'll try to look at it and send my
comments either tomorrow or on Monday.

However, allow me to just say that, from a quick glance, the various
solutions does not look really convincing to me. Basically, you've
added:
 - a couple of flags (pi_blocking_cleaned_up, down)
 - a new spinlock (pi_hotplug_lock)

And yet, neither the various changelogs, nor code comments explain much
about what the lock serializes and protects, and/or what the flags
represent ad how they should be used.

So, if you want try argumenting a bit on what was your line of
reasoning when doing things this way, that would be helpful (at least
to me).

I'm also non-convinced that, in patch 4, the right thing to do is to
just to pick-up a random online pCPU. At some point, during v1 review,
I mentioned arch_move_irqs(), because it seemed to me the place from
where you actually have the proper information available (i.e., where
the vcpu is actually going, e.g. because the pCPU is on is going
away!). It may well be the case that I'm wrong about it being suitable,
and I'll look better at what you actually have implemented, but at a
first glance, it looks cumbersome.

For instance, now arch_vcpu_block() returns a value and, as you say
yourself in a comment, that is for (potentially) preventing a vcpu to
block. So the behavior of schedule.c:vcpu_block(), now depends on your
new flag per_cpu(vmx_pi_blocking, v->processor).down. Again, I'll look
better, but this has few chances of being right (at least logically).

Finally, you're calling *per-vCPU* things foo_hotplug_bar, which is
rather confusing, as it makes one thinking that they're related to
*pCPU* hotplug.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R 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 v2 08/13] ACPICA: Hardware: Add optimized access bit width support

[Boris Ostrovsky]

On 05/26/2016 12:26 PM, Jan Beulich wrote:
 Boris Ostrovsky  05/25/16 9:17 PM >>>
>> On 05/05/2016 12:58 AM, Lv Zheng wrote:
>>> +static u8
>>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 
>>> max_bit_width)
>>> +{
>>> +u64 address;
>>> +
>>> +if (!reg->access_width) {
>>> +/*
>>> + * Detect old register descriptors where only the bit_width field
>>> + * makes senses. The target address is copied to handle possible
>>> + * alignment issues.
>>> + */
>>> +ACPI_MOVE_64_TO_64(, >address);
>>> +if (!reg->bit_offset && reg->bit_width &&
>>> +ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
>>> +ACPI_IS_ALIGNED(reg->bit_width, 8) &&
>>> +ACPI_IS_ALIGNED(address, reg->bit_width)) {
>>> +return (reg->bit_width);
>>> +} else {
>>> +if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
>>> +return (32);
>> This (together with "... Add access_width/bit_offset support in
>> acpi_hw_write") breaks Xen guests using older QEMU which doesn't support
>> 4-byte IO accesses.
>>
>> Why not return "reg->bit_width?:max_bit_width" ? This will preserve
>> original behavior.
> Did you figure out why we get here in the first place, instead of taking the
> first "return"? I.e. isn't the issue the apparently wrong use of the second
> ACPI_IS_ALIGNED() above? Afaict it ought to be
> ACPI_IS_ALIGNED(address, reg->bit_width / 8)...

We are trying to access address 0x...b004 (PM1a control) so yes, fixing
alignment check would probably resolve the problem that we are seeing now.

However, for compatibility purposes we may consider not doing any checks
and simply return bit_width if access_width is not available.

-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[Anthony PERARD]

On Thu, May 26, 2016 at 05:10:52PM +0100, Anthony PERARD wrote:
> On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote:
> > From: Ian Jackson 
> > 
> > Each time round the main loop, we now fstat stderr.  If it is too big,
> > we dup2 /dev/null onto it.  This is not a very pretty patch but it is
> > very simple, easy to see that it's correct, and has a low risk of
> > collateral damage.
> > 
> > The limit is 1Mby by default but can be adjusted by setting a new
> > environment variable.
> > 
> > This fixes CVE-2014-3672.
> > 
> > Signed-off-by: Ian Jackson 
> > Tested-by: Ian Jackson 
> > 
> > Set the default to 0 so that it won't affect non-xen installation. The
> > limit will be set by Xen toolstack.
> > 
> > Signed-off-by: Wei Liu 
> 
> Beside the confusing commit message and the call in the WIN32 specific
> mainloop, the patch look good. So,
> 
> Acked-by: Anthony PERARD 

I have ajusted the commit message with
`s/The limit is 1Mby/There is no limit/` and going to push to staging.

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

[Jan Beulich]

>>> Boris Ostrovsky  05/25/16 9:17 PM >>>
>On 05/05/2016 12:58 AM, Lv Zheng wrote:
>> +static u8
>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 
>> max_bit_width)
>> +{
>> +u64 address;
>> +
>> +if (!reg->access_width) {
>> +/*
>> + * Detect old register descriptors where only the bit_width field
>> + * makes senses. The target address is copied to handle possible
>> + * alignment issues.
>> + */
>> +ACPI_MOVE_64_TO_64(, >address);
>> +if (!reg->bit_offset && reg->bit_width &&
>> +ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
>> +ACPI_IS_ALIGNED(reg->bit_width, 8) &&
>> +ACPI_IS_ALIGNED(address, reg->bit_width)) {
>> +return (reg->bit_width);
>> +} else {
>> +if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
>> +return (32);
>
>This (together with "... Add access_width/bit_offset support in
>acpi_hw_write") breaks Xen guests using older QEMU which doesn't support
>4-byte IO accesses.
>
>Why not return "reg->bit_width?:max_bit_width" ? This will preserve
>original behavior.

Did you figure out why we get here in the first place, instead of taking the
first "return"? I.e. isn't the issue the apparently wrong use of the second
ACPI_IS_ALIGNED() above? Afaict it ought to be
ACPI_IS_ALIGNED(address, reg->bit_width / 8)...

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

[Xu, Quan]

On Thursday, May 26, 2016 11:57 PM, Jan Beulich  wrote:
> >>> "Xu, Quan"  05/26/16 12:38 PM >>>
> >On May 25, 2016 4:30 PM, Jan Beulich  wrote:
> >> The patch getting too large is easy to deal with: Split it at a
> >> reasonable boundary.
> >I recall your suggestion: top one first, then low level one..
> >I am better not to make this patch as a first one, as this is really a low 
> >level
> one.
> >Then, I need to change condition from 'if ( !rc )'  to ' if ( rc < 0 )'
> >in my series. (but if this series would be merged together, I don't need to
> think about it.) Does it make sense?
> 
> I'm afraid I'm lacking context.

when the propagation value is positive, this patch fixes this flush issue
as follows:
  - call iommu_flush_write_buffer() to flush cache.
  - return zero.

So the condition can be 'if( rc )' for error, but if this patch is not a first 
one in series,
I need to change condition from 'if ( rc )'  to ' if ( rc < 0 )'.. as the 
propagation value may be positive..

Quan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

[Tamas K Lengyel]

On May 26, 2016 04:40, "George Dunlap"  wrote:
>
> On 26/05/16 04:55, Tamas K Lengyel wrote:
> > Move sharing locks above altp2m to avoid locking order violation. Allow
> > applying altp2m mem_access settings when the hostp2m entries are shared.
> > Also, do not trigger PoD for hostp2m when setting altp2m mem_access to
be
> > in-line with non-altp2m mem_access path. Also allow gfn remapping with
> > p2m_ram_shared type gfns in altp2m views.
> >
> > When using mem_sharing in combination with altp2m, unsharing events
overwrite
> > altp2m entries with that of the hostp2m (both remapped entries and
mem_access
> > settings). User should take precaution to not share pages where this
behavior
> > is undesired.
>
> I'm afraid this is not acceptable.  How could this ever be even remotely
> usable?  If this is a necessary side effect of sharing, then I think the
> original functionality, of un-sharing when setting an altp2m entry is
> the only option (and not allowing sharing to happen when an altp2m is
> present for a particular gfn).
>
> Hmm, but actually this also brings up another tricky point: In an altp2m
> you can change the mfn which backs a gfn.  This would need to be handled
> properly in the reverse map, which it doesn't look like it is at the
moment.
>
> On the whole, I think if you're going to allow a single gfn to be
> simultaneously shared and allow an altp2m for it, you're going to need
> to do a lot more work.
>
> (Sorry for not catching a lot of this before...)
>

Well this patch resolves the locking order violation and allows the
xen-access tool's altp2m tests to pass, so it does improve on the current
situation which is a hypervisor crash. To help with the override issue the
user can apply W mem_access permission on the shared hostp2m entries. That
way they get notification through vm_event of the event that leads to
unsharing and can then reapply the altp2m changes. So IMHO this patch is
already quite workable and while it requires more setup from the userside,
the VMM side is OK with this change.

Tamas

>
> >
> > Signed-off-by: Tamas K Lengyel 
> > ---
> > Cc: George Dunlap 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> >
> > v4: Resolve locking problem by moving sharing locks above altp2m locks
> > ---
> >  xen/arch/x86/mm/mm-locks.h | 30 +++---
> >  xen/arch/x86/mm/p2m.c  | 10 +-
> >  2 files changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
> > index 086c8bb..74fdfc1 100644
> > --- a/xen/arch/x86/mm/mm-locks.h
> > +++ b/xen/arch/x86/mm/mm-locks.h
> > @@ -242,6 +242,21 @@ declare_mm_lock(nestedp2m)
> >
> >  declare_mm_rwlock(p2m);
> >
> > +/* Sharing per page lock
> > + *
> > + * This is an external lock, not represented by an mm_lock_t. The
memory
> > + * sharing lock uses it to protect addition and removal of (gfn,domain)
> > + * tuples to a shared page. We enforce order here against the p2m lock,
> > + * which is taken after the page_lock to change the gfn's p2m entry.
> > + *
> > + * The lock is recursive because during share we lock two pages. */
> > +
> > +declare_mm_order_constraint(per_page_sharing)
> > +#define page_sharing_mm_pre_lock()
 mm_enforce_order_lock_pre_per_page_sharing()
> > +#define page_sharing_mm_post_lock(l, r) \
> > +mm_enforce_order_lock_post_per_page_sharing((l), (r))
> > +#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
> > +
> >  /* Alternate P2M list lock (per-domain)
> >   *
> >   * A per-domain lock that protects the list of alternate p2m's.
> > @@ -287,21 +302,6 @@ declare_mm_rwlock(altp2m);
> >  #define p2m_locked_by_me(p)   mm_write_locked_by_me(&(p)->lock)
> >  #define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
> >
> > -/* Sharing per page lock
> > - *
> > - * This is an external lock, not represented by an mm_lock_t. The
memory
> > - * sharing lock uses it to protect addition and removal of (gfn,domain)
> > - * tuples to a shared page. We enforce order here against the p2m lock,
> > - * which is taken after the page_lock to change the gfn's p2m entry.
> > - *
> > - * The lock is recursive because during share we lock two pages. */
> > -
> > -declare_mm_order_constraint(per_page_sharing)
> > -#define page_sharing_mm_pre_lock()
 mm_enforce_order_lock_pre_per_page_sharing()
> > -#define page_sharing_mm_post_lock(l, r) \
> > -mm_enforce_order_lock_post_per_page_sharing((l), (r))
> > -#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
> > -
> >  /* PoD lock (per-p2m-table)
> >   *
> >   * Protects private PoD data structs: entry and cache
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index 9b19769..dc97082 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1768,10 +1768,10 @@ int p2m_set_altp2m_mem_access(struct domain *d,
struct 

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

[Dario Faggioli]

On Thu, 2016-05-26 at 13:03 +, Wu, Feng wrote:
> > On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> > > 
> > > The patch fixing this issue has already been sent to upstream.
> > > 
> > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> > > blocking list "
> > > 
> > > v2 will be sent out soon.
> > > 
> > I just went through that thread. There are some open questions.
> > Also Jan
> > requested that you explore other possible options.
> > 
> > My current plan is to not block the release for this -- we're very
> > close
> > to the anticipated release date, and posted-interrupt is either
> > technical preview or experimental, so bugs there are expected.
> > 
> > This issue will be listed as a known issue for PI. And you can
> > continue
> > to develop a fix for it. Your fix will be integrated with next
> > version
> > of Xen. Then you can request for backport to 4.7 if you want to.
> > 
> > What do you think about this plan?
> I am going to send out the next version of this series, let's see how
> it is going on. But basically, I am fine with your release plan.
> 
This does not have anything to do with Wei's plan (with which I also
agree), but are you sure that the bug being reported here is related to
and would be fixed by the patch you're mentioning?

Have you also seen it, and is that what led to the patch? If yes,
please, add a bit more information (including excerpts of, or insights
about the splat) in the patch changelog.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R 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] Question about the usage of spinlock

[Dario Faggioli]

On Thu, 2016-05-26 at 10:30 +0900, 조현권 wrote:
> Hi
>
Hi,

> I am studying xen 4.6.0 version now and wonder the usage of spinlock
> which is located in free_heap_pages(xen/common/page_alloc. c)
> As its memory setup is ahead of multicore initialization, spinlock
> seems to be unnecessary during booting because it uses only single
> core
> spinlock looks required after multicore initialization finished and
> when xen needs to free memory space during work
>
I'm not sure I understand the point you're trying to make.

It's probably true that using spinlock is pointless before we actually
have more than 1 CPU up and running.

However, free_heap_pages() is called by other fucntions that are not
necessarily only used during boot. For instance, it's called
by free_domheap_pages(), which in its turn is called from functions
that are used outside from the init path, when we are already SMP.

> However i experimented not to use spin lock in free_heap_pages and
> dom0(linux-kernel) was booted well. It does not cause any error using
> internet or application program even reboot
>
That does not prove much, especially if you haven't actually tried
using multiple guest or, in general, causing an actual concurrent
execution of free_heap_pages().

However, even if you manage to construct a scenario where that happens,
and things works, that also won't mean much, as the fact that in one
particular case inconsistency due to races does not happen (or does not
manifest), does not mean it can't happen, or it's not there already.

All this, of course, provided I understood your question, which is
something I'm not sure about.

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R 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 QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[Anthony PERARD]

On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote:
> From: Ian Jackson 
> 
> Each time round the main loop, we now fstat stderr.  If it is too big,
> we dup2 /dev/null onto it.  This is not a very pretty patch but it is
> very simple, easy to see that it's correct, and has a low risk of
> collateral damage.
> 
> The limit is 1Mby by default but can be adjusted by setting a new
> environment variable.
> 
> This fixes CVE-2014-3672.
> 
> Signed-off-by: Ian Jackson 
> Tested-by: Ian Jackson 
> 
> Set the default to 0 so that it won't affect non-xen installation. The
> limit will be set by Xen toolstack.
> 
> Signed-off-by: Wei Liu 

Beside the confusing commit message and the call in the WIN32 specific
mainloop, the patch look good. So,

Acked-by: Anthony PERARD 

> ---
>  main-loop.c | 48 
>  1 file changed, 48 insertions(+)
> 
> diff --git a/main-loop.c b/main-loop.c
> index 3997043..aa32f5b 100644
> --- a/main-loop.c
> +++ b/main-loop.c
> @@ -164,6 +164,50 @@ int qemu_init_main_loop(Error **errp)
>  return 0;
>  }
>  
> +static void check_cve_2014_3672_xen(void)
> +{
> +static unsigned long limit = ~0UL;
> +const int fd = 2;
> +struct stat stab;
> +
> +if (limit == ~0UL) {
> +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
> +/* XEN_QEMU_CONSOLE_LIMIT=0 means no limit */
> +limit = s ? strtoul(s,0,0) : 0;
> +}
> +if (limit == 0)
> +return;
> +
> +int r = fstat(fd, );
> +if (r) {
> +perror("fstat stderr (for CVE-2014-3672 check)");
> +exit(-1);
> +}
> +if (!S_ISREG(stab.st_mode))
> +return;
> +if (stab.st_size <= limit)
> +return;
> +
> +/* oh dear */
> +fprintf(stderr,"\r\n"
> +"Closing stderr due to CVE-2014-3672 limit. "
> +" Set XEN_QEMU_CONSOLE_LIMIT to number of bytes to override,"
> +" or 0 for no limit.\n");
> +fflush(stderr);
> +
> +int nfd = open("/dev/null", O_WRONLY);
> +if (nfd < 0) {
> +perror("open /dev/null (for CVE-2014-3672 check)");
> +exit(-1);
> +}
> +r = dup2(nfd, fd);
> +if (r != fd) {
> +perror("dup2 /dev/null (for CVE-2014-3672 check)");
> +exit(-1);
> +}
> +close(nfd);
> +}
> +
>  static int max_priority;
>  
>  #ifndef _WIN32
> @@ -216,6 +260,8 @@ static int os_host_main_loop_wait(int64_t timeout)
>  int ret;
>  static int spin_counter;
>  
> +check_cve_2014_3672_xen();
> +
>  glib_pollfds_fill();
>  
>  /* If the I/O thread is very busy or we are incorrectly busy waiting in
> @@ -407,6 +453,8 @@ static int os_host_main_loop_wait(int64_t timeout)
>  fd_set rfds, wfds, xfds;
>  int nfds;
>  
> +check_cve_2014_3672_xen();
> +

That's the call within an #ifdef _WIN32.

>  /* XXX: need to suppress polling by better using win32 events */
>  ret = 0;
>  for (pe = first_polling_entry; pe != NULL; pe = pe->next) {

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[Wei Liu]

On Thu, May 26, 2016 at 04:36:57PM +0100, George Dunlap wrote:
> On Thu, May 26, 2016 at 4:21 PM, Wei Liu  wrote:
> > From: Ian Jackson 
> >
> > Each time round the main loop, we now fstat stderr.  If it is too big,
> > we dup2 /dev/null onto it.  This is not a very pretty patch but it is
> > very simple, easy to see that it's correct, and has a low risk of
> > collateral damage.
> >
> > The limit is 1Mby by default but can be adjusted by setting a new
> > environment variable.
> 
> There is no limit by default; a companion patch for libxl sets this to
> 1MiB.  This is so that this patch may be applied on a system qemu
> which is shared between multiple use cases (including non-Xen cases).
> 

I added a paragraph in that patch and have my S-o-B.

Did you miss that? Or do you mean I should rewrite the commit message
altogether?

Wei.

>  -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

[Jan Beulich]

>>> "Xu, Quan"  05/26/16 12:38 PM >>>
>On May 25, 2016 4:30 PM, Jan Beulich  wrote:
>> The patch getting too large is easy to deal with: Split it at a reasonable
>> boundary.
>
>If I follow the below rule, I need to merge most of patches into this one. I 
>can't find a reasonable boundary.

As before, boundaries are pretty easy to set: Just change one function at a 
time,
or when two or a few are very closely related, do the changes together. But try 
to
avoid changing ones in the same patch that call each other (unless of course
there's some sort of recursion).

But yes, as you say in the other reply, a big patch may not be a problem as
long as it remains reasonably understandable (e.g. many small hunks are
usually fine, but a single or a few hunks changing dozens or even hundreds
of lines in one go are usually hard to review).

>I recall your suggestion: top one first, then low level one..
>I am better not to make this patch as a first one, as this is really a low 
>level one.
>Then, I need to change condition from 'if ( !rc )'  to ' if ( rc < 0 )' in my 
>series. (but if this series would be merged together, I don't need to think 
>about it.)
>Does it make sense?

I'm afraid I'm lacking context.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[George Dunlap]

On Thu, May 26, 2016 at 4:21 PM, Wei Liu  wrote:
> From: Ian Jackson 
>
> Each time round the main loop, we now fstat stderr.  If it is too big,
> we dup2 /dev/null onto it.  This is not a very pretty patch but it is
> very simple, easy to see that it's correct, and has a low risk of
> collateral damage.
>
> The limit is 1Mby by default but can be adjusted by setting a new
> environment variable.

There is no limit by default; a companion patch for libxl sets this to
1MiB.  This is so that this patch may be applied on a system qemu
which is shared between multiple use cases (including non-Xen cases).

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

[Wei Liu]

On Thu, May 26, 2016 at 04:47:59PM +0100, Wei Liu wrote:
> On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for 
> > QEMU"):
> > > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> > > explicitly set the limit in libxl for 4.7.
> > ...
> > > +unsigned long limit = 0;
> > > +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
> > > +
> > > +limit = s ? strtoul(s,0,0) : 1*1024*1024;
> > > +flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT",
> > > +  GCSPRINTF("%lu", limit));
> > 
> > This is rather more complex than it needs to be.  What would be wrong
> > with
> >   if (getenv("XEN_QEMU_CONSOLE_LIMIT")) return;
> >   flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT", "1048576");
> > ?
> > 
> 
> Nice, this is simpler. I will use this version and keep your ack.
> 

I will push this patch soon.

---8<---
From 1d915bc7805bde9fe90341e9bcea01bf50154d87 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 26 May 2016 16:11:42 +0100
Subject: [PATCH] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
explicitly set the limit in libxl for 4.7.

Introduce a function for setting the environment variable and call it in
the right places.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_dm.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 6bbc7c3..155a653 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -365,6 +365,20 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
 return ERROR_FAIL;
 }
 
+/* XSA-180 / CVE-2014-3672
+ *
+ * The QEMU shipped with Xen has a bodge. It checks for
+ * XEN_QEMU_CONSOLE_LIMIT to see how much data QEMU is allowed
+ * to write to stderr. We set that to 1MB if it is not set by
+ * system administrator.
+ */
+static void libxl__set_qemu_env_for_xsa_180(libxl__gc *gc,
+flexarray_t *dm_envs)
+{
+if (getenv("XEN_QEMU_CONSOLE_LIMIT")) return;
+flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT", "1048576");
+}
+
 const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
 {
 const libxl_vnc_info *vnc = NULL;
@@ -415,6 +429,8 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
 dm_args = flexarray_make(gc, 16, 1);
 dm_envs = flexarray_make(gc, 16, 1);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+
 flexarray_vappend(dm_args, dm,
   "-d", GCSPRINTF("%d", domid), NULL);
 
@@ -913,6 +929,8 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
 dm_args = flexarray_make(gc, 16, 1);
 dm_envs = flexarray_make(gc, 16, 1);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+
 flexarray_vappend(dm_args, dm,
   "-xen-domid",
   GCSPRINTF("%d", guest_domid), NULL);
@@ -2193,8 +2211,8 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 void libxl__spawn_qdisk_backend(libxl__egc *egc, libxl__dm_spawn_state *dmss)
 {
 STATE_AO_GC(dmss->spawn.ao);
-flexarray_t *dm_args;
-char **args;
+flexarray_t *dm_args, *dm_envs;
+char **args, **envs;
 const char *dm;
 int logfile_w, null = -1, rc;
 uint32_t domid = dmss->guest_domid;
@@ -2203,6 +2221,8 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 dm = qemu_xen_path(gc);
 
 dm_args = flexarray_make(gc, 15, 1);
+dm_envs = flexarray_make(gc, 1, 1);
+
 flexarray_vappend(dm_args, dm, "-xen-domid",
   GCSPRINTF("%d", domid), NULL);
 flexarray_append(dm_args, "-xen-attach");
@@ -2216,6 +2236,9 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 flexarray_append(dm_args, NULL);
 args = (char **) flexarray_contents(dm_args);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+envs = (char **) flexarray_contents(dm_envs);
+
 logfile_w = libxl__create_qemu_logfile(gc, GCSPRINTF("qdisk-%u", domid));
 if (logfile_w < 0) {
 rc = logfile_w;
@@ -2253,7 +2276,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 goto out;
 if (!rc) { /* inner child */
 setsid();
-libxl__exec(gc, null, logfile_w, logfile_w, dm, args, NULL);
+libxl__exec(gc, null, logfile_w, logfile_w, dm, args, envs);
 }
 
 rc = 0;
-- 
2.1.4



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"):
> XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> explicitly set the limit in libxl for 4.7.
...
> +unsigned long limit = 0;
> +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
> +
> +limit = s ? strtoul(s,0,0) : 1*1024*1024;
> +flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT",
> +  GCSPRINTF("%lu", limit));

This is rather more complex than it needs to be.  What would be wrong
with
  if (getenv("XEN_QEMU_CONSOLE_LIMIT")) return;
  flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT", "1048576");
?

But I guess I don't object enough to care, so

Acked-by: Ian Jackson 


> +flexarray_t *dm_args, *dm_envs;
> +char **args, **envs;

All these parts are a bit of a palaver but I don't see a better way.
Thanks for doing this work!

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[Ian Jackson]

Wei Liu writes ("[PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk 
DoS in Xen setups"):
> The limit is 1Mby by default but can be adjusted by setting a new
> environment variable.
> 
> This fixes CVE-2014-3672.
> 
> Signed-off-by: Ian Jackson 
> Tested-by: Ian Jackson 
> 
> Set the default to 0 so that it won't affect non-xen installation. The
> limit will be set by Xen toolstack.

Maybe the commit message, earlier, could be adjusted ?  But otherwise

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/3] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

[Jan Beulich]

>>> Suravee Suthikulanit  05/25/16 9:01 PM >>>
>On 5/23/2016 6:54 AM, Jan Beulich wrote:
> On 22.05.16 at 01:42,  wrote:
>>> From: Suravee Suthikulpanit 
>>>
>>> The guest_iommu_init() is currently called by the following code path:
>>>
>>> arch/x86/domain.c: arch_domain_create()
>>>   ]- drivers/passthrough/iommu.c: iommu_domain_init()
>>> |- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
>>>   |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()
>>>
>>> At this point, the hvm_domain_initialised() has not been called.
>>> So register_mmio_handler() in guest_iommu_init() silently fails.
>>> This patch moves the iommu_domain_init() to a later point after the
>>> hvm_domain_intialise() instead.
>>
>> That's one possible approach, which I continue to be not really
>> happy with. guest_iommu_init() really is HVM-specific, so maybe
>> no longer calling it from amd_iommu_domain_init() would be the
>> better solution (instead calling it from hvm_domain_initialise()
>> would then seem to be the better option). Thoughts?
>
>Then, this goes back to the approach I proposed in the v1 of this patch 
>series, where I call guest_iommu_init/destroy() in the 
>svm_domain_initialise/destroy().
>
>However, I'm still not quite clear in why the iommu_domain_init() is 
>needed before hvm_domain_initialise().

I think the two things are only lightly related. Changing the order of calls is
generally fine, but recognizing that guest_iommu_init() really would better be
called elsewhere makes that re-ordering simply unnecessary.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Jan Beulich]

>>> "Xu, Quan"  05/26/16 3:42 AM >>>
>On May 26, 2016 12:02 AM, Jan Beulich  wrote:
>> >>> On 25.05.16 at 17:34,  wrote:
>> > On May 23, 2016 10:19 PM, Jan Beulich  wrote:
>> >> >>> On 18.05.16 at 10:08,  wrote:
>> >> > +unsigned long type,
>> >> > +int preemptible)
>> >> >  {
>> >> >  unsigned long nx, x, y = page->u.inuse.type_info;
>> >> > -int rc = 0;
>> >> > +int rc = 0, ret = 0;
>> >> >
>> >> >  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
>> >> >
>> >> > @@ -2578,11 +2579,11 @@ static int __get_page_type(struct page_info
>> >> *page, unsigned long type,
>> >> >  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
>> >> >  {
>> >> >  if ( (x & PGT_type_mask) == PGT_writable_page )
>> >> > -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
>> >> > +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
>> >> > + page_to_mfn(page)));
>> >> >  else if ( type == PGT_writable_page )
>> >> > -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
>> >> > -   page_to_mfn(page),
>> >> > -   IOMMUF_readable|IOMMUF_writable);
>> >> > +ret = iommu_map_page(d, mfn_to_gmfn(d, 
>> >> > page_to_mfn(page)),
>> >> > + page_to_mfn(page),
>> >> > +
>> >> > + IOMMUF_readable|IOMMUF_writable);
>> >> >  }
>> >> >  }
>> >> >
>> >> > @@ -2599,6 +2600,9 @@ static int __get_page_type(struct page_info
>> >> *page, unsigned long type,
>> >> >  if ( (x & PGT_partial) && !(nx & PGT_partial) )
>> >> >  put_page(page);
>> >> >
>> >> > +if ( !rc )
>> >> > +rc = ret;
>> >>
>> >> I know I've seen this a couple of time already, but with the special
>> >> purpose of "ret" I really wonder whether a more specific name
>> >> wouldn't be warranted - e.g. "iommu_rc" or "iommu_ret".
>> >
>> >
>> > rc is return value for this function, and no directly association with
>> > IOMMU related code ( rc is only for alloc_page_type() ).
>> > So the rc cannot be "iommu_rc"..
>> >
>> > ret can be "iommu_ret", but I think the pair 'rc' / 'ret' may look good.
>> 
>> Well, I'm not entirely opposed to keeping the names, but I continue to think
>> that while at the call sites the shorter name is reasonable, it is quite a 
>> bit less
>> clear at the point where you conditionally update rc.
>
>I am open to it. What about 'rc' / 'iommu_ret' ?

As that matches one of the two options I had suggested, I don't really see why
you ask back.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

[Wei Liu]

On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"):
> > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> > explicitly set the limit in libxl for 4.7.
> ...
> > +unsigned long limit = 0;
> > +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
> > +
> > +limit = s ? strtoul(s,0,0) : 1*1024*1024;
> > +flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT",
> > +  GCSPRINTF("%lu", limit));
> 
> This is rather more complex than it needs to be.  What would be wrong
> with
>   if (getenv("XEN_QEMU_CONSOLE_LIMIT")) return;
>   flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT", "1048576");
> ?
> 

Nice, this is simpler. I will use this version and keep your ack.

> But I guess I don't object enough to care, so
> 
> Acked-by: Ian Jackson 
> 
> 
> > +flexarray_t *dm_args, *dm_envs;
> > +char **args, **envs;
> 
> All these parts are a bit of a palaver but I don't see a better way.
> Thanks for doing this work!
> 

YW.

Wei.

> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] AMD IOMMU: Check io_handler before registering mmio handler

[Jan Beulich]

>>> Suravee Suthikulanit  05/25/16 8:52 PM >>>
>On 5/23/2016 3:23 AM, Paul Durrant wrote:
>> > From: suravee.suthikulpa...@amd.com
>> > Sent: 22 May 2016 00:43
>>> > guest_iommu_init tries to register mmio handler before HVM domain
>>> > is initialized. This cause registration to silently failing.
>>> > This patch adds a sanitiy check and puts out error message.
>>> >
>>> > Signed-off-by: Suravee Suthikulapanit 
>> This patch is now defunct isn't it?
>
>It is no longer required, but I think this is a good sanity check in 
>case something changes in the future and causing this to be called 
>before the HVM I/O handler initialized.

To be honest, in this case I'm not convinced, no matter that generally
appreciate ASSERT()s getting added.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[David Vrabel]

On 26/05/16 15:05, Boris Ostrovsky wrote:
> On 05/26/2016 06:24 AM, David Vrabel wrote:
>>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>>> pte_t pte)
>>>  * page tables for mapping the p2m list, too, and page tables MUST be
>>>  * mapped read-only.
>>>  */
>>> -   pfn = pte_pfn(pte);
>>> +   pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>>> if (pfn >= xen_start_info->first_p2m_pfn &&
>>> pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>>> -   pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
>>> +   pte &= ~_PAGE_RW;
>>>
>>> return pte;
>>>  }
>>> @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>>> pte_t pte)
>>>   * so always write the PTE directly and rely on Xen trapping and
>>>   * emulating any updates as necessary.
>>>   */
>>> +__visible __init pte_t xen_make_pte_init(pteval_t pte)
>>> +{
>>> +#ifdef CONFIG_X86_64
>>> +   pte = mask_rw_pte(pte);
>>> +#endif
> 
> 
> Won't make_pte() be called on 32-bit as well? (And if yes then we can
> get rid of xen_set_pte_init())

Yes, but the 32-bit check needs the pointer to the PTE to see if it is
currently read-only, this isn't available in make_pte().

> (Also there were build warnings about xen_make_pte_init() being in wrong
> section because PV_CALLEE_SAVE is not __init).

I intent to fix this up before posting a v2.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

[Wei Liu]

From: Ian Jackson 

Each time round the main loop, we now fstat stderr.  If it is too big,
we dup2 /dev/null onto it.  This is not a very pretty patch but it is
very simple, easy to see that it's correct, and has a low risk of
collateral damage.

The limit is 1Mby by default but can be adjusted by setting a new
environment variable.

This fixes CVE-2014-3672.

Signed-off-by: Ian Jackson 
Tested-by: Ian Jackson 

Set the default to 0 so that it won't affect non-xen installation. The
limit will be set by Xen toolstack.

Signed-off-by: Wei Liu 
---
 main-loop.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/main-loop.c b/main-loop.c
index 3997043..aa32f5b 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -164,6 +164,50 @@ int qemu_init_main_loop(Error **errp)
 return 0;
 }
 
+static void check_cve_2014_3672_xen(void)
+{
+static unsigned long limit = ~0UL;
+const int fd = 2;
+struct stat stab;
+
+if (limit == ~0UL) {
+const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
+/* XEN_QEMU_CONSOLE_LIMIT=0 means no limit */
+limit = s ? strtoul(s,0,0) : 0;
+}
+if (limit == 0)
+return;
+
+int r = fstat(fd, );
+if (r) {
+perror("fstat stderr (for CVE-2014-3672 check)");
+exit(-1);
+}
+if (!S_ISREG(stab.st_mode))
+return;
+if (stab.st_size <= limit)
+return;
+
+/* oh dear */
+fprintf(stderr,"\r\n"
+"Closing stderr due to CVE-2014-3672 limit. "
+" Set XEN_QEMU_CONSOLE_LIMIT to number of bytes to override,"
+" or 0 for no limit.\n");
+fflush(stderr);
+
+int nfd = open("/dev/null", O_WRONLY);
+if (nfd < 0) {
+perror("open /dev/null (for CVE-2014-3672 check)");
+exit(-1);
+}
+r = dup2(nfd, fd);
+if (r != fd) {
+perror("dup2 /dev/null (for CVE-2014-3672 check)");
+exit(-1);
+}
+close(nfd);
+}
+
 static int max_priority;
 
 #ifndef _WIN32
@@ -216,6 +260,8 @@ static int os_host_main_loop_wait(int64_t timeout)
 int ret;
 static int spin_counter;
 
+check_cve_2014_3672_xen();
+
 glib_pollfds_fill();
 
 /* If the I/O thread is very busy or we are incorrectly busy waiting in
@@ -407,6 +453,8 @@ static int os_host_main_loop_wait(int64_t timeout)
 fd_set rfds, wfds, xfds;
 int nfds;
 
+check_cve_2014_3672_xen();
+
 /* XXX: need to suppress polling by better using win32 events */
 ret = 0;
 for (pe = first_polling_entry; pe != NULL; pe = pe->next) {
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

[Wei Liu]

XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
explicitly set the limit in libxl for 4.7.

Introduce a function for setting the environment variable and call it in
the right places.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl_dm.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 6bbc7c3..1412c29 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -365,6 +365,24 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
 return ERROR_FAIL;
 }
 
+/* XSA-180 / CVE-2014-3672
+ *
+ * The QEMU shipped with Xen has a bodge. It checks for
+ * XEN_QEMU_CONSOLE_LIMIT to see how much data QEMU is allowed
+ * to write to stderr. We set that to 1MB if it is not set by
+ * system administrator.
+ */
+static void libxl__set_qemu_env_for_xsa_180(libxl__gc *gc,
+flexarray_t *dm_envs)
+{
+unsigned long limit = 0;
+const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
+
+limit = s ? strtoul(s,0,0) : 1*1024*1024;
+flexarray_append_pair(dm_envs, "XEN_QEMU_CONSOLE_LIMIT",
+  GCSPRINTF("%lu", limit));
+}
+
 const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
 {
 const libxl_vnc_info *vnc = NULL;
@@ -415,6 +433,8 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
 dm_args = flexarray_make(gc, 16, 1);
 dm_envs = flexarray_make(gc, 16, 1);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+
 flexarray_vappend(dm_args, dm,
   "-d", GCSPRINTF("%d", domid), NULL);
 
@@ -913,6 +933,8 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
 dm_args = flexarray_make(gc, 16, 1);
 dm_envs = flexarray_make(gc, 16, 1);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+
 flexarray_vappend(dm_args, dm,
   "-xen-domid",
   GCSPRINTF("%d", guest_domid), NULL);
@@ -2193,8 +2215,8 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 void libxl__spawn_qdisk_backend(libxl__egc *egc, libxl__dm_spawn_state *dmss)
 {
 STATE_AO_GC(dmss->spawn.ao);
-flexarray_t *dm_args;
-char **args;
+flexarray_t *dm_args, *dm_envs;
+char **args, **envs;
 const char *dm;
 int logfile_w, null = -1, rc;
 uint32_t domid = dmss->guest_domid;
@@ -2203,6 +2225,8 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 dm = qemu_xen_path(gc);
 
 dm_args = flexarray_make(gc, 15, 1);
+dm_envs = flexarray_make(gc, 1, 1);
+
 flexarray_vappend(dm_args, dm, "-xen-domid",
   GCSPRINTF("%d", domid), NULL);
 flexarray_append(dm_args, "-xen-attach");
@@ -2216,6 +2240,9 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 flexarray_append(dm_args, NULL);
 args = (char **) flexarray_contents(dm_args);
 
+libxl__set_qemu_env_for_xsa_180(gc, dm_envs);
+envs = (char **) flexarray_contents(dm_envs);
+
 logfile_w = libxl__create_qemu_logfile(gc, GCSPRINTF("qdisk-%u", domid));
 if (logfile_w < 0) {
 rc = logfile_w;
@@ -2253,7 +2280,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 goto out;
 if (!rc) { /* inner child */
 setsid();
-libxl__exec(gc, null, logfile_w, logfile_w, dm, args, NULL);
+libxl__exec(gc, null, logfile_w, logfile_w, dm, args, envs);
 }
 
 rc = 0;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.7] XSA-180 patches for 4.7

[Wei Liu]

Two patches for XSA-180 for Xen 4.7 release.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about the usage of spinlock

[Julien Grall]

Hello,

On 26/05/2016 12:07, Xu, Quan wrote:

On May 26, 2016 9:31 AM, 조현권  wrote:

I am studying xen 4.6.0 version now and wonder the usage of spinlock which is 
located in free_heap_pages(xen/common/page_alloc. c)
As its memory setup is ahead of multicore initialization, spinlock seems to be 
unnecessary during booting because it uses only single core
spinlock looks required after multicore initialization finished and when xen 
needs to free memory space during work
However i experimented not to use spin lock in free_heap_pages and 
dom0(linux-kernel) was booted well. It does not cause any error using internet 
or application program even reboot
Are therr any special reason to use spinlock?
My experiment environment was ODROID-XU4 which uses arm architecture


Ah, you can try to test more for DomU..


Please try to be helpful when answering to a question. I.e provide 
comment which will help to understand the need (or not) of spinlock.


In this case, booting a single domU will unlikely exacerbate the need of 
spinlock because you need concurrent call to {alloc,free}_heap_pages. 
The easiest way would be creating/destroying multiple guests at the same 
time.


Anyway, Xen will need to manage memory (with {alloc,free}_heap_pages) 
after boot, such as allocating/freeing internal structure associated to 
a domain/vCPU. Search for {alloc,free}_xenheap_pages, which are helpers 
for *_heap_pages.


After Xen has finished to boot, the memory can be managed from any CPUs.
So the code in those functions need to be protected against concurrent 
access.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC4

[Wei Liu]

Hi all

Xen 4.7 rc4 is tagged. You can check that out from xen.git:

  git://xenbits.xen.org/xen.git 4.7.0-rc4

For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc4/xen-4.7.0-rc4.tar.gz

And the signature is at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc4/xen-4.7.0-rc4.tar.gz.sig

Please send bug reports and test reports to
xen-de...@lists.xenproject.org. When sending bug reports, please CC
relevant maintainers and me (wei.l...@citrix.com).

Thanks
Wei.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

[Xu, Quan]

On May 26, 2016 6:38 PM, Xu, Quan  wrote:
> On May 25, 2016 4:30 PM, Jan Beulich  wrote:
> > The patch getting too large is easy to deal with: Split it at a
> > reasonable boundary.
> 
> Jan,
> If I follow the below rule, I need to merge most of patches into this one. I 
> can't
> find a reasonable boundary.
> I recall your suggestion: top one first, then low level one..
> I am better not to make this patch as a first one, as this is really a low 
> level one.
> Then, I need to change condition from 'if ( !rc )'  

Sorry, a typo, 'if ( rc )'

btw, the __must_check annotation is helpful, and  we have  multiple rounds  
review..
I think a big patch is not a big deal. 

Quan

> to ' if ( rc < 0 )' in my series.
> (but if this series would be merged together, I don't need to think about it.)
> Does it make sense?
> 
> Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Boris Ostrovsky]

On 05/26/2016 06:24 AM, David Vrabel wrote:
>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>> pte_t pte)
>>   * page tables for mapping the p2m list, too, and page tables MUST be
>>   * mapped read-only.
>>   */
>> -pfn = pte_pfn(pte);
>> +pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>>  if (pfn >= xen_start_info->first_p2m_pfn &&
>>  pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>> -pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
>> +pte &= ~_PAGE_RW;
>>
>>  return pte;
>>  }
>> @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>> pte_t pte)
>>   * so always write the PTE directly and rely on Xen trapping and
>>   * emulating any updates as necessary.
>>   */
>> +__visible __init pte_t xen_make_pte_init(pteval_t pte)
>> +{
>> +#ifdef CONFIG_X86_64
>> +pte = mask_rw_pte(pte);
>> +#endif


Won't make_pte() be called on 32-bit as well? (And if yes then we can
get rid of xen_set_pte_init())

(Also there were build warnings about xen_make_pte_init() being in wrong
section because PV_CALLEE_SAVE is not __init).

-boris



>> +pte = pte_pfn_to_mfn(pte);
>> +
>> +if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
>> +pte = 0;
>> +
>> +return native_make_pte(pte);
>> +}
>> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
>> +
>>  static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>>  {
>> +#ifdef CONFIG_X86_32
>>  if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>>  pte = mask_rw_pte(ptep, pte);
>> -else
>> -pte = __pte_ma(0);
>> -
>> +#endif
>>  native_set_pte(ptep, pte);
>>  }
>>
>> @@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
>>  pv_mmu_ops.alloc_pud = xen_alloc_pud;
>>  pv_mmu_ops.release_pud = xen_release_pud;
>>  #endif
>> +pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
>>
>>  #ifdef CONFIG_X86_64
>>  pv_mmu_ops.write_cr3 = _write_cr3;
>> @@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops
>> __initconst = {
>>  .pte_val = PV_CALLEE_SAVE(xen_pte_val),
>>  .pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
>>
>> -.make_pte = PV_CALLEE_SAVE(xen_make_pte),
>> +.make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
>>  .make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
>>
>>  #ifdef CONFIG_X86_PAE
>>
>
> ___
> 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

[Xen-devel] [PATCH v2 4/4] VMX: fixup PI descritpor when cpu is offline

[Feng Wu]

When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it. And we need to
carefully handle the situation that calling to vmx_vcpu_block() and
cpu offline occur concurrently.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmcs.c|  1 +
 xen/arch/x86/hvm/vmx/vmx.c | 90 +-
 xen/common/schedule.c  |  8 +---
 xen/include/asm-x86/hvm/hvm.h  |  4 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  2 +-
 xen/include/asm-x86/hvm/vmx/vmx.h  |  1 +
 6 files changed, 96 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8284281..aa25788 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -590,6 +590,7 @@ void vmx_cpu_dead(unsigned int cpu)
 vmx_free_vmcs(per_cpu(vmxon_region, cpu));
 per_cpu(vmxon_region, cpu) = 0;
 nvmx_cpu_dead(cpu);
+vmx_pi_desc_fixup(cpu);
 }
 
 int vmx_cpu_up(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 662b38d..b56082e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -87,6 +87,7 @@ static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
 struct vmx_pi_blocking_vcpu {
 struct list_head list;
 spinlock_t   lock;
+bool_t   down;
 };
 
 /*
@@ -102,9 +103,10 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
 {
 INIT_LIST_HEAD(_cpu(vmx_pi_blocking, cpu).list);
 spin_lock_init(_cpu(vmx_pi_blocking, cpu).lock);
+per_cpu(vmx_pi_blocking, cpu).down = 0;
 }
 
-static void vmx_vcpu_block(struct vcpu *v)
+static bool_t vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
 unsigned int dest;
@@ -122,10 +124,25 @@ static void vmx_vcpu_block(struct vcpu *v)
  * new vCPU to the list.
  */
 spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
-return;
+return 1;
 }
 
 spin_lock(pi_blocking_list_lock);
+if ( unlikely(per_cpu(vmx_pi_blocking, v->processor).down) )
+{
+/*
+ * We being here means that the v->processor is going away, and all
+ * the vcpus on its blocking list were removed from it. Hence we
+ * cannot add new vcpu to it. Besides that, we return -1 to
+ * prevent the vcpu from being blocked. This is needed because
+ * if the vCPU is continue to block and here we don't put it
+ * in a per-cpu blocking list, it might not be woken up by the
+ * notification event.
+ */
+spin_unlock(pi_blocking_list_lock);
+spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
+return 0;
+}
 old_lock = cmpxchg(>arch.hvm_vmx.pi_blocking.lock, NULL,
pi_blocking_list_lock);
 
@@ -161,6 +178,8 @@ static void vmx_vcpu_block(struct vcpu *v)
  x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));
 
 write_atomic(_desc->nv, pi_wakeup_vector);
+
+return 1;
 }
 
 static void vmx_pi_switch_from(struct vcpu *v)
@@ -253,6 +272,73 @@ static void vmx_pi_blocking_cleanup(struct vcpu *v)
 spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
 }
 
+void vmx_pi_desc_fixup(int cpu)
+{
+unsigned int new_cpu, dest;
+unsigned long flags;
+struct arch_vmx_struct *vmx, *tmp;
+spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
+
+if ( !iommu_intpost )
+return;
+
+spin_lock_irqsave(old_lock, flags);
+per_cpu(vmx_pi_blocking, cpu).down = 1;
+
+list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
+{
+/*
+ * We need to find an online cpu as the NDST of the PI descriptor, it
+ * doesn't matter whether it is within the cpupool of the domain or
+ * not. As long as it is online, the vCPU will be woken up once the
+ * notification event arrives.
+ */
+new_cpu = cpu;
+restart:
+while ( 1 )
+{
+new_cpu = (new_cpu + 1) % nr_cpu_ids;
+if ( cpu_online(new_cpu) )
+break;
+}
+new_lock = _cpu(vmx_pi_blocking, cpu).lock;
+
+spin_lock(new_lock);
+/*
+ * After acquiring the blocking list lock for the new cpu, we need
+ * to check whether new_cpu is still online.
+ *
+ * If '.down' is true, it mean 'new_cpu' is also going to be offline,
+ * so just go back to find another one, otherwise, there are two
+ * possibilities:
+ *   case 1 - 'new_cpu' is online.
+ *   case 2 - 'new_cpu' is about to be offline, but doesn't get to
+ *the point where '.down' is set.
+ * In either case above, we can just set 'new_cpu' to 'NDST' field.
+ * For case 2 the 'NDST' field will be set to another online cpu 

[Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

[Feng Wu]

Normally, in vmx_cpu_block() 'NDST' filed should have the same
value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
on whether x2apic is enabled. However, in the following scenario,
'NDST' has different value:

'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
other three PI hooks have not been assigned or not been excuted yet.
And during this interval, we are running in vmx_vcpu_block(), then
'NDST' may have different value.

This patch fix this concern case.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b01128a..662b38d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -146,8 +146,19 @@ static void vmx_vcpu_block(struct vcpu *v)
 
 dest = cpu_physical_id(v->processor);
 
-ASSERT(pi_desc->ndst ==
-   (x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK)));
+/*
+ * Normally, 'NDST' filed should have the same value with dest or
+ * MASK_INSR(dest, PI_xAPIC_NDST_MASK) depending on whether x2apic is
+ * enabled. However, in the following scenario, 'NDST' has different
+ * value:
+ *
+ * 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
+ * other three PI hooks have not been assigned or not been excuted yet.
+ * And during this interval, we get here in this function, then 'NDST'
+ * may have different value.
+ */
+write_atomic(_desc->ndst,
+ x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));
 
 write_atomic(_desc->nv, pi_wakeup_vector);
 }
-- 
2.1.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

[Feng Wu]

The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next time we attach another device to the domain,
which makes the PI realted hooks avaliable again, the status
of the pi descriptor is not true. Beside that, the blocking vcpu
may still remain in the per-cpu blocking in this case.

Solution for this case: [patch v2 1/4]
- Don't zap the PI hooks after the last assigned device is dettatched.
- Remove all the vCPU of the domain from the per-cpu blocking list,
  when the last assigned devices is dettached.

2. After the domain is destroyed, the the blocking vcpu may also
remain in the per-cpu blocking.

Solution for this case: [patch v2 2/4]
- Remove the vCPU from the per-cpu blocking list when it is going
  to be destroyed.

3. When a pCPU is unplugged, and there might be vCPUs on its
list. Since the pCPU is offline, those vCPUs might not be woken
up again.

Solution for this case: [patch v2 4/4]
- When the pCPU is unplugged, move those vCPUs to another blocking
  list of an online pCPU, as well as, set the new cpu to the 'NDST'
  field of PI descriptor.

Feng Wu (4):
  VMX: Properly handle pi when all the assigned devices are removed
  VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
  VMX: Assign the right value to 'NDST' field in a concern case
  VMX: fixup PI descritpor when cpu is offline

 xen/arch/x86/hvm/vmx/vmcs.c|   1 +
 xen/arch/x86/hvm/vmx/vmx.c | 179 +
 xen/common/schedule.c  |   8 +-
 xen/include/asm-x86/hvm/hvm.h  |   4 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |   5 +-
 xen/include/asm-x86/hvm/vmx/vmx.h  |   1 +
 6 files changed, 174 insertions(+), 24 deletions(-)

-- 
2.1.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

[Feng Wu]

This patch handles some concern case when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again. This is achrived by always
making all the pi hooks available, so the pi descriptor is updated
during scheduling, which make it always up-to-data.
- No remaining vcpus of the domain in the per-cpu blocking list.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 75 +++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  3 ++
 2 files changed, 65 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bc4410f..65f5288 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -113,7 +113,19 @@ static void vmx_vcpu_block(struct vcpu *v)
_cpu(vmx_pi_blocking, v->processor).lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
 
-spin_lock_irqsave(pi_blocking_list_lock, flags);
+spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
+if ( unlikely(v->arch.hvm_vmx.pi_blocking_cleaned_up) )
+{
+/*
+ * The vcpu is to be destroyed and it has already been removed
+ * from the per-CPU list if it is blocking, we shouldn't add
+ * new vCPU to the list.
+ */
+spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
+return;
+}
+
+spin_lock(pi_blocking_list_lock);
 old_lock = cmpxchg(>arch.hvm_vmx.pi_blocking.lock, NULL,
pi_blocking_list_lock);
 
@@ -126,7 +138,9 @@ static void vmx_vcpu_block(struct vcpu *v)
 
 list_add_tail(>arch.hvm_vmx.pi_blocking.list,
   _cpu(vmx_pi_blocking, v->processor).list);
-spin_unlock_irqrestore(pi_blocking_list_lock, flags);
+spin_unlock(pi_blocking_list_lock);
+
+spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
 
 ASSERT(!pi_test_sn(pi_desc));
 
@@ -199,32 +213,65 @@ static void vmx_pi_do_resume(struct vcpu *v)
 spin_unlock_irqrestore(pi_blocking_list_lock, flags);
 }
 
+static void vmx_pi_blocking_cleanup(struct vcpu *v)
+{
+unsigned long flags;
+spinlock_t *pi_blocking_list_lock;
+
+if ( !iommu_intpost )
+return;
+
+spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
+v->arch.hvm_vmx.pi_blocking_cleaned_up = 1;
+
+pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
+if (pi_blocking_list_lock == NULL)
+{
+spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
+return;
+}
+
+spin_lock(pi_blocking_list_lock);
+if ( v->arch.hvm_vmx.pi_blocking.lock != NULL )
+{
+ASSERT(v->arch.hvm_vmx.pi_blocking.lock == pi_blocking_list_lock);
+list_del(>arch.hvm_vmx.pi_blocking.list);
+v->arch.hvm_vmx.pi_blocking.lock = NULL;
+}
+spin_unlock(pi_blocking_list_lock);
+spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
+}
+
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
+for_each_vcpu ( d, v )
+v->arch.hvm_vmx.pi_blocking_cleaned_up = 0;
 
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
-d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
-d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
-d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
+if ( !d->arch.hvm_domain.vmx.vcpu_block )
+{
+d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
+d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
+d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
+d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
+}
 }
 
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_deassign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
-
-d->arch.hvm_domain.vmx.vcpu_block = NULL;
-d->arch.hvm_domain.vmx.pi_switch_from = NULL;
-d->arch.hvm_domain.vmx.pi_switch_to = NULL;
-d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+for_each_vcpu ( d, v )
+vmx_pi_blocking_cleanup(v);
 }
 
 static int vmx_domain_initialise(struct domain *d)
@@ -256,6 +303,8 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 
 INIT_LIST_HEAD(>arch.hvm_vmx.pi_blocking.list);
 
+spin_lock_init(>arch.hvm_vmx.pi_hotplug_lock);
+
 v->arch.schedule_tail= vmx_do_resume;
 v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
 v->arch.ctxt_switch_to   = vmx_ctxt_switch_to;
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 

[Xen-devel] [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

[Feng Wu]

We should remove the vCPU from the per-cpu blocking list
if it is going to be destroyed.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 65f5288..b01128a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -366,6 +366,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
 vmx_destroy_vmcs(v);
 vpmu_destroy(v);
 passive_domain_destroy(v);
+vmx_pi_blocking_cleanup(v);
 }
 
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
-- 
2.1.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: 
Support 32-bit default_ioport_* accesses"):
> On 05/25/2016 12:09 PM, Ian Jackson wrote:
> > I think this question can only be resolved de jure by looking at what
> > previous ACPI specifications (before this AccessSize field) said.
> 
> It's been around since 3.0 (which is 2004). Prior to that --- my cursory
> read of 2.0 suggests that accesses were 8-bit.

That would mean that in the absence of indication that the new
standard is supported, accesses should be 8-bit.

> > But, I think: de facto, what is going on here is that ACPICA and hence
> > Linux have changed their behaviour in a way that is not compatible
> > with at least some existing "hardware".  Is this not arguably a
> > compatibility defect Linux ?
> >
> > It would surely be better to make Linux do whatever it did before,
> > when AccessSize is not supplied.  That will avoid breaking any other
> > things (whether or not those other things are de jure broken according
> > to previous specs).  It will also avoid us having to make changes our
> > ACPI tables which themselves come with a risk of compatibility
> > problems.
> 
> ACPICA will use 32-bit accesses for access_size=0:
> https://github.com/acpica/acpica/commit/c49a751b

That commit message does not justify the decision other than as an
optimisation.  Backward-incompatible `optimisations' are a bad idea
both de jure and de facto.

> However, Linux appears to have some sort of workaround for FreeBSD,
> which *appears* as it should be applicable to hvmloader's tables as
> well. But it clearly does not as we are failing on Linux.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi/acpica/hwregs.c?id=b314a172ee968d45f72dffea68ab8af38aa80ded
> 
> Let me see whether which path we take.

I confess I don't understand that patch, but it does seem to be an
attempt to provide backward-compatible behaviour.

Overall, all this new information tends to reinforce my initial
supposition that the bug is in ACPICA and that qemu-xen-traditional
ought not to be changed.

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/psr: make opt_psr persistent

[Wei Liu]

On Thu, May 26, 2016 at 11:44:15AM +0100, Andrew Cooper wrote:
> On 26/05/16 03:03, Chao Peng wrote:
> > opt_psr is now not only used at booting time but also at runtime.
> > More specifically, it is used to check CDP switch in psr_cpu_init()
> > which can potentially be called in CPU hotplug case.
> >
> > Signed-off-by: Chao Peng 
> 
> Reviewed-by: Andrew Cooper 
> 
> Wei: This should be taken for 4.7
> 

Release-acked-by: Wei Liu 

> ~Andrew
> 
> > ---
> >  xen/arch/x86/psr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> > index f796552..0b5073c 100644
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -52,7 +52,7 @@ static unsigned long *__read_mostly cat_socket_enable;
> >  static struct psr_cat_socket_info *__read_mostly cat_socket_info;
> >  static unsigned long *__read_mostly cdp_socket_enable;
> >  
> > -static unsigned int __initdata opt_psr;
> > +static unsigned int opt_psr;
> >  static unsigned int __initdata opt_rmid_max = 255;
> >  static unsigned int __read_mostly opt_cos_max = 255;
> >  static uint64_t rmid_mask;
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94790: trouble: blocked/broken

[osstest service owner]

flight 94790 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94790/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   61 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

[Wei Liu]

On Thu, May 26, 2016 at 01:03:53PM +, Wu, Feng wrote:
> 
> 
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Thursday, May 26, 2016 6:27 PM
> > To: Wu, Feng 
> > Cc: Hao, Xudong ; Xen-devel  > de...@lists.xenproject.org>; Wei Liu 
> > Subject: Re: [BUG] Xen panic with VT-d PI
> > 
> > On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> > > The patch fixing this issue has already been sent to upstream.
> > >
> > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking 
> > > list "
> > >
> > > v2 will be sent out soon.
> > >
> > 
> > I just went through that thread. There are some open questions. Also Jan
> > requested that you explore other possible options.
> > 
> > My current plan is to not block the release for this -- we're very close
> > to the anticipated release date, and posted-interrupt is either
> > technical preview or experimental, so bugs there are expected.
> > 
> > This issue will be listed as a known issue for PI. And you can continue
> > to develop a fix for it. Your fix will be integrated with next version
> > of Xen. Then you can request for backport to 4.7 if you want to.
> > 
> > What do you think about this plan?
> 
> I am going to send out the next version of this series, let's see how
> it is going on. But basically, I am fine with your release plan.
> 

Ack. Thanks for confirming.

Wei.

> Thanks,
> Feng
> 
> > 
> > Wei.
> > 
> > > Thanks,
> > > Feng

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 3/6] build: convert verbose to Kconfig

[Daniel De Graaf]

On 05/24/2016 09:56 AM, Doug Goldstein wrote:

Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 


Acked-by: Daniel De Graaf 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

[Wu, Feng]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, May 26, 2016 6:27 PM
> To: Wu, Feng 
> Cc: Hao, Xudong ; Xen-devel  de...@lists.xenproject.org>; Wei Liu 
> Subject: Re: [BUG] Xen panic with VT-d PI
> 
> On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> > The patch fixing this issue has already been sent to upstream.
> >
> > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list "
> >
> > v2 will be sent out soon.
> >
> 
> I just went through that thread. There are some open questions. Also Jan
> requested that you explore other possible options.
> 
> My current plan is to not block the release for this -- we're very close
> to the anticipated release date, and posted-interrupt is either
> technical preview or experimental, so bugs there are expected.
> 
> This issue will be listed as a known issue for PI. And you can continue
> to develop a fix for it. Your fix will be integrated with next version
> of Xen. Then you can request for backport to 4.7 if you want to.
> 
> What do you think about this plan?

I am going to send out the next version of this series, let's see how
it is going on. But basically, I am fine with your release plan.

Thanks,
Feng

> 
> Wei.
> 
> > Thanks,
> > Feng

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94784: regressions - FAIL

[osstest service owner]

flight 94784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94784/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 6b571c4d8c827a39a5e249d5d9db4f99aebb5d63
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z1 days
Failing since 94750  2016-05-25 03:43:08 Z1 days5 attempts
Testing same since94784  2016-05-26 02:56:04 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Hao Wu 
  Laszlo Ersek 
  Marvin H?user 
  Marvin Haeuser 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 6b571c4d8c827a39a5e249d5d9db4f99aebb5d63
Author: Hao Wu 
Date:   Wed May 25 10:00:08 2016 +0800

MdeModulePkg NvmExpressDxe: Fix VS2010 build error

Potentially uninitialized 'Status' might be returned in functions
NvmeCreateIoCompletionQueue() and NvmeCreateIoSubmissionQueue() in file
NvmExpressHci.c.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Qiu Shumin 
Reviewed-by: Feng Tian 

commit 855743f7177459bea95798e59b6b18dab867710c
Author: Laszlo Ersek 
Date:   Wed May 18 20:13:41 2016 +0200

OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

According to edk2 commit

  "MdeModulePkg/PciBus: do not improperly degrade resource"

and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.

In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.

(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)

In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.

The driver added in this patch could be simplified based on the following
facts:

- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
  the driver will exit immediately. Therefore the driver could be omitted
  from the Ia32 build.

- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
  was defined (because in that case the degradation would be justified).
  On the other hand, if CSM_ENABLE was undefined, then the driver could be
  included, 

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Andrew Cooper]

On 26/05/16 09:29, Lan Tianyu wrote:
> Hi All:
> We try pushing virtual iommu support for Xen guest and there are some
> features blocked by it.
>
> Motivation:
> ---
> 1) Add SVM(Shared Virtual Memory) support for Xen guest
> To support iGFX pass-through for SVM enabled devices, it requires
> virtual iommu support to emulate related registers and intercept/handle
> guest SVM configure in the VMM.
>
> 2) Increase max vcpu support for one VM.
>
> So far, max vcpu for Xen hvm guest is 128. For HPC(High Performance
> Computing) cloud computing, it requires more vcpus support in a single
> VM. The usage model is to create just one VM on a machine with the
> same number vcpus as logical cpus on the host and pin vcpu on each
> logical cpu in order to get good compute performance.
>
> Intel Xeon phi KNL(Knights Landing) is dedicated to HPC market and
> supports 288 logical cpus. So we hope VM can support 288 vcpu
> to meet HPC requirement.
>
> Current Linux kernel requires IR(interrupt remapping) when MAX APIC
> ID is > 255 because interrupt only can be delivered among 0~255 cpus
> without IR. IR in VM relies on the virtual iommu support.
>
> KVM Virtual iommu support status
> 
> Current, Qemu has a basic virtual iommu to do address translation for
> virtual device and it only works for the Q35 machine type. KVM reuses it
> and Redhat is adding IR to support more than 255 vcpus.
>
> How to add virtual iommu for Xen?
> -
> First idea came to my mind is to reuse Qemu virtual iommu but Xen didn't
> support Q35 so far. Enabling Q35 for Xen seems not a short term task.
> Anthony did some related jobs before.
>
> I'd like to see your comments about how to implement virtual iommu for Xen.
>
> 1) Reuse Qemu virtual iommu or write a separate one for Xen?
> 2) Enable Q35 for Xen to reuse Qemu virtual iommu?
>
> Your comments are very appreciated. Thanks a lot.

To be viable going forwards, any solution must work with PVH/HVMLite as
much as HVM.  This alone negates qemu as a viable option.

From a design point of view, having Xen needing to delegate to qemu to
inject an interrupt into a guest seems backwards.


A whole lot of this would be easier to reason about if/when we get a
basic root port implementation in Xen, which is necessary for HVMLite,
and which will make the interaction with qemu rather more clean.  It is
probably worth coordinating work in this area.


As for the individual issue of 288vcpu support, there are already issues
with 64vcpu guests at the moment.  While it is certainly fine to remove
the hard limit at 255 vcpus, there is a lot of other work required to
even get 128vcpu guests stable.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about the usage of spinlock

[Xu, Quan]

On May 26, 2016 9:31 AM, 조현권  wrote:
> I am studying xen 4.6.0 version now and wonder the usage of spinlock which is 
> located in free_heap_pages(xen/common/page_alloc. c)
> As its memory setup is ahead of multicore initialization, spinlock seems to 
> be unnecessary during booting because it uses only single core
> spinlock looks required after multicore initialization finished and when xen 
> needs to free memory space during work
> However i experimented not to use spin lock in free_heap_pages and 
> dom0(linux-kernel) was booted well. It does not cause any error using 
> internet or application program even reboot
> Are therr any special reason to use spinlock?
> My experiment environment was ODROID-XU4 which uses arm architecture

Ah, you can try to test more for DomU..
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: use vma_pages().

[David Vrabel]

On 24/05/16 01:04, Muhammad Falak R Wani wrote:
> Replace explicit computation of vma page count by a call to
> vma_pages().

Applied to for-linus-4.8, thanks.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/psr: make opt_psr persistent

[Andrew Cooper]

On 26/05/16 03:03, Chao Peng wrote:
> opt_psr is now not only used at booting time but also at runtime.
> More specifically, it is used to check CDP switch in psr_cpu_init()
> which can potentially be called in CPU hotplug case.
>
> Signed-off-by: Chao Peng 

Reviewed-by: Andrew Cooper 

Wei: This should be taken for 4.7

~Andrew

> ---
>  xen/arch/x86/psr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index f796552..0b5073c 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -52,7 +52,7 @@ static unsigned long *__read_mostly cat_socket_enable;
>  static struct psr_cat_socket_info *__read_mostly cat_socket_info;
>  static unsigned long *__read_mostly cdp_socket_enable;
>  
> -static unsigned int __initdata opt_psr;
> +static unsigned int opt_psr;
>  static unsigned int __initdata opt_rmid_max = 255;
>  static unsigned int __read_mostly opt_cos_max = 255;
>  static uint64_t rmid_mask;


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/compat: correct SMEP/SMAP NOPs patching

[Andrew Cooper]

On 25/05/16 16:00, Jan Beulich wrote:
> Correct the number of single byte NOPs we want to be replaced in case
> neither SMEP nor SMAP are available.
>
> Also simplify the expression adding these NOPs - at that location .
> equals .Lcr4_orig, and removing that part of the expression fixes a
> bogus ".space or fill with negative value, ignored" warning by very old
> gas (which actually is what made me look at those constructs again).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

[George Dunlap]

On 26/05/16 04:55, Tamas K Lengyel wrote:
> Move sharing locks above altp2m to avoid locking order violation. Allow
> applying altp2m mem_access settings when the hostp2m entries are shared.
> Also, do not trigger PoD for hostp2m when setting altp2m mem_access to be
> in-line with non-altp2m mem_access path. Also allow gfn remapping with
> p2m_ram_shared type gfns in altp2m views.
> 
> When using mem_sharing in combination with altp2m, unsharing events overwrite
> altp2m entries with that of the hostp2m (both remapped entries and mem_access
> settings). User should take precaution to not share pages where this behavior
> is undesired.

I'm afraid this is not acceptable.  How could this ever be even remotely
usable?  If this is a necessary side effect of sharing, then I think the
original functionality, of un-sharing when setting an altp2m entry is
the only option (and not allowing sharing to happen when an altp2m is
present for a particular gfn).

Hmm, but actually this also brings up another tricky point: In an altp2m
you can change the mfn which backs a gfn.  This would need to be handled
properly in the reverse map, which it doesn't look like it is at the moment.

On the whole, I think if you're going to allow a single gfn to be
simultaneously shared and allow an altp2m for it, you're going to need
to do a lot more work.

(Sorry for not catching a lot of this before...)

 -George

> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> v4: Resolve locking problem by moving sharing locks above altp2m locks
> ---
>  xen/arch/x86/mm/mm-locks.h | 30 +++---
>  xen/arch/x86/mm/p2m.c  | 10 +-
>  2 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
> index 086c8bb..74fdfc1 100644
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -242,6 +242,21 @@ declare_mm_lock(nestedp2m)
>  
>  declare_mm_rwlock(p2m);
>  
> +/* Sharing per page lock
> + *
> + * This is an external lock, not represented by an mm_lock_t. The memory
> + * sharing lock uses it to protect addition and removal of (gfn,domain)
> + * tuples to a shared page. We enforce order here against the p2m lock,
> + * which is taken after the page_lock to change the gfn's p2m entry.
> + *
> + * The lock is recursive because during share we lock two pages. */
> +
> +declare_mm_order_constraint(per_page_sharing)
> +#define page_sharing_mm_pre_lock()   
> mm_enforce_order_lock_pre_per_page_sharing()
> +#define page_sharing_mm_post_lock(l, r) \
> +mm_enforce_order_lock_post_per_page_sharing((l), (r))
> +#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
> +
>  /* Alternate P2M list lock (per-domain)
>   *
>   * A per-domain lock that protects the list of alternate p2m's.
> @@ -287,21 +302,6 @@ declare_mm_rwlock(altp2m);
>  #define p2m_locked_by_me(p)   mm_write_locked_by_me(&(p)->lock)
>  #define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
>  
> -/* Sharing per page lock
> - *
> - * This is an external lock, not represented by an mm_lock_t. The memory
> - * sharing lock uses it to protect addition and removal of (gfn,domain)
> - * tuples to a shared page. We enforce order here against the p2m lock,
> - * which is taken after the page_lock to change the gfn's p2m entry.
> - *
> - * The lock is recursive because during share we lock two pages. */
> -
> -declare_mm_order_constraint(per_page_sharing)
> -#define page_sharing_mm_pre_lock()   
> mm_enforce_order_lock_pre_per_page_sharing()
> -#define page_sharing_mm_post_lock(l, r) \
> -mm_enforce_order_lock_post_per_page_sharing((l), (r))
> -#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
> -
>  /* PoD lock (per-p2m-table)
>   * 
>   * Protects private PoD data structs: entry and cache
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 9b19769..dc97082 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1768,10 +1768,10 @@ int p2m_set_altp2m_mem_access(struct domain *d, 
> struct p2m_domain *hp2m,
>  if ( !mfn_valid(mfn) )
>  {
>  mfn = hp2m->get_entry(hp2m, gfn_l, , _a,
> -  P2M_ALLOC | P2M_UNSHARE, _order, NULL);
> +  0, _order, NULL);
>  
>  rc = -ESRCH;
> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> +if ( !mfn_valid(mfn) || (t != p2m_ram_rw && t != p2m_ram_shared) )
>  return rc;
>  
>  /* If this is a superpage, copy that first */
> @@ -2542,9 +2542,9 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned 
> int idx,
>  if ( !mfn_valid(mfn) )
>  {
>  mfn = hp2m->get_entry(hp2m, gfn_x(old_gfn), , ,
> -  P2M_ALLOC | P2M_UNSHARE, _order, NULL);
> +  P2M_ALLOC, 

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

[Xu, Quan]

On May 25, 2016 4:30 PM, Jan Beulich  wrote:
> The patch getting too large is easy to deal with: Split it at a reasonable
> boundary.

Jan, 
If I follow the below rule, I need to merge most of patches into this one. I 
can't find a reasonable boundary.
I recall your suggestion: top one first, then low level one..
I am better not to make this patch as a first one, as this is really a low 
level one.
Then, I need to change condition from 'if ( !rc )'  to ' if ( rc < 0 )' in my 
series. (but if this series would be merged together, I don't need to think 
about it.)
Does it make sense?

Quan


> It's one thing that I want to be clear: Any conversion of a void
> return type of some function to non-void should be accompanied by it at the
> same time becoming __must_check. I dislike having to repeat yet again what I
> have been saying a number of times: Without doing so, it is harder for you as
> the person writing the patch to verify all callers deal with errors, and it's
> perhaps even harder for reviewers to verify you did.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[David Vrabel]

On 11/05/16 14:07, Arnd Bergmann wrote:
> A bugfix patch for the xen balloon driver introduced a forward
> declaration for a static function that is conditionally compiled,
> causing a warning if only the declaration but not the definition
> are there:
> 
> drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
> 'static' but never defined [-Werror=unused-function]
>  static void release_memory_resource(struct resource *resource);
> 
> This removes the declaration again and instead moves the function
> definition to the right place, before its first caller and inside
> of the #ifdef protecting both.

I've applied the equivalent patch from Ross, instead.

> The patch that introduced the warning is marked for stable
> backports, so if that gets applied to 4.4, so should this one.

Fixes for compiler warnings are not sufficiently important to be
backported to stable.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

[Andrew Cooper]

>>> @@ -42,11 +38,12 @@ UINT64 __read_mostly efi_boot_remain_var_store_size;
>>>  UINT64 __read_mostly efi_boot_max_var_size;
>>>
>>>  struct efi __read_mostly efi = {
>>> -   .acpi   = EFI_INVALID_TABLE_ADDR,
>>> -   .acpi20 = EFI_INVALID_TABLE_ADDR,
>>> -   .mps= EFI_INVALID_TABLE_ADDR,
>>> -   .smbios = EFI_INVALID_TABLE_ADDR,
>>> -   .smbios3 = EFI_INVALID_TABLE_ADDR,
>>> +   .flags   = 0, /* Initialized later. */
>>> +   .acpi= EFI_INVALID_TABLE_ADDR,
>>> +   .acpi20  = EFI_INVALID_TABLE_ADDR,
>>> +   .mps = EFI_INVALID_TABLE_ADDR,
>>> +   .smbios  = EFI_INVALID_TABLE_ADDR,
>>> +   .smbios3 = EFI_INVALID_TABLE_ADDR
>>>  };
>> This, again, is an unnecessary hunk. And in no case should you drop
> Ditto.
>
>> the trailing comma - that's there for a reason.
> What is the reason for trailing comma?

If you put in a trailing comma, subsequent patches to add a further item
become a 1 line addition, rather than a 1 subtraction and 2 addition.

It makes patches for future additions smaller and more clear.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen/balloon: Fix declared-but-not-defined warning

[David Vrabel]

On 10/05/16 10:27, Ross Lagerwall wrote:
> Fix a declared-but-not-defined warning when building with
> XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
> commit dfd74a1edfab
> ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE").

Applied to for-linus-4.7b, thanks.

I have not Cc'd stable since this only fixes a warning.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

[Andrew Cooper]

>>> @@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER 
>>> /
>>>  .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
>>>  multiboot1_header_end:
>>>
>>> +/*** MULTIBOOT2 HEADER /
>>> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
>>> file. */
>>> +.align  MULTIBOOT2_HEADER_ALIGN
>>> +
>>> +multiboot2_header_start:
>>> +/* Magic number indicating a Multiboot2 header. */
>>> +.long   MULTIBOOT2_HEADER_MAGIC
>>> +/* Architecture: i386. */
>>> +.long   MULTIBOOT2_ARCHITECTURE_I386
>>> +/* Multiboot2 header length. */
>>> +.long   multiboot2_header_end - multiboot2_header_start
>>> +/* Multiboot2 header checksum. */
>>> +.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + 
>>> \
>>> +(multiboot2_header_end - multiboot2_header_start))
>>> +
>>> +/* Multiboot2 information request tag. */
>>> +mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
>>> +   MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
>>> +
>>> +/* Align modules at page boundry. */
>>> +mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
>>> +
>>> +/* Console flags tag. */
>>> +mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
>>> +   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
>>> +
>>> +/* Framebuffer tag. */
>>> +mb2ht_init MB2_HT(FRAMEBUFFER), MB2_HT(OPTIONAL), \
>>> +   0, /* Number of the columns - no preference. */ \
>>> +   0, /* Number of the lines - no preference. */ \
>>> +   0  /* Number of bits per pixel - no preference. */
>>> +
>>> +/* Multiboot2 header end tag. */
>>> +mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
>>> +multiboot2_header_end:
>> Imo "end" labels should always preferably be .L-prefixed, to avoid
>> them getting used by a consumer instead of another "proper" label
>> starting whatever comes next.
> Make sense, however, I am in line with multiboot1_header_end label here.
> So, if we wish .L here then we should change multiboot1_header_end label
> above too. Of course in separate patch.

The multiboot1 header is very specifically not a local label, so you can
distinguish the actual header from the 3 nops following it in the
disassembly.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

[Wei Liu]

On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> The patch fixing this issue has already been sent to upstream.
> 
> " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list "
> 
> v2 will be sent out soon.
> 

I just went through that thread. There are some open questions. Also Jan
requested that you explore other possible options.

My current plan is to not block the release for this -- we're very close
to the anticipated release date, and posted-interrupt is either
technical preview or experimental, so bugs there are expected.

This issue will be listed as a known issue for PI. And you can continue
to develop a fix for it. Your fix will be integrated with next version
of Xen. Then you can request for backport to 4.7 if you want to.

What do you think about this plan?

Wei.

> Thanks,
> Feng

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[David Vrabel]

On 17/05/16 16:11, David Vrabel wrote:
> On 11/05/16 11:16, David Vrabel wrote:
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
> 
> Kevin, can you try this patch.
> 
> David
> 
> 8<-
> x86/xen: avoid m2p lookup when setting early page table entries
> 
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
> 
> In 64 guest (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() because an M2P lookup faults because the MFN is in
> MMIO space and not mapped in the M2P.  This lookup is done to see if
> the PFN in in the range used for the initial page table pages, so that
> the PTE may be set as read-only.
> 
> The M2P lookup can be avoided by moving the check (and clear of RW)
> earlier when the PFN is still available.
> 
> [ Not entirely happy with this as the 32/64 bit paths diverge even
>   more. Is there some way to unify them instead? ]

Boris, Juergen, any opinion on this patch?

David

> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
> pte)
>   return pte;
>  }
>  #else /* CONFIG_X86_64 */
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> +static pteval_t __init mask_rw_pte(pteval_t pte)
>  {
>   unsigned long pfn;
> 
> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
> pte_t pte)
>* page tables for mapping the p2m list, too, and page tables MUST be
>* mapped read-only.
>*/
> - pfn = pte_pfn(pte);
> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>   if (pfn >= xen_start_info->first_p2m_pfn &&
>   pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
> + pte &= ~_PAGE_RW;
> 
>   return pte;
>  }
> @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
> pte_t pte)
>   * so always write the PTE directly and rely on Xen trapping and
>   * emulating any updates as necessary.
>   */
> +__visible __init pte_t xen_make_pte_init(pteval_t pte)
> +{
> +#ifdef CONFIG_X86_64
> + pte = mask_rw_pte(pte);
> +#endif
> + pte = pte_pfn_to_mfn(pte);
> +
> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
> + pte = 0;
> +
> + return native_make_pte(pte);
> +}
> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
> +
>  static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  {
> +#ifdef CONFIG_X86_32
>   if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>   pte = mask_rw_pte(ptep, pte);
> - else
> - pte = __pte_ma(0);
> -
> +#endif
>   native_set_pte(ptep, pte);
>  }
> 
> @@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
>   pv_mmu_ops.alloc_pud = xen_alloc_pud;
>   pv_mmu_ops.release_pud = xen_release_pud;
>  #endif
> + pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
> 
>  #ifdef CONFIG_X86_64
>   pv_mmu_ops.write_cr3 = _write_cr3;
> @@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops
> __initconst = {
>   .pte_val = PV_CALLEE_SAVE(xen_pte_val),
>   .pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
> 
> - .make_pte = PV_CALLEE_SAVE(xen_make_pte),
> + .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
>   .make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
> 
>  #ifdef CONFIG_X86_PAE
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Stefano Stabellini]

On Thu, 26 May 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 16/05/2016 12:11, Stefano Stabellini wrote:
> > On Wed, 11 May 2016, Arnd Bergmann wrote:
> > > A bugfix patch for the xen balloon driver introduced a forward
> > > declaration for a static function that is conditionally compiled,
> > > causing a warning if only the declaration but not the definition
> > > are there:
> > > 
> > > drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared
> > > 'static' but never defined [-Werror=unused-function]
> > >  static void release_memory_resource(struct resource *resource);
> > > 
> > > This removes the declaration again and instead moves the function
> > > definition to the right place, before its first caller and inside
> > > of the #ifdef protecting both.
> > > 
> > > The patch that introduced the warning is marked for stable
> > > backports, so if that gets applied to 4.4, so should this one.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit
> > > PAE")
> > > Cc: sta...@vger.kernel.org
> > 
> > Reviewed-by: Stefano Stabellini 
> 
> You have applied this patch to the branch for-linus-4.8 but not for-linus-4.7.
> Is it intentional?

Yes it is. for-linus-4.7 is based on an older version of the kernel that
doesn't have dfd74a1edfab. Linus discourages rebasing the pull request
branches. That said, the patch could still go to Linus earlies in one of
the RCs.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] AMD IOMMU: Introduce support for IVHD block type 11h

[Andrew Cooper]

On 26/05/16 03:50, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit 
>
> Along with the IVHD block type 10h, newer AMD platforms also come with
> types 11h, which is a superset of the older one. Having multiple IVHD
> block types in the same platform allows backward compatibility of newer
> systems to work with existing drivers.  The driver should only parse
> the highest-level (newest) type of IVHD block that it can support.
> However, the current driver returns error when encounters with unknown
> IVHD block type. This causes existing driver to unnecessarily fail IOMMU
> initialization on new systems.
>
> This patch introduces a new logic, which scans through IVRS table looking
> for the highest-level supporsted IVHD block type. It also adds support
> for the new IVHD block type 11h. More information about the IVHD type 11h
> can be found in the AMD I/O Virtualization Technology (IOMMU) Specification
> rev 2.62.
>
> http://support.amd.com/TechDocs/48882_IOMMU.pdf
>
> Signed-off-by: Suravee Suthikulpanit 

Reviewed-by: Andrew Cooper  with two minor
style issues (which can be fixed on commit if necessary).

> @@ -978,6 +966,25 @@ static void __init dump_acpi_table_header(struct 
> acpi_table_header *table)
>  
>  }
>  
> +#define to_ivhd_block(hdr) \
> +container_of(hdr, const struct acpi_ivrs_hardware, header)
> +#define to_ivmd_block(hdr) \
> +container_of(hdr, const struct acpi_ivrs_memory, header)
> +
> +static inline bool_t is_ivhd_block(u8 type)
> +{
> +return ( type == ACPI_IVRS_TYPE_HARDWARE ||
> + type == ACPI_IVRS_TYPE_HARDWARE_11H );
> +}
> +
> +static inline bool_t is_ivmd_block(u8 type) \

Stray \

> @@ -1102,15 +1110,16 @@ static int __init get_last_bdf_ivhd(
>  {
>  const union acpi_ivhd_device *ivhd_device;
>  u16 block_length, dev_length;
> +size_t hdr_size = get_ivhd_header_size(ivhd_block) ;

Stray space.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Julien Grall]

Hi Stefano,

On 16/05/2016 12:11, Stefano Stabellini wrote:

On Wed, 11 May 2016, Arnd Bergmann wrote:

A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
are there:

drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
'static' but never defined [-Werror=unused-function]
 static void release_memory_resource(struct resource *resource);

This removes the declaration again and instead moves the function
definition to the right place, before its first caller and inside
of the #ifdef protecting both.

The patch that introduced the warning is marked for stable
backports, so if that gets applied to 4.4, so should this one.

Signed-off-by: Arnd Bergmann 
Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE")
Cc: sta...@vger.kernel.org


Reviewed-by: Stefano Stabellini 


You have applied this patch to the branch for-linus-4.8 but not 
for-linus-4.7. Is it intentional?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94787: trouble: blocked/broken

[osstest service owner]

flight 94787 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94787/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  109 days
Testing same since93977  2016-05-10 11:09:16 Z   15 days   60 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-unstable test] 94780: tolerable FAIL - PUSHED

[osstest service owner]

flight 94780 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94780/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 94756
 build-amd64-rumpuserxen   6 xen-buildfail   like 94756
 build-i386-rumpuserxen6 xen-buildfail   like 94756
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94756
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94756
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94756
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94756

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33
baseline version:
 xen  4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51

Last test of basis94756  2016-05-25 06:32:18 Z1 days
Failing since 94770  2016-05-25 17:11:38 Z0 days2 attempts
Testing same since94780  2016-05-26 01:19:56 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Ian Jackson 
  Julien Grall 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass

Re: [Xen-devel] [for-4.7 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

[Julien Grall]

Hi Stefano,

On 26/05/2016 10:18, Stefano Stabellini wrote:

On Wed, 25 May 2016, Julien Grall wrote:

On 25/05/16 14:14, Jan Beulich wrote:

Also - is Device_nGnRE a term uniform between ARM32 and ARM64?


Actually it should be Device-nGnRE to match with the spec. This has been
introduced on Armv8. Previously for Armv7, the name was "Device", although the
behavior is exactly the same.

I could say:

"ARM only; the region will be mapped in Stage-2 using the memory attribute
'Device-nGnRE' (previously named 'Device' on ARMv7)".


Small nit: I would say "the region gets mapped" or "is mapped" rather
than "will be" because that makes me think that it is a future behavior
of following Xen releases rather than the current behavior.


Good idea. I sent a v2 yesterday night [1]. So I will fix in the v3.


Acked-by: Stefano Stabellini 


[1] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02490.html

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [for-4.7 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

[Stefano Stabellini]

On Wed, 25 May 2016, Julien Grall wrote:
> Hi Jan,
> 
> On 25/05/16 14:14, Jan Beulich wrote:
> > > > > On 25.05.16 at 13:41,  wrote:
> > > --- a/xen/include/public/memory.h
> > > +++ b/xen/include/public/memory.h
> > > @@ -220,7 +220,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> > >   #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap
> > > only. */
> > >   #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
> > >   * XENMEM_add_to_physmap_batch only.
> > > */
> > > -#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
> > > +#define XENMAPSPACE_dev_mmio 5 /* device mmio region
> > > +  On ARM, the region will be mapped
> > > +  in stage-2 using the memory
> > > attribute
> > > +  Device_nGnRE. */
> > 
> > Since this is unimplemented on x86, may I suggest to make this "ARM
> > only; the region will be ..."?
> 
> Sounds good.
> 
> > 
> > Also - is Device_nGnRE a term uniform between ARM32 and ARM64?
> 
> Actually it should be Device-nGnRE to match with the spec. This has been
> introduced on Armv8. Previously for Armv7, the name was "Device", although the
> behavior is exactly the same.
> 
> I could say:
> 
> "ARM only; the region will be mapped in Stage-2 using the memory attribute
> 'Device-nGnRE' (previously named 'Device' on ARMv7)".

Small nit: I would say "the region gets mapped" or "is mapped" rather
than "will be" because that makes me think that it is a future behavior
of following Xen releases rather than the current behavior.

Acked-by: Stefano Stabellini 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] xen-hvm: ignore background I/O sections

[Stefano Stabellini]

On Wed, 25 May 2016, Paolo Bonzini wrote:
> > From: "Anthony PERARD" 
> > To: "Paul Durrant" 
> > Cc: qemu-de...@nongnu.org, xen-de...@lists.xenproject.org, "Stefano 
> > Stabellini" , "Paolo
> > Bonzini" 
> > Sent: Wednesday, May 25, 2016 5:52:32 PM
> > Subject: Re: [PATCH v3] xen-hvm: ignore background I/O sections
> > 
> > On Mon, May 09, 2016 at 05:31:20PM +0100, Paul Durrant wrote:
> > > Since Xen will correctly handle accesses to unimplemented I/O ports (by
> > > returning all 1's for reads and ignoring writes) there is no need for
> > > QEMU to register backgroud I/O sections.
> > > 
> > > This patch therefore adds checks to xen_io_add/del so that sections with
> > > memory-region ops pointing at 'unassigned_io_ops' are ignored.
> > > 
> > > Signed-off-by: Paul Durrant 
> > > Cc: Stefano Stabellini 
> > > Cc: Anthony Perard 
> > > Cc: Paolo Bonzini 
> > 
> > Acked-by: Anthony PERARD 
> 
> Do you have a signed GPG key or do I need to apply this for you?

I was going to say, I'll just queue this up in my tree, but I don't have
any other commits at this time, so if you are OK with applying this, I
am fine with it too.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] ARM Xen Bug #45: Is there a solution?

[Julien Grall]

On 25/05/2016 16:10, Dirk Behme wrote:

Hi Julien,


Hello Dirk,


On 24.05.2016 22:05, Julien Grall wrote:



On 24/05/2016 14:39, Dirk Behme wrote:

Hi Julien,


Hello Dirk,


On 23.05.2016 22:15, Julien Grall wrote:

Hello Dirk,


is there a solution for

arm: domain 0 disables clocks which are in fact being used
http://bugs.xenproject.org/xen/bug/45

?

On an ARM based board I have to use 'clk_ignore_unused' preventing
that
Dom0 disables the UART clock for the console UART configured with
console=hvc0.


There is no better solution than passing "clk_ignore_unused" on the
kernel command line so far.



What would be the solution for this issue? The

"propagate any clock related properties from the UART
node into the Xen hypervisor node"

mentioned in the ticket?


That is correct. Xen would copy the property "clocks" of the UART into
the hypervisor node.

DOM0 would then parse the clocks associated to this node and mark them
as used by Xen (I think CLK_IGNORE_UNUSED could do the job for us).



I've started to look into this:

I'd think in arm_uart.c in dt_uart_init() after

if ( !dev )

we know the UART node we are looking for. From this we have to read the
clock configuration.

To be clarified: How to read the clock configuration? I couldn't find
any convenient function dt_device_get_clock() or similar for that.


Xen does not need to parse the content of the property "clocks" but copy 
the raw value to the DOM0 DT.


You cand find the value of a property with dt_get_property.



Now, we have the clocks we are looking for.

These are needed in domain_build.c in make_hypervisor_node(), then.

To be clarified: How to pass the clock configuration from arm_uart.c to
domain_build.c (and not break the non-dt / non-ARM platforms)?

Any ideas or comments?


All the devices (UART included) used by Xen will return DOMID_XEN when 
dt_device_used_by is called to the node.


You could use it to collect the clocks of all those devices and gather 
the value in a single property to be created in the hypervisor node.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Dong, Eddie]

If enabling virtual Q35 solves the problem, it has the advantage: When more and 
more virtual IOMMU feature comes (likely), we can reuse the KVM code for Xen.
How big is the effort for virtual Q35?

Thx Eddie

> -Original Message-
> From: Lan, Tianyu
> Sent: Thursday, May 26, 2016 4:30 PM
> To: jbeul...@suse.com; sstabell...@kernel.org; ian.jack...@eu.citrix.com;
> xen-de...@lists.xensource.com; Tian, Kevin ; Dong,
> Eddie ; Nakajima, Jun ;
> yang.zhang...@gmail.com; anthony.per...@citrix.com
> Subject: Discussion about virtual iommu support for Xen guest
> 
> Hi All:
> We try pushing virtual iommu support for Xen guest and there are some
> features blocked by it.
> 
> Motivation:
> ---
> 1) Add SVM(Shared Virtual Memory) support for Xen guest To support iGFX
> pass-through for SVM enabled devices, it requires virtual iommu support to
> emulate related registers and intercept/handle guest SVM configure in the
> VMM.
> 
> 2) Increase max vcpu support for one VM.
> 
> So far, max vcpu for Xen hvm guest is 128. For HPC(High Performance
> Computing) cloud computing, it requires more vcpus support in a single VM.
> The usage model is to create just one VM on a machine with the same number
> vcpus as logical cpus on the host and pin vcpu on each logical cpu in order 
> to get
> good compute performance.
> 
> Intel Xeon phi KNL(Knights Landing) is dedicated to HPC market and supports
> 288 logical cpus. So we hope VM can support 288 vcpu to meet HPC
> requirement.
> 
> Current Linux kernel requires IR(interrupt remapping) when MAX APIC ID is >
> 255 because interrupt only can be delivered among 0~255 cpus without IR. IR in
> VM relies on the virtual iommu support.
> 
> KVM Virtual iommu support status
> 
> Current, Qemu has a basic virtual iommu to do address translation for virtual
> device and it only works for the Q35 machine type. KVM reuses it and Redhat is
> adding IR to support more than 255 vcpus.
> 
> How to add virtual iommu for Xen?
> -
> First idea came to my mind is to reuse Qemu virtual iommu but Xen didn't
> support Q35 so far. Enabling Q35 for Xen seems not a short term task.
> Anthony did some related jobs before.
> 
> I'd like to see your comments about how to implement virtual iommu for Xen.
> 
> 1) Reuse Qemu virtual iommu or write a separate one for Xen?
> 2) Enable Q35 for Xen to reuse Qemu virtual iommu?
> 
> Your comments are very appreciated. Thanks a lot.
> --
> Best regards
> Tianyu Lan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Question about the usage of spinlock

[조현권]

Hi

I am studying xen 4.6.0 version now and wonder the usage of spinlock which
is located in free_heap_pages(xen/common/page_alloc. c)

As its memory setup is ahead of multicore initialization, spinlock seems to
be unnecessary during booting because it uses only single core

spinlock looks required after multicore initialization finished and when
xen needs to free memory space during work

However i experimented not to use spin lock in free_heap_pages and
dom0(linux-kernel) was booted well. It does not cause any error using
internet or application program even reboot

Are therr any special reason to use spinlock?

My experiment environment was ODROID-XU4 which uses arm architecture

Thabk you
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: RTDS: fix another instance of the 'read NOW()' race

[George Dunlap]

On 24/05/16 16:06, Dario Faggioli wrote:
> which was overlooked in 779511f4bf5ae ("sched: avoid
> races on time values read from NOW()").
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

> ---
> Cc: Meng Xu 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Wei Liu 
> ---
>  xen/common/sched_rt.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 0946101..5b077d7 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -840,12 +840,14 @@ static void
>  rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct rt_vcpu *svc = rt_vcpu(vc);
> -s_time_t now = NOW();
> +s_time_t now;
>  spinlock_t *lock;
>  
>  BUG_ON( is_idle_vcpu(vc) );
>  
>  lock = vcpu_schedule_lock_irq(vc);
> +
> +now = NOW();
>  if ( now >= svc->cur_deadline )
>  rt_update_deadline(now, svc);
>  
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Discussion about virtual iommu support for Xen guest

[Lan Tianyu]

Hi All:
We try pushing virtual iommu support for Xen guest and there are some
features blocked by it.

Motivation:
---
1) Add SVM(Shared Virtual Memory) support for Xen guest
To support iGFX pass-through for SVM enabled devices, it requires
virtual iommu support to emulate related registers and intercept/handle
guest SVM configure in the VMM.

2) Increase max vcpu support for one VM.

So far, max vcpu for Xen hvm guest is 128. For HPC(High Performance
Computing) cloud computing, it requires more vcpus support in a single
VM. The usage model is to create just one VM on a machine with the
same number vcpus as logical cpus on the host and pin vcpu on each
logical cpu in order to get good compute performance.

Intel Xeon phi KNL(Knights Landing) is dedicated to HPC market and
supports 288 logical cpus. So we hope VM can support 288 vcpu
to meet HPC requirement.

Current Linux kernel requires IR(interrupt remapping) when MAX APIC
ID is > 255 because interrupt only can be delivered among 0~255 cpus
without IR. IR in VM relies on the virtual iommu support.

KVM Virtual iommu support status

Current, Qemu has a basic virtual iommu to do address translation for
virtual device and it only works for the Q35 machine type. KVM reuses it
and Redhat is adding IR to support more than 255 vcpus.

How to add virtual iommu for Xen?
-
First idea came to my mind is to reuse Qemu virtual iommu but Xen didn't
support Q35 so far. Enabling Q35 for Xen seems not a short term task.
Anthony did some related jobs before.

I'd like to see your comments about how to implement virtual iommu for Xen.

1) Reuse Qemu virtual iommu or write a separate one for Xen?
2) Enable Q35 for Xen to reuse Qemu virtual iommu?

Your comments are very appreciated. Thanks a lot.
-- 
Best regards
Tianyu Lan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 3/6] build: convert verbose to Kconfig

[Julien Grall]

Hi Doug,

On 24/05/2016 14:56, Doug Goldstein wrote:

Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 


Acked-by: Julien Grall 

Regards,


---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
---
 INSTALL | 1 -
 xen/Kconfig.debug   | 7 +++
 xen/Rules.mk| 6 +++---
 xen/arch/arm/kernel.c   | 2 +-
 xen/arch/x86/domain_build.c | 2 +-
 xen/include/xsm/dummy.h | 2 +-
 6 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/INSTALL b/INSTALL
index 2974b9b..35668bd 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "

 The following variables can be used to tweak some aspects of the
 hypervisor build.
-verbose=y
 perfc=y
 perfc_arrays=y
 lock_profile=y
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 8eeb13f..fb11c56 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -20,6 +20,13 @@ config CRASH_DEBUG
  If you want to attach gdb to Xen to debug Xen if it crashes
  then say Y.

+config VERBOSE_DEBUG
+   bool "Verbose debug messages"
+   default DEBUG
+   ---help---
+ Guest output from HYPERVISOR_console_io and hypervisor parsing
+ ELF images (dom0) will be logged in the Xen ring buffer.
+
 endif # DEBUG || EXPERT

 endmenu
diff --git a/xen/Rules.mk b/xen/Rules.mk
index b077e25..2a93ef7 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,7 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-verbose   ?= n
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
@@ -17,7 +16,6 @@ include $(XEN_ROOT)/Config.mk
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
 ifeq ($(debug),y)
-verbose   := y
 frame_pointer := y
 endif
 ifeq ($(perfc_arrays),y)
@@ -33,6 +31,9 @@ endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
+ifneq ($(origin verbose),undefined)
+$(error "You must use 'make menuconfig' to enable/disable verbose now.")
+endif

 # Set ARCH/SUBARCH appropriately.
 override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
@@ -60,7 +61,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif

-CFLAGS-$(verbose)   += -DVERBOSE
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9871bd9..3f6cce3 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -472,7 +472,7 @@ static int kernel_elf_probe(struct kernel_info *info,

 if ( (rc = elf_init(>elf.elf, info->elf.kernel_img, size )) != 0 )
 goto err;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose(>elf.elf);
 #endif
 elf_parse_binary(>elf.elf);
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index f9a3eca..b29c377 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -942,7 +942,7 @@ int __init construct_dom0(

 if ( (rc = elf_init(, image_start, image_len)) != 0 )
 return rc;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose();
 #endif
 elf_parse_binary();
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index abbe282..406cd18 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -215,7 +215,7 @@ static XSM_INLINE int 
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
 static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_OTHER);
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 if ( cmd == CONSOLEIO_write )
 return xsm_default_action(XSM_HOOK, d, NULL);
 #endif



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 25 May 2016 21:58
> To: Paul Durrant; zhigang.x.w...@oracle.com
> Cc: Wei Liu; Olaf Hering; Stefano Stabellini; Andrew Cooper; xen-
> de...@lists.xen.org; Anthony Perard
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
> 
> On Thu, May 12, 2016 at 02:13:21PM +, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > >
> > > > Ok. Do you regard this as a critical issue for 4.7?
> > > >
> > >
> > > Our general support statement is to support N->N+1 migration, so it is
> > > not really critical for me. On the other hand, if the fix is not overly
> > > complex, it would be nice to have for 4.7.
> > >
> > > Note that the fix will need to be in upstream QEMU first before it can
> > > be cherry-picked to our tree, so there is risk that it might just be
> > > blocked on QEMU side (I haven't checked their schedule). So I wouldn't
> > > really block xen release just for that.
> > >
> >
> > Ok.
> >
> > > If for some reason (either you don't have time or the patch is blocked
> > > on QEMU side) the fix doesn't make 4.7.0 I would suggest QEMU
> maintainer
> > > to backport to 4.7.1 etc.
> > >
> >
> > I'll try to get to it as soon as I can, but my guess is that it will miss 
> > 4.7.0.
> 
> +CC Zhigang.
> 
> Any ideas on the timeline for this fix? Thanks!

It's likely to be a while before I could find some time for this; rough guess 
would be a month... It depends how other stuff pans out.

  Paul

> >
> >   Paul
> >
> > ___
> > 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 v3 3/3] AMD IOMMU: Check io_handler before registering mmio handler

[Paul Durrant]

> -Original Message-
> From: Suravee Suthikulanit [mailto:suravee.suthikulpa...@amd.com]
> Sent: 25 May 2016 19:52
> To: Paul Durrant; xen-devel@lists.xen.org; jbeul...@suse.com; George
> Dunlap
> Cc: Keir (Xen.org)
> Subject: Re: [PATCH v3 3/3] AMD IOMMU: Check io_handler before
> registering mmio handler
> 
> On 5/23/2016 3:23 AM, Paul Durrant wrote:
> >> -Original Message-
> >> > From: suravee.suthikulpa...@amd.com
> >> > [mailto:suravee.suthikulpa...@amd.com]
> >> > Sent: 22 May 2016 00:43
> >> > To: xen-devel@lists.xen.org; Paul Durrant; jbeul...@suse.com; George
> >> > Dunlap
> >> > Cc: Keir (Xen.org); Suravee Suthikulpanit; Suravee Suthikulapanit
> >> > Subject: [PATCH v3 3/3] AMD IOMMU: Check io_handler before
> registering
> >> > mmio handler
> >> >
> >> > From: Suravee Suthikulpanit 
> >> >
> >> > guest_iommu_init tries to register mmio handler before HVM domain
> >> > is initialized. This cause registration to silently failing.
> >> > This patch adds a sanitiy check and puts out error message.
> >> >
> >> > Signed-off-by: Suravee Suthikulapanit
> 
> > This patch is now defunct isn't it?
> >
> >   Paul
> >
> 
> It is no longer required, but I think this is a good sanity check in
> case something changes in the future and causing this to be called
> before the HVM I/O handler initialized.

Maybe, but shouldn't it result in a domain_crash()?

  Paul

> 
> Thanks,
> Suravee

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/mce: handle DOMID_XEN properly in XEN_MC_msrinject

[Haozhong Zhang]

On 05/26/16 09:15, Egger, Christoph wrote:
> On 26/05/16 03:07, Haozhong Zhang wrote:
> > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> > address" forgot to consider dom_xen, which fails tools/xen-mceinj when
> > it's going to inject into domain DOMID_XEN (e.g. when -d option is not
> > used) via XEN_MC_msrinject. Use dom_xen when the domain id DOMID_XEN is
> > passed in.
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Why not also consider DOMID_IO, DOMID_COW, DOMID_INVALID ?
> In "nature" a memory error can happen everywhere anytime.
>

This is to align to the original behavior before commit 26646f3 and a
later commit 4ddf474 "tools/xen-mceinj: Pass in GPA when injecting
through MSR_MCI_ADDR", which only supported injecting MCE of address
belonging to domains whose id is <= DOMID_FIRST_RESERVED (0x7FF0) or
DOMID_XEN (0x7FF2).

And I just found the fix in this patch is invalid. If a domain id >
DOMID_FIRST_RESERVED is passed, XEN_MC_msrinject should ensure that
MC_MSRINJ_F_GPADDR is not set in mc_msrinject->mcinj_flags and treat
the address passed-in as machine physical address (i.e. skip the
address translation in XEN_MCE_msrinject). In this way, DOMID_XEN,
DOMID_COW and DOMID_INVALID can be handled properly.

Thanks,
Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/4] xen/arm: Change the variable type of cpu_logical_map to register_t

[Wei Chen]

The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. While Xen is running on ARM64, the
hardware ID expands to 64-bits and then the cpu_logical_map will overflow.

Change the variable type of cpu_logical_map to register_t will make
cpu_logical_map to store hardware IDs correctly on ARM32 and ARM64.

Signed-off-by: Wei Chen 
Acked-by: Julien Grall 
---
v2: 
1. Fix typos in commit messages that were commented by Julien.
2. Add Julien's Acked-by.
---
 xen/arch/arm/gic-v3.c   |  2 +-
 xen/arch/arm/smpboot.c  | 13 +++--
 xen/include/asm-arm/processor.h |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..9910877 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -674,7 +674,7 @@ static int __init gicv3_populate_rdist(void)
 } while ( !(typer & GICR_TYPER_LAST) );
 }
 
-dprintk(XENLOG_ERR, "GICv3: CPU%d: mpidr 0x%x has no re-distributor!\n",
+dprintk(XENLOG_ERR, "GICv3: CPU%d: mpidr 0x%"PRIregister" has no 
re-distributor!\n",
 smp_processor_id(), cpu_logical_map(smp_processor_id()));
 
 return -ENODEV;
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c5109bf..ba83406 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -40,7 +40,7 @@ cpumask_t cpu_possible_map;
 struct cpuinfo_arm cpu_data[NR_CPUS];
 
 /* CPU logical map: map xen cpuid to an MPIDR */
-u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
+register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
 
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
@@ -100,7 +100,7 @@ static void __init dt_smp_init_cpus(void)
 struct dt_device_node *cpu;
 unsigned int i, j;
 unsigned int cpuidx = 1;
-static u32 tmp_map[NR_CPUS] __initdata =
+static register_t tmp_map[NR_CPUS] __initdata =
 {
 [0 ... NR_CPUS - 1] = MPIDR_INVALID
 };
@@ -120,7 +120,8 @@ static void __init dt_smp_init_cpus(void)
 {
 const __be32 *prop;
 u64 addr;
-u32 reg_len, hwid;
+u32 reg_len;
+register_t hwid;
 
 if ( !dt_device_type_is_equal(cpu, "cpu") )
 continue;
@@ -160,7 +161,7 @@ static void __init dt_smp_init_cpus(void)
  */
 if ( hwid & ~MPIDR_HWID_MASK )
 {
-printk(XENLOG_WARNING "cpu node `%s`: invalid hwid value (0x%x)\n",
+printk(XENLOG_WARNING "cpu node `%s`: invalid hwid value 
(0x%"PRIregister")\n",
dt_node_full_name(cpu), hwid);
 continue;
 }
@@ -176,7 +177,7 @@ static void __init dt_smp_init_cpus(void)
 if ( tmp_map[j] == hwid )
 {
 printk(XENLOG_WARNING
-   "cpu node `%s`: duplicate /cpu reg properties %"PRIx32" 
in the DT\n",
+   "cpu node `%s`: duplicate /cpu reg properties 
%"PRIregister" in the DT\n",
dt_node_full_name(cpu), hwid);
 break;
 }
@@ -211,7 +212,7 @@ static void __init dt_smp_init_cpus(void)
 
 if ( (rc = arch_cpu_init(i, cpu)) < 0 )
 {
-printk("cpu%d init failed (hwid %x): %d\n", i, hwid, rc);
+printk("cpu%d init failed (hwid %"PRIregister"): %d\n", i, hwid, 
rc);
 tmp_map[i] = MPIDR_INVALID;
 }
 else
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 6789cd0..7de9c8e 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -348,7 +348,7 @@ extern void identify_cpu(struct cpuinfo_arm *);
 extern struct cpuinfo_arm cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
 
-extern u32 __cpu_logical_map[];
+extern register_t __cpu_logical_map[];
 #define cpu_logical_map(cpu) __cpu_logical_map[cpu]
 
 /* HSR data abort size definition */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 2/4] xen/arm: Make AFFINITY_MASK generate correct mask for level3

[Wei Chen]

The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to generate correct
mask for level3.

Signed-off-by: Wei Chen 
Reviewed-by: Julien Grall 
---
v2: Add Julien's reviewed-by.
---
 xen/include/asm-arm/processor.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 7de9c8e..b4cce7e 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -21,7 +21,6 @@
 #define MPIDR_HWID_MASK _AC(0xff,U)
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
-#define AFFINITY_MASK(level)~((_AC(0x1,U) << ((level) * MPIDR_LEVEL_BITS)) 
- 1)
 
 
 /*
@@ -37,6 +36,8 @@
 #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
  ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
 
+#define AFFINITY_MASK(level)~((_AC(0x1,UL) << MPIDR_LEVEL_SHIFT(level)) - 
1)
+
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE_AC(0x8000,U)
 #define TTBCR_N_MASK _AC(0x07,U)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

[Wei Chen]

In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
as 32-bit register.
We have to provide correct accessing to this register to avoid
unexpected issues that is caused by incorrect MPIDR value.

Wei Chen (4):
  xen/arm: Change the variable type of cpu_logical_map to register_t
  xen/arm: Make AFFINITY_MASK generate correct mask for level3
  xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
  xen/arm: arm64: Remove MPIDR multiprocessing extensions check

 xen/arch/arm/arm64/head.S   |  3 +--
 xen/arch/arm/gic-v3.c   |  2 +-
 xen/arch/arm/smpboot.c  | 13 +++--
 xen/include/asm-arm/processor.h |  9 +++--
 4 files changed, 16 insertions(+), 11 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 3/4] xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64

[Wei Chen]

Currently, MPIDR_HWID_MASK is using the bit definition of AArch32 MPIDR.
From ARMv8 ARM we can see there are 4 levels of affinity on AArch64
whilst AArch32 has only 3. So, this value is not correct when Xen is
running on AArch64.

Now, we use the value 0xff00ff for this macro on AArch64. But neither
of this value and its bitwise invert value can be used in mov instruction
with the encoding of {imm16:shift} or {imms:immr}. So we have to use ldr
to load the bitwise invert value to register.

The details of mov immediate encoding are listed in ARMv8 ARM C4.2.5.

Signed-off-by: Wei Chen 
---
v2: Address Julien's comments
1. Fix typos in commit messages.
2. Explain valid MPIDR_HWID_MASK value in AArch64.
3. Simply explain mov immediate encoding.
---
 xen/arch/arm/arm64/head.S   | 2 +-
 xen/include/asm-arm/processor.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index d5831f2..3090beb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -270,7 +270,7 @@ common_start:
 tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
-mov   x13, #(~MPIDR_HWID_MASK)
+ldr   x13, =(~MPIDR_HWID_MASK)
 bic   x24, x0, x13   /* Mask out flags to get CPU ID */
 1:
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index b4cce7e..284ad6a 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -18,7 +18,11 @@
 #define MPIDR_SMP   (_AC(1,U) << _MPIDR_SMP)
 #define MPIDR_AFF0_SHIFT(0)
 #define MPIDR_AFF0_MASK (_AC(0xff,U) << MPIDR_AFF0_SHIFT)
+#ifdef CONFIG_ARM_64
+#define MPIDR_HWID_MASK _AC(0xff00ff,UL)
+#else
 #define MPIDR_HWID_MASK _AC(0xff,U)
+#endif
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 4/4] xen/arm: arm64: Remove MPIDR multiprocessing extensions check

[Wei Chen]

In AArch32, MPIDR bit31 is defined as multiprocessing extensions bit.
But in AArch64, this bit is always RES1. So the value check for this
bit is no longer necessary in AArch64.

Signed-off-by: Wei Chen 
---
v2: Make clear the status of MPIDR.SMP bit in AArch32 and AArch64.
---
 xen/arch/arm/arm64/head.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 3090beb..91e2817 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -267,7 +267,6 @@ common_start:
   * find that multiprocessor extensions are
   * present and the system is SMP  */
 mrs   x0, mpidr_el1
-tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
 ldr   x13, =(~MPIDR_HWID_MASK)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/mce: handle DOMID_XEN properly in XEN_MC_msrinject

[Egger, Christoph]

On 26/05/16 03:07, Haozhong Zhang wrote:
> Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> address" forgot to consider dom_xen, which fails tools/xen-mceinj when
> it's going to inject into domain DOMID_XEN (e.g. when -d option is not
> used) via XEN_MC_msrinject. Use dom_xen when the domain id DOMID_XEN is
> passed in.
> 
> Signed-off-by: Haozhong Zhang 

Why not also consider DOMID_IO, DOMID_COW, DOMID_INVALID ?
In "nature" a memory error can happen everywhere anytime.

Christoph

> ---
>  xen/arch/x86/cpu/mcheck/mce.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index cc446eb..65de627 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1427,17 +1427,18 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
>  
>  if ( mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR )
>  {
> -struct domain *d;
> +domid_t domid = mc_msrinject->mcinj_domid;
> +struct domain *d = (domid == DOMID_XEN) ?
> +   dom_xen : get_domain_by_id(domid);
>  struct mcinfo_msr *msr;
>  unsigned int i;
>  paddr_t gaddr;
>  unsigned long gfn, mfn;
>  p2m_type_t t;
>  
> -d = get_domain_by_id(mc_msrinject->mcinj_domid);
>  if ( d == NULL )
>  return x86_mcerr("do_mca inject: bad domain id %d",
> - -EINVAL, mc_msrinject->mcinj_domid);
> + -EINVAL, domid);
>  
>  for ( i = 0, msr = _msrinject->mcinj_msr[0];
>i < mc_msrinject->mcinj_count;
> @@ -1452,7 +1453,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
>  put_gfn(d, gfn);
>  put_domain(d);
>  return x86_mcerr("do_mca inject: bad gfn %#lx of domain 
> %d",
> - -EINVAL, gfn, 
> mc_msrinject->mcinj_domid);
> + -EINVAL, gfn, domid);
>  }
>  
>  msr->value = pfn_to_paddr(mfn) | (gaddr & (PAGE_SIZE - 1));
> 

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel