Il 03/09/2013 10:35, Andreas Färber ha scritto:
> Am 03.09.2013 09:22, schrieb Paolo Bonzini:
>> Il 03/09/2013 09:05, liguang ha scritto:
>>> Signed-off-by: liguang <lig.f...@cn.fujitsu.com>
>>> ---
>>>  cputlb.c |   15 ---------------
>>>  1 files changed, 0 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/cputlb.c b/cputlb.c
>>> index 977c0ca..08e50e0 100644
>>> --- a/cputlb.c
>>> +++ b/cputlb.c
>>> @@ -169,21 +169,6 @@ static inline ram_addr_t 
>>> qemu_ram_addr_from_host_nofail(void *ptr)
>>>      return ram_addr;
>>>  }
>>>  
>>> -static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
>>> -{
>>> -    ram_addr_t ram_addr;
>>> -    void *p;
>>> -
>>> -    if (tlb_is_dirty_ram(tlb_entry)) {
>>> -        p = (void *)(uintptr_t)((tlb_entry->addr_write & TARGET_PAGE_MASK)
>>> -            + tlb_entry->addend);
>>> -        ram_addr = qemu_ram_addr_from_host_nofail(p);
>>> -        if (!cpu_physical_memory_is_dirty(ram_addr)) {
>>> -            tlb_entry->addr_write |= TLB_NOTDIRTY;
>>> -        }
>>> -    }
>>> -}
>>> -
>>>  void cpu_tlb_reset_dirty_all(ram_addr_t start1, ram_addr_t length)
>>>  {
>>>      CPUState *cpu;
>>>
>>
>> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com>
>>
>> and CCing qemu-trivial.
> 
> Negative, please keep qemu-trivial out of this. My qom-cpu pull was
> already blocked by the s390 and ppc pulls, so let's not add yet another
> potentially interfering one to the mix.
> 
> IF rth agrees as TCG maintainer that this is not needed in any of his
> upcoming refactorings then I'll queue it on qom-cpu. My upcoming
> qom-cpu-13 series touches upon pretty much every core CPU file
> perceivable, including this cputlb.c.

Sure.

> I also don't understand why qemu-trivial is suddenly picking up Stefan's
> arm translation patch, it used to be for unmaintained areas only. But
> arm is not my problem.

That patch is also not "trivial", too.

Paolo


Reply via email to