[RFC][PATCH]mini-os: big-endian mini-os on ia64

[RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

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

Hi,

currently I'am porting the mini-os to ia64. A first version is already in the 
ia64xen-tree.
I would like to have a big-endian mini-os running on the ia64 little-endian 
hypervisor.
My target is to have only changes in the domU. This requires to swap all the 
domU data the hypervisor/dom0 see und use.
Attached is a patch with a first draft. I use the macro SWAP() to swap the 
right pieces (on x86 of course empty).
Currently netfront is not supported.
With this patch and small changes in the ia64xen hypervisor + loader I'am able 
to run a big andian mini-os on a ia64xen hypervisor.
The patch contains only changes in the common mini-os parts. The ia64 part in 
the tree is already fine with that.
The patches for the hypervisor will come with an extra patch.
Please have a look and send comments or check in if there are no questions.
Thanks.

Dietmar.

[-- Attachment #2: mini-os_be.patch --]
[-- Type: text/x-diff, Size: 16119 bytes --]

# HG changeset patch
# User dietmar.hahn@fujitsu-siemens.com
# Date 1171978487 -3600
# Node ID 0e0869793af2f614fd020d2f7f893225dc6021be
# Parent  b83cfb117bddc1f44be53bde49d86b5075bdaa2a
First step to have big endian mini-os an little endian hypervisor for ia64.


Signed-off-by: Dietmar Hahn <dietmar.hahn@fujitsu-siemens.com>


diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/arch/x86/arch.mk
--- a/extras/mini-os/arch/x86/arch.mk	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/arch/x86/arch.mk	Tue Feb 20 14:34:47 2007 +0100
@@ -3,6 +3,7 @@
 # (including x86_32, x86_32y and x86_64).
 #
 
+pae=y
 ifeq ($(TARGET_ARCH),x86_32)
 ARCH_CFLAGS  := -m32 -march=i686
 ARCH_LDFLAGS := -m elf_i386
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/console/xencons_ring.c
--- a/extras/mini-os/console/xencons_ring.c	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/console/xencons_ring.c	Tue Feb 20 14:34:47 2007 +0100
@@ -28,8 +28,8 @@ int xencons_ring_send_no_notify(const ch
     int sent = 0;
 	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
-	cons = intf->out_cons;
-	prod = intf->out_prod;
+	cons = SWAP(intf->out_cons);
+	prod = SWAP(intf->out_prod);
 	mb();
 	BUG_ON((prod - cons) > sizeof(intf->out));
 
@@ -37,7 +37,7 @@ int xencons_ring_send_no_notify(const ch
 		intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
 
 	wmb();
-	intf->out_prod = prod;
+	intf->out_prod = SWAP(prod);
     
     return sent;
 }
@@ -58,8 +58,8 @@ static void handle_input(evtchn_port_t p
 	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
 
-	cons = intf->in_cons;
-	prod = intf->in_prod;
+	cons = SWAP(intf->in_cons);
+	prod = SWAP(intf->in_prod);
 	mb();
 	BUG_ON((prod - cons) > sizeof(intf->in));
 
@@ -69,7 +69,7 @@ static void handle_input(evtchn_port_t p
 	}
 
 	mb();
-	intf->in_cons = cons;
+	intf->in_cons = SWAP(cons);
 
 	notify_daemon();
 
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/events.c
--- a/extras/mini-os/events.c	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/events.c	Tue Feb 20 14:34:47 2007 +0100
@@ -46,7 +46,7 @@ void unbind_all_ports(void)
         {
             struct evtchn_close close;
             mask_evtchn(i);
-            close.port = i;
+            close.port = SWAP(i);
             HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
         }
     }
@@ -107,16 +107,16 @@ int bind_virq(uint32_t virq, evtchn_hand
 	evtchn_bind_virq_t op;
 
 	/* Try to bind the virq to a port */
-	op.virq = virq;
-	op.vcpu = smp_processor_id();
+	op.virq = SWAP(virq);
+	op.vcpu = SWAP((uint32_t)smp_processor_id());
 
 	if ( HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq, &op) != 0 )
 	{
 		printk("Failed to bind virtual IRQ %d\n", virq);
 		return 1;
     }
-    set_bit(op.port,bound_ports);
-    bind_evtchn(op.port, handler, data);
+    set_bit(SWAP(op.port),bound_ports);
+    bind_evtchn(SWAP(op.port), handler, data);
 	return 0;
 }
 
@@ -168,12 +168,12 @@ int evtchn_alloc_unbound(domid_t pal, ev
 						 void *data, evtchn_port_t *port)
 {
     evtchn_alloc_unbound_t op;
-    op.dom = DOMID_SELF;
-    op.remote_dom = pal;
+    op.dom = SWAP((domid_t)DOMID_SELF);
+    op.remote_dom = SWAP(pal);
     int err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &op);
     if (err)
 		return err;
-    *port = bind_evtchn(op.port, handler, data);
+    *port = bind_evtchn(SWAP(op.port), handler, data);
     return err;
 }
 
@@ -185,13 +185,13 @@ int evtchn_bind_interdomain(domid_t pal,
 			    evtchn_port_t *local_port)
 {
     evtchn_bind_interdomain_t op;
-    op.remote_dom = pal;
-    op.remote_port = remote_port;
+    op.remote_dom = SWAP(pal);
+    op.remote_port = SWAP(remote_port);
     int err = HYPERVISOR_event_channel_op(EVTCHNOP_bind_interdomain, &op);
     if (err)
 		return err;
-    set_bit(op.local_port,bound_ports);
-	evtchn_port_t port = op.local_port;
+    set_bit(SWAP(op.local_port),bound_ports);
+	evtchn_port_t port = SWAP(op.local_port);
     clear_evtchn(port);	      /* Without, handler gets invoked now! */
     *local_port = bind_evtchn(port, handler, data);
     return err;
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/gnttab.c
--- a/extras/mini-os/gnttab.c	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/gnttab.c	Tue Feb 20 14:34:47 2007 +0100
@@ -54,11 +54,12 @@ gnttab_grant_access(domid_t domid, unsig
     grant_ref_t ref;
 
     ref = get_free_entry();
-    gnttab_table[ref].frame = frame;
-    gnttab_table[ref].domid = domid;
+    gnttab_table[ref].frame = SWAP((uint32_t)frame);
+    gnttab_table[ref].domid = SWAP(domid);
     wmb();
     readonly *= GTF_readonly;
-    gnttab_table[ref].flags = GTF_permit_access | readonly;
+    uint16_t flags = (uint16_t) GTF_permit_access | (uint16_t) readonly;
+    gnttab_table[ref].flags = SWAP(flags);
 
     return ref;
 }
@@ -69,10 +70,10 @@ gnttab_grant_transfer(domid_t domid, uns
     grant_ref_t ref;
 
     ref = get_free_entry();
-    gnttab_table[ref].frame = pfn;
-    gnttab_table[ref].domid = domid;
+    gnttab_table[ref].frame = SWAP((uint32_t)pfn);
+    gnttab_table[ref].domid = SWAP(domid);
     wmb();
-    gnttab_table[ref].flags = GTF_accept_transfer;
+    gnttab_table[ref].flags = SWAP((uint16_t)GTF_accept_transfer);
 
     return ref;
 }
@@ -82,14 +83,14 @@ gnttab_end_access(grant_ref_t ref)
 {
     u16 flags, nflags;
 
-    nflags = gnttab_table[ref].flags;
+    nflags = SWAP(gnttab_table[ref].flags);
     do {
         if ((flags = nflags) & (GTF_reading|GTF_writing)) {
             printk("WARNING: g.e. still in use!\n");
             return 0;
         }
-    } while ((nflags = synch_cmpxchg(&gnttab_table[ref].flags, flags, 0)) !=
-            flags);
+    } while ((nflags = SWAP(synch_cmpxchg(&gnttab_table[ref].flags,
+                                                SWAP(flags), 0))) != flags);
 
     put_free_entry(ref);
     return 1;
@@ -101,8 +102,9 @@ gnttab_end_transfer(grant_ref_t ref)
     unsigned long frame;
     u16 flags;
 
-    while (!((flags = gnttab_table[ref].flags) & GTF_transfer_committed)) {
-        if (synch_cmpxchg(&gnttab_table[ref].flags, flags, 0) == flags) {
+    while (!((flags = SWAP(gnttab_table[ref].flags)) & GTF_transfer_committed)) {
+        if (SWAP(synch_cmpxchg(&gnttab_table[ref].flags, SWAP(flags), 0)) ==
+                                                                      flags) {
             printk("Release unused transfer grant.\n");
             put_free_entry(ref);
             return 0;
@@ -111,12 +113,12 @@ gnttab_end_transfer(grant_ref_t ref)
 
     /* If a transfer is in progress then wait until it is completed. */
     while (!(flags & GTF_transfer_completed)) {
-        flags = gnttab_table[ref].flags;
+        flags = SWAP(gnttab_table[ref].flags);
     }
 
     /* Read the frame number /after/ reading completion status. */
     rmb();
-    frame = gnttab_table[ref].frame;
+    frame = SWAP(gnttab_table[ref].frame);
 
     put_free_entry(ref);
 
@@ -157,9 +159,9 @@ init_gnttab(void)
     for (i = NR_RESERVED_ENTRIES; i < NR_GRANT_ENTRIES; i++)
         put_free_entry(i);
 
-    setup.dom = DOMID_SELF;
-    setup.nr_frames = NR_GRANT_FRAMES;
-    set_xen_guest_handle(setup.frame_list, frames);
+    setup.dom = SWAP((domid_t)DOMID_SELF);
+    setup.nr_frames = SWAP((uint32_t)NR_GRANT_FRAMES);
+    set_xen_guest_handle(setup.frame_list, (void*)SWAP((unsigned long)frames));
 
     HYPERVISOR_grant_table_op(GNTTABOP_setup_table, &setup, 1);
     gnttab_table = map_frames(frames, NR_GRANT_FRAMES);
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/hypervisor.c
--- a/extras/mini-os/hypervisor.c	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/hypervisor.c	Tue Feb 20 14:34:47 2007 +0100
@@ -30,8 +30,8 @@
 #include <events.h>
 
 #define active_evtchns(cpu,sh,idx)              \
-    ((sh)->evtchn_pending[idx] &                \
-     ~(sh)->evtchn_mask[idx])
+    (SWAP((sh)->evtchn_pending[idx]) &                \
+     SWAP(~(sh)->evtchn_mask[idx]))
 
 void do_hypervisor_callback(struct pt_regs *regs)
 {
@@ -44,7 +44,7 @@ void do_hypervisor_callback(struct pt_re
    
     vcpu_info->evtchn_upcall_pending = 0;
     /* NB. No need for a barrier here -- XCHG is a barrier on x86. */
-    l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
+    l1 = SWAP(xchg(&vcpu_info->evtchn_pending_sel, 0));
     while ( l1 != 0 )
     {
         l1i = __ffs(l1);
@@ -82,7 +82,7 @@ inline void unmask_evtchn(u32 port)
     if (  synch_test_bit        (port,    &s->evtchn_pending[0]) && 
          !synch_test_and_set_bit(port>>5, &vcpu_info->evtchn_pending_sel) )
     {
-        vcpu_info->evtchn_upcall_pending = 1;
+        vcpu_info->evtchn_upcall_pending = SWAP((uint8_t)1);
         if ( !vcpu_info->evtchn_upcall_mask )
             force_evtchn_callback();
     }
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/include/events.h
--- a/extras/mini-os/include/events.h	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/include/events.h	Tue Feb 20 14:34:47 2007 +0100
@@ -41,7 +41,7 @@ static inline int notify_remote_via_evtc
 static inline int notify_remote_via_evtchn(evtchn_port_t port)
 {
     evtchn_send_t op;
-    op.port = port;
+    op.port = SWAP(port);
     return HYPERVISOR_event_channel_op(EVTCHNOP_send, &op);
 }
 
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/include/x86/os.h
--- a/extras/mini-os/include/x86/os.h	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/include/x86/os.h	Tue Feb 20 14:34:47 2007 +0100
@@ -13,6 +13,9 @@
 #define unlikely(x)  __builtin_expect((x),0)
 
 #define smp_processor_id() 0
+
+/* Used in ia64 mini-os to run big endian on little endian hypervisor. */
+#define SWAP(x) (x)
 
 
 #ifndef __ASSEMBLY__
diff -r b83cfb117bdd -r 0e0869793af2 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Mon Feb 19 22:50:07 2007 +0000
+++ b/extras/mini-os/xenbus/xenbus.c	Tue Feb 20 14:34:47 2007 +0100
@@ -99,33 +99,35 @@ char* xenbus_wait_for_value(const char* 
     return NULL;
 }
 
-
 static void xenbus_thread_func(void *ign)
 {
     struct xsd_sockmsg msg;
-    unsigned prod = 0;
+    XENSTORE_RING_IDX rsp_cons, rsp_prod = 0;
 
     for (;;) 
     {
-        wait_event(xb_waitq, prod != xenstore_buf->rsp_prod);
+        wait_event(xb_waitq, rsp_prod != SWAP(xenstore_buf->rsp_prod));
         while (1) 
         {
-            prod = xenstore_buf->rsp_prod;
-            DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
-                    xenstore_buf->rsp_prod);
-            if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < sizeof(msg))
+            rsp_prod = SWAP(xenstore_buf->rsp_prod);
+            rsp_cons = SWAP(xenstore_buf->rsp_cons);
+            DEBUG("Rsp_cons %d, rsp_prod %d.\n", rsp_cons, rsp_prod);
+            if (rsp_prod - rsp_cons < sizeof(msg))
                 break;
             rmb();
             memcpy_from_ring(xenstore_buf->rsp,
                     &msg,
-                    MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
+                    MASK_XENSTORE_IDX(rsp_cons),
                     sizeof(msg));
+            msg.type   = SWAP(msg.type);
+            msg.req_id = SWAP(msg.req_id);
+            msg.tx_id  = SWAP(msg.tx_id);
+            msg.len    = SWAP(msg.len);
             DEBUG("Msg len %d, %d avail, id %d.\n",
                     msg.len + sizeof(msg),
-                    xenstore_buf->rsp_prod - xenstore_buf->rsp_cons,
+                    rsp_prod - rsp_cons,
                     msg.req_id);
-            if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
-                    sizeof(msg) + msg.len)
+            if (rsp_prod - rsp_cons < sizeof(msg) + msg.len)
                 break;
 
             DEBUG("Message is good.\n");
@@ -137,13 +139,14 @@ static void xenbus_thread_func(void *ign
 
                 memcpy_from_ring(xenstore_buf->rsp,
                     payload,
-                    MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
+                    MASK_XENSTORE_IDX(rsp_cons),
                     msg.len + sizeof(msg));
 
                 path = payload + sizeof(msg);
                 token = path + strlen(path) + 1;
 
-                xenstore_buf->rsp_cons += msg.len + sizeof(msg);
+                rsp_cons += msg.len + sizeof(msg);
+                xenstore_buf->rsp_cons = SWAP(rsp_cons);
                 free(payload);
                 wake_up(&watch_queue);
             }
@@ -153,9 +156,10 @@ static void xenbus_thread_func(void *ign
                 req_info[msg.req_id].reply = malloc(sizeof(msg) + msg.len);
                 memcpy_from_ring(xenstore_buf->rsp,
                     req_info[msg.req_id].reply,
-                    MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
+                    MASK_XENSTORE_IDX(rsp_cons),
                     msg.len + sizeof(msg));
-                xenstore_buf->rsp_cons += msg.len + sizeof(msg);
+                rsp_cons += msg.len + sizeof(msg);
+                xenstore_buf->rsp_cons = SWAP(rsp_cons);
                 wake_up(&req_info[msg.req_id].waitq);
             }
         }
@@ -251,13 +255,13 @@ static void xb_write(int type, int req_i
     int req_off;
     int total_off;
     int this_chunk;
-    struct xsd_sockmsg m = {.type = type, .req_id = req_id,
-        .tx_id = trans_id };
+    struct xsd_sockmsg m = {.type = SWAP(type), .req_id = SWAP(req_id),
+        .tx_id = SWAP(trans_id) };
     struct write_req header_req = { &m, sizeof(m) };
 
     for (r = 0; r < nr_reqs; r++)
         len += req[r].len;
-    m.len = len;
+    m.len = SWAP(len);
     len += sizeof(m);
 
     cur_req = &header_req;
@@ -265,17 +269,17 @@ static void xb_write(int type, int req_i
     BUG_ON(len > XENSTORE_RING_SIZE);
     /* Wait for the ring to drain to the point where we can send the
        message. */
-    prod = xenstore_buf->req_prod;
-    if (prod + len - xenstore_buf->req_cons > XENSTORE_RING_SIZE) 
+    prod = SWAP(xenstore_buf->req_prod);
+    if (prod + len - SWAP(xenstore_buf->req_cons) > XENSTORE_RING_SIZE) 
     {
         /* Wait for there to be space on the ring */
         DEBUG("prod %d, len %d, cons %d, size %d; waiting.\n",
-                prod, len, xenstore_buf->req_cons, XENSTORE_RING_SIZE);
+                prod, len, SWAP(xenstore_buf->req_cons), XENSTORE_RING_SIZE);
         wait_event(xb_waitq,
-                xenstore_buf->req_prod + len - xenstore_buf->req_cons <=
-                XENSTORE_RING_SIZE);
+                SWAP(xenstore_buf->req_prod) + len -
+                SWAP(xenstore_buf->req_cons) <= XENSTORE_RING_SIZE);
         DEBUG("Back from wait.\n");
-        prod = xenstore_buf->req_prod;
+        prod = SWAP(xenstore_buf->req_prod);
     }
 
     /* We're now guaranteed to be able to send the message without
@@ -304,12 +308,13 @@ static void xb_write(int type, int req_i
     DEBUG("Complete main loop of xb_write.\n");
     BUG_ON(req_off != 0);
     BUG_ON(total_off != len);
-    BUG_ON(prod > xenstore_buf->req_cons + XENSTORE_RING_SIZE);
+    BUG_ON(prod > SWAP(xenstore_buf->req_cons) + XENSTORE_RING_SIZE);
 
     /* Remote must see entire message before updating indexes */
     wmb();
 
-    xenstore_buf->req_prod += len;
+    XENSTORE_RING_IDX req_prod = SWAP(xenstore_buf->req_prod) + len;
+    xenstore_buf->req_prod = SWAP(req_prod);
 
     /* Send evtchn to notify remote */
     notify_remote_via_evtchn(start_info.store_evtchn);
@@ -337,6 +342,11 @@ xenbus_msg_reply(int type,
     wake(current);
 
     rep = req_info[id].reply;
+    rep->type   = SWAP(rep->type);
+    rep->req_id = SWAP(rep->req_id);
+    rep->tx_id  = SWAP(rep->tx_id);
+    rep->len    = SWAP(rep->len);
+
     BUG_ON(rep->req_id != id);
     release_xenbus_id(id);
     return rep;
@@ -370,7 +380,7 @@ static void xenbus_debug_msg(const char 
 
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
     DEBUG("Got a reply, type %d, id %d, len %d.\n",
-            reply->type, reply->req_id, reply->len);
+            SWAP(reply->type), SWAP(reply->req_id), SWAP(reply->len));
 }
 
 /* List the contents of a directory.  Returns a malloc()ed array of

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

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

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Keir Fraser]

On 20/2/07 14:00, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:

> I would like to have a big-endian mini-os running on the ia64 little-endian
> hypervisor.

What's the motivation for wanting to do this?

 -- Keir

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Hi Keir,

Am Dienstag, 20. Februar 2007 15:36 schrieb Keir Fraser:
> On 20/2/07 14:00, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:
> > I would like to have a big-endian mini-os running on the ia64
> > little-endian hypervisor.
>
> What's the motivation for wanting to do this?
>
>  -- Keir

I do some conceptual studies to get our mainframe OS running with xen and 
ia64. This OS is running big endian, so ...
My thoughts were to publish the results - maybe another one can use it.
Thanks.

Dietmar.

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Grzegorz Milos]

Would you like to have this applied to mainstream? Personally, I don't 
think it's too useful there. But I'm open to convincing.

Thanks
Gregor


Dietmar Hahn wrote:
> Hi Keir,
> 
> Am Dienstag, 20. Februar 2007 15:36 schrieb Keir Fraser:
>> On 20/2/07 14:00, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:
>>> I would like to have a big-endian mini-os running on the ia64
>>> little-endian hypervisor.
>> What's the motivation for wanting to do this?
>>
>>  -- Keir
> 
> I do some conceptual studies to get our mainframe OS running with xen and 
> ia64. This OS is running big endian, so ...
> My thoughts were to publish the results - maybe another one can use it.
> Thanks.
> 
> Dietmar.

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Dienstag, 20. Februar 2007 20:03 schrieb Grzegorz Milos:
> Would you like to have this applied to mainstream? Personally, I don't
> think it's too useful there. But I'm open to convincing.
Sure, I would like to have this in mainstream.
Then I can download the xen-source, set big-endian flag in ia64 makerules, try 
make and can test the big endian domU ;-) Ok, this was a joke!
Why not have it in the mainstream? Xen is developing very fast. After x86 now 
we have ia64 and ppc. ia64 is able to run big and little endian (and this is 
used in reality - HP-UX for ia64 is big -endian).
And with Gerd Hoffmann's great new domain builder it's an easiness to start a 
big-endian domU on little-endian dom0.
We did some changes to mini-os. Maybe one of the ppc people may port the 
mini-os - more changes may be needed.
I think the SWAP()'s are not that much. Maybe I can reduce this by moving some 
into the ia64-hypercall interface. What remain are the accesses to the ring 
buffers (not that simple in netfront because of the xen-macros).
Perhaps some other guys contribute their opinion.
Thanks.

Dietmar.

>
> Thanks
> Gregor
>
> Dietmar Hahn wrote:
> > Hi Keir,
> >
> > Am Dienstag, 20. Februar 2007 15:36 schrieb Keir Fraser:
> >> On 20/2/07 14:00, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> 
wrote:
> >>> I would like to have a big-endian mini-os running on the ia64
> >>> little-endian hypervisor.
> >>
> >> What's the motivation for wanting to do this?
> >>
> >>  -- Keir
> >
> > I do some conceptual studies to get our mainframe OS running with xen and
> > ia64. This OS is running big endian, so ...
> > My thoughts were to publish the results - maybe another one can use it.
> > Thanks.
> >
> > Dietmar.

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Keir Fraser]

On 21/2/07 13:04, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:

> I think the SWAP()'s are not that much. Maybe I can reduce this by moving some
> into the ia64-hypercall interface. What remain are the accesses to the ring
> buffers (not that simple in netfront because of the xen-macros).
> Perhaps some other guys contribute their opinion.

I would actually argue that they're scattered all over the place and it will
be hard to be sure that we have all the SWAPs we need and only the SWAPs we
need. Particularly to continue ensuring that given that most development
will be with minios having same endianness as Xen.

In short: it's ugly and unless someone really cares it will rot.

 -- Keir

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Mittwoch, 21. Februar 2007 14:51 schrieb Keir Fraser:
> On 21/2/07 13:04, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:
> > I think the SWAP()'s are not that much. Maybe I can reduce this by moving
> > some into the ia64-hypercall interface. What remain are the accesses to
> > the ring buffers (not that simple in netfront because of the xen-macros).
> > Perhaps some other guys contribute their opinion.
>
> I would actually argue that they're scattered all over the place and it
> will be hard to be sure that we have all the SWAPs we need and only the
> SWAPs we need. Particularly to continue ensuring that given that most
> development will be with minios having same endianness as Xen.
>
> In short: it's ugly and unless someone really cares it will rot.
>
>  -- Keir

Now that the environment (libxc, xen-ia64) is ready to start a simple BE domU, 
I want to start a new discussion about BE able mini-os.
What I want to have is a mini-os, where everybody whith ia64 hardware can 
build and run a BE mini-os beside LE mini-os (or other domU's) on xen-ia64 
hypervisor. If you say at this point: no interrest for such a thing, than we 
can stop this discussion here.
On the other side we should discuss how this can be realized.
My target with the first patch was to minimize the impact on common mini-os 
source as small as possible and that the hypervisor shouldn't be touched by 
BE/LE problematic. Therewidth I did only the SWAPs at the right place in the 
mini-os. Maybe that SWAPs are ugly but the SWAPs have to be done somewhere 
and the best place in my opinion is in the domU at the lowest level functions 
on top of the hypervisor interface - in gnttab, xenbus, xencons, event.
The other way would be building wrappers around all the accesses to 
domU/hypervisor interfaces and hide the SWAPs there. But this seems a little 
bit overkill at this stage.
Oh and yes I will care about this in the mini-os!
Thanks.

Dietmar

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Keir Fraser]

On 27/2/07 09:55, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:

> What I want to have is a mini-os, where everybody whith ia64 hardware can
> build and run a BE mini-os beside LE mini-os (or other domU's) on xen-ia64
> hypervisor. If you say at this point: no interrest for such a thing, than we
> can stop this discussion here.

I don;t think we'd have a problem with incorportaing support for ia64-be if
there's a good reason for it (a better reason than "because it's possible").

> The other way would be building wrappers around all the accesses to
> domU/hypervisor interfaces and hide the SWAPs there. But this seems a little
> bit overkill at this stage.

It would be less ugly and I think less prone to missing some open-coded
accesses. Open-coding the SWAP()s is pretty grim.

 -- Keir

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Mark Williamson]

> > What I want to have is a mini-os, where everybody whith ia64 hardware can
> > build and run a BE mini-os beside LE mini-os (or other domU's) on
> > xen-ia64 hypervisor. If you say at this point: no interrest for such a
> > thing, than we can stop this discussion here.

Is there going to be a port of a full-featured BE OS to Xen/IA64?  Would 
existing OSes be able to be paravirtualised, or would it need to be HVM?

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Dienstag, 27. Februar 2007 13:07 schrieb Mark Williamson:
> Is there going to be a port of a full-featured BE OS to Xen/IA64?  Would
> existing OSes be able to be paravirtualised, or would it need to be HVM?
Currently we have a prototype of our OS (BS2000 - S/390 like mainframe os) 
running in big-endian mode on ia64 hardware. We have built a virtual 
environment within linux to let the OS running. Linux is used as the 
IO-system. Therewidth we have some experiences with the SWAP stuff. The 
target is to substitute linux with dom0 and to full paravirtualise the OS.
At the moment I do some groundwork in preparation for the port.
Thanks.

Dietmar.

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Keir Fraser]

On 28/2/07 08:21, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:

> Currently we have a prototype of our OS (BS2000 - S/390 like mainframe os)
> running in big-endian mode on ia64 hardware.

Couldn't you run BS2000 in little-endian mode? How hardcoded is the
endianness assumption (e.g., all over your ia64-specific additions)?

 -- Keir

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Mittwoch, 28. Februar 2007 09:42 schrieb Keir Fraser:
> On 28/2/07 08:21, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:
> > Currently we have a prototype of our OS (BS2000 - S/390 like mainframe
> > os) running in big-endian mode on ia64 hardware.
>
> Couldn't you run BS2000 in little-endian mode? How hardcoded is the
> endianness assumption (e.g., all over your ia64-specific additions)?
No, BS2000 in little-endian mode is not possible. We talk about millions of  
lines of code and billions of dollars customer application software. It's 
much better to prepare the base for big-endian.
Thanks.

Dietmar.

Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Dienstag, 27. Februar 2007 11:51 schrieb Keir Fraser:
> I don;t think we'd have a problem with incorportaing support for ia64-be if
> there's a good reason for it (a better reason than "because it's
> possible").
I understand this.

> > The other way would be building wrappers around all the accesses to
> > domU/hypervisor interfaces and hide the SWAPs there. But this seems a
> > little bit overkill at this stage.
>
> It would be less ugly and I think less prone to missing some open-coded
> accesses. Open-coding the SWAP()s is pretty grim.
Yes I see this. It's simply more work and more code is touched but from the 
design view it's a lot better.
If this is OK for you, I will try this and send a new patch as a proposal.
Thanks.

Dietmar.

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Keir Fraser]

On 28/2/07 08:25, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:

>> I don;t think we'd have a problem with incorportaing support for ia64-be if
>> there's a good reason for it (a better reason than "because it's
>> possible").
> I understand this.

Doing this for an OS that has pre-existing dependencies on being big-endian
(like your BS2000, presumably) I can understand. But I don't see why adding
contrary-endianness support to minios is part of your roadmap when your end
goal is the porting of a completely different OS? If it's part of a
work-scoping exercise then maybe that's understandable, but I don't see why
we'd necessarily take the resulting minios modifications upstream.

>> It would be less ugly and I think less prone to missing some open-coded
>> accesses. Open-coding the SWAP()s is pretty grim.
> Yes I see this. It's simply more work and more code is touched but from the
> design view it's a lot better.
> If this is OK for you, I will try this and send a new patch as a proposal.

*If* we decide that this is a worthwhile exercise at all for minios, then I
think this has to be the way to go.

 -- Keir

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Am Mittwoch, 28. Februar 2007 09:37 schrieb Keir Fraser:
> On 28/2/07 08:25, "Dietmar Hahn" <dietmar.hahn@fujitsu-siemens.com> wrote:
> >> I don;t think we'd have a problem with incorportaing support for ia64-be
> >> if there's a good reason for it (a better reason than "because it's
> >> possible").
> >
> > I understand this.
>
> Doing this for an OS that has pre-existing dependencies on being big-endian
> (like your BS2000, presumably) I can understand. But I don't see why adding
> contrary-endianness support to minios is part of your roadmap when your end
> goal is the porting of a completely different OS? If it's part of a
> work-scoping exercise then maybe that's understandable, but I don't see why
> we'd necessarily take the resulting minios modifications upstream.
I did the mini-os port to ia64 as a starting point to get familiar with the 
internals of xen. The big-endian stuff in mini-os was a "work-scoping 
exercise" for me, but after getting big-endianess extensions into ia64-xen 
this was an offer to all developers interested in testing/developing the 
big-endian feature in xen-ia64.

> >> It would be less ugly and I think less prone to missing some open-coded
> >> accesses. Open-coding the SWAP()s is pretty grim.
> >
> > Yes I see this. It's simply more work and more code is touched but from
> > the design view it's a lot better.
> > If this is OK for you, I will try this and send a new patch as a
> > proposal.
>
> *If* we decide that this is a worthwhile exercise at all for minios, then I
> think this has to be the way to go.
I understand this.
Thanks.

Dietmar.

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Grzegorz Milos]

>> What I want to have is a mini-os, where everybody whith ia64 hardware can
>> build and run a BE mini-os beside LE mini-os (or other domU's) on xen-ia64
>> hypervisor. If you say at this point: no interrest for such a thing, than we
>> can stop this discussion here.
> 
> I don;t think we'd have a problem with incorportaing support for ia64-be if
> there's a good reason for it (a better reason than "because it's possible").
> 
>> The other way would be building wrappers around all the accesses to
>> domU/hypervisor interfaces and hide the SWAPs there. But this seems a little
>> bit overkill at this stage.
> 
> It would be less ugly and I think less prone to missing some open-coded
> accesses. Open-coding the SWAP()s is pretty grim.
> 

One solution to the rotting problem would be write regression tests. 
High level tests (like for example netfront test) would be quite good at 
picking missing SWAPs, since they exercise a fair amount of Xen/Dom0 
interfaces. Still it's quite hard to check the coverage (anybody happens 
to be an expert on coverage testing?).

I too dislike scattering SWAPs all over the code, but I guess having a 
nice set of wrappers would at least confine the problem. Still ... not 
that fond of it.

Cheers
Gregor

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Hi Gregor,

Am Donnerstag, 1. März 2007 23:08 schrieb Grzegorz Milos:
> One solution to the rotting problem would be write regression tests.
> High level tests (like for example netfront test) would be quite good at
> picking missing SWAPs, since they exercise a fair amount of Xen/Dom0
> interfaces. Still it's quite hard to check the coverage (anybody happens
> to be an expert on coverage testing?).
>
> I too dislike scattering SWAPs all over the code, but I guess having a
> nice set of wrappers would at least confine the problem. Still ... not
> that fond of it.
>
> Cheers
> Gregor

I send this as a private mail to you.
First thanks for opening a possible door to the SWAP stuff.
I don't full understand your rotting problem.
With recent binutils (see 
http://sources.redhat.com/ml/binutils/2004-07/msg00110.html) everybody on 
ia64 hardware can build big-endian images on a little-endian linux machine. 
Only some special make flags in mini-os/arch/ia64/arch.mk (and the SWAPs) are 
needed to build a big-endian mini-os on ia64-linux. So a running big-endian 
mini-os on xen-ia64 is already a regression test itself I think.
So the most currently used interfaces are checked with a running mini-os. 
Maybe for some more interface regression tests are possible/needed.
What do you think? Where is my mistake in thinking about this?
Thanks.

Dietmar

Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64

[Dietmar Hahn]

Sorry, this should only go to 
Grzegorz Milos <gm281@cam.ac.uk>
Thanks.

Dietmar.

Am Donnerstag, 15. März 2007 11:55 schrieb Dietmar Hahn:
> Hi Gregor,
>
> Am Donnerstag, 1. März 2007 23:08 schrieb Grzegorz Milos:
> > One solution to the rotting problem would be write regression tests.
> > High level tests (like for example netfront test) would be quite good at
> > picking missing SWAPs, since they exercise a fair amount of Xen/Dom0
> > interfaces. Still it's quite hard to check the coverage (anybody happens
> > to be an expert on coverage testing?).
> >
> > I too dislike scattering SWAPs all over the code, but I guess having a
> > nice set of wrappers would at least confine the problem. Still ... not
> > that fond of it.
> >
> > Cheers
> > Gregor
>
> I send this as a private mail to you.
> First thanks for opening a possible door to the SWAP stuff.
> I don't full understand your rotting problem.
> With recent binutils (see
> http://sources.redhat.com/ml/binutils/2004-07/msg00110.html) everybody on
> ia64 hardware can build big-endian images on a little-endian linux machine.
> Only some special make flags in mini-os/arch/ia64/arch.mk (and the SWAPs)
> are needed to build a big-endian mini-os on ia64-linux. So a running
> big-endian mini-os on xen-ia64 is already a regression test itself I think.
> So the most currently used interfaces are checked with a running mini-os.
> Maybe for some more interface regression tests are possible/needed.
> What do you think? Where is my mistake in thinking about this?
> Thanks.
>
> Dietmar
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel