[XenPPC] Re: [Xen-devel] [PATCH 1/2] [xencomm, linux] linux xencomm consolidation
On Tue, Aug 07, 2007 at 05:48:54PM +0900, Isaku Yamahata wrote: - add gcc bug work around. gcc 4.1.2 on ia64 doesn't handle properly auto variables with align attribute. I thought this gcc issue was ia64 specific at first. But it seems to be generic (non-arch specific) issue. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 (The patch exists, but it doesn't seem to be included in the main line yet.) Does the current xencomm_map_no_alloc() work on powerpc properly? At least my powerpc64-linux-gcc (gcc 4.1.1) doesn't seem to support __attribute__((aligned(32))) on stack variables. thanks, -- yamahata ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] DOM0 can not be set up
On Fri, 2007-08-10 at 09:56 +0800, Jun Hui Bu wrote: According to the instructions in Xen wiki, Xen could not set up DOM0 guest OS(SLES10 SP1) when try it on JS20. Would you please help take a look it? Thanks a lot! How old is your source? The boot log contains this line: OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) Sun Sep 9 09:34:58 EDT 2007 ... which is clearly inaccurate. What exact command line are you using to build Xen? How are you attaching your dom0? I've never used yaboot to boot Xen, but please paste your xen yaboot config. I find this interesting in particular: boot_of_module: Dom0 was loaded and found using r3/r4:0xf0[size 0x35d000] mod0: 63 L 3 Ì boot_of_module: dom0 mod @ 0x00f0[0x125d000] That mod0 output looks suspicious if it's supposed to be an ELF file... -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [ppc/xen-unstable.hg] [POWERPC][XEN] Fix unused variable warni...
Changeset 1d87e8ce6aab :
http://xenbits.xensource.com/ext/ppc/xen-unstable.hg?cmd=changeset;node=1d87e8ce6aab
[POWERPC][XEN] Fix unused variable warning when asserts are disabled.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diffstat:
1 files changed, 1 insertion(+), 1 deletion(-)
xen/arch/powerpc/shadow.c |2 +-
diffs (19 lines):
diff -r 04fb85a46dc5 -r 1d87e8ce6aab xen/arch/powerpc/shadow.c
--- a/xen/arch/powerpc/shadow.c Thu Aug 02 09:54:18 2007 -0500
+++ b/xen/arch/powerpc/shadow.c Fri Aug 10 14:27:21 2007 -0500
@@ -39,7 +39,6 @@ static ulong htab_alloc(struct domain *d
{
ulong htab_raddr;
uint log_htab_bytes = order + PAGE_SHIFT;
-uint htab_bytes = 1UL log_htab_bytes;
/* we use xenheap pages to keep domheap pages usefull for domains */
@@ -50,6 +49,7 @@ static ulong htab_alloc(struct domain *d
htab_raddr = (ulong)alloc_xenheap_pages(order);
if (htab_raddr 0) {
+uint htab_bytes = 1UL log_htab_bytes;
ASSERT((htab_raddr (htab_bytes - 1)) == 0);
d-arch.htab.order = order;
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [PATCH] [xen, xencomm] various xencomm fixes (was Re: [XenPPC] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side))
On Tue, 2007-08-07 at 17:44 +0900, Isaku Yamahata wrote:
+/* get_page() to prevent from another vcpu freeing the page */
+static int
+xencomm_paddr_to_maddr(unsigned long paddr, unsigned long *maddr,
+struct page_info **page)
+{
+*maddr = paddr_to_maddr(paddr);
+if (*maddr == 0)
+return -EFAULT;
+
+*page = virt_to_page(*maddr);
+if (get_page(*page, current-domain) == 0) {
+if (page_get_owner(*page) != current-domain)
+/* This page might be a page granted by another domain */
+panic_domain(NULL, copy_from_guest from foreign domain\n);
+
+/* Try again. */
+return -EAGAIN;
+}
+
+return 0;
+}
PPC doesn't implement panic_domain(), so this doesn't build for me.
I don't see how we'd ever hit this case though, nor why we'd panic the
domain. How could paddr_to_maddr() ever return an maddr that doesn't
belong to the current domain? If paddr is invalid, an error should be
returned from there and propagated up, which is better than killing the
whole domain IMHO...
+*page = virt_to_page(*maddr);
This line doesn't make sense. Is it an maddr or a vaddr? If it's an
maddr, we shouldn't be passing it as virt to virt_to_page().
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
