qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-2.4 0/8] memory: enable unlocked PIO/MMIO in


From: Jan Kiszka
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
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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



reply via email to

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