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'm not sure the problem is general enough to merit a check in our > generic mmio dispatch code (granted, now it has a check in the vcpu exit > path which is much worse). The current situation is indeed much worse. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
