Byrne, John (HP Labs)
2009-May-11 04:32 UTC
[Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 with debugger_attached set, I was seeing the debug traps getting lost from the EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from real to protected mode. In my codebase, I could fix this trivially by clearing the debug_state_latch and letting vmx_do_resume() reapply the setting. However, while it looks like a valid issue in the unmodified codebase, I''m not sure. So maybe someone might test/examine it and decide if it is real and whether some more complex fix is required? John Byrne _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-May-11 06:52 UTC
Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> wrote:> Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 with > debugger_attached set, I was seeing the debug traps getting lost from the > EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from real to > protected mode. In my codebase, I could fix this trivially by clearing the > debug_state_latch and letting vmx_do_resume() reapply the setting. However, > while it looks like a valid issue in the unmodified codebase, I''m not sure. So > maybe someone might test/examine it and decide if it is real and whether some > more complex fix is required?In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after exit from real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and raise_softirq(SCHEDULE_SOFTIRQ). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Byrne, John (HP Labs)
2009-May-11 16:05 UTC
RE: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
The schedule_softirq() does close a hole I wasn''t noticing. Thanks.> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Sunday, May 10, 2009 11:52 PM > To: Byrne, John (HP Labs); xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP > setting > > On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> > wrote: > > > Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 > with > > debugger_attached set, I was seeing the debug traps getting lost from > the > > EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from > real to > > protected mode. In my codebase, I could fix this trivially by > clearing the > > debug_state_latch and letting vmx_do_resume() reapply the setting. > However, > > while it looks like a valid issue in the unmodified codebase, I''m not > sure. So > > maybe someone might test/examine it and decide if it is real and > whether some > > more complex fix is required? > > In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after exit > from > real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and > raise_softirq(SCHEDULE_SOFTIRQ). > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-May-11 17:14 UTC
Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
Very cryptic. Did it fix the bug you originally posted about? -- Keir On 11/05/2009 17:05, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> wrote:> The schedule_softirq() does close a hole I wasn''t noticing. > > Thanks. > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Sunday, May 10, 2009 11:52 PM >> To: Byrne, John (HP Labs); xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP >> setting >> >> On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> >> wrote: >> >>> Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 >> with >>> debugger_attached set, I was seeing the debug traps getting lost from >> the >>> EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from >> real to >>> protected mode. In my codebase, I could fix this trivially by >> clearing the >>> debug_state_latch and letting vmx_do_resume() reapply the setting. >> However, >>> while it looks like a valid issue in the unmodified codebase, I''m not >> sure. So >>> maybe someone might test/examine it and decide if it is real and >> whether some >>> more complex fix is required? >> >> In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after exit >> from >> real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and >> raise_softirq(SCHEDULE_SOFTIRQ). >> >> -- Keir >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Byrne, John (HP Labs)
2009-May-11 17:21 UTC
RE: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
I had hit upon the fix of clearing v->arch.hvm_vcpu.debug_state_latch=0 and this had apparently fixed the problem I was seeing. However, reviewing the code, the schedule_softirq(SECHDULE_SOFTIRQ) you added looks necessary for a complete fix. A caveat: I am not running a domain-debugger, I am just borrowing the code for my lockstep work. I don''t see why the fix wouldn''t work in that case, but I''m not testing it. John> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Monday, May 11, 2009 10:15 AM > To: Byrne, John (HP Labs) > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP > setting > > Very cryptic. Did it fix the bug you originally posted about? > > -- Keir > > On 11/05/2009 17:05, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> > wrote: > > > The schedule_softirq() does close a hole I wasn''t noticing. > > > > Thanks. > > > >> -----Original Message----- > >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > >> Sent: Sunday, May 10, 2009 11:52 PM > >> To: Byrne, John (HP Labs); xen-devel@lists.xensource.com > >> Subject: Re: [Xen-devel] vmx_update_guest_cr() losing > EXCEPTION_BITMAP > >> setting > >> > >> On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> > >> wrote: > >> > >>> Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 > >> with > >>> debugger_attached set, I was seeing the debug traps getting lost > from > >> the > >>> EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from > >> real to > >>> protected mode. In my codebase, I could fix this trivially by > >> clearing the > >>> debug_state_latch and letting vmx_do_resume() reapply the setting. > >> However, > >>> while it looks like a valid issue in the unmodified codebase, I''m > not > >> sure. So > >>> maybe someone might test/examine it and decide if it is real and > >> whether some > >>> more complex fix is required? > >> > >> In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after > exit > >> from > >> real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and > >> raise_softirq(SCHEDULE_SOFTIRQ). > >> > >> -- Keir > >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-May-11 17:38 UTC
Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
Ah, I see. Well I can do a cleaner patch than that I think, so I''ll sort that out and check it in. -- Keir On 11/05/2009 18:21, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> wrote:> > I had hit upon the fix of clearing v->arch.hvm_vcpu.debug_state_latch=0 and > this had apparently fixed the problem I was seeing. However, reviewing the > code, the schedule_softirq(SECHDULE_SOFTIRQ) you added looks necessary for a > complete fix. A caveat: I am not running a domain-debugger, I am just > borrowing the code for my lockstep work. I don''t see why the fix wouldn''t work > in that case, but I''m not testing it. > > John > > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Monday, May 11, 2009 10:15 AM >> To: Byrne, John (HP Labs) >> Cc: xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP >> setting >> >> Very cryptic. Did it fix the bug you originally posted about? >> >> -- Keir >> >> On 11/05/2009 17:05, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> >> wrote: >> >>> The schedule_softirq() does close a hole I wasn''t noticing. >>> >>> Thanks. >>> >>>> -----Original Message----- >>>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >>>> Sent: Sunday, May 10, 2009 11:52 PM >>>> To: Byrne, John (HP Labs); xen-devel@lists.xensource.com >>>> Subject: Re: [Xen-devel] vmx_update_guest_cr() losing >> EXCEPTION_BITMAP >>>> setting >>>> >>>> On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@hp.com> >>>> wrote: >>>> >>>>> Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 >>>> with >>>>> debugger_attached set, I was seeing the debug traps getting lost >> from >>>> the >>>>> EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from >>>> real to >>>>> protected mode. In my codebase, I could fix this trivially by >>>> clearing the >>>>> debug_state_latch and letting vmx_do_resume() reapply the setting. >>>> However, >>>>> while it looks like a valid issue in the unmodified codebase, I''m >> not >>>> sure. So >>>>> maybe someone might test/examine it and decide if it is real and >>>> whether some >>>>> more complex fix is required? >>>> >>>> In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after >> exit >>>> from >>>> real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and >>>> raise_softirq(SCHEDULE_SOFTIRQ). >>>> >>>> -- Keir >>>> >>> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-May-11 20:27 UTC
[Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore
I was able to rebuild xen& tools with only one line modified in Config.mk :-
PYTHON ?= /usr/bin/python2.5
PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)"
# make clean
# make uninstall
# make install-xen
# make install-tools
IF PYTHON_PREFIX_ARG ?=''''
OR
PYTHON_PREFIX_ARG ?= --prefix=''''
# make tools
fails.
Xen 3.4 Dom0 with 2.6.30-rc3-tip loads fine. Xend starts fine.
Reports bellow :-
# xm info
# brctl show
# ifconfig
Demonstrate normal Xen Host state.
However, working in same Xen environment and same kernel , been built on top of
Ubuntu Server 8.10, F10 PV DomU fails to start:-
root@ServerJaunty:/home/boris/vm# cat f10.pyrun
name="F10PV"
memory=2048
disk = [''phy:/dev/sdb7,xvda,w'' ]
vif = [ ''bridge=eth1'' ]
bootloader = "/usr/bin/pygrub"
vcpus=2
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Traceback (most recent call last):
File "/usr/bin/pygrub", line 684,
in <module>
chosencfg = run_grub(file, entry, fs, incfg["args"])
File "/usr/bin/pygrub",
line 521, in run_grub
curses.wrapper(run_main)
File "/usr/lib/python2.5/curses/wrapper.py",
line 47, in wrapper
root@ServerJaunty:/home/boris/vm# Error: Boot loader didn''t return any
data!
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Error: Boot loader didn''t return any data!
root@ServerJaunty:/home/boris/vm# xm create -c rhel.pyrun
Using config file "./rhel.pyrun".
Error: Boot loader didn''t return any data!
root@ServerJaunty:/home/boris/vm#
Boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-May-11 21:11 UTC
Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore
Attempt to install F10 PV DomU fails at DHCP request for DomU:-
Welcome to Fedora for x86_64
+-------------------------------------------------------+
| |
| root@ServerJaunty:/home/boris/vm# Error: Device 0 (vif) could not
be connected. Hotplug scripts not
working. |
+-------------------------------------------------------+
--- On Mon, 5/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04
causes pygrub doesn''t return any data anymore
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>
Date: Monday, May 11, 2009, 4:27 PM
I was able to rebuild xen& tools with only one line modified in Config.mk :-
PYTHON ?= /usr/bin/python2.5
PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)"
# make clean
# make uninstall
# make install-xen
# make install-tools
IF PYTHON_PREFIX_ARG ?=''''
OR
PYTHON_PREFIX_ARG ?= --prefix=''''
# make tools
fails.
Xen 3.4 Dom0 with 2.6.30-rc3-tip loads fine. Xend starts fine.
Reports bellow :-
# xm info
# brctl show
# ifconfig
Demonstrate normal Xen Host state.
However, working in same Xen environment and same kernel , been built on top of
Ubuntu Server 8.10, F10 PV DomU fails to start:-
root@ServerJaunty:/home/boris/vm# cat f10.pyrun
name="F10PV"
memory=2048
disk = [''phy:/dev/sdb7,xvda,w'' ]
vif = [ ''bridge=eth1'' ]
bootloader "/usr/bin/pygrub"
vcpus=2
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Traceback (most recent call last):
File "/usr/bin/pygrub", line 684,
in <module>
chosencfg = run_grub(file,
entry, fs, incfg["args"])
File "/usr/bin/pygrub",
line 521, in run_grub
curses.wrapper(run_main)
File "/usr/lib/python2.5/curses/wrapper.py",
line 47, in wrapper
root@ServerJaunty:/home/boris/vm# Error: Boot loader didn''t return any
data!
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Error: Boot loader didn''t return any
data!
root@ServerJaunty:/home/boris/vm# xm create -c rhel.pyrun
Using config file "./rhel.pyrun".
Error: Boot loader didn''t return any data!
root@ServerJaunty:/home/boris/vm#
Boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-May-11 22:45 UTC
Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore
Attempt to load same F10 PV DomU via profile , to avoid pygrub issue :-
memory = 1024
name = "FedoraPV"
ramdisk="/home/boris/kernel/initrd-2.6.27.19-170.2.35.fc10.x86_64.img"
kernel="/home/boris/kernel/vmlinuz-2.6.27.19-170.2.35.fc10.x86_64"
root="/dev/VolGroup00/LogVol00 ro"
extra = ''console=hvc0''
# vif = [ ''mac=00:16:3e:00:00:00'' ]
disk = [ ''phy:/dev/sdb7,xvda,w'']
vif = [ ''bridge=eth1'' ]
Failure at booting up:-
****************************************************************
XENBUS: Timeout connecting to device: /device/vbd/51712
vif(0) could not be connected . Hotplug scripts not working.
*****************************************************************
Boris.
--- On Mon, 5/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04
causes pygrub doesn''t return any data anymore
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>
Date: Monday, May 11, 2009, 5:11 PM
Attempt to install F10 PV DomU fails at DHCP request for DomU:-
Welcome to Fedora for x86_64
+-------------------------------------------------------+
| |
| root@ServerJaunty:/home/boris/vm# Error: Device 0 (vif) could
not be connected. Hotplug scripts not
working. |
+-------------------------------------------------------+
--- On Mon, 5/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04
causes pygrub doesn''t return any data anymore
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc:
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Monday, May 11, 2009, 4:27 PM
I was able to rebuild xen& tools with only one line modified in Config.mk :-
PYTHON ?= /usr/bin/python2.5
PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)"
# make clean
# make uninstall
# make install-xen
# make install-tools
IF PYTHON_PREFIX_ARG ?=''''
OR
PYTHON_PREFIX_ARG ?= --prefix=''''
# make tools
fails.
Xen 3.4 Dom0 with 2.6.30-rc3-tip loads fine. Xend starts fine.
Reports bellow :-
# xm info
# brctl show
# ifconfig
Demonstrate normal Xen
Host state.
However, working in same Xen environment and same kernel , been built on top of
Ubuntu Server 8.10, F10 PV DomU fails to start:-
root@ServerJaunty:/home/boris/vm# cat f10.pyrun
name="F10PV"
memory=2048
disk = [''phy:/dev/sdb7,xvda,w'' ]
vif = [ ''bridge=eth1'' ]
bootloader "/usr/bin/pygrub"
vcpus=2
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Traceback (most recent call last):
File "/usr/bin/pygrub", line 684,
in <module>
chosencfg = run_grub(file,
entry, fs, incfg["args"])
File "/usr/bin/pygrub",
line 521, in run_grub
curses.wrapper(run_main)
File "/usr/lib/python2.5/curses/wrapper.py",
line 47, in wrapper
root@ServerJaunty:/home/boris/vm# Error: Boot loader didn''t return any
data!
root@ServerJaunty:/home/boris/vm# xm create -c f10.pyrun
Using config file "./f10.pyrun".
Error: Boot loader didn''t return any
data!
root@ServerJaunty:/home/boris/vm# xm create -c rhel.pyrun
Using config file "./rhel.pyrun".
Error: Boot loader didn''t return any data!
root@ServerJaunty:/home/boris/vm#
Boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Jackson
2009-May-12 14:13 UTC
Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore
Boris Derzhavets writes ("[Xen-devel] Changeset 19594 for Xen 3.4 build on
Ubuntu Server 9.04 causes pygrub doesn''t return any data
anymore"):> I was able to rebuild xen& tools with only one line modified in
Config.mk :-
>
> PYTHON ?= /usr/bin/python2.5
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the line you changed ? I''m afraid your message wasn''t
very
clear.
> IF PYTHON_PREFIX_ARG ?=''''
This is the feature I put in to let you override the --prefix
specification from the Xen build system, specifically to try to work
around the Ubuntu python installation bug. If it doesn''t work then
something is wrong.
That is, I think the following config should work on those Ubuntu
systems
PYTHON=python
PYTHON_PREFIX_ARG=''''
although you may need to do
PREFIX=/usr/local
too.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Maybe Matching Threads
- How to disable checksum offloading for OSOL DomU via kmdb at initial boot ?
- [PATCH 10/14] Nested Virtualization: svm specific implementation
- Re: Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore
- [PATCH] svm: support VMCB cleanbits
- scheduler independent forced vcpu selection