thr3ads.net - Xen devel - [Xen-devel] vmx_update_guest_cr() losing EXCEPTION

If this information is useful, please help other people find it:
Share via:

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

[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

head link

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

head link

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

head link

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

Search for more maybe matching threads

Xen devel - May 2009 - vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

[Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

RE: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

RE: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

[Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore

Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore

Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore

Re: [Xen-devel] Changeset 19594 for Xen 3.4 build on Ubuntu Server 9.04 causes pygrub doesn''t return any data anymore

Maybe Matching Threads