|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop |
Date: | Sun, 24 Jun 2012 17:59:58 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
On 06/24/2012 05:58 PM, Jan Kiszka wrote: >>> Are there really cases where the framebuffer is accessible both via MMIO >>> and RAM-like mappings at the same time? If so, the current flushing on >>> vmexit would help either as the direct mappings would not trigger exits. >>> Or what do you mean? >> >> I meant accesses by the display code to put the framebuffer in front of >> the user's eyes. Those just access the memory directly. We could wrap >> them with memory_region_get/put_ram_ptr() (as Xen requires anyway) and >> have those issue the flush. > > That's a non issue, we already have to flush on display updates. See > e.g. vga_update_display. > Ah, of course. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |