From mboxrd@z Thu Jan  1 00:00:00 1970
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [PATCH ARM v3 7/7] mini-os: initial ARM support
Date: Wed, 11 Jun 2014 21:24:53 +0200
Message-ID: <20140611192453.GM6816@type.mobile.lan>
References: <1402482618-15269-1-git-send-email-talex5@gmail.com>
	<1402482618-15269-8-git-send-email-talex5@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=G/WP=3I=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Wup4c-0006QE-CJ
	for xen-devel@lists.xenproject.org; Wed, 11 Jun 2014 20:24:42 +0000
Content-Disposition: inline
In-Reply-To: <1402482618-15269-8-git-send-email-talex5@gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Thomas Leonard <talex5@gmail.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@eu.citrix.com, Dave.Scott@eu.citrix.com, anil@recoil.org
List-Id: xen-devel@lists.xenproject.org

Hello,

I don't know the arm hardware very much, so I can't really review the
arm-specific things, there a just a few things which catched my eyes:

Thomas Leonard, le Wed 11 Jun 2014 11:30:18 +0100, a =E9crit :
> +#define LOCK_PREFIX ""
> +#define LOCK ""

You don't need to define them, they were meant for x86 code.

> +#define ADDR (*(volatile long *) addr)

You aren't using it, no need to define it either.

> +static inline unsigned long __xchg(unsigned long x, volatile void * ptr,=
 int size)
> +{
> +    //TODO
> +    unsigned volatile long y, tmp =3D 0;
> +    switch(size){
> +    case 1:
> +#if CPU_EXCLUSIVE_LDST
> +        __asm__ __volatile__("1:ldrexb %0, [%1]\n"
> +            "strexb %3, %2, [%1]\n"
> +            "cmp %3, #1\n"
> +            "beq 1b\n\n"
> +            "dmb\n":"=3D&r"(y):"r"(ptr), "r"(x), "r"(tmp):"memory");
> +#else
> +        y =3D (*(char *)ptr) & 0x000000ff;
> +        *((char *)ptr) =3D (char)x;

The second version is very fragile :) I'd rather put a strong #warning
here, to make sure nobody ever uses that code for anything close to
production level.


> +static __inline__ int test_and_clear_bit(int nr, volatile void * addr)
> +{
> +    //TODO
> +    unsigned long *tmp =3D (unsigned long *)addr;
> +
> +    int x =3D tmp[nr >> 5] & (1 << (nr & 0x1f));
> +    tmp[nr >> 5] &=3D ~(1 << (nr & 0x1f));
> +    return x;
> +}

And this must be atomic, so an atomic version is really needed.

I guess we could perhaps revert to gcc instrinsics by default to save
porting work here.


> +static inline unsigned long __synch_cmpxchg(volatile void *ptr,
> +        unsigned long old,
> +        unsigned long new, int size)
> +{
> +    //TODO:
> +    //BUG();
> +    return 0;
> +}
> +
> +static __inline__ void synch_set_bit(int nr, volatile void * addr)
> +{
> +    //TODO:
> +    set_bit(nr, addr);
> +}

Same story for these


Apart from these, the integration into the existing mini-os looks nice.

Samuel