[XenPPC] todays xen-unstable is throwing gcc errors when compiling on PPC
When compiling Xen on PPC today I get the following error that is being caused by casting (u32 *). Once the cast is removed all is well and things compile fine. Is this happening on x86 or x86-64 ? I'm using gcc 4.1.0 on Suse SLES 10. There Error: grant_table.c: In function ‘gnttab_prepare_for_transfer’: grant_table.c:825: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c: In function ‘__acquire_grant_for_copy’: grant_table.c:1055: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules make[3]: *** [grant_table.o] Error 1 make[3]: Leaving directory `/Work/xen-unstable.hg/xen/common' make[2]: *** [/Work/xen-unstable.hg/xen/common/built_in.o] Error 2 make[2]: Leaving directory `/Work/xen-unstable.hg/xen/arch/powerpc' make[1]: *** [/Work/xen-unstable.hg/xen/xen] Error 2 make[1]: Leaving directory `/Work/xen-unstable.hg/xen' make: *** [build] Error 2 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix for PPC xen in xen-unstable .. missing header
Fix build in xen-unstable for PPC. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff -r aa640601575f xen/arch/powerpc/sysctl.c --- a/xen/arch/powerpc/sysctl.c Mon Jul 09 14:51:44 2007 +0100 +++ b/xen/arch/powerpc/sysctl.c Mon Jul 09 17:12:59 2007 -0500 @@ -24,6 +24,7 @@ #include xen/sched.h #include xen/guest_access.h #include xen/shadow.h +#include xen/nodemask.h #include public/xen.h #include public/domctl.h #include public/sysctl.h ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH][POWERPC] Fix missing '{' for mm.c in xen-unstable
A '{' was missing from conditional if statement.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r d54d47fc8c6c xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Thu Jul 05 10:19:25 2007 +0100
+++ b/xen/arch/powerpc/mm.c Fri Jul 06 08:48:23 2007 -0500
@@ -187,7 +187,7 @@ int replace_grant_host_mapping(
unsigned long addr, unsigned long frame, unsigned long new_addr,
unsigned int flags)
{
-if (new_addr)
+if (new_addr) {
printk(%s: new_addr not supported\n, __func__);
BUG();
return GNTST_general_error;
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix xchg api to for Xen-unstable
On Thu, 2007-04-05 at 11:23 -0400, Jimi Xenidis wrote:
On Apr 4, 2007, at 10:43 PM, Jerone Young wrote:
On Wed, 2007-04-04 at 08:57 -0400, Jimi Xenidis wrote:
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
The caller is in common/domain.c @ line 310:
/* Already dying? Then bail. */
if ( xchg(d-is_dying, 1) )
{
domain_unpause(d);
return;
}
The current macro matches that one in x86. But the parameters we have
for __xchg are not in the same order. So one has to change to be
right.
I notice we have the macro wrong (at least in my copy of xen source):
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)
(v),
(ptr),sizeof(*(ptr
where it should be (from Linux):
#define xchg(ptr,x)
\
({
\
__typeof__(*(ptr)) _x_ = (x);
\
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*
(ptr))); \
})
Will that change fix your issue?
Doubtful..see use of code above.
Why?
How did I know that this would come back to haunt me :-)... it was late
and I wasn't thinking straight.
So this should work. The parameters are correct now with this approach.
I'll send another patch using this instead ;-)
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix xchg api to for Xen-unstable
This fixes the api for __xchg function in system.h so that PPC Xen can
build correctly in Xen unstable. This is the same API used in the __xchg
on x86.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 7e431ea834a8 xen/include/asm-powerpc/system.h
--- a/xen/include/asm-powerpc/system.h Tue Apr 03 13:22:37 2007 +0100
+++ b/xen/include/asm-powerpc/system.h Wed Jan 29 05:37:30 2031 -0600
@@ -73,7 +73,7 @@ extern void __xchg_called_with_bad_point
extern void __xchg_called_with_bad_pointer(void);
static __inline__ unsigned long
-__xchg(volatile void *ptr, unsigned long x, int size)
+__xchg(unsigned long x, volatile void *ptr, int size)
{
switch (size) {
case 4:
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Remove uses of packed attribute so Xen-unstable will build
So use of packed attribute is bad for PPC. PPC Xen build checks for
this and will not build if this is in the code.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r a1b17c48fb40 xen/include/public/acm.h
--- a/xen/include/public/acm.h Tue Apr 03 11:44:10 2007 +0100
+++ b/xen/include/public/acm.h Tue Jan 28 15:42:36 2031 -0600
@@ -124,7 +124,7 @@ struct acm_policy_version
{
uint32_t major;
uint32_t minor;
-} __attribute__((packed));
+};
/* each buffer consists of all policy information for
@@ -145,12 +145,12 @@ struct acm_policy_buffer {
uint32_t secondary_policy_code;
uint32_t secondary_buffer_offset;
struct acm_policy_version xml_pol_version; /* add in V3 */
-} __attribute__((packed));
+};
struct acm_policy_reference_buffer {
uint32_t len;
-} __attribute__((packed));
+};
struct acm_chwall_policy_buffer {
uint32_t policy_version; /* ACM_CHWALL_VERSION */
@@ -162,7 +162,7 @@ struct acm_chwall_policy_buffer {
uint32_t chwall_conflict_sets_offset;
uint32_t chwall_running_types_offset;
uint32_t chwall_conflict_aggregate_offset;
-} __attribute__((packed));
+};
struct acm_ste_policy_buffer {
uint32_t policy_version; /* ACM_STE_VERSION */
@@ -170,7 +170,7 @@ struct acm_ste_policy_buffer {
uint32_t ste_max_types;
uint32_t ste_max_ssidrefs;
uint32_t ste_ssid_offset;
-} __attribute__((packed));
+};
struct acm_stats_buffer {
uint32_t magic;
@@ -179,7 +179,7 @@ struct acm_stats_buffer {
uint32_t primary_stats_offset;
uint32_t secondary_policy_code;
uint32_t secondary_stats_offset;
-} __attribute__((packed));
+};
struct acm_ste_stats_buffer {
uint32_t ec_eval_count;
@@ -188,7 +188,7 @@ struct acm_ste_stats_buffer {
uint32_t gt_denied_count;
uint32_t ec_cachehit_count;
uint32_t gt_cachehit_count;
-} __attribute__((packed));
+};
struct acm_ssid_buffer {
uint32_t len;
@@ -200,7 +200,7 @@ struct acm_ssid_buffer {
uint32_t secondary_policy_code;
uint32_t secondary_max_types;
uint32_t secondary_types_offset;
-} __attribute__((packed));
+};
#endif
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Missing function __xchg_called_with_bad_pointer .. what todo ?
So now that __xchg has started to be used we have a problem building xen-syms as the function __xchg_called_with_bad_pointer used in include/asm-powerpc/system.h does not exist (see line 73). I get a linker error but it's for an udefined reference: /XEN/xen-unstable.hg/xen/common/built_in.o: In function `__xchg': /XEN/xen-unstable.hg/xen/include/asm/system.h:84: undefined reference to `__xchg_called_with_bad_pointer' /XEN/xen-unstable.hg/xen/include/asm/system.h:84: undefined reference to `__xchg_called_with_bad_pointer' /XEN/xen-unstable.hg/xen/include/asm/system.h:84: undefined reference to `__xchg_called_with_bad_pointer' /XEN/xen-unstable.hg/xen/include/asm/system.h:84: undefined reference to `__xchg_called_with_bad_pointer' Is there a better way to do this check? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix xchg api to for Xen-unstable
On Wed, 2007-04-04 at 08:57 -0400, Jimi Xenidis wrote:
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
The caller is in common/domain.c @ line 310:
/* Already dying? Then bail. */
if ( xchg(d-is_dying, 1) )
{
domain_unpause(d);
return;
}
The current macro matches that one in x86. But the parameters we have
for __xchg are not in the same order. So one has to change to be right.
I notice we have the macro wrong (at least in my copy of xen source):
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)(v),
(ptr),sizeof(*(ptr
where it should be (from Linux):
#define xchg(ptr,x)
\
({ \
__typeof__(*(ptr)) _x_ = (x);\
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*
(ptr))); \
})
Will that change fix your issue?
Doubtful..see use of code above.
I'd rather not change __xchg().
Ok .. I've attached a patch to this email with that change instead of
changing __xchg()
-JX
On Apr 4, 2007, at 2:04 AM, Jerone Young wrote:
This fixes the api for __xchg function in system.h so that PPC Xen can
build correctly in Xen unstable. This is the same API used in the
__xchg
on x86.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 7e431ea834a8 xen/include/asm-powerpc/system.h
--- a/xen/include/asm-powerpc/system.h Tue Apr 03 13:22:37 2007 +0100
+++ b/xen/include/asm-powerpc/system.h Wed Jan 29 05:37:30 2031 -0600
@@ -73,7 +73,7 @@ extern void __xchg_called_with_bad_point
extern void __xchg_called_with_bad_pointer(void);
static __inline__ unsigned long
-__xchg(volatile void *ptr, unsigned long x, int size)
+__xchg(unsigned long x, volatile void *ptr, int size)
{
switch (size) {
case 4:
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix so now can use Zimages again
This fixes the issue where you could not use zimages. The problem was that the program counter was not starting at the entry point in the elf image. This patch fixes it so it does. Signed-off-by: Jerone Young [EMAIL PROTECTED] Signed-off-by: Jerone Young [EMAIL PROTECTED] diff -r cc72b77132f9 xen/arch/powerpc/domain_build.c--- a/xen/arch/powerpc/domain_build.c Wed Mar 21 18:29:49 2007 -0500 +++ b/xen/arch/powerpc/domain_build.c Mon Jan 27 20:30:49 2031 -0600 @@ -229,7 +229,7 @@ int construct_dom0(struct domain *d, /* Load the dom0 kernel. */ elf.dest = (void *)dst; elf_load_binary(elf); -v-arch.ctxt.pc = dst - rma; +v-arch.ctxt.pc = dst - rma + (parms.virt_entry - parms.virt_kstart); dst = ALIGN_UP(dst + parms.virt_kend, PAGE_SIZE); /* Load the initrd. */ ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] libvirt not compatible with Xen-unstable hypercall API ?
While trying to verify any potential problem between with libvirt Xen PPC port. I've found that libvirt currently in CVS attempts to determine what hypercall version to follow, by looking at the hypervisior version. It determines that this is some arbitrary versioning v2 of the hypercall api. This starts on line 1250 of xen_internal.c. This does not appear to be compatible with current Xen-Unstable from testing and trying to hack it up. Has any work been done toward making libvirt compatible with Xen-unstable that has not been included? Or is it waiting till the offical 3.0.5 release? We are attempting to ensure that Xen PPC works with libvirt. Though we have to use the latest hypercall api. Thanks, Jerone ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Add USB Nvidia Frame buffer support to default config for Bimini
This will add support for USB the Nvidia Frame buffer to the default config so that monitor, keyboard, and mouse will work on Bimini systems. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff -r 04f6ad5d9232 arch/powerpc/configs/xen_maple_defconfig --- a/arch/powerpc/configs/xen_maple_defconfig Mon Mar 05 13:23:38 2007 -0600 +++ b/arch/powerpc/configs/xen_maple_defconfig Wed Jan 15 17:51:10 2031 -0600 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17 -# Mon Jan 15 23:48:47 2007 +# Wed Jan 15 17:49:45 2031 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -507,6 +507,7 @@ CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=10240 @@ -959,18 +960,57 @@ CONFIG_VIDEO_V4L2=y # Digital Video Broadcasting Devices # # CONFIG_DVB is not set +# CONFIG_USB_DABUSB is not set # # Graphics support # CONFIG_FIRMWARE_EDID=y -# CONFIG_FB is not set +CONFIG_FB=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_MODE_HELPERS=y +# CONFIG_FB_TILEBLITTING is not set +# CONFIG_FB_CIRRUS is not set +# CONFIG_FB_PM2 is not set +# CONFIG_FB_CYBER2000 is not set +# CONFIG_FB_OF is not set +# CONFIG_FB_CT65550 is not set +# CONFIG_FB_ASILIANT is not set +# CONFIG_FB_IMSTT is not set +# CONFIG_FB_VGA16 is not set +# CONFIG_FB_S1D13XXX is not set +CONFIG_FB_NVIDIA=y +# CONFIG_FB_NVIDIA_I2C is not set +# CONFIG_FB_RIVA is not set +# CONFIG_FB_MATROX is not set +# CONFIG_FB_RADEON is not set +# CONFIG_FB_ATY128 is not set +# CONFIG_FB_ATY is not set +# CONFIG_FB_SAVAGE is not set +# CONFIG_FB_SIS is not set +# CONFIG_FB_NEOMAGIC is not set +# CONFIG_FB_KYRO is not set +# CONFIG_FB_3DFX is not set +# CONFIG_FB_VOODOO1 is not set +# CONFIG_FB_TRIDENT is not set +# CONFIG_FB_VIRTUAL is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +# CONFIG_FRAMEBUFFER_CONSOLE is not set + +# +# Logo configuration +# +# CONFIG_LOGO is not set +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound @@ -983,10 +1023,123 @@ CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y -# CONFIG_USB is not set +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_SPLIT_ISO is not set +# CONFIG_USB_EHCI_ROOT_HUB_TT is not set +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +# CONFIG_USB_ISP116X_HCD is not set +# CONFIG_USB_OHCI_HCD is not set +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_ISD200 is not set +# CONFIG_USB_STORAGE_DPCM is not set +# CONFIG_USB_STORAGE_USBAT is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Input Devices +# +CONFIG_USB_HID=y +CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set +# CONFIG_HID_FF is not set +# CONFIG_USB_HIDDEV is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set +# CONFIG_USB_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_TOUCHSCREEN is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CY7C63 is not set +# CONFIG_USB_CYTHERM is not set
Re: [XenPPC] [PATCH] add machine info to /proc/cpuinfo change platform to Xen
The output of /proc/cpuinfo from this patch looks like the following:
[EMAIL PROTECTED] ~]# cat /proc/cpuinfo
processor : 0
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
processor : 1
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
timebase: 199838713
platform: Xen
machine : CHRP IBM,8842-21X
Looks nice doesn't it :-) notice you see the machine type... ready for
the tree.
On Thu, 2007-03-01 at 17:09 -0600, Hollis Blanchard wrote:
On Thu, 2007-03-01 at 15:27 -0600, Jerone Young wrote:
This patch adds machine information to /proc/cpuinfo as well as
changes the platform for Xen-Maple to Xen.
Jimi, this is the patch I was talking about.
Jerone, can you please paste cpuinfo from a system with this patch
applied? Also, see below.
diff -r 3e512eaf2a6f arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cThu Mar 01 10:27:39
2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.cThu Mar 01 14:27:23
2007 -0600
@@ -39,6 +39,18 @@ extern struct machdep_calls mach_maple_m
extern struct machdep_calls mach_maple_md;
extern void maple_pci_init(void);
+static void xen_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *model = ;
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, machine\t\t: CHRP %s\n, model);
+ of_node_put(root);
+}
Why CHRP? I don't think that should be there (think about PA Semi),
except *maybe* if the system actually is CHRP.
int direct_remap_pfn_range(struct vm_area_struct *vma,
unsigned long address,
unsigned long mfn,
@@ -272,9 +284,10 @@ void xen_machine_crash_shutdown(struct p
#endif
define_machine(xen) {
- .name = Xen-Maple,
+ .name = Xen,
.probe = xen_probe,
.setup_arch = xen_setup_arch,
+ .show_cpuinfo = xen_show_cpuinfo,
.init_early = xen_init_early,
#ifdef CONFIG_SHARE_MPIC
.init_IRQ = xen_maple_init_IRQ,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] add machine info to /proc/cpuinfo change platform to Xen
Ouch forgot to remove CHRP. Will send a new patch.
On Mon, 2007-03-12 at 18:04 -0500, Jerone Young wrote:
The output of /proc/cpuinfo from this patch looks like the following:
[EMAIL PROTECTED] ~]# cat /proc/cpuinfo
processor : 0
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
processor : 1
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
timebase: 199838713
platform: Xen
machine : CHRP IBM,8842-21X
Looks nice doesn't it :-) notice you see the machine type... ready for
the tree.
On Thu, 2007-03-01 at 17:09 -0600, Hollis Blanchard wrote:
On Thu, 2007-03-01 at 15:27 -0600, Jerone Young wrote:
This patch adds machine information to /proc/cpuinfo as well as
changes the platform for Xen-Maple to Xen.
Jimi, this is the patch I was talking about.
Jerone, can you please paste cpuinfo from a system with this patch
applied? Also, see below.
diff -r 3e512eaf2a6f arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cThu Mar 01 10:27:39
2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.cThu Mar 01 14:27:23
2007 -0600
@@ -39,6 +39,18 @@ extern struct machdep_calls mach_maple_m
extern struct machdep_calls mach_maple_md;
extern void maple_pci_init(void);
+static void xen_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *model = ;
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, machine\t\t: CHRP %s\n, model);
+ of_node_put(root);
+}
Why CHRP? I don't think that should be there (think about PA Semi),
except *maybe* if the system actually is CHRP.
int direct_remap_pfn_range(struct vm_area_struct *vma,
unsigned long address,
unsigned long mfn,
@@ -272,9 +284,10 @@ void xen_machine_crash_shutdown(struct p
#endif
define_machine(xen) {
- .name = Xen-Maple,
+ .name = Xen,
.probe = xen_probe,
.setup_arch = xen_setup_arch,
+ .show_cpuinfo = xen_show_cpuinfo,
.init_early = xen_init_early,
#ifdef CONFIG_SHARE_MPIC
.init_IRQ = xen_maple_init_IRQ,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] add machine info to /proc/cpuinfo change platform to Xen
So with the PA Simi board I'm very unsure since it is unknown if PA Simi
supports CHRP. But by removing it here it may be proper to remove it.
SLOF also does not advertise that it is CHRP anywhere in it's device
tree. Some examples are:
/proc/device-tree/compatible:
Momentum,Maple
/proc/device-tree/model:
IBM,8842-21X
Redhat happens to have a shared library that uses IBM CHRP in cpuinfo
as a way to identify the machine is a PPC 64 pseries box. But this is at
least not used by Anaconda.
So it seems right to remove CHRP. Patch is attached.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
On Mon, 2007-03-12 at 18:16 -0500, Jerone Young wrote:
Ouch forgot to remove CHRP. Will send a new patch.
On Mon, 2007-03-12 at 18:04 -0500, Jerone Young wrote:
The output of /proc/cpuinfo from this patch looks like the following:
[EMAIL PROTECTED] ~]# cat /proc/cpuinfo
processor : 0
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
processor : 1
cpu : PPC970, altivec supported
clock : 1600.00MHz
revision: 2.2 (pvr 0039 0202)
timebase: 199838713
platform: Xen
machine : CHRP IBM,8842-21X
Looks nice doesn't it :-) notice you see the machine type... ready for
the tree.
On Thu, 2007-03-01 at 17:09 -0600, Hollis Blanchard wrote:
On Thu, 2007-03-01 at 15:27 -0600, Jerone Young wrote:
This patch adds machine information to /proc/cpuinfo as well as
changes the platform for Xen-Maple to Xen.
Jimi, this is the patch I was talking about.
Jerone, can you please paste cpuinfo from a system with this patch
applied? Also, see below.
diff -r 3e512eaf2a6f arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cThu Mar 01 10:27:39
2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.cThu Mar 01 14:27:23
2007 -0600
@@ -39,6 +39,18 @@ extern struct machdep_calls mach_maple_m
extern struct machdep_calls mach_maple_md;
extern void maple_pci_init(void);
+static void xen_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *model = ;
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, machine\t\t: CHRP %s\n, model);
+ of_node_put(root);
+}
Why CHRP? I don't think that should be there (think about PA Semi),
except *maybe* if the system actually is CHRP.
int direct_remap_pfn_range(struct vm_area_struct *vma,
unsigned long address,
unsigned long mfn,
@@ -272,9 +284,10 @@ void xen_machine_crash_shutdown(struct p
#endif
define_machine(xen) {
- .name = Xen-Maple,
+ .name = Xen,
.probe = xen_probe,
.setup_arch = xen_setup_arch,
+ .show_cpuinfo = xen_show_cpuinfo,
.init_early = xen_init_early,
#ifdef CONFIG_SHARE_MPIC
.init_IRQ = xen_maple_init_IRQ,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
diff -r 04f6ad5d9232 arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.c Mon Mar 05 13:23:38 2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.c Mon Jan 06 23:38:05 2031 -0600
@@ -39,6 +39,18 @@ extern struct machdep_calls mach_maple_m
extern struct machdep_calls mach_maple_md;
extern void maple_pci_init(void);
+static void xen_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *model = ;
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, machine\t\t: %s\n, model);
+ of_node_put(root);
+}
+
int direct_remap_pfn_range(struct vm_area_struct *vma,
unsigned long address,
unsigned long mfn,
@@ -269,9 +281,10 @@ void xen_machine_crash_shutdown(struct p
#endif
define_machine(xen) {
- .name = Xen-Maple,
+ .name = Xen,
.probe = xen_probe,
.setup_arch = xen_setup_arch,
+ .show_cpuinfo = xen_show_cpuinfo,
.init_early = xen_init_early,
#ifdef CONFIG_SHARE_MPIC
.init_IRQ = xen_maple_init_IRQ,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Hg versions of PPC that is working
Current merge with xen-unstable has caused some problems. To help keep things going and help fix the problem. Here is the last working change set. changeset: 14614:9fe6fe88a6a1 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] add machine info to /proc/cpuinfo change platform to Xen
This patch adds machine information to /proc/cpuinfo as well as changes
the platform for Xen-Maple to Xen.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 3e512eaf2a6f arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.c Thu Mar 01 10:27:39 2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.c Thu Mar 01 14:27:23 2007 -0600
@@ -39,6 +39,18 @@ extern struct machdep_calls mach_maple_m
extern struct machdep_calls mach_maple_md;
extern void maple_pci_init(void);
+static void xen_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *model = ;
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, machine\t\t: CHRP %s\n, model);
+ of_node_put(root);
+}
+
int direct_remap_pfn_range(struct vm_area_struct *vma,
unsigned long address,
unsigned long mfn,
@@ -272,9 +284,10 @@ void xen_machine_crash_shutdown(struct p
#endif
define_machine(xen) {
- .name = Xen-Maple,
+ .name = Xen,
.probe = xen_probe,
.setup_arch = xen_setup_arch,
+ .show_cpuinfo = xen_show_cpuinfo,
.init_early = xen_init_early,
#ifdef CONFIG_SHARE_MPIC
.init_IRQ = xen_maple_init_IRQ,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Should the platform name be Xen-Maple
In /proc/cpuinfo of a domain0 you see the following: processor : 0 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) timebase: 14318378 platform: Xen-Maple The platform line Xen-Maple is currently used by some tools in distros to identify the platform of the machine. The question I pose is should this be changed from Xen-Maple since running on Xen does not mean you are running on Maple. Something like Xen would probably be better. What do you guys think ? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Should the platform name be Xen-Maple
Ok. But there is another thing I left out. Under global firmware you normally have a line machine: in /proc/cpuinfo that shows the machine platform you are running on. In case of the JS20s this looks like: machine : CHRP IBM,8842-21X On Tue, 2007-02-27 at 14:56 -0500, Jimi Xenidis wrote: This comes from the fact that we are running xen from an underlying host platform. for example, if you boot linux without xen but on SLOF your machine name is Maple. see: arch/powerpc/platforms/xen/setup.c define_machine 246 define_machine(xen) I'd be interested in changing this to Xen for DomUs, but Dom0 should reflect the underlying machine type that linux would use without Xen. -JX On Feb 27, 2007, at 2:48 PM, Jerone Young wrote: In /proc/cpuinfo of a domain0 you see the following: processor : 0 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) timebase: 14318378 platform: Xen-Maple The platform line Xen-Maple is currently used by some tools in distros to identify the platform of the machine. The question I pose is should this be changed from Xen-Maple since running on Xen does not mean you are running on Maple. Something like Xen would probably be better. What do you guys think ? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix up potential memory leaks introduced by xencomm patch
On Thu, 2007-02-08 at 07:18 -0500, Jimi Xenidis wrote:
mostly Linux Kernel style NITS
On Feb 7, 2007, at 4:26 PM, Jerone Young wrote:
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have
memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.cTue Feb 06 17:10:20 2007
-0500
+++ b/arch/powerpc/platforms/xen/hcall.cWed Feb 07 14:50:05 2007
-0600
@@ -203,11 +203,16 @@ int HYPERVISOR_sched_op(int cmd, void *a
desc = xencomm_map_no_alloc(arg, argsize);
- if (desc == NULL)
- return -EINVAL;
-
- rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
- cmd, desc);
+ if (desc)
+ {
brace on same line
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
+ cmd, desc);
+ xencomm_free(desc);
+ }
+ else
+ {
no braces for single line, in fact avoid the single line by pre-
assigning the rc, the compiler will do the right optimization anyway.
+ rc = -EINVAL;
I thought we agreed that xencomm_map_* failures would be ENOMEM or
ENOSPC?
No changed it (based on your suggestion) to EINVAL. ENOSPC is really
meant for disks out of space. So this actually kind of made the mode
since, it's an invalid argument, because it is too big.
+ }
xencomm_free(ports);
@@ -389,8 +394,8 @@ static int xenppc_privcmd_domctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_domctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -463,8 +468,8 @@ static int xenppc_privcmd_sysctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_sysctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -514,8 +519,8 @@ static int xenppc_privcmd_platform_op(pr
if (copy_to_user(user_op, kern_op, sizeof(xen_platform_op_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -547,7 +552,10 @@ int HYPERVISOR_memory_op(unsigned int cm
sizeof(*xen_guest_handle(mop-extent_start)));
if (desc == NULL)
+ {
Curlies again
ok I'll send a new patch with all the curlie braces on the first line.
+ xencomm_free(op_desc);
return -ENOMEM;
+ }
set_xen_guest_handle(mop-extent_start,
desc);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [RESEND] Fix up potential memory leaks introduced by xencomm
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Feb 06 17:10:20 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Feb 07 08:19:45 2007 -0600
@@ -203,11 +203,14 @@ int HYPERVISOR_sched_op(int cmd, void *a
desc = xencomm_map_no_alloc(arg, argsize);
- if (desc == NULL)
- return -EINVAL;
-
- rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
-cmd, desc);
+ if (desc) {
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
+ cmd, desc);
+ xencomm_free(desc);
+ }
+ else {
+ rc = -EINVAL;
+ }
xencomm_free(ports);
@@ -389,8 +392,8 @@ static int xenppc_privcmd_domctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_domctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -463,8 +466,8 @@ static int xenppc_privcmd_sysctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_sysctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -514,8 +517,8 @@ static int xenppc_privcmd_platform_op(pr
if (copy_to_user(user_op, kern_op, sizeof(xen_platform_op_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -546,8 +549,10 @@ int HYPERVISOR_memory_op(unsigned int cm
mop-nr_extents *
sizeof(*xen_guest_handle(mop-extent_start)));
- if (desc == NULL)
+ if (desc == NULL) {
+xencomm_free(op_desc);
return -ENOMEM;
+ }
set_xen_guest_handle(mop-extent_start,
desc);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Problems with Xen in hg tree
OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) On Tue, 2007-02-06 at 17:58 -0600, Jerone Young wrote: So cloning the Xen tree as of today .. you can no longer bootup Xen :-). Here is the output on a JS21 The currently active flashside is: 1 (temporary) Stopping BMC watchdog... Trying to load: sync_console debug || root=/dev/sda3 debug from: net ... Bootloader 1.5 Reading MAC address from device: 00:14:5E:9C:1C:C5 Requesting IP address via BOOTP: 9.3.189.7 Requesting file leaf4 via TFTP Receiving data: A###A| TFTP: Received leaf4 (65359 KBytes) Successfully loaded --- OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) Tue Feb 6 17:18:51 CST 2007 boot_of_init args: 0x0 0x0 0xe11027c 0xe28bed2 0x2a boot msr: 0x10003000 boot_of_init: _start 004000d0 _end 042b0310 0xe28bed2 boot_of_alloc_init: pg :0x2000 of our image is different HANG I'll be looking into this in the morning. But just an FYI to everybody. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] boot failure with large dom0
I'll give it a try. On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote: I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with full debug symbols is 55MB here, which probably explains this problem. Could you see how easy it would be to catch this problem at runtime and have a nice panic? Checking dom0_len in __start_xen() would probably do the trick, maybe something like: if (dom0_start + dom0_len (3220)) panic(dom0 is too big); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix up potential memory leaks introduced by xencomm patch
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Feb 06 17:10:20 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Feb 07 14:50:05 2007 -0600
@@ -203,11 +203,16 @@ int HYPERVISOR_sched_op(int cmd, void *a
desc = xencomm_map_no_alloc(arg, argsize);
- if (desc == NULL)
- return -EINVAL;
-
- rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
-cmd, desc);
+ if (desc)
+ {
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
+ cmd, desc);
+ xencomm_free(desc);
+ }
+ else
+ {
+ rc = -EINVAL;
+ }
xencomm_free(ports);
@@ -389,8 +394,8 @@ static int xenppc_privcmd_domctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_domctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -463,8 +468,8 @@ static int xenppc_privcmd_sysctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_sysctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -514,8 +519,8 @@ static int xenppc_privcmd_platform_op(pr
if (copy_to_user(user_op, kern_op, sizeof(xen_platform_op_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -547,7 +552,10 @@ int HYPERVISOR_memory_op(unsigned int cm
sizeof(*xen_guest_handle(mop-extent_start)));
if (desc == NULL)
+ {
+xencomm_free(op_desc);
return -ENOMEM;
+ }
set_xen_guest_handle(mop-extent_start,
desc);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix bug where dtb database is not created
This fixes a bug in the creating of the flat dev tree. If open is used
and O_CREAT not is specified, it will fail if the file has not already
been created. This patch will create the file if it does not exist
already. Which will allow for DomU creation.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
--- tools/libxc/powerpc64/mk_flatdevtree.c.orig 2007-02-06 16:15:47.0 -0600
+++ tools/libxc/powerpc64/mk_flatdevtree.c 2007-02-06 16:33:06.0 -0600
@@ -618,7 +618,7 @@
}
/* write a copy of the tree to a file */
-if ((dtb_fd = open(DTB_FILE , O_RDWR)) == -1) {
+if ((dtb_fd = open(DTB_FILE, O_CREAT|O_RDWR)) == -1) {
PERROR(%s: failed to open file %s, __func__, DTB_FILE);
goto error;
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Problems with Xen in hg tree
So cloning the Xen tree as of today .. you can no longer bootup Xen :-). Here is the output on a JS21 The currently active flashside is: 1 (temporary) Stopping BMC watchdog... Trying to load: sync_console debug || root=/dev/sda3 debug from: net ... Bootloader 1.5 Reading MAC address from device: 00:14:5E:9C:1C:C5 Requesting IP address via BOOTP: 9.3.189.7 Requesting file leaf4 via TFTP Receiving data: A###A| TFTP: Received leaf4 (65359 KBytes) Successfully loaded --- OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) Tue Feb 6 17:18:51 CST 2007 boot_of_init args: 0x0 0x0 0xe11027c 0xe28bed2 0x2a boot msr: 0x10003000 boot_of_init: _start 004000d0 _end 042b0310 0xe28bed2 boot_of_alloc_init: pg :0x2000 of our image is different HANG I'll be looking into this in the morning. But just an FYI to everybody. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [UPDATE] Xencomm patch
Yes..another Xencomm patch :-). The last one actually hit a bug that was
currently in xen-linux with handling of domain control operation
XEN_DOMCTL_shadow_op. This fix is included in the patch. I've also
added error handling and changed return codes from xencomm_no_alloc()
failure to be EINVAL.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r ab3b5849331d arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Sun Feb 04 12:12:24 2007 -0600
@@ -244,8 +244,8 @@ static void gnttab_post_map_grant_ref(
int HYPERVISOR_grant_table_op(unsigned int cmd, void *op, unsigned int count)
{
- void *desc;
- void *frame_list;
+ void *desc = NULL;
+ void *frame_list = NULL;
int argsize;
int ret;
@@ -263,8 +263,13 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(*xen_guest_handle(setup.frame_list))
+ * setup.nr_frames));
+
+ if (frame_list == NULL)
+ return -ENOMEM;
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,12 +291,18 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map_no_alloc(op, argsize);
+
+ if (desc == NULL)
+ return -ENOSPC;
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
if (cmd == GNTTABOP_map_grant_ref)
gnttab_post_map_grant_ref(op, count);
+
+ xencomm_free(frame_list);
+ xencomm_free(desc);
return ret;
}
diff -r ab3b5849331d arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Sun Feb 04 12:08:49 2007 -0600
@@ -54,25 +54,43 @@
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ int rc;
+
+ void *desc = xencomm_map_no_alloc(str, count);
+
+ if (desc == NULL)
+ return -EINVAL;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
+
+ xencomm_free(desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ int rc;
+
+ void *desc = xencomm_map_no_alloc(op, sizeof(evtchn_op_t));
+ if (desc == NULL)
+ return -EINVAL;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
+
+ xencomm_free(desc);
+
+ return rc;
+
}
EXPORT_SYMBOL(HYPERVISOR_event_channel_op);
-int HYPERVISOR_xen_version_userspace(int cmd, void *arg)
-{
- struct xencomm_desc *desc;
+int HYPERVISOR_xen_version(int cmd, void *arg)
+{
+ void *desc;
const unsigned long hcall = __HYPERVISOR_xen_version;
int argsize;
int rc;
@@ -97,7 +115,10 @@ int HYPERVISOR_xen_version_userspace(int
argsize = sizeof(xen_platform_parameters_t);
break;
case XENVER_pagesize:
- argsize = (arg == NULL) ? 0 : sizeof(void *);
+ if (arg == NULL)
+ argsize = 0;
+ else
+ argsize = sizeof(void *);
break;
case XENVER_get_features:
argsize = sizeof(xen_feature_info_t);
@@ -107,38 +128,41 @@ int HYPERVISOR_xen_version_userspace(int
return -ENOSYS;
}
- rc = xencomm_create(arg, argsize, desc, GFP_KERNEL);
- if (rc)
- return rc;
-
- rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, xencomm_pa(desc));
-
- xencomm_free(desc);
+ /* desc could be NULL in the case of XENVER_pagesize with NULL arg */
+ desc = xencomm_map(arg, argsize);
+
+ rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, desc);
+
+ xencomm_free(desc);
+
return rc;
}
EXPORT_SYMBOL(HYPERVISOR_xen_version);
-int HYPERVISOR_xen_version(int cmd, void *arg)
-{
- if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
- }
- return HYPERVISOR_xen_version_userspace(cmd, arg);
-}
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
+ void *desc = xencomm_map_no_alloc(op, sizeof(physdev_op_t));
+ int rc;
+
+ if (desc == NULL)
+ return -EINVAL;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
+
+ xencomm_free(desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_physdev_op);
int HYPERVISOR_sched_op(int cmd, void *arg)
{
- struct xencomm_desc *desc;
+ int argsize = 0;
+ int rc;
+ void *desc;
+ evtchn_port_t *ports = NULL;
switch (cmd) {
case SCHEDOP_yield:
@@ -148,30 +172,46 @@ int HYPERVISOR_sched_op(int cmd, void *a
break;
case SCHEDOP_poll: {
- evtchn_port_t *ports
[XenPPC] [PATCH] [RESEND] Xencomm patch
This patch should addresses many of the issues discussed with previous
revisions of the Xencomm patch.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r ab3b5849331d -r 3cca2783d266 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Thu Feb 01 12:00:26 2007 -0600
@@ -263,8 +263,10 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(*xen_guest_handle(setup.frame_list))
+ * setup.nr_frames));
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +288,10 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map_no_alloc(op, argsize);
+
+ if (desc == NULL)
+ return -ENOSPC;
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r ab3b5849331d -r 3cca2783d266 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Thu Feb 01 12:00:26 2007 -0600
@@ -54,25 +54,38 @@
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ void *desc = xencomm_map_no_alloc(str, count);
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ void *desc = xencomm_map_no_alloc(op, sizeof(evtchn_op_t));
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
+
+ return rc;
+
}
EXPORT_SYMBOL(HYPERVISOR_event_channel_op);
-int HYPERVISOR_xen_version_userspace(int cmd, void *arg)
-{
- struct xencomm_desc *desc;
+int HYPERVISOR_xen_version(int cmd, void *arg)
+{
+ void *desc;
const unsigned long hcall = __HYPERVISOR_xen_version;
int argsize;
int rc;
@@ -97,7 +110,10 @@ int HYPERVISOR_xen_version_userspace(int
argsize = sizeof(xen_platform_parameters_t);
break;
case XENVER_pagesize:
- argsize = (arg == NULL) ? 0 : sizeof(void *);
+ if (arg == NULL)
+ argsize = 0;
+ else
+ argsize = sizeof(void *);
break;
case XENVER_get_features:
argsize = sizeof(xen_feature_info_t);
@@ -107,38 +123,38 @@ int HYPERVISOR_xen_version_userspace(int
return -ENOSYS;
}
- rc = xencomm_create(arg, argsize, desc, GFP_KERNEL);
- if (rc)
- return rc;
-
- rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, xencomm_pa(desc));
-
- xencomm_free(desc);
+ /* desc could be NULL in the case of XENVER_pagesize with NULL arg */
+ desc = xencomm_map(arg, argsize);
+ rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, desc);
+
+ xencomm_free(desc);
+
return rc;
}
EXPORT_SYMBOL(HYPERVISOR_xen_version);
-int HYPERVISOR_xen_version(int cmd, void *arg)
-{
- if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
- }
- return HYPERVISOR_xen_version_userspace(cmd, arg);
-}
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
+ void *desc = xencomm_map_no_alloc(op, sizeof(physdev_op_t));
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_physdev_op);
int HYPERVISOR_sched_op(int cmd, void *arg)
{
- struct xencomm_desc *desc;
+ int argsize = 0;
+ int rc;
+ void *desc;
+ evtchn_port_t *ports = NULL;
switch (cmd) {
case SCHEDOP_yield:
@@ -148,30 +164,46 @@ int HYPERVISOR_sched_op(int cmd, void *a
break;
case SCHEDOP_poll: {
- evtchn_port_t *ports;
struct sched_poll sched_poll;
+ argsize = sizeof(struct sched_poll);
+
memcpy(sched_poll, arg, sizeof(sched_poll));
- ports = xencomm_create_inline(
- xen_guest_handle(sched_poll.ports));
+ ports = xencomm_map(
+xen_guest_handle(sched_poll.ports),
+(sizeof(evtchn_port_t) * sched_poll.nr_ports));
+
+ if (ports == NULL)
+ return -ENOMEM;
+
set_xen_guest_handle(sched_poll.ports, ports);
memcpy(arg, sched_poll, sizeof(sched_poll));
}
break;
case SCHEDOP_shutdown:
+ argsize = sizeof(struct sched_shutdown);
+ break;
case SCHEDOP_remote_shutdown:
+ argsize = sizeof(struct sched_remote_shutdown);
break;
default:
printk(KERN_ERR %s: unknown
Re: [XenPPC] [PATCH] [RESEND] Xencomm patch
Sorry guys. Please ignore this patch. I found a bug with it. Will submit a fixed version shortly. On Fri, 2007-02-02 at 16:42 -0600, Jerone Young wrote: This patch should addresses many of the issues discussed with previous revisions of the Xencomm patch. Signed-off-by: Jerone Young [EMAIL PROTECTED] ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Xencomm virutal Adress translation question?
On Sun, 2007-01-28 at 10:40 -0500, Jimi Xenidis wrote: Ok, xencomm is simply a data structure that describes (we'll call it the descriptor or desc) the physical memory that another data structure occupies (we'll call data). Sometimes this data is self described, such that all the data exists on a single page, or proven to be physically contiguous, so it is tagged as inline and no separate descriptor is necessary and therefore no allocation (or free) is required, so lets only consider when allocation is required. There are two methods to create this desc: (1) _map_early() and (2) _map(). _map_early() is used when allocation occurs from the stack and the size of data is known to be a small number (less than 4) pages, this is helpfull for performance and in cases where the allocator is unavailable (too early or in interrupt). The descriptor returned from this call does not require a corresponding free(). BTW: the above paragraph makes me want to rename _map_early() to _map_auto() or _map_stack() which in an obvious manner explains why no free() is needed. Hollis? Now to answer your question: In the case of _map(), if the data cannot be inlined then a single kernel page is allocated to describe up to 511 (+-1) pages of data, this page is known to easily be translated from kernel_virtual to kernel_physycal using __va() and __pa() function, so there should be no problem in using: desc = __pa(alloc_page()); and: free_page(__va(desc)); Well this is what is at issue. Acutally this was the first thing I thought of except with xencomm_pa if you are not not physically contiguous we will get back a physical address that cannot (I believe) corretly resolved by __va(). Hinting part of the problem. It's fine if it's Inline but it's the case that it's not inline that there seems there would be a problem. BTW: xencomm_pa(), should only be used when building the contents of desc in order to describe data, _not_ in creating the value of desc, that should always be __pa(). Ok.. this would explain a lot then. If this is the case then forget what I just said above. I need to change my function to not return a xencomm_pa(). Then everything should be fine. -JX On Jan 27, 2007, at 8:13 PM, Jerone Young wrote: I'm facing an interesting problem and I was wondering if anyone on the list (Jimi) could answer it. So in the xencomm patch that has been floating the list I have functions xencomm_map xencomm_map_early . Now currently they return physcial addresses regardless of the case. BUT, in the cases where they are not inline I face a BIG problem. As I have no way to truly translate back to a virtual address to free the memory with xencomm_free (__va() isn't going to cut it). So I currently have a patch (yet to go to the list) that has xencomm_map early returning a phyiscal address if it's inline and a virtual address if it is not. Well then I have a hack in xencomm_vtop that says if the address has bit XENCOMM_INLINE_FLAG. Then just return the address, since you are already physical. So when xencomm_pa() is used within the code it will return the proper address. Is this acceptable? I'm not sure of any other way of going about this since there is no good way to translate back to a virtual address to use xencomm_free. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [UPDATE] Xencomm
Here is yet another go at this. This patch I have thoroughly gone
thought.
Changes:
- move xencomm_map_early to xencomm_map_no_alloc
- added xencomm_free everywhere
- return ERRNOs instead of -1
Testing:
- loaded Dom0
- load modules xenblk(VIO) xennet
- lodaded DomU loading VI
- load modules xenblk(VIO) xennet
It appears that it allways hits create_inline everytime within the _map
functions and so xencomm_create_mini() xencomm_create are not getting
worked out yet.
But I think I've found problems making all the suggestions workout:
For xencomm_map xencomm_map_no_alloc there is a bit of an issue. The
caller has to accept the fact that it will get physcial address, since
it does not know if argument address can be made inline or not. It has
to use the resulting address in the following hypercall, and converting
it is unsure, since if are argument address can be made to an inline you
are converting a physical address to an invalid physical address.
The other problem that is created in this case is where we get an
physical address from xencomm_map that is returned from function
xencomm_pa() and cannot be simply converted back to a it's resulting
virtual address with __va().
If I'm wrong about this please blast away :-)
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r ab3b5849331d arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Sat Jan 29 20:02:49 2028 -0600
@@ -263,8 +263,10 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(*xen_guest_handle(setup.frame_list))
+ * setup.nr_frames));
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +288,10 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map_no_alloc(op, argsize);
+
+ if (desc == NULL)
+ return -ENOSPC;
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r ab3b5849331d arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Sat Jan 29 20:03:35 2028 -0600
@@ -54,25 +54,42 @@
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ void *desc = xencomm_map_no_alloc(str, count);
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
+
+ xencomm_free(desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ void *desc = xencomm_map_no_alloc(op, sizeof(evtchn_op_t));
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
+
+ xencomm_free(desc);
+
+ return rc;
+
}
EXPORT_SYMBOL(HYPERVISOR_event_channel_op);
-int HYPERVISOR_xen_version_userspace(int cmd, void *arg)
-{
- struct xencomm_desc *desc;
+int HYPERVISOR_xen_version(int cmd, void *arg)
+{
+ void *desc;
const unsigned long hcall = __HYPERVISOR_xen_version;
int argsize;
int rc;
@@ -107,38 +124,42 @@ int HYPERVISOR_xen_version_userspace(int
return -ENOSYS;
}
- rc = xencomm_create(arg, argsize, desc, GFP_KERNEL);
- if (rc)
- return rc;
-
- rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, xencomm_pa(desc));
-
- xencomm_free(desc);
+ desc = xencomm_map_no_alloc(arg, argsize);
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, desc);
+
+ xencomm_free(desc);
+
return rc;
}
EXPORT_SYMBOL(HYPERVISOR_xen_version);
-int HYPERVISOR_xen_version(int cmd, void *arg)
-{
- if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
- }
- return HYPERVISOR_xen_version_userspace(cmd, arg);
-}
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
+ void *desc = xencomm_map_no_alloc(op, sizeof(physdev_op_t));
+ int rc;
+
+ if (desc == NULL)
+ return -ENOSPC;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
+
+ xencomm_free(desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_physdev_op);
int HYPERVISOR_sched_op(int cmd, void *arg)
{
- struct xencomm_desc *desc;
+ int argsize
[XenPPC] Interesting warnings while compiling Xen modules
I was compiling the Xen block network as modules when I saw the following warnings during compile: WARNING: xen_start_info [drivers/xen/netfront/xennet.ko] undefined! WARNING: .is_running_on_xen [drivers/xen/netfront/xennet.ko] undefined! WARNING: .is_running_on_xen [drivers/xen/blkfront/xenblk.ko] undefined! I haven't looked into it yet. But I figured sending an email whould be good reminder for myself and any interested parties. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Export symbol xen_start_info for modules
Not sure exactly why this was not exported. But here is a patch to export xen_start_info symbol for modules. Signed-off-by: Jerone Young [EMAIL PROTECTED] # HG changeset patch # User [EMAIL PROTECTED] # Date 1169050609 21600 # Node ID a9acbe8fa5d711786082856aefa9f8c92af30b83 # Parent d450e2b2a85a7640643ecf7b2fddff2faa6dbcd4 export symbol xen_start_info for modules diff -r d450e2b2a85a -r a9acbe8fa5d7 arch/powerpc/platforms/xen/setup.c --- a/arch/powerpc/platforms/xen/setup.cTue Jan 16 00:12:50 2007 -0600 +++ b/arch/powerpc/platforms/xen/setup.cWed Jan 17 10:16:49 2007 -0600 @@ -33,6 +33,7 @@ EXPORT_SYMBOL(HYPERVISOR_shared_info); /* Raw start-of-day parameters from the hypervisor. */ start_info_t *xen_start_info; +EXPORT_SYMBOL(xen_start_info); extern struct machdep_calls mach_maple_md; extern void maple_pci_init(void); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Export symbol is_xen_running for modules
This patch will export the symbol is_xen_running for modules.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1169051130 21600
# Node ID e5962db179663fbae33a627f36e0a0c288c5fbdb
# Parent a9acbe8fa5d711786082856aefa9f8c92af30b83
Export symbol is_running_on_xen for modules
diff -r a9acbe8fa5d7 -r e5962db17966 arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cWed Jan 17 10:16:49 2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.cWed Jan 17 10:25:30 2007 -0600
@@ -151,6 +151,7 @@ int is_running_on_xen(void)
{
return running_on_xen;
}
+EXPORT_SYMBOL(is_running_on_xen);
static void xen_power_save(void)
{
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [RFC] Xencomm patch to fix modules
I haven't had a chance to fully test this patch. As I have been having
problems with my blade today. But here is the code for review. I'll get
back to the list once it is fully tested.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r e5962db17966 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Wed Jan 17 10:25:30 2007 -0600
+++ b/arch/powerpc/platforms/xen/gnttab.c Tue Jan 16 23:50:28 2007 -0600
@@ -263,8 +263,9 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(ulong) * setup.nr_frames));
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +287,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map(op, argsize);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r e5962db17966 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.cWed Jan 17 10:25:30 2007 -0600
+++ b/arch/powerpc/platforms/xen/hcall.cWed Jan 17 00:17:17 2007 -0600
@@ -50,11 +50,16 @@
* In general, we need a xencomm descriptor to cover the top-level data
* structure (e.g. the domctl op), plus another for every embedded
pointer to
* another data structure (i.e. for every GUEST_HANDLE).
+ *
+ * Some hypercalls are made before the memory subsystem is up, so
instead of
+ * calling xencomm_create(), we allocate XENCOMM_MINI_AREA bytes from
the stack
+ * to hold the xencomm descriptor.
*/
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
+
+ void *desc = xencomm_map_early(str, count);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
@@ -63,7 +68,8 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+
+ void *desc = xencomm_map_early(op, sizeof(evtchn_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
@@ -120,8 +126,8 @@ EXPORT_SYMBOL(HYPERVISOR_xen_version);
int HYPERVISOR_xen_version(int cmd, void *arg)
{
- if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
+ if (is_phys_contiguous((unsigned long)arg)) {
+ void *desc = xencomm_map_early(arg, sizeof(__u64));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version),
cmd,
desc);
}
return HYPERVISOR_xen_version_userspace(cmd, arg);
@@ -129,7 +135,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ void *desc = xencomm_map(op, sizeof(physdev_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
@@ -139,6 +145,7 @@ int HYPERVISOR_sched_op(int cmd, void *a
int HYPERVISOR_sched_op(int cmd, void *arg)
{
struct xencomm_desc *desc;
+ int argsize = 0;
switch (cmd) {
case SCHEDOP_yield:
@@ -151,24 +158,29 @@ int HYPERVISOR_sched_op(int cmd, void *a
evtchn_port_t *ports;
struct sched_poll sched_poll;
+ argsize = sizeof(struct sched_poll);
+
memcpy(sched_poll, arg, sizeof(sched_poll));
- ports = xencomm_create_inline(
- xen_guest_handle(sched_poll.ports));
+ ports = xencomm_map(
+ xen_guest_handle(sched_poll.ports),
+ (sizeof(evtchn_port_t) * sched_poll.nr_ports));
set_xen_guest_handle(sched_poll.ports, ports);
memcpy(arg, sched_poll, sizeof(sched_poll));
-
+
}
break;
case SCHEDOP_shutdown:
+ argsize = sizeof(struct sched_shutdown);
case SCHEDOP_remote_shutdown:
+ argsize = sizeof(struct sched_remote_shutdown);
break;
default:
printk(KERN_ERR %s: unknown sched op %d\n, __func__, cmd);
return -ENOSYS;
}
- desc = xencomm_create_inline(arg);
+ desc = xencomm_map(arg, argsize);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
cmd, desc);
diff -r e5962db17966 drivers/xen/core/xencomm.c
--- a/drivers/xen/core
[XenPPC] [PATCH] Enable more IP options to default kernel config
This patch enables many IP options to allow support for better support of IP tables IPv6. This patch mainly address an issue with SuSE firewall scripts that will hang on startup. This bug can be found here: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=841 Signed-off-by: Jerone Young [EMAIL PROTECTED] # HG changeset patch # User [EMAIL PROTECTED] # Date 1168927970 21600 # Node ID d450e2b2a85a7640643ecf7b2fddff2faa6dbcd4 # Parent bbf2db4ddf5400e908ee6bf92ac798e5cfed82a0 Add many options for IP configuration so that Suse firewall scripts will no longer fail. diff -r bbf2db4ddf54 -r d450e2b2a85a arch/powerpc/configs/xen_maple_defconfig --- a/arch/powerpc/configs/xen_maple_defconfig Tue Dec 19 09:22:37 2006 -0500 +++ b/arch/powerpc/configs/xen_maple_defconfig Tue Jan 16 00:12:50 2007 -0600 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17 -# Thu Oct 12 16:16:49 2006 +# Mon Jan 15 23:48:47 2007 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -230,15 +230,24 @@ CONFIG_XFRM=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y -# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_ASK_IP_FIB_HASH=y +# CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_FWMARK=y +CONFIG_IP_ROUTE_MULTIPATH=y +# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set +# CONFIG_IP_ROUTE_VERBOSE is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y # CONFIG_NET_IPGRE is not set -# CONFIG_IP_MROUTE is not set +CONFIG_IP_MROUTE=y +CONFIG_IP_PIMSM_V1=y +CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set @@ -257,9 +266,18 @@ CONFIG_TCP_CONG_BIC=y # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set -# CONFIG_IPV6 is not set -# CONFIG_INET6_XFRM_TUNNEL is not set -# CONFIG_INET6_TUNNEL is not set +CONFIG_IPV6=y +CONFIG_IPV6_PRIVACY=y +CONFIG_IPV6_ROUTER_PREF=y +CONFIG_IPV6_ROUTE_INFO=y +CONFIG_INET6_AH=y +CONFIG_INET6_ESP=y +CONFIG_INET6_IPCOMP=y +CONFIG_INET6_XFRM_TUNNEL=y +CONFIG_INET6_TUNNEL=y +CONFIG_INET6_XFRM_MODE_TRANSPORT=y +CONFIG_INET6_XFRM_MODE_TUNNEL=y +CONFIG_IPV6_TUNNEL=y # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set @@ -268,15 +286,114 @@ CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # -# CONFIG_NETFILTER_NETLINK is not set -# CONFIG_NF_CONNTRACK is not set -# CONFIG_NETFILTER_XTABLES is not set +CONFIG_NETFILTER_NETLINK=y +CONFIG_NETFILTER_NETLINK_QUEUE=y +CONFIG_NETFILTER_NETLINK_LOG=y +CONFIG_NETFILTER_XTABLES=y +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y +CONFIG_NETFILTER_XT_TARGET_CONNMARK=y +CONFIG_NETFILTER_XT_TARGET_MARK=y +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y +CONFIG_NETFILTER_XT_TARGET_NOTRACK=y +CONFIG_NETFILTER_XT_MATCH_COMMENT=y +CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y +CONFIG_NETFILTER_XT_MATCH_CONNMARK=y +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y +CONFIG_NETFILTER_XT_MATCH_DCCP=y +CONFIG_NETFILTER_XT_MATCH_ESP=y +CONFIG_NETFILTER_XT_MATCH_HELPER=y +CONFIG_NETFILTER_XT_MATCH_LENGTH=y +CONFIG_NETFILTER_XT_MATCH_LIMIT=y +CONFIG_NETFILTER_XT_MATCH_MAC=y +CONFIG_NETFILTER_XT_MATCH_MARK=y +CONFIG_NETFILTER_XT_MATCH_POLICY=y +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y +CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y +CONFIG_NETFILTER_XT_MATCH_QUOTA=y +CONFIG_NETFILTER_XT_MATCH_REALM=y +CONFIG_NETFILTER_XT_MATCH_SCTP=y +CONFIG_NETFILTER_XT_MATCH_STATE=y +CONFIG_NETFILTER_XT_MATCH_STATISTIC=y +CONFIG_NETFILTER_XT_MATCH_STRING=y +CONFIG_NETFILTER_XT_MATCH_TCPMSS=y # # IP: Netfilter Configuration # -# CONFIG_IP_NF_CONNTRACK is not set +CONFIG_IP_NF_CONNTRACK=y +CONFIG_IP_NF_CT_ACCT=y +CONFIG_IP_NF_CONNTRACK_MARK=y +CONFIG_IP_NF_CONNTRACK_EVENTS=y +CONFIG_IP_NF_CONNTRACK_NETLINK=y +CONFIG_IP_NF_CT_PROTO_SCTP=y +CONFIG_IP_NF_FTP=y +CONFIG_IP_NF_IRC=y +# CONFIG_IP_NF_NETBIOS_NS is not set +CONFIG_IP_NF_TFTP=y +CONFIG_IP_NF_AMANDA=y +CONFIG_IP_NF_PPTP=y +# CONFIG_IP_NF_H323 is not set +# CONFIG_IP_NF_SIP is not set # CONFIG_IP_NF_QUEUE is not set +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_MATCH_IPRANGE=y +CONFIG_IP_NF_MATCH_TOS=y +CONFIG_IP_NF_MATCH_RECENT=y +CONFIG_IP_NF_MATCH_ECN=y +CONFIG_IP_NF_MATCH_DSCP=y +CONFIG_IP_NF_MATCH_AH=y +CONFIG_IP_NF_MATCH_TTL=y +CONFIG_IP_NF_MATCH_OWNER=y +CONFIG_IP_NF_MATCH_ADDRTYPE=y +CONFIG_IP_NF_MATCH_HASHLIMIT=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_TARGET_LOG=y +CONFIG_IP_NF_TARGET_ULOG=y +CONFIG_IP_NF_TARGET_TCPMSS=y +CONFIG_IP_NF_NAT=y +CONFIG_IP_NF_NAT_NEEDED=y +CONFIG_IP_NF_TARGET_MASQUERADE=y +CONFIG_IP_NF_TARGET_REDIRECT=y +CONFIG_IP_NF_TARGET_NETMAP=y +CONFIG_IP_NF_TARGET_SAME=y +CONFIG_IP_NF_NAT_SNMP_BASIC=y +CONFIG_IP_NF_NAT_IRC=y +CONFIG_IP_NF_NAT_FTP=y +CONFIG_IP_NF_NAT_TFTP=y +CONFIG_IP_NF_NAT_AMANDA=y +CONFIG_IP_NF_NAT_PPTP=y +CONFIG_IP_NF_MANGLE=y +CONFIG_IP_NF_TARGET_TOS=y +CONFIG_IP_NF_TARGET_ECN=y
[XenPPC] [PATCH] Fix xenminicom optimazation to work for modules
If a structure that does not fit within 1 page is pointed to, we need
to create a structure on the stack to represent this structure for the
hypervisor. This code affects kernel module addresses which are do not
have physically contiguous memory.
This has been tested to boot and also some tests to ensure that the code
path is taken. I have yet to test any modules though.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Thu Jan 11 11:42:57 2007 -0600
@@ -264,7 +264,8 @@ int HYPERVISOR_grant_table_op(unsigned i
argsize = sizeof(setup);
frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ xen_guest_handle(setup.frame_list),
+ (sizeof(ulong) * setup.nr_frames));
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +287,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_create_inline(op, argsize);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Thu Jan 11 11:50:19 2007 -0600
@@ -50,11 +50,31 @@
* In general, we need a xencomm descriptor to cover the top-level data
* structure (e.g. the domctl op), plus another for every embedded pointer to
* another data structure (i.e. for every GUEST_HANDLE).
+ *
+ * Some hypercalls are made before the memory subsystem is up, so instead of
+ * calling xencomm_create(), we allocate XENCOMM_MINI_AREA bytes from the stack
+ * to hold the xencomm descriptor.
*/
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *desc;
+ int rc;
+
+ desc = xencomm_create_inline(str, count);
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA, str, count,
+ desc);
+ if (rc)
+ return rc;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ cmd, count, __pa(desc));
+
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
@@ -63,7 +83,22 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *desc;
+ int rc;
+
+ desc = xencomm_create_inline(op, sizeof(evtchn_op_t));
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA,
+ op, sizeof(evtchn_op_t), desc);
+ if (rc)
+ return rc;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ cmd, __pa(desc));
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
@@ -121,7 +156,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_xen_version(int cmd, void *arg)
{
if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
+ void *desc = xencomm_create_inline(arg, sizeof(__u64));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
}
return HYPERVISOR_xen_version_userspace(cmd, arg);
@@ -129,7 +164,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ void *desc = xencomm_create_inline(op, sizeof(physdev_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
@@ -139,6 +174,7 @@ int HYPERVISOR_sched_op(int cmd, void *a
int HYPERVISOR_sched_op(int cmd, void *arg)
{
struct xencomm_desc *desc;
+ int argsize = 0;
switch (cmd) {
case SCHEDOP_yield:
@@ -151,24 +187,29 @@ int HYPERVISOR_sched_op(int cmd, void *a
evtchn_port_t *ports;
struct sched_poll sched_poll;
+ argsize = sizeof(struct sched_poll);
+
memcpy(sched_poll, arg, sizeof(sched_poll));
ports = xencomm_create_inline(
- xen_guest_handle(sched_poll.ports));
+ xen_guest_handle(sched_poll.ports),
+ (sizeof(evtchn_port_t) * sched_poll.nr_ports));
set_xen_guest_handle(sched_poll.ports, ports);
memcpy(arg, sched_poll, sizeof(sched_poll));
-
+
}
break;
case SCHEDOP_shutdown:
+ argsize = sizeof(struct sched_shutdown);
case SCHEDOP_remote_shutdown:
+ argsize = sizeof(struct sched_remote_shutdown);
break;
default:
printk(KERN_ERR %s: unknown sched op %d\n, __func__, cmd);
return -ENOSYS;
}
- desc = xencomm_create_inline(arg);
+ desc = xencomm_create_inline(arg, argsize);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
cmd, desc);
diff -r bbf2db4ddf54 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.c Tue Dec 19 09:22:37 2006 -0500
+++ b
Re: [XenPPC] [PATCH] Fix xenminicom optimazation to work for modules
On Thu, 2007-01-11 at 13:06 -0600, Hollis Blanchard wrote:
On Thu, 2007-01-11 at 12:12 -0600, Jerone Young wrote:
@@ -121,7 +156,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_xen_version(int cmd, void *arg)
{
if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
+ void *desc = xencomm_create_inline(arg, sizeof(__u64));
return
plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
}
return HYPERVISOR_xen_version_userspace(cmd, arg);
Any use of is_kernel_addr() is a red flag.
So the issue here is what else to use to use the userspace function. It
looked liked like this was actually a correct way of going about it in
this case. I'll figure something better.
-void *xencomm_create_inline(void *ptr)
+void *xencomm_create_inline(void *ptr, unsigned long bytes)
{
unsigned long paddr;
+ unsigned long first_page;
+ unsigned long last_page;
- BUG_ON(!is_kernel_addr((unsigned long)ptr));
+ first_page = xencomm_vtop(ptr) PAGE_MASK;
+ last_page = xencomm_vtop(ptr + bytes) PAGE_MASK;
+
+ if (first_page != last_page)
+ return NULL;
I still think you should drop xencomm_vtop(). If ptr and ptr+bytes are
on different virtual pages, they will be on different physical pages
too, so we don't need to do the more expensive virtual-to-physical
translation you're doing here.
Will drop it.
But anyways, let's think about abstracting this a little bit.
Pseudo-code below.
First, the test we really want is is this area of memory physically
contiguous? If so, we can do inline.
void *xencomm_map(void *ptr, ulong bytes)
{
if (is_phys_contiguous(ptr))
return xencomm_create_inline(ptr);
return xencomm_create(ptr, bytes);
}
In particular we know that vmalloc space, from which modules are
allocated, is not physically contiguous. Other code makes reference to
VMALLOC_START/END, so we can too:
int is_physically_contiguous(ulong addr)
{
return (ptr VMALLOC_START) || (ptr = VMALLOC_END);
}
We can have a separate early function:
#define xencomm_map_early(ptr, bytes) \
char xc_area[bytes*2]; \
__xencomm_map_early(ptr, bytes, xc_area)
void *__xencomm_map_early(void *ptr, ulong bytes, char *xc_area)
{
if (is_phys_contiguous(ptr))
return xencomm_create_inline(ptr);
return xencomm_create_mini(ptr, bytes, xc_area);
}
(We need that macro because the *caller* needs to allocate stack space.)
With these interfaces, all a caller needs to do is use xencomm_map() or
xencomm_map_early(), and all the details of inline or mini or regular
are hidden.
Does this make sense (to anybody)?
Got the basics. I'll get out another patch and that will show if I got
what you are saying.
--
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] [PATCH] [RFC] Fix xenminicom optimizations to work for module
First patch to attempt to re introduce older code written by Hollis.
If a structure that does not fit within 1 page is pointed to, we need
to create a structure on the stack to represent this structure for the
hypervisor. This code affects kernel module addresses which are do not
have physically contiguous memory.
This patch isn't perfect yet. But comments would be nice.
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Wed Jan 10 00:50:24 2007 -0600
@@ -264,7 +264,7 @@ int HYPERVISOR_grant_table_op(unsigned i
argsize = sizeof(setup);
frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ xen_guest_handle(setup.frame_list), 0);
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +286,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_create_inline(op, 0);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Jan 10 10:30:08 2007 -0600
@@ -50,11 +50,31 @@
* In general, we need a xencomm descriptor to cover the top-level data
* structure (e.g. the domctl op), plus another for every embedded pointer to
* another data structure (i.e. for every GUEST_HANDLE).
+ *
+ * Some hypercalls are made before the memory subsystem is up, so instead of
+ * calling xencomm_create(), we allocate XENCOMM_MINI_AREA bytes from the stack
+ * to hold the xencomm descriptor.
*/
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *x_desc;
+ int rc;
+
+ void *desc = xencomm_create_inline(str, count);
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA, str, count,
+ x_desc);
+ if (rc)
+ return rc;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ cmd, count, __pa(x_desc));
+
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
@@ -63,7 +83,22 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *x_desc;
+ int rc;
+
+ void *desc = xencomm_create_inline(op, sizeof(evtchn_op_t));
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA,
+ op, sizeof(evtchn_op_t), x_desc);
+ if (rc)
+ return rc;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ cmd, __pa(x_desc));
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
@@ -121,7 +156,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_xen_version(int cmd, void *arg)
{
if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
+ void *desc = xencomm_create_inline(arg, 0);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
}
return HYPERVISOR_xen_version_userspace(cmd, arg);
@@ -129,7 +164,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ void *desc = xencomm_create_inline(op, sizeof(physdev_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
@@ -154,7 +189,7 @@ int HYPERVISOR_sched_op(int cmd, void *a
memcpy(sched_poll, arg, sizeof(sched_poll));
ports = xencomm_create_inline(
- xen_guest_handle(sched_poll.ports));
+ xen_guest_handle(sched_poll.ports), 0);
set_xen_guest_handle(sched_poll.ports, ports);
memcpy(arg, sched_poll, sizeof(sched_poll));
@@ -168,7 +203,7 @@ int HYPERVISOR_sched_op(int cmd, void *a
return -ENOSYS;
}
- desc = xencomm_create_inline(arg);
+ desc = xencomm_create_inline(arg, 0);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
cmd, desc);
diff -r bbf2db4ddf54 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.c Tue Dec 19 09:22:37 2006 -0500
+++ b/drivers/xen/core/xencomm.c Wed Jan 10 01:15:50 2007 -0600
@@ -119,13 +119,59 @@ int xencomm_create(void *buffer, unsigne
return 0;
}
-void *xencomm_create_inline(void *ptr)
+void *xencomm_create_inline(void *ptr, unsigned long bytes)
{
unsigned long paddr;
-
- BUG_ON(!is_kernel_addr((unsigned long)ptr));
-
+ unsigned long first;
+ unsigned long last;
+
+ first = xencomm_vtop(ptr) PAGE_MASK;
+ last = xencomm_vtop(ptr+bytes) PAGE_MASK;
+
+ if (first != last)
+ return NULL;
+
paddr = (unsigned long)xencomm_pa(ptr);
BUG_ON(paddr XENCOMM_INLINE_FLAG);
return (void *)(paddr | XENCOMM_INLINE_FLAG);
}
+
Re: [XenPPC] [PATCH] [RFC] Fix xenminicom optimizations to work for module
On Wed, 2007-01-10 at 12:45 -0600, Hollis Blanchard wrote:
On Wed, 2007-01-10 at 11:51 -0600, Jerone Young wrote:
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Dec 19 09:22:37 2006
-0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Wed Jan 10 00:50:24 2007
-0600
@@ -264,7 +264,7 @@ int HYPERVISOR_grant_table_op(unsigned i
argsize = sizeof(setup);
frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ xen_guest_handle(setup.frame_list), 0);
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +286,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_create_inline(op, 0);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
Throughout your entire patch you're using a size of 0. That can't be
right.
Glad you pointed this out. Actually, in these cases I use 0 (why the
patch isn't perfect) to ensure that we are not returned a NULL pointer.
Since this is code that has just been added. Since the check is not
needed in theses cases, but perhaps it will always pass and this is not
going to be a worry.
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.cTue Dec 19 09:22:37 2006
-0500
+++ b/arch/powerpc/platforms/xen/hcall.cWed Jan 10 10:30:08 2007
-0600
@@ -63,7 +83,22 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *x_desc;
+ int rc;
+
+ void *desc = xencomm_create_inline(op, sizeof(evtchn_op_t));
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA,
+ op, sizeof(evtchn_op_t), x_desc);
+ if (rc)
+ return rc;
+
+ rc =
plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ cmd, __pa(x_desc));
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
You don't need both desc and x_desc. Just remove x_desc.
Sounds good.
diff -r bbf2db4ddf54 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.cTue Dec 19 09:22:37 2006 -0500
+++ b/drivers/xen/core/xencomm.cWed Jan 10 01:15:50 2007 -0600
@@ -119,13 +119,59 @@ int xencomm_create(void *buffer, unsigne
return 0;
}
-void *xencomm_create_inline(void *ptr)
+void *xencomm_create_inline(void *ptr, unsigned long bytes)
{
unsigned long paddr;
-
- BUG_ON(!is_kernel_addr((unsigned long)ptr));
-
+ unsigned long first;
+ unsigned long last;
+
+ first = xencomm_vtop(ptr) PAGE_MASK;
+ last = xencomm_vtop(ptr+bytes) PAGE_MASK;
Rename first and last to something like first_phys_page and
last_phys_page.
Does this code actually work? It seemed like the problem with your other
patch was that xencomm_vtop() doesn't work early. A simpler but
overly-broad test could work here:
first_page = ptr PAGE_MASK;
last_page = (ptr + bytes) PAGE_MASK;
+ if (first != last)
+ return NULL;
paddr = (unsigned long)xencomm_pa(ptr);
BUG_ON(paddr XENCOMM_INLINE_FLAG);
return (void *)(paddr | XENCOMM_INLINE_FLAG);
}
How has this patch been tested?
Yes this one has been tested. It boots. Not thoroughly as of yet. So I
just wanted comments of what I had for now.
Thanks for the comments :-)
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH]fix xencomm_copy_{from, to}_guest.
Keir, can you commit this patch to the tree. It has been tested and does
not appear to cause any issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
On Fri, 2007-01-05 at 12:19 +0900, Isaku Yamahata wrote:
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
Originally this issue was found in xen/ia64 xencomm code and
in fact I didn't test this patch because currently ia64 xencomm forked
from common code. They should be consolidated somehow.
--
yamahata
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1167966417 -32400
# Node ID 25cdcc5f21f8147371aed5fb8f56d93479df0ca8
# Parent 338ceb7b1f0993bf9735c0c1c5d21e39c381cf2f
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
PATCHNAME: fix_xencomm_copy_tofrom_guest
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 338ceb7b1f09 -r 25cdcc5f21f8 xen/common/xencomm.c
--- a/xen/common/xencomm.c Thu Jan 04 10:58:01 2007 +
+++ b/xen/common/xencomm.c Fri Jan 05 12:06:57 2007 +0900
@@ -119,7 +119,7 @@ xencomm_copy_from_guest(void *to, const
chunksz -= chunk_skip;
skip -= chunk_skip;
-if (skip == 0) {
+if (skip == 0 chunksz 0) {
unsigned long src_maddr;
unsigned long dest = (unsigned long)to + to_pos;
unsigned int bytes = min(chunksz, n - to_pos);
@@ -225,7 +225,7 @@ xencomm_copy_to_guest(void *to, const vo
chunksz -= chunk_skip;
skip -= chunk_skip;
-if (skip == 0) {
+if (skip == 0 chunksz 0) {
unsigned long dest_maddr;
unsigned long source = (unsigned long)from + from_pos;
unsigned int bytes = min(chunksz, n - from_pos);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Remove invalid optimization
This patch removes an invalid optimization that works great if you are a kernel address (which is contiguous), but if you are module then you have a kernel address but you are not contiguous. So this check is invalid. diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/xencomm.c --- a/arch/powerpc/platforms/xen/xencomm.c Tue Dec 19 09:22:37 2006 -0500 +++ b/arch/powerpc/platforms/xen/xencomm.c Tue Jan 09 14:50:55 2007 -0600 @@ -36,9 +36,6 @@ unsigned long xencomm_vtop(unsigned long if (vaddr == 0) return 0; - if (is_kernel_addr(vaddr)) - return __pa(vaddr); - /* XXX double-check (lack of) locking */ vma = find_extend_vma(current-mm, vaddr); BUG_ON(!vma); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH]fix xencomm_copy_{from, to}_guest.
Just quickly tried it out and my js20 blade boots without issue with
this patch.
On Mon, 2007-01-08 at 16:51 -0600, Hollis Blanchard wrote:
On Fri, 2007-01-05 at 12:19 +0900, Isaku Yamahata wrote:
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
Thanks Yamahata-san! I've asked Jerone (CCed) to give this a quick test.
Originally this issue was found in xen/ia64 xencomm code and
in fact I didn't test this patch because currently ia64 xencomm forked
from common code. They should be consolidated somehow.
I couldn't agree more. I've posted comments on that before; please let
me know if anybody on the ia64 side has questions about it.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Change to add boot param delimiter ||
Update patch with Jimi's suggestions:
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cWed Dec 06 11:34:37 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+int sepr_index = 0;
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,17 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+/* look for deliminator -- or || is delimator */
+for(sepr_index; sepr_index ARRAY_SIZE(sepr); sepr_index++){
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
-*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]);
mods[mod].string = (u32)(ulong)p;
of_printf(%s: dom0 mod string: %s\n, __func__, p);
}
On Tue, 2006-12-05 at 19:06 -0500, Jimi Xenidis wrote:
On Dec 5, 2006, at 6:20 PM, Jerone Young wrote:
This patch changes the code so can support more than one type
delimiter
on the command line. Now you can use || as well as --. ||
works
better with SLOF currently available. There is a bug in some cases
using
SLOF where -- is not treated as desired.
Patch has been tested and ready to go.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cTue Dec 05 17:08:41 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+static int sepr_index = 0;
no reason for sepr_index to be static
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,18 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+//look for deliminator -- or || is delimator
We avoid C++ comments please use /* */ and I can't believe _I_ cought
a typo :)
+for(sepr_index; sepr_index (sizeof(sepr)/sizeof(char *));
sepr_index++){
Please use ARRAY_SIZE(sepr)
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]) - 1;
The -1 is because sizeof() includes '\0', so you can drop it here.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Change to add boot param delimiter ||
Thanks Hollis for the feedback. Added changes.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cWed Dec 06 13:59:37 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+int sepr_index;
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,18 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+/* look for delimiter -- or || is delimiter */
+for (sepr_index = 0; sepr_index ARRAY_SIZE(sepr); sepr_index++){
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]);
mods[mod].string = (u32)(ulong)p;
of_printf(%s: dom0 mod string: %s\n, __func__, p);
}
On Wed, 2006-12-06 at 13:41 -0600, Hollis Blanchard wrote:
On Wed, 2006-12-06 at 11:37 -0600, Jerone Young wrote:
Update patch with Jimi's suggestions:
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cWed Dec 06 11:34:37 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+int sepr_index = 0;
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,17 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+/* look for deliminator -- or || is delimator */
delimiter
+for(sepr_index; sepr_index ARRAY_SIZE(sepr); sepr_index++){
Add a space after for, and move the sepr_index = 0 initialization
here please.
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
-*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]);
mods[mod].string = (u32)(ulong)p;
of_printf(%s: dom0 mod string: %s\n, __func__, p);
}
You've removed the code where we terminate Xen's arguments with a NULL
char.
Fix these issues and I'm quite happy with it.
--
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] [PATCH] Change to add boot param delimiter ||
This patch changes the code so can support more than one type delimiter
on the command line. Now you can use || as well as --. || works
better with SLOF currently available. There is a bug in some cases using
SLOF where -- is not treated as desired.
Patch has been tested and ready to go.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cTue Dec 05 17:08:41 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+static int sepr_index = 0;
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,18 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+//look for deliminator -- or || is delimator
+for(sepr_index; sepr_index (sizeof(sepr)/sizeof(char *));
sepr_index++){
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]) - 1;
mods[mod].string = (u32)(ulong)p;
of_printf(%s: dom0 mod string: %s\n, __func__, p);
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen Wiki] Update of XenPPC/Run by JeroneYoung
On Wed, 2006-11-01 at 13:27 -0500, Jimi Xenidis wrote:
First, I really appreciate you updating the wiki, I think its awesome!
On Oct 31, 2006, at 4:24 PM, [EMAIL PROTECTED] wrote:
+ === Example ===
+ Have a machine with Linux install on /dev/hda3. We do not have
any parameters to pass to the Xen hypervisor. So once
+ SLOTH firmware loads up. You will PXE boot the Xen image built
(no command line paramters specified in the build) and specify the
parameters on here:
What do you mean PXE boot? I think this is an intel/x86 world term.
This is a standard Open Firmware command:
boot device params
sigh...me coming from x86, I screwed the terminology. I will change it,
if it has not already been changed. netboot would be a much better
word.
Specifically, (assuming you have not defined the file, IP
configuration, and TFTP server) in this case you will be TFTPing the
image that that a BOOTP packet tells net1 to load
+ {{{
+ boot net1 xen -- root=/dev/hda3
+ }}}
Yes I left out the part about setting up the bootp tftp enviroment
(figured most folks whould probably know that part), mainly I was
putting an example of the command line to enter when using Sloth. I was
at first just doing netboot root=/dev/hda3. I can rework the example
and make it more clear. But thought there needed to be a clear example
for folks to try and understand.
+ ! - note the word xen is placed as the parameter for the
Hypervisor because you cannot have no parameter, so just put
somehting that will just be dropped.
Is this _still_ true? I think at some point Xen actually wanted to
see this string to verify that the person actually wanted to boot Xen
and has since been removed. You should be able to boot without it,
if not we need to find out why.
I'll give it a try and let everyone know.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
