From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsIQ2-0008VT-RW for qemu-devel@nongnu.org; Fri, 30 Oct 2015 18:45:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZsIPx-0000nH-Sd for qemu-devel@nongnu.org; Fri, 30 Oct 2015 18:45:10 -0400 Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:34880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsIPx-0000ls-LL for qemu-devel@nongnu.org; Fri, 30 Oct 2015 18:45:05 -0400 Received: by lfbn126 with SMTP id n126so41227400lfb.2 for ; Fri, 30 Oct 2015 15:45:04 -0700 (PDT) References: From: Dmitry Osipenko Message-ID: <5633F2B3.2000406@gmail.com> Date: Sat, 31 Oct 2015 01:44:03 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v7 0/2] PTimer fix and ARM MPTimer conversion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Peter Crosthwaite , QEMU Developers 31.10.2015 00:52, Peter Maydell пишет: > On 24 October 2015 at 13:21, Dmitry Osipenko wrote: >> Changelog for ARM MPTimer QEMUTimer to ptimer conversion: >> >> V2: Fixed changing periodic timer counter value "on the fly". I added a >> test to the gist to cover that issue. >> >> V3: Fixed starting the timer with load = 0 and counter != 0, added tests >> to the gist for this issue. Changed vmstate version for all VMSD's, >> since loadvm doesn't check version of nested VMSD. >> >> V4: Fixed spurious IT bit set for the timer starting in the periodic mode >> with counter = 0. Test added. >> >> V5: Code cleanup, now depends on ptimer_set_limit() fix. >> >> V6: No code change, added test to check ptimer_get_count() with corrected >> .limit value. >> >> V7: No change. >> >> ARM MPTimer tests: https://gist.github.com/digetx/dbd46109503b1a91941a > > Hi. Given that we're now in the second half of softfreeze, and > the discussions about the design of the changes to ptimer don't > seem to have reached a conclusion yet, I would prefer to defer > this to 2.6. (It feels a bit late in the release cycle to make changes > to a core component like ptimer that affects multiple boards.) Sure, I have no objections. > My understanding is that although this patchset fixes a bunch of > edge cases and odd features in the mptimer, there aren't any bugs > that it fixes that cause problems for common guests like Linux, right? > Yes, it should be alright. -- Dmitry