* [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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ messages in thread
end of thread, other threads:[~2017-02-21 13:51 UTC | newest]
Thread overview: 6+ 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).