[XenPPC] Re: xencomm porting and inline handles

2006-09-29 Thread Tristan Gingold
Le Jeudi 28 Septembre 2006 17:07, Hollis Blanchard a écrit :
 On Thu, 2006-09-28 at 08:27 +0200, Tristan Gingold wrote:
  Le Mercredi 27 Septembre 2006 17:10, Hollis Blanchard a écrit :
   On Wed, 2006-09-27 at 08:19 +0200, Tristan Gingold wrote:
Le Mardi 26 Septembre 2006 20:23, Hollis Blanchard a écrit :
 On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote:
  After more work, inline xencomm is not that magic: it doesn't
  work for modules which are loaded in virtual memory.  So I have
  to use mini xencomm at least for modules.

 What's the problem with modules? Their text/data isn't physically
 contiguous, but where exactly is the problem?
   
Inline xencomm only works for physically contiguous area because only
the base address is passed.  Therefore it doesn't work for modules.
  
   I understand that; please explain exactly what about the modules isn't
   working.
  
   For example, the stack used in kernel modules is still physically
   contiguous, so using stack-allocated data structures should work fine.
   However, making hypercalls directly using global data structures
   wouldn't work. However, the inline code is only being used for the
   hypercalls that could be made early. Is that the problem? Please
   identify the specific issue(s).
 
  Yes, some hypercalls data are global data.
  Sorry, I was not specific enough!

 Hi Tristan, *which* hypercalls? Please identify some specific lines of
 code that are causing the problems...
This issue was at least hit in drivers/xen/netback/netback.c:

static void net_rx_action(unsigned long unused)
{
netif_t *netif = NULL;
s8 status;
u16 id, irq, flags;
netif_rx_response_t *resp;
multicall_entry_t *mcl;
struct sk_buff_head rxq;
struct sk_buff *skb;
int notify_nr = 0;
int ret;
int nr_frags;
int count;
unsigned long offset;

/*
 * Putting hundreds of bytes on the stack is considered rude.
 * Static works because a tasklet can only be on one CPU at any time.
 */
static multicall_entry_t rx_mcl[NET_RX_RING_SIZE+3];
static mmu_update_t rx_mmu[NET_RX_RING_SIZE];
static gnttab_transfer_t grant_trans_op[NET_RX_RING_SIZE];
static gnttab_copy_t grant_copy_op[NET_RX_RING_SIZE];
static unsigned char rx_notify[NR_IRQS];
static u16 notify_list[NET_RX_RING_SIZE];
static struct netbk_rx_meta meta[NET_RX_RING_SIZE];

Lot's of hypercall parameters in module data segment!

Tristan.

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


[XenPPC] Re: [Xen-devel] [PATCH 0/3][XM-TEST] Updates to xm-test ramdisk code

2006-09-29 Thread Keir Fraser
On 29/9/06 5:52 am, Hollis Blanchard [EMAIL PROTECTED] wrote:

  1: Instead of using a dated snapshot (which no longer exists)
 use buildroot-snapshot.
  2: Remove hardcoded references to i386.
  3: Rename configs/buildroot - configs/buildroot-i386
 and update Makefiles.
 
 With patches applied x86 still builds an initrd.img
 
 Feedback appreciated.
 
 Who maintains xm-test and could take a look at these patches?

Ewan Mellor normally would. He's on holiday until Monday.

 -- Keir



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


Re: [XenPPC] dom0_mem=2G panics Xen

2006-09-29 Thread Jimi Xenidis


On Sep 29, 2006, at 5:55 AM, Jimi Xenidis wrote:



On Sep 29, 2006, at 12:25 AM, Amos Waterland wrote:



At dom0_mem 2G and 7G, we get:

(XEN) *** LOADING DOMAIN 0 ***
(XEN) Cannot handle page request order 13!
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) shadow allocation failed 0x0  0x20
(XEN) 
Oh of course, we allocate the shadow (HTAB) for dom0 as 1/64th of  
dom0_mem.

Now I know another reason why PHYP-L steals 256M from your blade :)

-JX


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


Re: [XenPPC] xm dump-core

2006-09-29 Thread Maria Butrico
If anyone knows anything about how this is supposed to work I can take 
quick stab at it.  We can probably use it.


Jimi Xenidis wrote:


On Sep 28, 2006, at 3:58 PM, Maria Butrico wrote:

I can dump part of the core file out but not all.  I see a message 
about connection refused to xend.  Yet xend is running.Are there 
tools for reading the core file?


Sorry, not supported yet, not even in our checklist:
  http://wiki.xensource.com/xenwiki/XenPPC/XMChecklist

-JX






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