Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Florian Lohoff" <flo@rfc822.org>
Cc: <debian-mips@lists.debian.org>, <linux-mips@oss.sgi.com>
Subject: Re: first packages for mipsel
Date: Fri, 6 Apr 2001 17:33:23 +0200	[thread overview]
Message-ID: <011e01c0beae$f0d12840$0deca8c0@Ulysses> (raw)
In-Reply-To: 20010406152836.A21459@paradigm.rfc822.org

> > > If there is a working ll/sc emulation fine - Currently there is none
> > > so the only way to go TODAY is sysmips.
> >
> > I'll work on one in the background.  It should be pretty straightforward
> > for the uniprocessor case, but an SMP version will be messier, and
> > possibly require a platform-dependent hook.  Of course, the same
> > is true of sysmips()...
>
> For SMP versions we could currently just put an "#error" in it. There has
> to be machine dependent support as the older SGI Challenge have. So dont
> worry on that case.

I've just glanced at the unfinished ll emulation code in the 2.4.3 baseline.
It looks like someone was trying to do a full and precise emulation of
the instruction as documented, which is admirable but horribly difficult.
The trick is that one can be aggressive in clearing the lock "flip flop".
In real CPU's for example, the flop is cleared on every exception taken.
Emulating that alone would make for a semi-functional operation,
at least in terms of protecting kernel threads.  One needs to do a bit
more to cover user-level multithreading.  Stricktly speaking, one should
search the entire address space of the executing task and tag all
virtual pages that map to the targeted physical page as being
non-writable, and on a write protect error clear both the ll bit and
the protections.  On a sc, one can either do nothing or proactively
make the pages writable.  I find the notion of the *same* task having
a lock cell virtually aliased to be wildly improbable, and would be
tempted to consider elimitating the reverse translation and only
flagging the page where the ll/sc is taking place.  That would not
be 100% correct emulation, but I would be very surprised to find
any code that would notice.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Florian Lohoff <flo@rfc822.org>
Cc: debian-mips@lists.debian.org, linux-mips@oss.sgi.com
Subject: Re: first packages for mipsel
Date: Fri, 6 Apr 2001 17:33:23 +0200	[thread overview]
Message-ID: <011e01c0beae$f0d12840$0deca8c0@Ulysses> (raw)
Message-ID: <20010406153323.DZZPUkfuvjr6eauMYpqDMHu1eeujcqPiciN7fPEz0yY@z> (raw)
In-Reply-To: 20010406152836.A21459@paradigm.rfc822.org

> > > If there is a working ll/sc emulation fine - Currently there is none
> > > so the only way to go TODAY is sysmips.
> >
> > I'll work on one in the background.  It should be pretty straightforward
> > for the uniprocessor case, but an SMP version will be messier, and
> > possibly require a platform-dependent hook.  Of course, the same
> > is true of sysmips()...
>
> For SMP versions we could currently just put an "#error" in it. There has
> to be machine dependent support as the older SGI Challenge have. So dont
> worry on that case.

I've just glanced at the unfinished ll emulation code in the 2.4.3 baseline.
It looks like someone was trying to do a full and precise emulation of
the instruction as documented, which is admirable but horribly difficult.
The trick is that one can be aggressive in clearing the lock "flip flop".
In real CPU's for example, the flop is cleared on every exception taken.
Emulating that alone would make for a semi-functional operation,
at least in terms of protecting kernel threads.  One needs to do a bit
more to cover user-level multithreading.  Stricktly speaking, one should
search the entire address space of the executing task and tag all
virtual pages that map to the targeted physical page as being
non-writable, and on a write protect error clear both the ll bit and
the protections.  On a sc, one can either do nothing or proactively
make the pages writable.  I find the notion of the *same* task having
a lock cell virtually aliased to be wildly improbable, and would be
tempted to consider elimitating the reverse translation and only
flagging the page where the ll/sc is taking place.  That would not
be 100% correct emulation, but I would be very surprised to find
any code that would notice.

            Regards,

            Kevin K.

  reply	other threads:[~2001-04-06 15:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010406130958.A14083@paradigm.rfc822.org>
2001-04-06 11:22 ` first packages for mipsel Florian Lohoff
2001-04-06 11:43   ` Kevin D. Kissell
2001-04-06 11:43     ` Kevin D. Kissell
2001-04-06 11:58     ` Florian Lohoff
2001-04-06 12:23       ` Kevin D. Kissell
2001-04-06 12:23         ` Kevin D. Kissell
2001-04-06 13:28         ` Florian Lohoff
2001-04-06 15:33           ` Kevin D. Kissell [this message]
2001-04-06 15:33             ` Kevin D. Kissell
2001-04-06 16:48           ` Maciej W. Rozycki
2001-04-06 16:40     ` Maciej W. Rozycki
2001-04-07  9:05       ` Kevin D. Kissell
2001-04-07  9:05         ` Kevin D. Kissell
2001-04-07 10:55         ` Maciej W. Rozycki
2001-04-07 15:29           ` Florian Lohoff
2001-04-09  9:48             ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='011e01c0beae$f0d12840$0deca8c0@Ulysses' \
    --to=kevink@mips.com \
    --cc=debian-mips@lists.debian.org \
    --cc=flo@rfc822.org \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox