From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-trivial@nongnu.org, Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD
Date: Fri, 28 Jun 2013 17:11:19 +0200 [thread overview]
Message-ID: <51CDA797.9000803@redhat.com> (raw)
In-Reply-To: <CAFEAcA-8n0GEYd3Rif-XGaPaC1vwKk_eYJKu2Z8VMyKp-0-nfw@mail.gmail.com>
Il 28/06/2013 16:55, Peter Maydell ha scritto:
>>> >> I don't understand what you mean by "no need for it". We are
>>> >> already multithreaded in system mode, so this is simply
>>> >> making FreeBSD do the same thing as Linux.
>> >
>> > cpu_single_env is protected by the BQL unless you're running on KVM.
> That doesn't make it magically not a per-thread variable.
If it were possible to say "make cpu_single_env magically not per-thread
on Linux/TCG", I'd be all for it!
But I _can_ make cpu_single_env not per-thread on FreeBSD/TCG, because
no one needs per-thread cpu_single_env on FreeBSD.
If we could drop support for platforms that lack __thread (or some other
fast TLS mechanism), then it would be another story of course. We would
not have to do things like this for qtest:
while (1) {
cpu_single_env = NULL;
qemu_mutex_unlock_iothread();
do {
int sig;
r = sigwait(&waitset, &sig);
} while (r == -1 && (errno == EAGAIN || errno == EINTR));
if (r == -1) {
perror("sigwait");
exit(1);
}
qemu_mutex_lock_iothread();
cpu_single_env = env;
qemu_wait_io_event_common(cpu);
}
or similarly set cpu_single_env in cpu_exec.
And of course if bsd-user supported 1:1 mapping between guest and host
threads on FreeBSD, cpu_single_env would have to be thread-local.
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-trivial@nongnu.org, Ed Maste <emaste@freebsd.org>,
Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD
Date: Fri, 28 Jun 2013 17:11:19 +0200 [thread overview]
Message-ID: <51CDA797.9000803@redhat.com> (raw)
In-Reply-To: <CAFEAcA-8n0GEYd3Rif-XGaPaC1vwKk_eYJKu2Z8VMyKp-0-nfw@mail.gmail.com>
Il 28/06/2013 16:55, Peter Maydell ha scritto:
>>> >> I don't understand what you mean by "no need for it". We are
>>> >> already multithreaded in system mode, so this is simply
>>> >> making FreeBSD do the same thing as Linux.
>> >
>> > cpu_single_env is protected by the BQL unless you're running on KVM.
> That doesn't make it magically not a per-thread variable.
If it were possible to say "make cpu_single_env magically not per-thread
on Linux/TCG", I'd be all for it!
But I _can_ make cpu_single_env not per-thread on FreeBSD/TCG, because
no one needs per-thread cpu_single_env on FreeBSD.
If we could drop support for platforms that lack __thread (or some other
fast TLS mechanism), then it would be another story of course. We would
not have to do things like this for qtest:
while (1) {
cpu_single_env = NULL;
qemu_mutex_unlock_iothread();
do {
int sig;
r = sigwait(&waitset, &sig);
} while (r == -1 && (errno == EAGAIN || errno == EINTR));
if (r == -1) {
perror("sigwait");
exit(1);
}
qemu_mutex_lock_iothread();
cpu_single_env = env;
qemu_wait_io_event_common(cpu);
}
or similarly set cpu_single_env in cpu_exec.
And of course if bsd-user supported 1:1 mapping between guest and host
threads on FreeBSD, cpu_single_env would have to be thread-local.
Paolo
next prev parent reply other threads:[~2013-06-28 15:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 19:21 [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD Ed Maste
2013-06-24 19:21 ` [Qemu-devel] " Ed Maste
2013-06-24 21:15 ` [Qemu-trivial] " Paolo Bonzini
2013-06-24 21:15 ` [Qemu-devel] " Paolo Bonzini
2013-06-24 21:30 ` [Qemu-trivial] " Peter Maydell
2013-06-24 21:30 ` Peter Maydell
2013-06-25 6:18 ` [Qemu-trivial] " Paolo Bonzini
2013-06-25 6:18 ` [Qemu-devel] " Paolo Bonzini
2013-06-25 10:56 ` [Qemu-trivial] " Peter Maydell
2013-06-25 10:56 ` Peter Maydell
2013-06-25 10:58 ` [Qemu-trivial] " Paolo Bonzini
2013-06-25 10:58 ` Paolo Bonzini
2013-06-28 10:34 ` [Qemu-trivial] " Michael Tokarev
2013-06-28 10:34 ` [Qemu-devel] " Michael Tokarev
2013-06-28 12:54 ` [Qemu-trivial] [Qemu-devel] " Ed Maste
2013-06-28 12:54 ` [Qemu-devel] [Qemu-trivial] " Ed Maste
2013-06-28 13:03 ` [Qemu-trivial] [Qemu-devel] " Paolo Bonzini
2013-06-28 13:03 ` [Qemu-devel] [Qemu-trivial] " Paolo Bonzini
2013-06-28 13:05 ` [Qemu-trivial] [Qemu-devel] " Peter Maydell
2013-06-28 13:05 ` [Qemu-devel] [Qemu-trivial] " Peter Maydell
2013-06-28 14:08 ` [Qemu-trivial] [Qemu-devel] " Ed Maste
2013-06-28 14:08 ` [Qemu-devel] [Qemu-trivial] " Ed Maste
2013-06-28 14:47 ` Paolo Bonzini
2013-06-28 14:47 ` [Qemu-devel] " Paolo Bonzini
2013-06-28 14:55 ` Peter Maydell
2013-06-28 14:55 ` [Qemu-devel] " Peter Maydell
2013-06-28 15:11 ` Paolo Bonzini [this message]
2013-06-28 15:11 ` Paolo Bonzini
2013-06-28 15:35 ` Ed Maste
2013-06-28 15:35 ` [Qemu-devel] " Ed Maste
2013-06-28 15:37 ` Paolo Bonzini
2013-06-28 15:37 ` [Qemu-devel] " Paolo Bonzini
2013-07-01 8:03 ` Stefan Hajnoczi
2013-07-01 8:03 ` [Qemu-devel] " Stefan Hajnoczi
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=51CDA797.9000803@redhat.com \
--to=pbonzini@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.