[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of in
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop |
Date: |
Sun, 24 Jun 2012 16:58:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, (continued)
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, liu ping fan, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Jan Kiszka, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Avi Kivity, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Jan Kiszka, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Avi Kivity, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Jan Kiszka, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Avi Kivity, 2012/06/24
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop,
Jan Kiszka <=
- Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Avi Kivity, 2012/06/24
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Marcelo Tosatti, 2012/06/26
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Marcelo Tosatti, 2012/06/28
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Avi Kivity, 2012/06/27
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Jan Kiszka, 2012/06/27
Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop, Anthony Liguori, 2012/06/28