qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about atomics


From: Warner Losh
Subject: Re: Question about atomics
Date: Tue, 8 Mar 2022 07:09:55 -0700



On Mon, Mar 7, 2022 at 10:00 PM Richard Henderson <richard.henderson@linaro.org> wrote:
On 3/7/22 18:18, Warner Losh wrote:
> I have a question related to the user-mode emulation and atomics. I asked on IRC, but
> thinking about it, I think it may be too complex to discuss in that medium...
>
> In FreeBSD we have a system call that uses host atomic operations to interact memory that
> userland also interacts with using atomic operations.
>
> In bsd-user we call the kernel with a special flag for dealing with 32-bit processes
> running on a 64-bit kernel. In this case, we use 32-bit-sized atomics to set variables in
> the address space of the bsd-user guest. This is used when running armv7 binaries on amd64
> hosts.
>
> First question: Is this expected to work? I know I'm a bit vague, so as a followup
> question: If there's restrictions on this, what might they be? Do some classes of atomic
> operations work, while others may fail or need additional cooperation? Are there any
> conformance tests I could compile for FreeBSD/armv7 to test the hypothesis that atomic
> operations are misbehaving?

Yes, qatomic_foo is expected to work.  It's what we use across threads, and it is expected
to work "in kernel mode", i.e. within cpu_loop().

Even when the writers are done in the context of system calls to the kernel?
 
There are compile-time restrictions on the set of atomic operations, mostly based on what
the host supports.  But anything that actually compiles is expected to work (there are a
set of ifdefs if you need something more than the default).

Beyond that, there is start_exclusive() / end_exclusive() which will stop-the-world and
make sure that the current thread is the only one running.

So anything that happens in the BSD host kernel would need to be confined to the one
and only on running thread? It also assumes only one thread is scheduled and running
and that might be a source of 'brokeness' if there's an issue in the BSD implementation
of the mechanisms that are used for that. And if the system call does this w/o using
the start_exclusive/end_exclusive stuff, is that a problem?
 
> Thanks for any help you might be able to give.

Show the code in question?

Which code? The test cases that are failing, or the bsd-user code in the branch I suspect?

Warner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]