On 2011-07-20 10:24, Avi Kivity wrote: > On 07/19/2011 08:23 PM, Jan Kiszka wrote: >> On 2011-07-19 19:17, Avi Kivity wrote: >>> On 07/19/2011 08:14 PM, Jan Kiszka wrote: >>>> >>>> Another improvement - unfortunately less transparent for user space - >>>> would be to overcome the single ring buffer that forces us to hold a >>>> central lock in user space while processing the entries. We rather need >>>> per-device rings. While waiting for coalesced VGA MMIO being processed, >>>> way too many kittens are killed. >>>> >>>> I have this on our agenda, but I wouldn't be disappointed as well if >>>> someone else is faster. >>> >>> The socket mmio would have accomplished this as well. >> >> I haven't followed the outcome in all details - is that approach dead >> due to its complexity? >> >>> One thing to >>> beware of is to preserve correctness: >>> >>> 1) write to 0xa0000 (queued) >>> 2) write to 0xa0002 (queued) >>> 3) remap 0xa0000 region (executed) >> >> Obviously, there must be 3a) here: drain all affected queues. > > How do you implement this 3a, if your consumers are outside the main > process? I guess you could have an additional synchonize API (for > in-kernel consumers) or RPC (for external process consumers), but then > this is no longer a simple API.
I'm not planning to leave the hypervisor process for now, not to speak of in-kernel models. Already for many other reasons, a synchronization API between a hypothetical decoupled device model and the core will be quite complex. The first step is to get it scalable using a single process. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
