On 2012-06-24 16:56, Avi Kivity wrote: > 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. That's a non issue, we already have to flush on display updates. See e.g. vga_update_display. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
