From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCQ3L-0007Cf-7C for qemu-devel@nongnu.org; Wed, 30 Jul 2014 05:20:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCQ3C-00028K-V0 for qemu-devel@nongnu.org; Wed, 30 Jul 2014 05:20:07 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:51601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCQ3C-00028C-Nf for qemu-devel@nongnu.org; Wed, 30 Jul 2014 05:19:58 -0400 Received: by mail-wg0-f43.google.com with SMTP id l18so847631wgh.26 for ; Wed, 30 Jul 2014 02:19:55 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53D8B8B6.7090209@redhat.com> Date: Wed, 30 Jul 2014 11:19:50 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20140717110153.8352.80175.stgit@PASHA-ISP> <20140717110233.8352.53806.stgit@PASHA-ISP> <53D61ED6.80508@redhat.com> <19697.8771281012$1406703748@news.gmane.org> In-Reply-To: <19697.8771281012$1406703748@news.gmane.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 06/49] serial: fixing vmstate for save/restore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgaluk , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, fred.konrad@greensocs.com Il 30/07/2014 09:01, Pavel Dovgaluk ha scritto: > >> -----Original Message----- >> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo Bonzini >> Sent: Monday, July 28, 2014 1:59 PM >> To: Pavel Dovgalyuk; qemu-devel@nongnu.org >> Cc: peter.maydell@linaro.org; peter.crosthwaite@xilinx.com; mark.burton@greensocs.com; >> real@ispras.ru; batuzovk@ispras.ru; fred.konrad@greensocs.com >> Subject: Re: [RFC PATCH v2 06/49] serial: fixing vmstate for save/restore >> >> Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto: >>> - .version_id = 3, >>> + .version_id = 4, >>> .minimum_version_id = 2, >>> .pre_save = serial_pre_save, >>> .post_load = serial_post_load, >>> .fields = (VMStateField[]) { >>> VMSTATE_UINT16_V(divider, SerialState, 2), >>> VMSTATE_UINT8(rbr, SerialState), >>> + VMSTATE_UINT8_V(thr, SerialState, 4), >>> + VMSTATE_UINT8_V(tsr, SerialState, 4), >>> VMSTATE_UINT8(ier, SerialState), >>> VMSTATE_UINT8(iir, SerialState), >>> VMSTATE_UINT8(lcr, SerialState), >>> @@ -613,6 +627,15 @@ const VMStateDescription vmstate_serial = { >>> VMSTATE_UINT8(msr, SerialState), >>> VMSTATE_UINT8(scr, SerialState), >>> VMSTATE_UINT8_V(fcr_vmstate, SerialState, 3), >>> + VMSTATE_INT32_V(thr_ipending, SerialState, 4), >> >> Subsection, only migrated if it doesn't match "(s->iir & UART_IIR_ID) == >> UART_IIR_THRI". > > thr_ipending is set here: > if (s->lsr & UART_LSR_THRE) { > s->lsr |= UART_LSR_TEMT; > s->thr_ipending = 1; > serial_update_irq(s); > } > > serial_update_irq has several if-else branches. One of them sets tmp_iir = UART_IIR_THRI, as you said. > Couldn't be possible, that this branch will not be reached, because one of the previous ones will be executed? Yes, what I wrote is equivalent to the following: int serial_pre_load(void *opaque) { SerialState *s = opaque; s->thr_ipending = -1; return 0; } int serial_post_load(void *opaque) { SerialState *s = opaque; ... if (s->thr_ipending == -1) { s->thr_ipending = ((s->iir & UART_IIR_ID) == UART_IIR_THRI); } ... } bool thr_ipending_needed(void *opaque) { SerialState *s = opaque; bool expected_value = ((s->iir & UART_IIR_ID) == UART_IIR_THRI); return s->thr_pending != expected_value; } The case you mention is exactly the one that will cause thr_ipending to be migrated. Paolo