Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

[Avi Kivity]

On 06/29/2012 07:37 PM, Jan Kiszka wrote:
> Instead of flushing pending coalesced MMIO requests on every vmexit,
> this provides a mechanism to selectively flush when memory regions
> related to the coalesced one are accessed. This first of all includes
> the coalesced region itself but can also applied to other regions, e.g.
> of the same device, by calling memory_region_set_flush_coalesced.

Looks fine.

I have a hard time deciding whether this should go through the kvm tree
or memory tree.  Anthony, perhaps you can commit it directly to avoid
the livelock?

Reviewed-by: Avi Kivity <avi@redhat.com>


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

[Avi Kivity]

On 07/02/2012 12:07 PM, Avi Kivity wrote:
> 
> Reviewed-by: Avi Kivity <avi@redhat.com>

(for the entire patchset)


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

[Jan Kiszka]

On 2012-07-02 11:07, Avi Kivity wrote:
> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
>> Instead of flushing pending coalesced MMIO requests on every vmexit,
>> this provides a mechanism to selectively flush when memory regions
>> related to the coalesced one are accessed. This first of all includes
>> the coalesced region itself but can also applied to other regions, e.g.
>> of the same device, by calling memory_region_set_flush_coalesced.
> 
> Looks fine.
> 
> I have a hard time deciding whether this should go through the kvm tree
> or memory tree.  Anthony, perhaps you can commit it directly to avoid
> the livelock?
> 
> Reviewed-by: Avi Kivity <avi@redhat.com>
> 

Anthony, ping?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

[Jan Kiszka]

On 2012-07-10 12:41, Jan Kiszka wrote:
> On 2012-07-02 11:07, Avi Kivity wrote:
>> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
>>> Instead of flushing pending coalesced MMIO requests on every vmexit,
>>> this provides a mechanism to selectively flush when memory regions
>>> related to the coalesced one are accessed. This first of all includes
>>> the coalesced region itself but can also applied to other regions, e.g.
>>> of the same device, by calling memory_region_set_flush_coalesced.
>>
>> Looks fine.
>>
>> I have a hard time deciding whether this should go through the kvm tree
>> or memory tree.  Anthony, perhaps you can commit it directly to avoid
>> the livelock?
>>
>> Reviewed-by: Avi Kivity <avi@redhat.com>
>>
> 
> Anthony, ping?

Argh, missed that this series was forgotten. Patch 1 is a bug fix, will
resend it separately so that it can make it into 1.2. Will repost the
rest once master reopens.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access

[Avi Kivity]

On 08/17/2012 01:55 PM, Jan Kiszka wrote:
> On 2012-07-10 12:41, Jan Kiszka wrote:
>> On 2012-07-02 11:07, Avi Kivity wrote:
>>> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
>>>> Instead of flushing pending coalesced MMIO requests on every vmexit,
>>>> this provides a mechanism to selectively flush when memory regions
>>>> related to the coalesced one are accessed. This first of all includes
>>>> the coalesced region itself but can also applied to other regions, e.g.
>>>> of the same device, by calling memory_region_set_flush_coalesced.
>>>
>>> Looks fine.
>>>
>>> I have a hard time deciding whether this should go through the kvm tree
>>> or memory tree.  Anthony, perhaps you can commit it directly to avoid
>>> the livelock?
>>>
>>> Reviewed-by: Avi Kivity <avi@redhat.com>
>>>
>> 
>> Anthony, ping?
> 
> Argh, missed that this series was forgotten. Patch 1 is a bug fix, will
> resend it separately so that it can make it into 1.2. Will repost the
> rest once master reopens.

My fault, I should have just taken it into memory/core and sent a pull
request.  Sorry about that.

-- 
error compiling committee.c: too many arguments to function