From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1D7XP1-0001c2-9I
	for qemu-devel@nongnu.org; Sat, 05 Mar 2005 06:24:59 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1D7XKY-0000pb-2u
	for qemu-devel@nongnu.org; Sat, 05 Mar 2005 06:20:29 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1D7XJT-0000ZL-NA
	for qemu-devel@nongnu.org; Sat, 05 Mar 2005 06:19:17 -0500
Received: from [213.165.64.20] (helo=mail.gmx.net)
	by monty-python.gnu.org with smtp (Exim 4.34) id 1D7WlQ-0006zP-Ha
	for qemu-devel@nongnu.org; Sat, 05 Mar 2005 05:44:04 -0500
Message-ID: <42298D70.7010706@gmx.de>
Date: Sat, 05 Mar 2005 11:44:00 +0100
From: Oliver Gerlich <olig9@gmx.de>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Qemu Guest Tools
References: <BAY104-F12FB13568D81B8DB5ACCDABC5D0@phx.gbl>
In-Reply-To: <BAY104-F12FB13568D81B8DB5ACCDABC5D0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Nathan Kunkee schrieb:

> Another way to fix this, and the next concern on vm save/load, is to 
> develop an APM or ACPI device. There is a standard interface between 
> the hardware and the OS, almost all OS's now support a version of APM 
> or ACPI, and the OS knows to reinitialize various parts of the 
> hardware after certain events. This would simplify the question of 
> special instructions or unused IO port. In a way, it would allow the 
> emulator to be treated like a laptop, where the user can tell it to 
> suspend or sleep, and when to wake up again. Since the OS has a driver 
> for APM, it would be aware of these events, reinitialize devices (RTC, 
> NIC), and Qemu would not be responsible for as many internal details.
>
> My humble $0.02 on the issue....
> Nathan

ACPI support in Qemu would be nice; but loadvm is useful for those guest 
OSes that don't support ACPI or sleep states. So in my opinion loadvm 
should not be replaced by ACPI, but it should be usable in those cases 
where ACPI or sleep states are not available (eg. Win9x, DOS).

Oliver