From: Jan Kiszka <jan.kiszka@siemens.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.4 0/8] memory: enable unlocked PIO/MMIO in KVM
Date: Wed, 18 Mar 2015 16:04:59 +0100 [thread overview]
Message-ID: <5509941B.4000501@siemens.com> (raw)
In-Reply-To: <5509912E.7020007@redhat.com>
On 2015-03-18 15:52, Paolo Bonzini wrote:
>
>
> On 18/03/2015 15:33, Jan Kiszka wrote:
>> Just in time: I'm planning to rebase our queue soon, specifically to
>> benefit from RCU support. Will let you know if it works on top of this
>> series.
>
> Great. FWIW, this is the most similar version to the one we played with
> in 2013.
>
> I have an alternative one that keeps the single address_space_rw API,
> and checks if you have the iothread mutex using thread-local storage.
qemu_mutex_iothread_is_locked() with a qemu_global_mutex-specific flag
or qemu_mutex_is_locked(&qemu_global_mutex)?
> The reason for that is that I would have to introduce
> address_space_map/unmap_unlocked too, which I didn't really like. Also,
> in the not-so-long term we want the same code (e.g. SCSI layer) to run
> in both locked and unlocked mode.
>
> What do you think?
I cannot envision the code differences yet as we didn't have the need to
play with lockless MMIO or even DMA so far (will probably happen soon,
though - for networking). For me it boils down to the code impact as
well, how much we can reuse by hiding locked vs. unlocked mode, and how
much we may make more fragile and harder to design correctly by doing so.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2015-03-18 15:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 13:21 [Qemu-devel] [PATCH for-2.4 0/8] memory: enable unlocked PIO/MMIO in KVM Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 1/8] memory: Add global-locking property to memory regions Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 2/8] exec: move rcu_read_lock/unlock to address_space_translate callers Paolo Bonzini
2015-03-19 13:27 ` Jan Kiszka
2015-03-19 14:55 ` Jan Kiszka
2015-03-19 16:23 ` Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 3/8] memory: Provide address_space_rw_unlocked Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 4/8] kvm: First step to push iothread lock out of inner run loop Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 5/8] kvm: Switch to unlocked PIO Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 6/8] exec: mark unassigned_io_ops as unlocked Paolo Bonzini
2015-03-18 14:33 ` Jan Kiszka
2015-03-18 14:53 ` Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 7/8] acpi: mark PMTIMER " Paolo Bonzini
2015-03-18 13:21 ` [Qemu-devel] [PATCH 8/8] kvm: Switch to unlocked MMIO Paolo Bonzini
2015-03-18 14:33 ` [Qemu-devel] [PATCH for-2.4 0/8] memory: enable unlocked PIO/MMIO in KVM Jan Kiszka
2015-03-18 14:52 ` Paolo Bonzini
2015-03-18 15:04 ` Jan Kiszka [this message]
2015-03-19 8:52 ` Paolo Bonzini
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=5509941B.4000501@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@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.