* [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
@ 2017-02-19 23:20 osstest service owner
2017-02-20 0:20 ` Andrew Cooper
0 siblings, 1 reply; 9+ messages in thread
From: osstest service owner @ 2017-02-19 23:20 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: ab914e04a62727b75782e401eaf2e8b72f717f61
Bug not present: 2f4d2198a9b3ba94c959330b5c94fe95917c364c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105915/
commit ab914e04a62727b75782e401eaf2e8b72f717f61
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Feb 17 15:51:03 2017 +0100
x86: package up context switch hook pointers
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_tail() in the only two places invoking it, allowing the macro
to be dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-start --summary-out=tmp/105917.bisection-summary --basis-template=59254 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvh-intel guest-start
Searching for failure / basis pass:
105905 fail [host=fiano0] / 105897 ok.
Failure / basis pass flights: 105905 / 105897
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
Basis pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 7127d53fe891f9ea67357587a33a7aaba4b55f45
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#6dc39c50e4aeb769c8ae06edf2b1a732f3490913-00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#b669e922b37b8957248798a5eb7aa96a666cd3fe-b669e922b37b8957248798a5eb7aa96a666cd3fe git://xenbits.xen.org/qemu-xen.git#e88462aaa2f19e1238e77c1bcebbab7ef5380d7a-08c008de9c7d3ac71f71c87cc04a47819ca228dc git://xenbits.xen.org/xen.git#7127d53fe891f9ea67357587a33a7aaba4b55f45-75da1b150e646bb9aaa26c5b2452f0c3e782d302
From git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
137d01d..c470abd master -> origin/master
* [new tag] v4.10 -> v4.10
Loaded 493033 nodes in revision graph
Searching for test results:
105910 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 2f4d2198a9b3ba94c959330b5c94fe95917c364c
105893 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 7127d53fe891f9ea67357587a33a7aaba4b55f45
105911 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a ab914e04a62727b75782e401eaf2e8b72f717f61
105897 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 7127d53fe891f9ea67357587a33a7aaba4b55f45
105898 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
105912 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 2f4d2198a9b3ba94c959330b5c94fe95917c364c
105913 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a ab914e04a62727b75782e401eaf2e8b72f717f61
105901 fail 2763f92f858f7c4c3198335c0542726eaed07ba3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
105914 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 2f4d2198a9b3ba94c959330b5c94fe95917c364c
105905 fail 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
105904 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 7127d53fe891f9ea67357587a33a7aaba4b55f45
105915 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a ab914e04a62727b75782e401eaf2e8b72f717f61
105906 fail 2763f92f858f7c4c3198335c0542726eaed07ba3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
105907 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a b8932b138578a9583645e29e636b38d9d4a43637
105916 pass 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 7127d53fe891f9ea67357587a33a7aaba4b55f45
105908 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a fe416bf9957669e34e93a614970546b3a002f0e8
105909 fail 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 71af7d4220227529ea43b898683d4d2e68a90ffd
105917 fail 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 75da1b150e646bb9aaa26c5b2452f0c3e782d302
Searching for interesting versions
Result found: flight 105893 (pass), for basis pass
Result found: flight 105905 (fail), for basis failure
Repro found: flight 105916 (pass), for basis pass
Repro found: flight 105917 (fail), for basis failure
0 revisions at 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 2f4d2198a9b3ba94c959330b5c94fe95917c364c
No revisions left to test, checking graph state.
Result found: flight 105910 (pass), for last pass
Result found: flight 105911 (fail), for first failure
Repro found: flight 105912 (pass), for last pass
Repro found: flight 105913 (fail), for first failure
Repro found: flight 105914 (pass), for last pass
Repro found: flight 105915 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: ab914e04a62727b75782e401eaf2e8b72f717f61
Bug not present: 2f4d2198a9b3ba94c959330b5c94fe95917c364c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105915/
commit ab914e04a62727b75782e401eaf2e8b72f717f61
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Feb 17 15:51:03 2017 +0100
x86: package up context switch hook pointers
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_tail() in the only two places invoking it, allowing the macro
to be dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-start.{dot,ps,png,html,svg}.
----------------------------------------
105917: tolerable ALL FAIL
flight 105917 linux-linus real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/105917/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail baseline untested
jobs:
test-amd64-amd64-xl-pvh-intel 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
2017-02-19 23:20 [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel osstest service owner
@ 2017-02-20 0:20 ` Andrew Cooper
2017-02-20 0:26 ` Andrew Cooper
2017-02-20 10:42 ` Removing PVHv1 code (was: Re: [linux-linus bisection] complete) test-amd64-amd64-xl-pvh-intel Roger Pau Monne
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Cooper @ 2017-02-20 0:20 UTC (permalink / raw)
To: osstest service owner, xen-devel
Cc: Ian Jackson, Boris Ostrovsky, Wei Liu, Jan Beulich, Roger Pau Monne
On 19/02/2017 23:20, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-pvh-intel
> testid guest-start
>
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: ab914e04a62727b75782e401eaf2e8b72f717f61
> Bug not present: 2f4d2198a9b3ba94c959330b5c94fe95917c364c
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105915/
>
>
> commit ab914e04a62727b75782e401eaf2e8b72f717f61
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Feb 17 15:51:03 2017 +0100
>
> x86: package up context switch hook pointers
>
> They're all solely dependent on guest type, so we don't need to repeat
> all the same three pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it anyway, take the opportunity and expand
> schedule_tail() in the only two places invoking it, allowing the macro
> to be dropped.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
From
http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
around Feb 19 23:12:06.269706
(XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 2
(XEN) RIP: e008:[<ffff82d08016795a>]
domain.c#__context_switch+0x1a3/0x3e3
(XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0)
(XEN) rax: 0000000000000000 rbx: 0000000000000002 rcx: 0000000000000000
(XEN) rdx: 00000031fd44b600 rsi: 0000000000000003 rdi: ffff83007de27000
(XEN) rbp: ffff83027d78fdb0 rsp: ffff83027d78fd60 r8: 0000000000000000
(XEN) r9: 0000005716f6126f r10: 0000000000007ff0 r11: 0000000000000246
(XEN) r12: ffff83007de27000 r13: ffff83027fb74000 r14: ffff83007dafd000
(XEN) r15: ffff83027d7c8000 cr0: 000000008005003b cr4: 00000000001526e0
(XEN) cr3: 000000007dd05000 cr2: 0000000000000008
(XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) Xen code around <ffff82d08016795a>
(domain.c#__context_switch+0x1a3/0x3e3):
(XEN) 85 68 07 00 00 4c 89 e7 <ff> 50 08 4c 89 ef e8 36 e1 02 00 41 80
bd 78 08
(XEN) Xen stack trace from rsp=ffff83027d78fd60:
(XEN) ffff83027d78ffff 0000000000000003 0000000000000000 0000000000000000
(XEN) 0000000000000000 ffff83007de27000 ffff83007dafd000 ffff83027fb74000
(XEN) 0000000000000002 ffff83027d7c8000 ffff83027d78fe20 ffff82d08016bf1f
(XEN) ffff82d080131ae2 ffff83027d78fde0 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 ffff83027d78fe20 ffff83007dafd000
(XEN) ffff83007de27000 0000005716f5e5da ffff83027d796148 0000000000000001
(XEN) ffff83027d78feb0 ffff82d08012def9 ffff83027d7955a0 ffff83027d796160
(XEN) 0000000200000004 ffff83027d796140 ffff83027d78fe70 ffff82d08014af39
(XEN) ffff83027d78fe70 ffff83007de27000 0000000001c9c380 ffff82d0801bf800
(XEN) 000000107dafd000 ffff82d080322b80 ffff82d080322a80 ffffffffffffffff
(XEN) ffff83027d78ffff ffff83027d780000 ffff83027d78fee0 ffff82d08013128f
(XEN) ffff83027d78ffff ffff83007dd4c000 ffff83027d7c8000 00000000ffffffff
(XEN) ffff83027d78fef0 ffff82d0801312e4 ffff83027d78ff10 ffff82d080167582
(XEN) ffff82d0801312e4 ffff83007dafd000 ffff83027d78fdc8 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) ffffffff82374000 0000000000000000 0000000000000000 ffffffff81f59180
(XEN) 0000000000000000 0000000000000200 ffffffff82390000 0000000000000000
(XEN) 0000000000000000 02ffff8000000000 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
(XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
(XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
(XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
(XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
(XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
(XEN)
(XEN) Pagetable walk from 0000000000000008:
(XEN) L4[0x000] = 000000027d7cd063 ffffffffffffffff
(XEN) L3[0x000] = 000000027d7cc063 ffffffffffffffff
(XEN) L2[0x000] = 000000027d7cb063 ffffffffffffffff
(XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000008
(XEN) ****************************************
(XEN)
We have followed the ->to() hook on a domain with a NULL ctxt_switch
pointer (confirmed by the disassembly). n is derived from current,
which is d1v0, but that would mean we are trying to schedule a vcpu
before its domain structure has been fully constructed.
The problem is with hvm_domain_initialise()
int hvm_domain_initialise(struct domain *d)
{
...
if ( is_pvh_domain(d) )
{
register_portio_handler(d, 0, 0x10003, handle_pvh_io);
return 0;
}
...
rc = hvm_funcs.domain_initialise(d);
...
}
So PVH domains exit hvm_domain_initialise() earlier than when we call
the vendor-specific initialisation hooks.
Rather than fixing this specific issue, can I suggest we properly kill
PVH v1 at this point? Given what else it skips in
hvm_domain_initialise(), it clearly hasn't functioned properly in the past.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
2017-02-20 0:20 ` Andrew Cooper
@ 2017-02-20 0:26 ` Andrew Cooper
2017-02-20 0:36 ` Andrew Cooper
2017-02-20 10:42 ` Removing PVHv1 code (was: Re: [linux-linus bisection] complete) test-amd64-amd64-xl-pvh-intel Roger Pau Monne
1 sibling, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2017-02-20 0:26 UTC (permalink / raw)
To: osstest service owner, xen-devel
Cc: Wei Liu, Boris Ostrovsky, Ian Jackson, Jan Beulich, Roger Pau Monne
On 20/02/2017 00:20, Andrew Cooper wrote:
> On 19/02/2017 23:20, osstest service owner wrote:
>> branch xen-unstable
>> xenbranch xen-unstable
>> job test-amd64-amd64-xl-pvh-intel
>> testid guest-start
>>
>> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>> Tree: xen git://xenbits.xen.org/xen.git
>>
>> *** Found and reproduced problem changeset ***
>>
>> Bug is in tree: xen git://xenbits.xen.org/xen.git
>> Bug introduced: ab914e04a62727b75782e401eaf2e8b72f717f61
>> Bug not present: 2f4d2198a9b3ba94c959330b5c94fe95917c364c
>> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105915/
>>
>>
>> commit ab914e04a62727b75782e401eaf2e8b72f717f61
>> Author: Jan Beulich <jbeulich@suse.com>
>> Date: Fri Feb 17 15:51:03 2017 +0100
>>
>> x86: package up context switch hook pointers
>>
>> They're all solely dependent on guest type, so we don't need to repeat
>> all the same three pointers in every vCPU control structure. Instead use
>> static const structures, and store pointers to them in the domain
>> control structure.
>>
>> Since touching it anyway, take the opportunity and expand
>> schedule_tail() in the only two places invoking it, allowing the macro
>> to be dropped.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> From
> http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
> around Feb 19 23:12:06.269706
>
> (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
> (XEN) CPU: 2
> (XEN) RIP: e008:[<ffff82d08016795a>]
> domain.c#__context_switch+0x1a3/0x3e3
> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0)
> (XEN) rax: 0000000000000000 rbx: 0000000000000002 rcx: 0000000000000000
> (XEN) rdx: 00000031fd44b600 rsi: 0000000000000003 rdi: ffff83007de27000
> (XEN) rbp: ffff83027d78fdb0 rsp: ffff83027d78fd60 r8: 0000000000000000
> (XEN) r9: 0000005716f6126f r10: 0000000000007ff0 r11: 0000000000000246
> (XEN) r12: ffff83007de27000 r13: ffff83027fb74000 r14: ffff83007dafd000
> (XEN) r15: ffff83027d7c8000 cr0: 000000008005003b cr4: 00000000001526e0
> (XEN) cr3: 000000007dd05000 cr2: 0000000000000008
> (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
> (XEN) Xen code around <ffff82d08016795a>
> (domain.c#__context_switch+0x1a3/0x3e3):
> (XEN) 85 68 07 00 00 4c 89 e7 <ff> 50 08 4c 89 ef e8 36 e1 02 00 41 80
> bd 78 08
> (XEN) Xen stack trace from rsp=ffff83027d78fd60:
> (XEN) ffff83027d78ffff 0000000000000003 0000000000000000 0000000000000000
> (XEN) 0000000000000000 ffff83007de27000 ffff83007dafd000 ffff83027fb74000
> (XEN) 0000000000000002 ffff83027d7c8000 ffff83027d78fe20 ffff82d08016bf1f
> (XEN) ffff82d080131ae2 ffff83027d78fde0 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 ffff83027d78fe20 ffff83007dafd000
> (XEN) ffff83007de27000 0000005716f5e5da ffff83027d796148 0000000000000001
> (XEN) ffff83027d78feb0 ffff82d08012def9 ffff83027d7955a0 ffff83027d796160
> (XEN) 0000000200000004 ffff83027d796140 ffff83027d78fe70 ffff82d08014af39
> (XEN) ffff83027d78fe70 ffff83007de27000 0000000001c9c380 ffff82d0801bf800
> (XEN) 000000107dafd000 ffff82d080322b80 ffff82d080322a80 ffffffffffffffff
> (XEN) ffff83027d78ffff ffff83027d780000 ffff83027d78fee0 ffff82d08013128f
> (XEN) ffff83027d78ffff ffff83007dd4c000 ffff83027d7c8000 00000000ffffffff
> (XEN) ffff83027d78fef0 ffff82d0801312e4 ffff83027d78ff10 ffff82d080167582
> (XEN) ffff82d0801312e4 ffff83007dafd000 ffff83027d78fdc8 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) ffffffff82374000 0000000000000000 0000000000000000 ffffffff81f59180
> (XEN) 0000000000000000 0000000000000200 ffffffff82390000 0000000000000000
> (XEN) 0000000000000000 02ffff8000000000 0000000000000000 0000000000000000
> (XEN) Xen call trace:
> (XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
> (XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
> (XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
> (XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
> (XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
> (XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
> (XEN)
> (XEN) Pagetable walk from 0000000000000008:
> (XEN) L4[0x000] = 000000027d7cd063 ffffffffffffffff
> (XEN) L3[0x000] = 000000027d7cc063 ffffffffffffffff
> (XEN) L2[0x000] = 000000027d7cb063 ffffffffffffffff
> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 2:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 0000000000000008
> (XEN) ****************************************
> (XEN)
>
> We have followed the ->to() hook on a domain with a NULL ctxt_switch
> pointer (confirmed by the disassembly). n is derived from current,
> which is d1v0, but that would mean we are trying to schedule a vcpu
> before its domain structure has been fully constructed.
>
> The problem is with hvm_domain_initialise()
>
> int hvm_domain_initialise(struct domain *d)
> {
> ...
> if ( is_pvh_domain(d) )
> {
> register_portio_handler(d, 0, 0x10003, handle_pvh_io);
> return 0;
> }
> ...
> rc = hvm_funcs.domain_initialise(d);
> ...
> }
>
> So PVH domains exit hvm_domain_initialise() earlier than when we call
> the vendor-specific initialisation hooks.
>
> Rather than fixing this specific issue, can I suggest we properly kill
> PVH v1 at this point? Given what else it skips in
> hvm_domain_initialise(), it clearly hasn't functioned properly in the past.
P.S. Ian: Why did this failure not block at the push gate?
It is a completely repeatable host crash, yet master has been pulled up
to match staging.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
2017-02-20 0:26 ` Andrew Cooper
@ 2017-02-20 0:36 ` Andrew Cooper
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2017-02-20 0:36 UTC (permalink / raw)
To: osstest service owner, xen-devel
Cc: Ian Jackson, Boris Ostrovsky, Wei Liu, Jan Beulich, Roger Pau Monne
On 20/02/2017 00:26, Andrew Cooper wrote:
> On 20/02/2017 00:20, Andrew Cooper wrote:
>> On 19/02/2017 23:20, osstest service owner wrote:
>>> branch xen-unstable
>>> xenbranch xen-unstable
>>> job test-amd64-amd64-xl-pvh-intel
>>> testid guest-start
>>>
>>> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>> Tree: xen git://xenbits.xen.org/xen.git
>>>
>>> *** Found and reproduced problem changeset ***
>>>
>>> Bug is in tree: xen git://xenbits.xen.org/xen.git
>>> Bug introduced: ab914e04a62727b75782e401eaf2e8b72f717f61
>>> Bug not present: 2f4d2198a9b3ba94c959330b5c94fe95917c364c
>>> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105915/
>>>
>>>
>>> commit ab914e04a62727b75782e401eaf2e8b72f717f61
>>> Author: Jan Beulich <jbeulich@suse.com>
>>> Date: Fri Feb 17 15:51:03 2017 +0100
>>>
>>> x86: package up context switch hook pointers
>>>
>>> They're all solely dependent on guest type, so we don't need to repeat
>>> all the same three pointers in every vCPU control structure. Instead use
>>> static const structures, and store pointers to them in the domain
>>> control structure.
>>>
>>> Since touching it anyway, take the opportunity and expand
>>> schedule_tail() in the only two places invoking it, allowing the macro
>>> to be dropped.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>> From
>> http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
>> around Feb 19 23:12:06.269706
>>
>> (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
>> (XEN) CPU: 2
>> (XEN) RIP: e008:[<ffff82d08016795a>]
>> domain.c#__context_switch+0x1a3/0x3e3
>> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0)
>> (XEN) rax: 0000000000000000 rbx: 0000000000000002 rcx: 0000000000000000
>> (XEN) rdx: 00000031fd44b600 rsi: 0000000000000003 rdi: ffff83007de27000
>> (XEN) rbp: ffff83027d78fdb0 rsp: ffff83027d78fd60 r8: 0000000000000000
>> (XEN) r9: 0000005716f6126f r10: 0000000000007ff0 r11: 0000000000000246
>> (XEN) r12: ffff83007de27000 r13: ffff83027fb74000 r14: ffff83007dafd000
>> (XEN) r15: ffff83027d7c8000 cr0: 000000008005003b cr4: 00000000001526e0
>> (XEN) cr3: 000000007dd05000 cr2: 0000000000000008
>> (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
>> (XEN) Xen code around <ffff82d08016795a>
>> (domain.c#__context_switch+0x1a3/0x3e3):
>> (XEN) 85 68 07 00 00 4c 89 e7 <ff> 50 08 4c 89 ef e8 36 e1 02 00 41 80
>> bd 78 08
>> (XEN) Xen stack trace from rsp=ffff83027d78fd60:
>> (XEN) ffff83027d78ffff 0000000000000003 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 ffff83007de27000 ffff83007dafd000 ffff83027fb74000
>> (XEN) 0000000000000002 ffff83027d7c8000 ffff83027d78fe20 ffff82d08016bf1f
>> (XEN) ffff82d080131ae2 ffff83027d78fde0 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 ffff83027d78fe20 ffff83007dafd000
>> (XEN) ffff83007de27000 0000005716f5e5da ffff83027d796148 0000000000000001
>> (XEN) ffff83027d78feb0 ffff82d08012def9 ffff83027d7955a0 ffff83027d796160
>> (XEN) 0000000200000004 ffff83027d796140 ffff83027d78fe70 ffff82d08014af39
>> (XEN) ffff83027d78fe70 ffff83007de27000 0000000001c9c380 ffff82d0801bf800
>> (XEN) 000000107dafd000 ffff82d080322b80 ffff82d080322a80 ffffffffffffffff
>> (XEN) ffff83027d78ffff ffff83027d780000 ffff83027d78fee0 ffff82d08013128f
>> (XEN) ffff83027d78ffff ffff83007dd4c000 ffff83027d7c8000 00000000ffffffff
>> (XEN) ffff83027d78fef0 ffff82d0801312e4 ffff83027d78ff10 ffff82d080167582
>> (XEN) ffff82d0801312e4 ffff83007dafd000 ffff83027d78fdc8 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) ffffffff82374000 0000000000000000 0000000000000000 ffffffff81f59180
>> (XEN) 0000000000000000 0000000000000200 ffffffff82390000 0000000000000000
>> (XEN) 0000000000000000 02ffff8000000000 0000000000000000 0000000000000000
>> (XEN) Xen call trace:
>> (XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
>> (XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
>> (XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
>> (XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
>> (XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
>> (XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
>> (XEN)
>> (XEN) Pagetable walk from 0000000000000008:
>> (XEN) L4[0x000] = 000000027d7cd063 ffffffffffffffff
>> (XEN) L3[0x000] = 000000027d7cc063 ffffffffffffffff
>> (XEN) L2[0x000] = 000000027d7cb063 ffffffffffffffff
>> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 2:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=0000]
>> (XEN) Faulting linear address: 0000000000000008
>> (XEN) ****************************************
>> (XEN)
>>
>> We have followed the ->to() hook on a domain with a NULL ctxt_switch
>> pointer (confirmed by the disassembly). n is derived from current,
>> which is d1v0, but that would mean we are trying to schedule a vcpu
>> before its domain structure has been fully constructed.
>>
>> The problem is with hvm_domain_initialise()
>>
>> int hvm_domain_initialise(struct domain *d)
>> {
>> ...
>> if ( is_pvh_domain(d) )
>> {
>> register_portio_handler(d, 0, 0x10003, handle_pvh_io);
>> return 0;
>> }
>> ...
>> rc = hvm_funcs.domain_initialise(d);
>> ...
>> }
>>
>> So PVH domains exit hvm_domain_initialise() earlier than when we call
>> the vendor-specific initialisation hooks.
>>
>> Rather than fixing this specific issue, can I suggest we properly kill
>> PVH v1 at this point? Given what else it skips in
>> hvm_domain_initialise(), it clearly hasn't functioned properly in the past.
> P.S. Ian: Why did this failure not block at the push gate?
>
> It is a completely repeatable host crash, yet master has been pulled up
> to match staging.
P.P.S.
We have a cascade failure during crash which we should fix.
(XEN) Assertion 'current == idle_vcpu[smp_processor_id()]' failed at
domain.c:2178
(XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 2
(XEN) RIP: e008:[<ffff82d08016cd3d>] __sync_local_execstate+0x44/0x67
(XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor (d1v0)
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d08016cd3d>] __sync_local_execstate+0x44/0x67
(XEN) [<ffff82d080196d8d>] invalidate_interrupt+0x40/0x7d
(XEN) [<ffff82d080176112>] do_IRQ+0x8c/0x60f
(XEN) [<ffff82d0802470f7>] common_interrupt+0x67/0x70
(XEN) [<ffff82d080196865>] machine_halt+0x1d/0x32
(XEN) [<ffff82d0801476c1>] panic+0x10b/0x115
(XEN) [<ffff82d0801a1955>] do_page_fault+0x424/0x4f8
(XEN) [<ffff82d0802471f8>] entry.o#handle_exception_saved+0x66/0xa4
(XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
(XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
(XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
(XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
(XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
(XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
We really shouldn't be enabling interrupts in machine_halt(), because
there is no guarantee that it is safe to.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Removing PVHv1 code (was: Re: [linux-linus bisection] complete) test-amd64-amd64-xl-pvh-intel
2017-02-20 0:20 ` Andrew Cooper
2017-02-20 0:26 ` Andrew Cooper
@ 2017-02-20 10:42 ` Roger Pau Monne
2017-02-21 13:51 ` Removing PVHv1 code Boris Ostrovsky
1 sibling, 1 reply; 9+ messages in thread
From: Roger Pau Monne @ 2017-02-20 10:42 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel, Wei Liu, Ian Jackson, osstest service owner,
Jan Beulich, Boris Ostrovsky
On Mon, Feb 20, 2017 at 12:20:10AM +0000, Andrew Cooper wrote:
> From
> http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
> around Feb 19 23:12:06.269706
>
> (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
> (XEN) CPU: 2
> (XEN) RIP: e008:[<ffff82d08016795a>]
> domain.c#__context_switch+0x1a3/0x3e3
> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0)
> (XEN) rax: 0000000000000000 rbx: 0000000000000002 rcx: 0000000000000000
> (XEN) rdx: 00000031fd44b600 rsi: 0000000000000003 rdi: ffff83007de27000
> (XEN) rbp: ffff83027d78fdb0 rsp: ffff83027d78fd60 r8: 0000000000000000
> (XEN) r9: 0000005716f6126f r10: 0000000000007ff0 r11: 0000000000000246
> (XEN) r12: ffff83007de27000 r13: ffff83027fb74000 r14: ffff83007dafd000
> (XEN) r15: ffff83027d7c8000 cr0: 000000008005003b cr4: 00000000001526e0
> (XEN) cr3: 000000007dd05000 cr2: 0000000000000008
> (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
> (XEN) Xen code around <ffff82d08016795a>
> (domain.c#__context_switch+0x1a3/0x3e3):
> (XEN) 85 68 07 00 00 4c 89 e7 <ff> 50 08 4c 89 ef e8 36 e1 02 00 41 80
> bd 78 08
> (XEN) Xen stack trace from rsp=ffff83027d78fd60:
> (XEN) ffff83027d78ffff 0000000000000003 0000000000000000 0000000000000000
> (XEN) 0000000000000000 ffff83007de27000 ffff83007dafd000 ffff83027fb74000
> (XEN) 0000000000000002 ffff83027d7c8000 ffff83027d78fe20 ffff82d08016bf1f
> (XEN) ffff82d080131ae2 ffff83027d78fde0 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 ffff83027d78fe20 ffff83007dafd000
> (XEN) ffff83007de27000 0000005716f5e5da ffff83027d796148 0000000000000001
> (XEN) ffff83027d78feb0 ffff82d08012def9 ffff83027d7955a0 ffff83027d796160
> (XEN) 0000000200000004 ffff83027d796140 ffff83027d78fe70 ffff82d08014af39
> (XEN) ffff83027d78fe70 ffff83007de27000 0000000001c9c380 ffff82d0801bf800
> (XEN) 000000107dafd000 ffff82d080322b80 ffff82d080322a80 ffffffffffffffff
> (XEN) ffff83027d78ffff ffff83027d780000 ffff83027d78fee0 ffff82d08013128f
> (XEN) ffff83027d78ffff ffff83007dd4c000 ffff83027d7c8000 00000000ffffffff
> (XEN) ffff83027d78fef0 ffff82d0801312e4 ffff83027d78ff10 ffff82d080167582
> (XEN) ffff82d0801312e4 ffff83007dafd000 ffff83027d78fdc8 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) ffffffff82374000 0000000000000000 0000000000000000 ffffffff81f59180
> (XEN) 0000000000000000 0000000000000200 ffffffff82390000 0000000000000000
> (XEN) 0000000000000000 02ffff8000000000 0000000000000000 0000000000000000
> (XEN) Xen call trace:
> (XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
> (XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
> (XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
> (XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
> (XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
> (XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
> (XEN)
> (XEN) Pagetable walk from 0000000000000008:
> (XEN) L4[0x000] = 000000027d7cd063 ffffffffffffffff
> (XEN) L3[0x000] = 000000027d7cc063 ffffffffffffffff
> (XEN) L2[0x000] = 000000027d7cb063 ffffffffffffffff
> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 2:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 0000000000000008
> (XEN) ****************************************
> (XEN)
>
> We have followed the ->to() hook on a domain with a NULL ctxt_switch
> pointer (confirmed by the disassembly). n is derived from current,
> which is d1v0, but that would mean we are trying to schedule a vcpu
> before its domain structure has been fully constructed.
>
> The problem is with hvm_domain_initialise()
>
> int hvm_domain_initialise(struct domain *d)
> {
> ...
> if ( is_pvh_domain(d) )
> {
> register_portio_handler(d, 0, 0x10003, handle_pvh_io);
> return 0;
> }
> ...
> rc = hvm_funcs.domain_initialise(d);
> ...
> }
>
> So PVH domains exit hvm_domain_initialise() earlier than when we call
> the vendor-specific initialisation hooks.
>
> Rather than fixing this specific issue, can I suggest we properly kill
> PVH v1 at this point? Given what else it skips in
> hvm_domain_initialise(), it clearly hasn't functioned properly in the past.
I'm completely fine with that. I'm currently in the middle of something else,
but I can hopefully prepare a patch either later today or tomorrow.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Removing PVHv1 code
2017-02-20 10:42 ` Removing PVHv1 code (was: Re: [linux-linus bisection] complete) test-amd64-amd64-xl-pvh-intel Roger Pau Monne
@ 2017-02-21 13:51 ` Boris Ostrovsky
0 siblings, 0 replies; 9+ messages in thread
From: Boris Ostrovsky @ 2017-02-21 13:51 UTC (permalink / raw)
To: Roger Pau Monne, Andrew Cooper
Cc: Ian Jackson, xen-devel, Wei Liu, osstest service owner, Jan Beulich
On 02/20/2017 05:42 AM, Roger Pau Monne wrote:
> On Mon, Feb 20, 2017 at 12:20:10AM +0000, Andrew Cooper wrote:
>> From
>> http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
>> around Feb 19 23:12:06.269706
>>
>> (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
>> (XEN) CPU: 2
>> (XEN) RIP: e008:[<ffff82d08016795a>]
>> domain.c#__context_switch+0x1a3/0x3e3
>> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0)
>> (XEN) rax: 0000000000000000 rbx: 0000000000000002 rcx: 0000000000000000
>> (XEN) rdx: 00000031fd44b600 rsi: 0000000000000003 rdi: ffff83007de27000
>> (XEN) rbp: ffff83027d78fdb0 rsp: ffff83027d78fd60 r8: 0000000000000000
>> (XEN) r9: 0000005716f6126f r10: 0000000000007ff0 r11: 0000000000000246
>> (XEN) r12: ffff83007de27000 r13: ffff83027fb74000 r14: ffff83007dafd000
>> (XEN) r15: ffff83027d7c8000 cr0: 000000008005003b cr4: 00000000001526e0
>> (XEN) cr3: 000000007dd05000 cr2: 0000000000000008
>> (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
>> (XEN) Xen code around <ffff82d08016795a>
>> (domain.c#__context_switch+0x1a3/0x3e3):
>> (XEN) 85 68 07 00 00 4c 89 e7 <ff> 50 08 4c 89 ef e8 36 e1 02 00 41 80
>> bd 78 08
>> (XEN) Xen stack trace from rsp=ffff83027d78fd60:
>> (XEN) ffff83027d78ffff 0000000000000003 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 ffff83007de27000 ffff83007dafd000 ffff83027fb74000
>> (XEN) 0000000000000002 ffff83027d7c8000 ffff83027d78fe20 ffff82d08016bf1f
>> (XEN) ffff82d080131ae2 ffff83027d78fde0 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 ffff83027d78fe20 ffff83007dafd000
>> (XEN) ffff83007de27000 0000005716f5e5da ffff83027d796148 0000000000000001
>> (XEN) ffff83027d78feb0 ffff82d08012def9 ffff83027d7955a0 ffff83027d796160
>> (XEN) 0000000200000004 ffff83027d796140 ffff83027d78fe70 ffff82d08014af39
>> (XEN) ffff83027d78fe70 ffff83007de27000 0000000001c9c380 ffff82d0801bf800
>> (XEN) 000000107dafd000 ffff82d080322b80 ffff82d080322a80 ffffffffffffffff
>> (XEN) ffff83027d78ffff ffff83027d780000 ffff83027d78fee0 ffff82d08013128f
>> (XEN) ffff83027d78ffff ffff83007dd4c000 ffff83027d7c8000 00000000ffffffff
>> (XEN) ffff83027d78fef0 ffff82d0801312e4 ffff83027d78ff10 ffff82d080167582
>> (XEN) ffff82d0801312e4 ffff83007dafd000 ffff83027d78fdc8 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN) ffffffff82374000 0000000000000000 0000000000000000 ffffffff81f59180
>> (XEN) 0000000000000000 0000000000000200 ffffffff82390000 0000000000000000
>> (XEN) 0000000000000000 02ffff8000000000 0000000000000000 0000000000000000
>> (XEN) Xen call trace:
>> (XEN) [<ffff82d08016795a>] domain.c#__context_switch+0x1a3/0x3e3
>> (XEN) [<ffff82d08016bf1f>] context_switch+0x147/0xf0d
>> (XEN) [<ffff82d08012def9>] schedule.c#schedule+0x5ba/0x615
>> (XEN) [<ffff82d08013128f>] softirq.c#__do_softirq+0x7f/0x8a
>> (XEN) [<ffff82d0801312e4>] do_softirq+0x13/0x15
>> (XEN) [<ffff82d080167582>] domain.c#idle_loop+0x55/0x62
>> (XEN)
>> (XEN) Pagetable walk from 0000000000000008:
>> (XEN) L4[0x000] = 000000027d7cd063 ffffffffffffffff
>> (XEN) L3[0x000] = 000000027d7cc063 ffffffffffffffff
>> (XEN) L2[0x000] = 000000027d7cb063 ffffffffffffffff
>> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 2:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=0000]
>> (XEN) Faulting linear address: 0000000000000008
>> (XEN) ****************************************
>> (XEN)
>>
>> We have followed the ->to() hook on a domain with a NULL ctxt_switch
>> pointer (confirmed by the disassembly). n is derived from current,
>> which is d1v0, but that would mean we are trying to schedule a vcpu
>> before its domain structure has been fully constructed.
>>
>> The problem is with hvm_domain_initialise()
>>
>> int hvm_domain_initialise(struct domain *d)
>> {
>> ...
>> if ( is_pvh_domain(d) )
>> {
>> register_portio_handler(d, 0, 0x10003, handle_pvh_io);
>> return 0;
>> }
>> ...
>> rc = hvm_funcs.domain_initialise(d);
>> ...
>> }
>>
>> So PVH domains exit hvm_domain_initialise() earlier than when we call
>> the vendor-specific initialisation hooks.
>>
>> Rather than fixing this specific issue, can I suggest we properly kill
>> PVH v1 at this point? Given what else it skips in
>> hvm_domain_initialise(), it clearly hasn't functioned properly in the past.
> I'm completely fine with that. I'm currently in the middle of something else,
> but I can hopefully prepare a patch either later today or tomorrow.
Note also that Linux will drop v1 support in 4.11 --- the patch is in
the staging tree, ready for a pull request, probably this week.
The same pull request will add domU v2 support so perhaps osstest should
replace 'pvh=1' with 'device_model_version="none"'.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
@ 2017-07-10 13:54 osstest service owner
0 siblings, 0 replies; 9+ messages in thread
From: osstest service owner @ 2017-07-10 13:54 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 90311148415ab23f5767fbb577a012d4405f12e5
Bug not present: 3a564bb3a8a6950e18b1f5d209bda39fc3831074
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111639/
(Revision log too long, omitted.)
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot --summary-out=tmp/111639.bisection-summary --basis-template=110515 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvh-intel xen-boot
Searching for failure / basis pass:
111611 fail [host=chardonnay0] / 111493 ok.
Failure / basis pass flights: 111611 / 111493
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2b976203417cf033079e0be30cae5f41d88e385e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
Basis pass 9ced560b82606b35adb33a27012a148d418a4c1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#9ced560b82606b35adb33a27012a148d418a4c1f-2b976203417cf033079e0be30cae5f41d88e385e git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#414d069b38ab114b89085e44989bf57604ea86d7-414d069b38ab114b89085e44989bf57604ea86d7 git://xenbits.xen.org/xen.git#a7d802bca13489d303749177127089af48844f29-d23afa6399a78ca7d0ed3294119632535828c9d8
Loaded 274402 nodes in revision graph
Searching for test results:
111493 pass 9ced560b82606b35adb33a27012a148d418a4c1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111529 fail irrelevant
111602 pass irrelevant
111630 pass 3a564bb3a8a6950e18b1f5d209bda39fc3831074 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111620 pass 0b49ce5a40702bf78a5f80076312b244785e9a2f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111612 pass d63206ee32b6e64b0e12d46e5d6004afd9913713 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111603 pass irrelevant
111606 pass irrelevant
111615 fail dc502142b65b9e31eb90ab4344b3acadb2698317 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111598 pass 9ced560b82606b35adb33a27012a148d418a4c1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111625 pass 3a564bb3a8a6950e18b1f5d209bda39fc3831074 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111607 fail irrelevant
111599 fail irrelevant
111580 fail 026d15f6b9878794fae1f794cae881ccd65052e5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111609 pass irrelevant
111616 pass 9ced560b82606b35adb33a27012a148d418a4c1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 ebf5104125fa209bc9d3a7f7f6583254d32bd57c
111610 fail 026d15f6b9878794fae1f794cae881ccd65052e5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111618 fail 0dfaeb618f6cd2010b23e8b2be3c892c35d39633 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111623 pass 9871ab22f2784b2823b01522772a72ee4fc9d1fa c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111611 fail 2b976203417cf033079e0be30cae5f41d88e385e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111627 fail 90311148415ab23f5767fbb577a012d4405f12e5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111631 fail 90311148415ab23f5767fbb577a012d4405f12e5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111636 fail 2b976203417cf033079e0be30cae5f41d88e385e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111633 pass 9ced560b82606b35adb33a27012a148d418a4c1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111639 fail 90311148415ab23f5767fbb577a012d4405f12e5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
111637 pass 3a564bb3a8a6950e18b1f5d209bda39fc3831074 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
Searching for interesting versions
Result found: flight 111493 (pass), for basis pass
Result found: flight 111611 (fail), for basis failure
Repro found: flight 111633 (pass), for basis pass
Repro found: flight 111636 (fail), for basis failure
0 revisions at 3a564bb3a8a6950e18b1f5d209bda39fc3831074 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d23afa6399a78ca7d0ed3294119632535828c9d8
No revisions left to test, checking graph state.
Result found: flight 111625 (pass), for last pass
Result found: flight 111627 (fail), for first failure
Repro found: flight 111630 (pass), for last pass
Repro found: flight 111631 (fail), for first failure
Repro found: flight 111637 (pass), for last pass
Repro found: flight 111639 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 90311148415ab23f5767fbb577a012d4405f12e5
Bug not present: 3a564bb3a8a6950e18b1f5d209bda39fc3831074
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111639/
(Revision log too long, omitted.)
Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
111639: tolerable ALL FAIL
flight 111639 linux-linus real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/111639/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 7 xen-boot fail baseline untested
jobs:
test-amd64-amd64-xl-pvh-intel 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
@ 2017-07-06 7:33 osstest service owner
0 siblings, 0 replies; 9+ messages in thread
From: osstest service owner @ 2017-07-06 7:33 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid guest-localmigrate
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 19964541c23156cc8f814a2137df6b833ccdbf12
Bug not present: 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111464/
(Revision log too long, omitted.)
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-localmigrate.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-localmigrate --summary-out=tmp/111464.bisection-summary --basis-template=110515 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvh-intel guest-localmigrate
Searching for failure / basis pass:
111383 fail [host=chardonnay0] / 111363 [host=baroque1] 111332 [host=nobling0] 111280 [host=elbling1] 111222 [host=baroque0] 111183 [host=huxelrebe0] 111148 [host=fiano0] 111124 [host=huxelrebe1] 111081 [host=italia0] 110984 [host=elbling0] 110950 [host=godello1] 110908 [host=fiano1] 110560 ok.
Failure / basis pass flights: 111383 / 110560
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
Basis pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 695bb5f504ab48c1d546446f104c1b6c0ead126d
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f-19964541c23156cc8f814a2137df6b833ccdbf12 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-414d069b38ab114b89085e44989bf57604ea86d7 git://xenbits.xen.org/xen.git#695bb5f504ab48c1d546446f104c1b6c0ead126d-a7d802bca13489d303749177127089af48844f29
adhoc-revtuple-generator: tree discontiguous: linux-2.6
From git://cache:9419/git://xenbits.xen.org/qemu-xen
fd479c6..2185c93 upstream-tested -> origin/upstream-tested
From git://cache:9419/git://xenbits.xen.org/xen
f7ad92a..d708b69 staging-4.6 -> origin/staging-4.6
e146b7e..4fbfa34 staging-4.7 -> origin/staging-4.7
Loaded 2007 nodes in revision graph
Searching for test results:
110464 [host=huxelrebe0]
110486 [host=elbling1]
110515 [host=nobling1]
110547 [host=chardonnay1]
110536 [host=nobling0]
110560 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 695bb5f504ab48c1d546446f104c1b6c0ead126d
110908 [host=fiano1]
110950 [host=godello1]
110984 [host=elbling0]
111081 [host=italia0]
111124 [host=huxelrebe1]
111148 [host=fiano0]
111280 [host=elbling1]
111183 [host=huxelrebe0]
111222 [host=baroque0]
111393 pass irrelevant
111332 [host=nobling0]
111382 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 695bb5f504ab48c1d546446f104c1b6c0ead126d
111412 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 695bb5f504ab48c1d546446f104c1b6c0ead126d
111363 [host=baroque1]
111374 fail irrelevant
111386 fail irrelevant
111407 pass irrelevant
111388 pass irrelevant
111404 pass irrelevant
111383 fail 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111415 fail 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111417 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 970c4a2a19e262afe72e9ae8200db1d9701b87ef
111451 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111423 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 2d7021cfd7b962cc4af71e6f7b79716680da39f2
111428 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 143e0c2c2d64e64fce2e1302ffda1cacf0727c8c
111456 fail 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111459 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111431 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 0b435afa6a07ccd111dae0942254833928395789
111461 fail 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111462 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111440 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 e97138de4e22593a06dadcfc7eef67bb38739152
111464 fail 19964541c23156cc8f814a2137df6b833ccdbf12 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
111445 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 d468f4299cef469d882f4bed8530fca53ebf2ebd
111449 pass 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 106b735df9deffab55603cb9ed4636c067a49d64
Searching for interesting versions
Result found: flight 110560 (pass), for basis pass
Result found: flight 111383 (fail), for basis failure
Repro found: flight 111412 (pass), for basis pass
Repro found: flight 111415 (fail), for basis failure
0 revisions at 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 a7d802bca13489d303749177127089af48844f29
No revisions left to test, checking graph state.
Result found: flight 111451 (pass), for last pass
Result found: flight 111456 (fail), for first failure
Repro found: flight 111459 (pass), for last pass
Repro found: flight 111461 (fail), for first failure
Repro found: flight 111462 (pass), for last pass
Repro found: flight 111464 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 19964541c23156cc8f814a2137df6b833ccdbf12
Bug not present: 3696e4f0b0072eb9753ffa1387be1dd2ebe2cb8f
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111464/
(Revision log too long, omitted.)
pnmtopng: 200 colors found
Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.guest-localmigrate.{dot,ps,png,html,svg}.
----------------------------------------
111464: tolerable ALL FAIL
flight 111464 linux-linus real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/111464/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 16 guest-localmigrate fail baseline untested
jobs:
test-amd64-amd64-xl-pvh-intel 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel
@ 2015-11-09 2:02 osstest service owner
0 siblings, 0 replies; 9+ messages in thread
From: osstest service owner @ 2015-11-09 2:02 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2
Bug not present: 4302d506d5f3419109abdd0d6e400ed6e8148209
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/63895/
commit 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2
Merge: 4302d50 e1a5832
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Nov 3 21:23:56 2015 -0800
Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm changes from Ingo Molnar:
"The main changes are: continued PAT work by Toshi Kani, plus a new
boot time warning about insecure RWX kernel mappings, by Stephen
Smalley.
The new CONFIG_DEBUG_WX=y warning is marked default-y if
CONFIG_DEBUG_RODATA=y is already eanbled, as a special exception, as
these bugs are hard to notice and this check already found several
live bugs"
* 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Warn on W^X mappings
x86/mm: Fix no-change case in try_preserve_large_page()
x86/mm: Fix __split_large_page() to handle large PAT bit
x86/mm: Fix try_preserve_large_page() to handle large PAT bit
x86/mm: Fix gup_huge_p?d() to handle large PAT bit
x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
x86/mm: Fix page table dump to show PAT bit
x86/asm: Add pud_pgprot() and pmd_pgprot()
x86/asm: Fix pud/pmd interfaces to handle large PAT bit
x86/asm: Add pud/pmd mask interfaces to handle large PAT bit
x86/asm: Move PUD_PAGE macros to page_types.h
x86/vdso32: Define PGTABLE_LEVELS to 32bit VDSO
commit e1a58320a38dfa72be48a0f1a3a92273663ba6db
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date: Mon Oct 5 12:55:20 2015 -0400
x86/mm: Warn on W^X mappings
Warn on any residual W+X mappings after setting NX
if DEBUG_WX is enabled. Introduce a separate
X86_PTDUMP_CORE config that enables the code for
dumping the page tables without enabling the debugfs
interface, so that DEBUG_WX can be enabled without
exposing the debugfs interface. Switch EFI_PGT_DUMP
to using X86_PTDUMP_CORE so that it also does not require
enabling the debugfs interface.
On success it prints this to the kernel log:
x86/mm: Checked W+X mappings: passed, no W+X pages found.
On failure it prints a warning and a count of the failed pages:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:226 note_page+0x610/0x7b0()
x86/mm: Found insecure W+X mapping at address ffffffff81755000/__stop___ex_table+0xfa8/0xabfa8
[...]
Call Trace:
[<ffffffff81380a5f>] dump_stack+0x44/0x55
[<ffffffff8109d3f2>] warn_slowpath_common+0x82/0xc0
[<ffffffff8109d48c>] warn_slowpath_fmt+0x5c/0x80
[<ffffffff8106cfc9>] ? note_page+0x5c9/0x7b0
[<ffffffff8106d010>] note_page+0x610/0x7b0
[<ffffffff8106d409>] ptdump_walk_pgd_level_core+0x259/0x3c0
[<ffffffff8106d5a7>] ptdump_walk_pgd_level_checkwx+0x17/0x20
[<ffffffff81063905>] mark_rodata_ro+0xf5/0x100
[<ffffffff817415a0>] ? rest_init+0x80/0x80
[<ffffffff817415bd>] kernel_init+0x1d/0xe0
[<ffffffff8174cd1f>] ret_from_fork+0x3f/0x70
[<ffffffff817415a0>] ? rest_init+0x80/0x80
---[ end trace a1f23a1e42a2ac76 ]---
x86/mm: Checked W+X mappings: FAILED, 171 W+X pages found.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1444064120-11450-1-git-send-email-sds@tycho.nsa.gov
[ Improved the Kconfig help text and made the new option default-y
if CONFIG_DEBUG_RODATA=y, because it already found buggy mappings,
so we really want people to have this on by default. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 38a413cbc2b2834683b21823d964bc2d2f0abb82
Merge: 55696b1 9ffecb1
Author: Ingo Molnar <mingo@kernel.org>
Date: Tue Oct 6 10:56:54 2015 +0200
Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new changes
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 55696b1f664e52b3036f21631f9c2247b667f587
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:24 2015 -0600
x86/mm: Fix no-change case in try_preserve_large_page()
try_preserve_large_page() checks if new_prot is the same as
old_prot. If so, it simply sets do_split to 0, and returns
with no-operation. However, old_prot is set as a 4KB pgprot
value while new_prot is a large page pgprot value.
Now that old_prot is initially set from p?d_pgprot() as a
large page pgprot value, fix it by not overwriting old_prot
with a 4KB pgprot value.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-12-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit d551aaa2f7e1387fa66093ce9914c2e91f283a50
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:23 2015 -0600
x86/mm: Fix __split_large_page() to handle large PAT bit
__split_large_page() is called from __change_page_attr() to change
the mapping attribute by splitting a given large page into smaller
pages. This function uses pte_pfn() and pte_pgprot() for PUD/PMD,
which do not handle the large PAT bit properly.
Fix __split_large_page() by using the corresponding pud/pmd pfn/
pgprot interfaces.
Also remove '#ifdef CONFIG_X86_64', which is not necessary.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-11-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 3a19109efbfa7d887996a74257556a46e00525c2
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:22 2015 -0600
x86/mm: Fix try_preserve_large_page() to handle large PAT bit
try_preserve_large_page() is called from __change_page_attr() to
change the mapping attribute of a given large page. This function
uses pte_pfn() and pte_pgprot() for PUD/PMD, which do not handle
the large PAT bit properly.
Fix try_preserve_large_page() by using the corresponding pud/pmd
prot/pfn interfaces.
Also remove '#ifdef CONFIG_X86_64', which is not necessary.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-10-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit daf3e35c5888e8bd6a2f5ed15ed392b2df362ecf
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:21 2015 -0600
x86/mm: Fix gup_huge_p?d() to handle large PAT bit
gup_huge_pud() and gup_huge_pmd() cast *pud and *pmd to *pte,
and use pte_xxx() interfaces to obtain the flags and PFN.
However, the pte_xxx() interface does not handle the large
PAT bit properly for PUD/PMD.
Fix gup_huge_pud() and gup_huge_pmd() to use pud_xxx() and
pmd_xxx() interfaces according to their type.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-9-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 34437e67a6727885bdf6cbfd8441b1ac43a1ee65
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:20 2015 -0600
x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
slow_virt_to_phys() calls lookup_address() to obtain *pte and
its level. It then calls pte_pfn() to obtain a physical address
for any level. However, this physical address is not correct
when the large PAT bit is set because pte_pfn() does not mask
the large PAT bit properly for PUD/PMD.
Fix slow_virt_to_phys() to use pud_pfn() and pmd_pfn() for 1GB
and 2MB mapping levels.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-8-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit da25e628c4c231a281b1c1de3168a36ab9bfe473
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:19 2015 -0600
x86/mm: Fix page table dump to show PAT bit
/sys/kernel/debug/kernel_page_tables does not show the PAT bit for
PUD/PMD mappings. This is because walk_pud_level(), walk_pmd_level()
and note_page() mask the flags with PTE_FLAGS_MASK, which does not
cover their PAT bit, _PAGE_PAT_LARGE.
Fix it by replacing the use of PTE_FLAGS_MASK with p?d_flags(),
which masks the flags properly.
Also change to show the PAT bit as "PAT" to be consistent with
other bits.
Reported-by: Robert Elliott <elliott@hpe.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-7-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit bbac8c6deadab921f4b7d00ce675ffa4f358ec7f
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:18 2015 -0600
x86/asm: Add pud_pgprot() and pmd_pgprot()
pte_pgprot() returns a pgprot_t value by calling pte_flags(). Now
that pud_flags() and pmd_flags() work specifically for the pud/pmd
levels, define pud_pgprot() and pmd_pgprot() for PUD/PMD.
Also update pte_pgprot() to remove the unnecessary mask with
PTE_FLAGS_MASK as pte_flags() takes care of it.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-6-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit f70abb0fc3da1b2945c92751ccda2744081bf2b7
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:17 2015 -0600
x86/asm: Fix pud/pmd interfaces to handle large PAT bit
Now that we have pud/pmd mask interfaces, which handle pfn & flags
mask properly for the large PAT bit.
Fix pud/pmd pfn & flags interfaces by replacing PTE_PFN_MASK and
PTE_FLAGS_MASK with the pud/pmd mask interfaces.
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-5-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 4be4c1fb9a754b100466ebaec50f825be0b2050b
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:16 2015 -0600
x86/asm: Add pud/pmd mask interfaces to handle large PAT bit
The PAT bit gets relocated to bit 12 when PUD and PMD mappings are
used. This bit 12, however, is not covered by PTE_FLAGS_MASK, which
is used for masking pfn and flags for all levels.
Add pud/pmd mask interfaces to handle pfn and flags properly by using
P?D_PAGE_MASK when PUD/PMD mappings are used, i.e. PSE bit is set.
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-4-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 832102671855f73962e7a04fdafd48b9385ea5c6
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:15 2015 -0600
x86/asm: Move PUD_PAGE macros to page_types.h
PUD_SHIFT is defined according to a given kernel configuration, which
allows it be commonly used by any x86 kernels. However, PUD_PAGE_SIZE
and PUD_PAGE_MASK, which are set from PUD_SHIFT, are defined in
page_64_types.h, which can be used by 64-bit kernel only.
Move PUD_PAGE_SIZE and PUD_PAGE_MASK to page_types.h so that they can
be used by any x86 kernels as well.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-3-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit fb535ccb30845fe0b7bd09caa37a838985b72ff9
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:14 2015 -0600
x86/vdso32: Define PGTABLE_LEVELS to 32bit VDSO
In case of CONFIG_X86_64, vdso32/vclock_gettime.c fakes a 32-bit
non-PAE kernel configuration by re-defining it to CONFIG_X86_32.
However, it does not re-define CONFIG_PGTABLE_LEVELS leaving it
as 4 levels.
This mismatch leads <asm/pgtable_type.h> to NOT include <asm-generic/
pgtable-nopud.h> and <asm-generic/pgtable-nopmd.h>, which will cause
compile errors when a later patch enhances <asm/pgtable_type.h> to
use PUD_SHIFT and PMD_SHIFT. These -nopud & -nopmd headers define
these SHIFTs for the 32-bit non-PAE kernel.
Fix it by re-defining CONFIG_PGTABLE_LEVELS to 2 levels.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-2-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot --summary-out=tmp/63895.bisection-summary --basis-template=59254 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvh-intel xen-boot
Searching for failure / basis pass:
63654 fail [host=fiano0] / 63536 ok.
Failure / basis pass flights: 63654 / 63536
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2dc10ad81fc017837037e60439662e1b16bdffb9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
Basis pass 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#5062ecdb662bf3aed6dc975019c53ffcd3b01d1c-2dc10ad81fc017837037e60439662e1b16bdffb9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-bc00cad75d8bcc3ba696992bec219c21db8406aa git://xenbits.xen.org/qemu-xen.git#816609b2841297925a223ec377c336360e044ee5-816609b2841297925a223ec377c336360e044ee5 git://xenbits.xen.org/xen.git#e294a0c3af9f4443dc692b180fb1771b1cb075e8-e294a0c3af9f4443dc692b180fb1771b1cb075e8
Loaded 1088 nodes in revision graph
Searching for test results:
63536 pass 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63654 fail 2dc10ad81fc017837037e60439662e1b16bdffb9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63837 pass 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63853 pass 4302d506d5f3419109abdd0d6e400ed6e8148209 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63842 fail 2dc10ad81fc017837037e60439662e1b16bdffb9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63865 fail 66ef3493d4bb387f5a83915e33dc893102fd1b43 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63846 pass 53528695ff6d8b77011bc818407c13e30914a946 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63858 fail b0f85fa11aefc4f3e03306b4cd47f113bd57dcba c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63871 fail 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63878 pass 4302d506d5f3419109abdd0d6e400ed6e8148209 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63881 fail 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63891 pass 4302d506d5f3419109abdd0d6e400ed6e8148209 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
63895 fail 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
Searching for interesting versions
Result found: flight 63536 (pass), for basis pass
Result found: flight 63654 (fail), for basis failure
Repro found: flight 63837 (pass), for basis pass
Repro found: flight 63842 (fail), for basis failure
0 revisions at 4302d506d5f3419109abdd0d6e400ed6e8148209 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 e294a0c3af9f4443dc692b180fb1771b1cb075e8
No revisions left to test, checking graph state.
Result found: flight 63853 (pass), for last pass
Result found: flight 63871 (fail), for first failure
Repro found: flight 63878 (pass), for last pass
Repro found: flight 63881 (fail), for first failure
Repro found: flight 63891 (pass), for last pass
Repro found: flight 63895 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2
Bug not present: 4302d506d5f3419109abdd0d6e400ed6e8148209
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/63895/
commit 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2
Merge: 4302d50 e1a5832
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Nov 3 21:23:56 2015 -0800
Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm changes from Ingo Molnar:
"The main changes are: continued PAT work by Toshi Kani, plus a new
boot time warning about insecure RWX kernel mappings, by Stephen
Smalley.
The new CONFIG_DEBUG_WX=y warning is marked default-y if
CONFIG_DEBUG_RODATA=y is already eanbled, as a special exception, as
these bugs are hard to notice and this check already found several
live bugs"
* 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Warn on W^X mappings
x86/mm: Fix no-change case in try_preserve_large_page()
x86/mm: Fix __split_large_page() to handle large PAT bit
x86/mm: Fix try_preserve_large_page() to handle large PAT bit
x86/mm: Fix gup_huge_p?d() to handle large PAT bit
x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
x86/mm: Fix page table dump to show PAT bit
x86/asm: Add pud_pgprot() and pmd_pgprot()
x86/asm: Fix pud/pmd interfaces to handle large PAT bit
x86/asm: Add pud/pmd mask interfaces to handle large PAT bit
x86/asm: Move PUD_PAGE macros to page_types.h
x86/vdso32: Define PGTABLE_LEVELS to 32bit VDSO
commit e1a58320a38dfa72be48a0f1a3a92273663ba6db
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date: Mon Oct 5 12:55:20 2015 -0400
x86/mm: Warn on W^X mappings
Warn on any residual W+X mappings after setting NX
if DEBUG_WX is enabled. Introduce a separate
X86_PTDUMP_CORE config that enables the code for
dumping the page tables without enabling the debugfs
interface, so that DEBUG_WX can be enabled without
exposing the debugfs interface. Switch EFI_PGT_DUMP
to using X86_PTDUMP_CORE so that it also does not require
enabling the debugfs interface.
On success it prints this to the kernel log:
x86/mm: Checked W+X mappings: passed, no W+X pages found.
On failure it prints a warning and a count of the failed pages:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:226 note_page+0x610/0x7b0()
x86/mm: Found insecure W+X mapping at address ffffffff81755000/__stop___ex_table+0xfa8/0xabfa8
[...]
Call Trace:
[<ffffffff81380a5f>] dump_stack+0x44/0x55
[<ffffffff8109d3f2>] warn_slowpath_common+0x82/0xc0
[<ffffffff8109d48c>] warn_slowpath_fmt+0x5c/0x80
[<ffffffff8106cfc9>] ? note_page+0x5c9/0x7b0
[<ffffffff8106d010>] note_page+0x610/0x7b0
[<ffffffff8106d409>] ptdump_walk_pgd_level_core+0x259/0x3c0
[<ffffffff8106d5a7>] ptdump_walk_pgd_level_checkwx+0x17/0x20
[<ffffffff81063905>] mark_rodata_ro+0xf5/0x100
[<ffffffff817415a0>] ? rest_init+0x80/0x80
[<ffffffff817415bd>] kernel_init+0x1d/0xe0
[<ffffffff8174cd1f>] ret_from_fork+0x3f/0x70
[<ffffffff817415a0>] ? rest_init+0x80/0x80
---[ end trace a1f23a1e42a2ac76 ]---
x86/mm: Checked W+X mappings: FAILED, 171 W+X pages found.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1444064120-11450-1-git-send-email-sds@tycho.nsa.gov
[ Improved the Kconfig help text and made the new option default-y
if CONFIG_DEBUG_RODATA=y, because it already found buggy mappings,
so we really want people to have this on by default. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 38a413cbc2b2834683b21823d964bc2d2f0abb82
Merge: 55696b1 9ffecb1
Author: Ingo Molnar <mingo@kernel.org>
Date: Tue Oct 6 10:56:54 2015 +0200
Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new changes
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 55696b1f664e52b3036f21631f9c2247b667f587
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:24 2015 -0600
x86/mm: Fix no-change case in try_preserve_large_page()
try_preserve_large_page() checks if new_prot is the same as
old_prot. If so, it simply sets do_split to 0, and returns
with no-operation. However, old_prot is set as a 4KB pgprot
value while new_prot is a large page pgprot value.
Now that old_prot is initially set from p?d_pgprot() as a
large page pgprot value, fix it by not overwriting old_prot
with a 4KB pgprot value.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-12-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit d551aaa2f7e1387fa66093ce9914c2e91f283a50
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:23 2015 -0600
x86/mm: Fix __split_large_page() to handle large PAT bit
__split_large_page() is called from __change_page_attr() to change
the mapping attribute by splitting a given large page into smaller
pages. This function uses pte_pfn() and pte_pgprot() for PUD/PMD,
which do not handle the large PAT bit properly.
Fix __split_large_page() by using the corresponding pud/pmd pfn/
pgprot interfaces.
Also remove '#ifdef CONFIG_X86_64', which is not necessary.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-11-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 3a19109efbfa7d887996a74257556a46e00525c2
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:22 2015 -0600
x86/mm: Fix try_preserve_large_page() to handle large PAT bit
try_preserve_large_page() is called from __change_page_attr() to
change the mapping attribute of a given large page. This function
uses pte_pfn() and pte_pgprot() for PUD/PMD, which do not handle
the large PAT bit properly.
Fix try_preserve_large_page() by using the corresponding pud/pmd
prot/pfn interfaces.
Also remove '#ifdef CONFIG_X86_64', which is not necessary.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-10-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit daf3e35c5888e8bd6a2f5ed15ed392b2df362ecf
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:21 2015 -0600
x86/mm: Fix gup_huge_p?d() to handle large PAT bit
gup_huge_pud() and gup_huge_pmd() cast *pud and *pmd to *pte,
and use pte_xxx() interfaces to obtain the flags and PFN.
However, the pte_xxx() interface does not handle the large
PAT bit properly for PUD/PMD.
Fix gup_huge_pud() and gup_huge_pmd() to use pud_xxx() and
pmd_xxx() interfaces according to their type.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-9-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 34437e67a6727885bdf6cbfd8441b1ac43a1ee65
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:20 2015 -0600
x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
slow_virt_to_phys() calls lookup_address() to obtain *pte and
its level. It then calls pte_pfn() to obtain a physical address
for any level. However, this physical address is not correct
when the large PAT bit is set because pte_pfn() does not mask
the large PAT bit properly for PUD/PMD.
Fix slow_virt_to_phys() to use pud_pfn() and pmd_pfn() for 1GB
and 2MB mapping levels.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-8-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit da25e628c4c231a281b1c1de3168a36ab9bfe473
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:19 2015 -0600
x86/mm: Fix page table dump to show PAT bit
/sys/kernel/debug/kernel_page_tables does not show the PAT bit for
PUD/PMD mappings. This is because walk_pud_level(), walk_pmd_level()
and note_page() mask the flags with PTE_FLAGS_MASK, which does not
cover their PAT bit, _PAGE_PAT_LARGE.
Fix it by replacing the use of PTE_FLAGS_MASK with p?d_flags(),
which masks the flags properly.
Also change to show the PAT bit as "PAT" to be consistent with
other bits.
Reported-by: Robert Elliott <elliott@hpe.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-7-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit bbac8c6deadab921f4b7d00ce675ffa4f358ec7f
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:18 2015 -0600
x86/asm: Add pud_pgprot() and pmd_pgprot()
pte_pgprot() returns a pgprot_t value by calling pte_flags(). Now
that pud_flags() and pmd_flags() work specifically for the pud/pmd
levels, define pud_pgprot() and pmd_pgprot() for PUD/PMD.
Also update pte_pgprot() to remove the unnecessary mask with
PTE_FLAGS_MASK as pte_flags() takes care of it.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-6-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit f70abb0fc3da1b2945c92751ccda2744081bf2b7
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:17 2015 -0600
x86/asm: Fix pud/pmd interfaces to handle large PAT bit
Now that we have pud/pmd mask interfaces, which handle pfn & flags
mask properly for the large PAT bit.
Fix pud/pmd pfn & flags interfaces by replacing PTE_PFN_MASK and
PTE_FLAGS_MASK with the pud/pmd mask interfaces.
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-5-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 4be4c1fb9a754b100466ebaec50f825be0b2050b
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:16 2015 -0600
x86/asm: Add pud/pmd mask interfaces to handle large PAT bit
The PAT bit gets relocated to bit 12 when PUD and PMD mappings are
used. This bit 12, however, is not covered by PTE_FLAGS_MASK, which
is used for masking pfn and flags for all levels.
Add pud/pmd mask interfaces to handle pfn and flags properly by using
P?D_PAGE_MASK when PUD/PMD mappings are used, i.e. PSE bit is set.
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-4-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 832102671855f73962e7a04fdafd48b9385ea5c6
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:15 2015 -0600
x86/asm: Move PUD_PAGE macros to page_types.h
PUD_SHIFT is defined according to a given kernel configuration, which
allows it be commonly used by any x86 kernels. However, PUD_PAGE_SIZE
and PUD_PAGE_MASK, which are set from PUD_SHIFT, are defined in
page_64_types.h, which can be used by 64-bit kernel only.
Move PUD_PAGE_SIZE and PUD_PAGE_MASK to page_types.h so that they can
be used by any x86 kernels as well.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-3-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit fb535ccb30845fe0b7bd09caa37a838985b72ff9
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Thu Sep 17 12:24:14 2015 -0600
x86/vdso32: Define PGTABLE_LEVELS to 32bit VDSO
In case of CONFIG_X86_64, vdso32/vclock_gettime.c fakes a 32-bit
non-PAE kernel configuration by re-defining it to CONFIG_X86_32.
However, it does not re-define CONFIG_PGTABLE_LEVELS leaving it
as 4 levels.
This mismatch leads <asm/pgtable_type.h> to NOT include <asm-generic/
pgtable-nopud.h> and <asm-generic/pgtable-nopmd.h>, which will cause
compile errors when a later patch enhances <asm/pgtable_type.h> to
use PUD_SHIFT and PMD_SHIFT. These -nopud & -nopmd headers define
these SHIFTs for the 32-bit non-PAE kernel.
Fix it by re-defining CONFIG_PGTABLE_LEVELS to 2 levels.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Robert Elliot <elliott@hpe.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1442514264-12475-2-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-intel.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
63895: tolerable ALL FAIL
flight 63895 linux-linus real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/63895/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail baseline untested
jobs:
test-amd64-amd64-xl-pvh-intel 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-07-10 13:54 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-19 23:20 [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel osstest service owner
2017-02-20 0:20 ` Andrew Cooper
2017-02-20 0:26 ` Andrew Cooper
2017-02-20 0:36 ` Andrew Cooper
2017-02-20 10:42 ` Removing PVHv1 code (was: Re: [linux-linus bisection] complete) test-amd64-amd64-xl-pvh-intel Roger Pau Monne
2017-02-21 13:51 ` Removing PVHv1 code Boris Ostrovsky
-- strict thread matches above, loose matches on Subject: below --
2017-07-10 13:54 [linux-linus bisection] complete test-amd64-amd64-xl-pvh-intel osstest service owner
2017-07-06 7:33 osstest service owner
2015-11-09 2:02 osstest service owner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.