From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sc1uN-0007nc-6y for qemu-devel@nongnu.org; Tue, 05 Jun 2012 18:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sc1uL-0001hX-5v for qemu-devel@nongnu.org; Tue, 05 Jun 2012 18:07:22 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:42057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sc1uK-0001hK-Tn for qemu-devel@nongnu.org; Tue, 05 Jun 2012 18:07:21 -0400 Received: by pbbro12 with SMTP id ro12so8719316pbb.4 for ; Tue, 05 Jun 2012 15:07:19 -0700 (PDT) Sender: fluxion Date: Tue, 5 Jun 2012 17:07:12 -0500 From: Michael Roth Message-ID: <20120605220712.GO2916@illuin> References: <1338858018-17189-1-git-send-email-mdroth@linux.vnet.ibm.com> <1338858018-17189-10-git-send-email-mdroth@linux.vnet.ibm.com> <4FCDDE98.50604@redhat.com> <4FCDE209.3070608@siemens.com> <4FCDFEB6.8070307@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCDFEB6.8070307@redhat.com> Subject: Re: [Qemu-devel] [PATCH 09/17] rtc: add qc annotations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, quintela@redhat.com, Jan Kiszka , owasserm@redhat.com, qemu-devel@nongnu.org, yamahata@valinux.co.jp, pbonzini@redhat.com, akong@redhat.com, afaerber@suse.de On Tue, Jun 05, 2012 at 03:42:30PM +0300, Avi Kivity wrote: > On 06/05/2012 01:40 PM, Jan Kiszka wrote: > > On 2012-06-05 12:25, Avi Kivity wrote: > >> On 06/05/2012 04:00 AM, Michael Roth wrote: > >>> Add our annotations according to QIDL documentation. > >>> > >>> +qc_declaration typedef struct RTCState { > >>> + ISADevice _immutable dev; > >>> + MemoryRegion _immutable io; > >>> uint8_t cmos_data[128]; > >>> uint8_t cmos_index; > >>> struct tm current_tm; > >>> int32_t base_year; > >>> - qemu_irq irq; > >>> - qemu_irq sqw_irq; > >>> - int it_shift; > >>> + qemu_irq _immutable irq; > >>> + qemu_irq _immutable sqw_irq; > >> > >> How is qemu_irq immutable? We're raising and lowering it many times a > >> second. It's _derived, perhaps, but not immutable. > > > > No, IRQState in its current form is immutable, doesn't contain any > > volatile state. > > Good point. So it's just like any pointer: it depends on the pointed-to > type. If it saves its state, then great, but if the pointed-to type > doesn't, then it's broken. > > > > >> > >>> + int32_t _immutable it_shift; > >>> /* periodic timer */ > >>> QEMUTimer *periodic_timer; > >>> int64_t next_periodic_time; > >>> /* second update */ > >>> int64_t next_second_time; > >>> - uint16_t irq_reinject_on_ack_count; > >>> + uint16_t _derived irq_reinject_on_ack_count; > >> > >> It's not derived from anything. It's _host, maybe. > > > > I think it is _broken. Agreed, using _derived was an error on my part > > I think it's _complicated. Migration involves downtime and so lost > ticks. In the case of RTC we probably need to trigger compensation code > that will try to handle it according to policy. We'd likely only be able to compensate based on calculated downtime or something along that line. I think we'd still want to send accumulated ticks as well, even if it's of little importance, since it's still guest state of a sort (in the sense that it guest-perceivable) that we should avoid discarding. > > >>> + LostTickPolicy _immutable lost_tick_policy; > >> > >> _host; nothign prevents us from changing it dynamically in theory. > > > > _host makes no sense to me. Either it is _immutable or _broken - or is > > properly saved/restored. What should be the semantic of _host? > > An emulated device manages some state, and also talks to a host device, > often through an interface like BlockDriverState or CharState. _host is > anything related to the host device that we should be able to > reconstruct on resume. > > Example of host state is a CharDriverState filename. Even if we allow > it to change, there is no point in migrating it since it belongs to the > source namespace, not destination. > > -- > error compiling committee.c: too many arguments to function >