On 06/24/2012 05:51 PM, Jan Kiszka wrote: > On 2012-06-24 16:46, Avi Kivity wrote: >> On 06/24/2012 05:40 PM, Jan Kiszka wrote: >>> On 2012-06-24 16:35, Avi Kivity wrote: >>>> On 06/24/2012 05:08 PM, Jan Kiszka wrote: >>>>> As a first step, I will post a series later that gets rid of >>>>> kvm_flush_coalesced_mmio_buffer in the common vmexit path. >>>> >>>> If you defer this, I can think of two places that need to flush: >>>> - anything that accesses those memory areas (such as DMA to the >>>> framebuffer, or updating the display) >>> >>> - anything that accesses related areas (in case of VGA: PIO accesses to >>> the control ports). I'm providing memory_region_set_flush_coalesced that >>> allows to flush on non-coalesced region accesses as well. Some PIO >>> accesses unfortunately still need open-coded >>> qemu_flush_coalesced_mmio_buffer as they do not use memory regions yet. >> >> Framebuffer access will bypass the MemoryRegionOps callbacks, did you >> intend to hook those? > > 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. -- error compiling committee.c: too many arguments to function
