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
