From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MdRjG-0001ae-BP for qemu-devel@nongnu.org; Tue, 18 Aug 2009 12:40:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MdRjA-0001Zd-T9 for qemu-devel@nongnu.org; Tue, 18 Aug 2009 12:40:09 -0400 Received: from [199.232.76.173] (port=56580 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MdRjA-0001ZR-Hw for qemu-devel@nongnu.org; Tue, 18 Aug 2009 12:40:04 -0400 Received: from mx2.redhat.com ([66.187.237.31]:40376) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MdRjA-0001HR-2d for qemu-devel@nongnu.org; Tue, 18 Aug 2009 12:40:04 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7IGe3dv003925 for ; Tue, 18 Aug 2009 12:40:03 -0400 From: Juan Quintela In-Reply-To: <20090818160650.GA26422@1und1.de> ("Reimar =?utf-8?Q?D=C3=B6f?= =?utf-8?Q?finger=22's?= message of "Tue, 18 Aug 2009 18:06:50 +0200") Date: Tue, 18 Aug 2009 18:37:48 +0200 Message-ID: References: <20090818142405.GA16563@1und1.de> <20090818152112.GA5483@1und1.de> <20090818160650.GA26422@1und1.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH 5/5] Port apic to new VMState design List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Reply-to: quintela@redhat.com Reimar D=C3=B6ffinger wrote: > On Tue, Aug 18, 2009 at 05:38:57PM +0200, Juan Quintela wrote: >> Are your changes on upstream hw/eepro100.c? I can't see anything there >> that can't be done in a table approach. > > No, so far noone got around to taking my patches apart (and that is > actually one I have not yet properly submitted, it is mangled into that > patch: http://article.gmane.org/gmane.comp.emulators.qemu/49853 > >> >> It is already that way. This design don't change anything. And I am >> >> not sure how to fix it. We don't have a "is this value safe for this >> >> field", around yet. It is possible to add some support for it, but I >> >> would like to 1st have an use case. >> > >> > Well, I meant nowadays it is just possible to add a check in load_vm a= nd >> > fix any values that are off. While it is quite a bit of work there is >> > nothing in the API stopping you from doing it, you even can return >> > -EINVAL and hopefully the core will print some somewhat useful message. >>=20 >> I guess we are going to have an optional callback to be called >> before/after loading the state. You should be able to put your verify >> there. > > Maybe I'm silly, but what would the callback for before loading state be > good for? qemu-kvm has in-kernel apic and pit (at least). You just need to sync state with the kernel after loading (the other way for saving). >> > That is completely different from what I meant. >> > Changing the RAM compromises the VM and only the VM, an exploit in a >> > device emulation might allow to compromise the _host_. Is it now clear= er >> > what I meant? >>=20 >> yes, I see where you are meaning now. But I guess that one is needed to >> be solved, not only for migration. Not sure what to do about this. > > I think it is mostly leg-work of finding the assumptions the emulations > do. That really should be left to maintainers where available IMO. > I'm just suggesting that it's better to design the API in a way that > doesn't further discourage fixing this :-). > If the patch is close to being accepted maybe I can help out by writing > such verification code for vmware_vga, there e.g. depth, bypp, wred, > wgreen and wblue must fit together as well as > width/height/new_width/new_height and fb_size (I think) > and width/height/bypp must be limit to ensure no integer overflows... If you sent a patch, I will take a look. Later, Juan.