From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScBtJ-0004Jk-1V for qemu-devel@nongnu.org; Wed, 06 Jun 2012 04:47:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScBtG-0008Vl-Sy for qemu-devel@nongnu.org; Wed, 06 Jun 2012 04:46:56 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:51674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScBtG-0008Uq-Mg for qemu-devel@nongnu.org; Wed, 06 Jun 2012 04:46:54 -0400 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Jun 2012 02:46:50 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 728E219D8048 for ; Wed, 6 Jun 2012 08:46:17 +0000 (WET) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q568jqfx210828 for ; Wed, 6 Jun 2012 02:46:02 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q568ja8r030531 for ; Wed, 6 Jun 2012 02:45:37 -0600 Message-ID: <4FCF18AC.3080005@us.ibm.com> Date: Wed, 06 Jun 2012 16:45:32 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <1338858018-17189-1-git-send-email-mdroth@linux.vnet.ibm.com> <1338858018-17189-2-git-send-email-mdroth@linux.vnet.ibm.com> <4FCDDA12.4040907@redhat.com> <4FCE9B88.2080908@us.ibm.com> <4FCF0AA0.5090105@redhat.com> <4FCF148E.8000104@us.ibm.com> <4FCF16BB.9010804@redhat.com> In-Reply-To: <4FCF16BB.9010804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: yamahata@valinux.co.jp, quintela@redhat.com, Michael Roth , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com, akong@redhat.com, afaerber@suse.de On 06/06/2012 04:37 PM, Avi Kivity wrote: > On 06/06/2012 11:27 AM, Anthony Liguori wrote: >> On 06/06/2012 03:45 PM, Avi Kivity wrote: >> >> I think you meant to add a const in there, but yeah, I know. > > Maybe also a _stupid. How can one get a one line example wrong by > omitting the important word out of five? For the same reason so few people actually write 'Type * const' in C, it's an incredibly awkward syntax :-/ >>> But I wasn't referring to that at all. >>> Instead, some state is simply not relevant to the guest view, even >>> though it is state. We don't have a lot of that since most host state >>> is behind nice interfaces, but think of a vga device that keeps track of >>> the host window size and alt-ctrl status. Those are not guest state and >>> need not be migrated. >> >> Both the host window size and alt-ctrl status are not device state. >> They are host backend state and they ought to be stored in a different >> data structure. This is exactly how we do it (both things are stored in >> sdl.c or vnc.c). >> >> If we're storing mutable host state in a device structure, that's a bug >> IMHO. That's sort of the premise of the QIDL annotations at least. > > Ok. But then the backend pointer is not 'const Backend * const', it's > 'Backend * const' (if we don't allow retargeting). So we can't say it's > _immutable (and it isn't). It's _host. 'Backend * const' is immutable That is, the *pointer* is immutable. What it points to is not. If you want to '#define _host _immutable' as a way to improve readability, I'm not against that. But from a conceptional perspective, we don't migrate it because nothing the guest does changes it. It's immutable from the guests PoV. >>>> In the case of a CharDriverState, the reference is always immutable. If >>>> we supported changing char backends dynamically, it would not happen by >>>> changing the reference, but almost certainly by having the ability to >>>> reopen the char driver in place. IOW, while the referenced object >>>> changes, the reference doesn't change. >>> >>> In either case, state changes. The reason we don't send it over is >>> because it's not guest state, not because we reopen in place or not (and >>> migration shouldn't depend on how we choose to implement changing >>> chardev backends -- reopen or delete/new). >> >> Well the goal is here not to support any possible way of separating >> guest state and host state. The goal is here is to be very opinionated >> about how we separate guest and host state such that we can take a >> rigorous approach to migrating guest state. >> >> I think we're actually pretty good today about separating host and guest >> state. I can't think of an example within devices where we don't >> cleanly separate things outside of block devices. > > And I agree that if we find such an example we should unexample it > quickly. But you still have a pointer (or even object) in there that is > not immutable. Why not mark it clearly instead of saying "well, the > important bits in it are immutable, we don't care about the rest"? If your argument is, we can improve readability by further classifying immutable things into why their immutable, I'm with you :-) Regards, Anthony Liguori >