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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Richard Miller
2006-Oct-03 18:17 UTC
[Xen-devel] xen-3.0.3-testing-install-x86_32 dom0 boot failure
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 # 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Richard Miller
2006-Oct-04 13:46 UTC
[Xen-devel] [PATCH] redundant ampersand before array name in __RING_SIZE macro
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 # 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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=585This 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! >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel