Xen 3.0.3 rc2 available

Xen 3.0.3 rc2 available

[Keir Fraser]

A new release candidate of Xen 3.0.3 is available for download and testing
at http://xenbits.xensource.com/xen-3.0.3-testing.hg

This takes the 3.0.3-testing tree up to changeset 11686:f426f6e646eb from
xen-unstable. Binary tarballs will be available in due course.

Please beat up on this release candidate and post bug reports on any
outstanding issues. We are getting close to 3.0.3-0 final release!

When posting a bug report, please remember to include boot output from Xen
(taken from a serial line dump, or by taking the output from 'xm dmesg')
and/or the platform info printed by 'xm info'.

 Thanks,
 Keir

invalid PTE for xen_start-info ?

[Rik van Riel]

Keir Fraser wrote:

> Please beat up on this release candidate and post bug reports on any
> outstanding issues. We are getting close to 3.0.3-0 final release!

I am seeing some suspicious output from the xen_start_info
pte address at startup.  This is with the 2.6.9 Xen code,
which is mostly based off an older code base, but I notice
that mfn_to_pfn() in the current codebase seems to have a
workaround for this bug.

Started domain crumble
xen_start_info @ffffffff8087c000
shared @m0000fc3000 @ffffffff80107000=@ffffffffff5fd000 [0x802]
xen_start_info: @ffffffff8087c000
cr3 0000000000101000 pml4p ffffffff80101ff8
pml4e 0000000000103067 (real 0000000035e09067) pgdp ffffff8000103ff0
pgde 0000000000105067 (real 0000000035e07067) pmdp ffffff8000105020
pmde 0000000000886067 (real 0000000035006067) ptep ffffff80008863e0
pte 0000000019800027 (real 0010000035010027)

That last PTE value does not look like a valid x86-64 PTE
value to me.  That high bit is not the NX bit, nor is it
within the physical address range of the system in question.

What's going on here?

Is this a bug you would like a fix for?

-- 
All Rights Reversed

xen-3.0.3-testing-install-x86_32 dom0 boot failure

[Richard Miller]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Error message is:

	VFS: Cannot open root device "hda1" or unknown-block(0,0)
	Please append a correct "root=" boot option
	Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The cause seems to be that the kernel was configured with IDE support
(CONFIG_BLK_DEV_IDE=y) but not IDE disk support (CONFIG_BLK_DEV_IDEDISK=m).

To make life easier for people with root filesystems on IDE disks (not
uncommon, I think) may I suggest this patch?

-- Richard Miller

[-- Attachment #2: Type: text/plain, Size: 1169 bytes --]

# HG changeset patch
# User miller@vt310
# Node ID 0273fa71dff31a72ccc7501203309ed62001bf2c
# Parent  000aa9510e5587f869a743121dd06ad2e0f21a99
Define CONFIG_BLK_DEV_IDEDISK=y for IDE root disk support.

diff -r 000aa9510e55 -r 0273fa71dff3 buildconfigs/linux-defconfig_xen_x86_32
--- a/buildconfigs/linux-defconfig_xen_x86_32	Wed Sep 27 14:30:36 2006 +0100
+++ b/buildconfigs/linux-defconfig_xen_x86_32	Tue Oct 03 11:38:38 2006 +0100
@@ -986,7 +986,7 @@ CONFIG_BLK_DEV_IDE=y
 #
 # CONFIG_BLK_DEV_IDE_SATA is not set
 # CONFIG_BLK_DEV_HD_IDE is not set
-CONFIG_BLK_DEV_IDEDISK=m
+CONFIG_BLK_DEV_IDEDISK=y
 CONFIG_IDEDISK_MULTI_MODE=y
 CONFIG_BLK_DEV_IDECS=m
 CONFIG_BLK_DEV_IDECD=m
diff -r 000aa9510e55 -r 0273fa71dff3 buildconfigs/linux-defconfig_xen_x86_64
--- a/buildconfigs/linux-defconfig_xen_x86_64	Wed Sep 27 14:30:36 2006 +0100
+++ b/buildconfigs/linux-defconfig_xen_x86_64	Tue Oct 03 11:38:38 2006 +0100
@@ -936,7 +936,7 @@ CONFIG_BLK_DEV_IDE=y
 #
 # CONFIG_BLK_DEV_IDE_SATA is not set
 # CONFIG_BLK_DEV_HD_IDE is not set
-CONFIG_BLK_DEV_IDEDISK=m
+CONFIG_BLK_DEV_IDEDISK=y
 CONFIG_IDEDISK_MULTI_MODE=y
 # CONFIG_BLK_DEV_IDECS is not set
 CONFIG_BLK_DEV_IDECD=m

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: invalid PTE for xen_start-info ?

[Keir Fraser]

On 3/10/06 7:06 pm, "Rik van Riel" <riel@redhat.com> wrote:

> pte 0000000019800027 (real 0010000035010027)
> 
> That last PTE value does not look like a valid x86-64 PTE
> value to me.  That high bit is not the NX bit, nor is it
> within the physical address range of the system in question.
> 
> What's going on here?
> 
> Is this a bug you would like a fix for?

It's not a bug -- it's one of the available-for-software flags that is
stolen by Xen to indicate a kernel PTE. This is done so that we can
distinguish kernel and user mappings, so that the latter can have the global
bit set. Sounds weird, but it avoids flushing user mappings from the TLB
when executing syscalls (we have to change %cr3 value when switching between
guest-user and guest-kernel modes).

 -- Keir

[PATCH] redundant ampersand before array name in __RING_SIZE macro

[Richard Miller]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

The __RING_SIZE macro in xen/include/public/io/ring.h has an ampersand
before (_s)->ring which is unnecessary (an array name without subscript already
means "address of"), and causes fussy C compilers like the Plan 9 one to generate
very many warning messages like this when the FRONT_RING_INIT macro is used:

	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	warning: etherxen.c:215 address of array/func ignored
	... etc

Would you like to tidy it up with the attached patch?

-- Richard Miller

[-- Attachment #2: Type: text/plain, Size: 835 bytes --]

# HG changeset patch
# User miller@vt310
# Node ID 16863ad2efc0f6b4abe7b8239f55946aa3f336fc
# Parent  473689acffdbc8b615fbc38ce8a877a904b702ed
Remove redundant '&' before array name in __RING_SIZE macro.

Signed-off-by: Richard Miller <9xen@hamnavoe.com>

diff -r 473689acffdb -r 16863ad2efc0 xen/include/public/io/ring.h
--- a/xen/include/public/io/ring.h	Tue Oct 03 17:53:42 2006 +0100
+++ b/xen/include/public/io/ring.h	Wed Oct 04 12:27:45 2006 +0100
@@ -25,7 +25,7 @@ typedef unsigned int RING_IDX;
  * power of two (so we can mask with (size-1) to loop around).
  */
 #define __RING_SIZE(_s, _sz) \
-    (__RD32(((_sz) - (long)&(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
+    (__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
 
 /*
  * Macros to make the correct C datatypes for a new kind of ring.

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: invalid PTE for xen_start-info ?

[Rik van Riel]

Keir Fraser wrote:
> On 3/10/06 7:06 pm, "Rik van Riel" <riel@redhat.com> wrote:
> 
>> pte 0000000019800027 (real 0010000035010027)
>>
>> That last PTE value does not look like a valid x86-64 PTE
>> value to me.  That high bit is not the NX bit, nor is it
>> within the physical address range of the system in question.
>>
>> What's going on here?
>>
>> Is this a bug you would like a fix for?
> 
> It's not a bug -- it's one of the available-for-software flags that is
> stolen by Xen to indicate a kernel PTE. This is done so that we can
> distinguish kernel and user mappings, so that the latter can have the global
> bit set. Sounds weird, but it avoids flushing user mappings from the TLB
> when executing syscalls (we have to change %cr3 value when switching between
> guest-user and guest-kernel modes).

OK, so pte_val() just needs to know about these software flags
and mask them out before passing the value to mfn_to_pfn ?

-- 
"You don't have to be crazy to do this... but it helps." -- Bob Ross

Re: invalid PTE for xen_start-info ?

[Keir Fraser]

On 4/10/06 14:47, "Rik van Riel" <riel@redhat.com> wrote:

>> It's not a bug -- it's one of the available-for-software flags that is
>> stolen by Xen to indicate a kernel PTE. This is done so that we can
>> distinguish kernel and user mappings, so that the latter can have the global
>> bit set. Sounds weird, but it avoids flushing user mappings from the TLB
>> when executing syscalls (we have to change %cr3 value when switching between
>> guest-user and guest-kernel modes).
> 
> OK, so pte_val() just needs to know about these software flags
> and mask them out before passing the value to mfn_to_pfn ?

You should use pte_pfn(), or pte_mfn(), or (pte_val() & PHYSICAL_PAGE_MASK)
for isolating the address part of a pte. If there is *any* Linux code that
is accessing addresses from pte contents via other methods then please do
let us know! But I suspect this won't be the case, due to the existing need
to mask off PAGE_NX.

 -- Keir

Re: invalid PTE for xen_start-info ?

[Rik van Riel]

Keir Fraser wrote:

> You should use pte_pfn(), or pte_mfn(), or (pte_val() & PHYSICAL_PAGE_MASK)
> for isolating the address part of a pte. If there is *any* Linux code that
> is accessing addresses from pte contents via other methods then please do
> let us know! But I suspect this won't be the case, due to the existing need
> to mask off PAGE_NX.

Does that break compatibility between the hypervisor and
older guests?

-- 
"You don't have to be crazy to do this... but it helps." -- Bob Ross

Re: invalid PTE for xen_start-info ?

[Keir Fraser]

On 4/10/06 16:06, "Rik van Riel" <riel@redhat.com> wrote:

>> You should use pte_pfn(), or pte_mfn(), or (pte_val() & PHYSICAL_PAGE_MASK)
>> for isolating the address part of a pte. If there is *any* Linux code that
>> is accessing addresses from pte contents via other methods then please do
>> let us know! But I suspect this won't be the case, due to the existing need
>> to mask off PAGE_NX.
> 
> Does that break compatibility between the hypervisor and
> older guests?

Assuming they ignore high-order software flags, no. I believe that's true
for Linux and Solaris. I don't think there are any other x86/64 PV guest
Oses.

 -- Keir

Re: Xen 3.0.3 rc2 available

[Nick Craig-Wood]

On Tue, Oct 03, 2006 at 11:33:44AM +0100, Keir Fraser wrote:
> Please beat up on this release candidate and post bug reports on any
> outstanding issues. We are getting close to 3.0.3-0 final release!

I couldn't get it to compile with gcc-3.3 under Debian, complaining
about linkonce errors. There is a previous note to the mailing list
about someone else with this problem :-

  http://lists.xensource.com/archives/html/xen-users/2006-09/msg00741.html

Once I did get it compiled (I compiled everything but the kernels with
gcc-4.1 and the kernels with gcc-3.4) it works fine!

I tested some non-hvm linux distros - these worked fine.  We've had a
few problems with Zombies in recent Xen version so I'll make sure this
version gets some more testing to see if they are eliminated.

HVM Windows 2003 worked well also. Both the previous bugs I reported
are still present though...

"vif-route configures wrong interface for hmx domains"

  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=584

  I've managed to work around this with a bit of cunning in the
  /etc/xen/qemu-ifup script though.

"vnc mouse pointer is offset when using win2003 hvm"

  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=585

  the serial console (SAC) is working now though, so you can use that
  to set the IP address and then go straight to rdesktop which works
  extrememly well.

Excellent work - I look forward to the release!

-- 
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

Re: Xen 3.0.3 rc2 available

[Anthony Liguori]

Nick Craig-Wood wrote:
>
> HVM Windows 2003 worked well also. Both the previous bugs I reported
> are still present though...
> 
> "vif-route configures wrong interface for hmx domains"
> 
>   http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=584
> 
>   I've managed to work around this with a bit of cunning in the
>   /etc/xen/qemu-ifup script though.
> 
> "vnc mouse pointer is offset when using win2003 hvm"
> 
>   http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=585

This is to do having mouse acceleration enabled.  It's not actually a 
bug but rather a limitation in the VNC protocol.

Enable USB tablet support and you won't have these problems.

Regards,

Anthony Liguori


>   the serial console (SAC) is working now though, so you can use that
>   to set the IP address and then go straight to rdesktop which works
>   extrememly well.
> 
> Excellent work - I look forward to the release!
> 

Re: Xen 3.0.3 rc2 available

[Keir Fraser]

On 6/10/06 9:47 pm, "Nick Craig-Wood" <nick@craig-wood.com> wrote:

> I couldn't get it to compile with gcc-3.3 under Debian, complaining
> about linkonce errors. There is a previous note to the mailing list
> about someone else with this problem :-

Global function sig_handler() is defined twice. Tsk.

I'll delete the one in tools/blktap/drivers/blktapctrl.c and that should fix
the build on Debian Sarge.

 -- Keir

Re: Xen 3.0.3 rc2 available

[Nick Craig-Wood]

On Fri, Oct 06, 2006 at 03:55:02PM -0500, Anthony Liguori wrote:
> Nick Craig-Wood wrote:
> >"vnc mouse pointer is offset when using win2003 hvm"
> >
> >  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=585
> 
> This is to do having mouse acceleration enabled.  It's not actually a 
> bug but rather a limitation in the VNC protocol.

I tried disabling the mouse acceleration which didn't seem to have any
effect.

> Enable USB tablet support and you won't have these problems.

Yes that works much better - thank you!

-- 
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick