From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLLlb-0004Ow-9x for qemu-devel@nongnu.org; Mon, 29 Jun 2009 14:39:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLLlW-0004MI-S1 for qemu-devel@nongnu.org; Mon, 29 Jun 2009 14:39:46 -0400 Received: from [199.232.76.173] (port=44601 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLLlW-0004MF-Na for qemu-devel@nongnu.org; Mon, 29 Jun 2009 14:39:42 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:36659) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLLlW-00056A-Aj for qemu-devel@nongnu.org; Mon, 29 Jun 2009 14:39:42 -0400 Received: by ewy7 with SMTP id 7so5047099ewy.34 for ; Mon, 29 Jun 2009 11:39:38 -0700 (PDT) Message-ID: <4A490A62.5030101@codemonkey.ws> Date: Mon, 29 Jun 2009 13:39:30 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Implement PC port80 debug register. References: <1246262725-23825-1-git-send-email-jljusten@gmail.com> <4A48C5F5.6030402@codemonkey.ws> <4A48CE67.9070705@redhat.com> <2a50f7880906290826t4128b11dyc68a36fd01e8208c@mail.gmail.com> <4A48DE4A.7090706@codemonkey.ws> <2a50f7880906290907m60bda19cy53a58c97fd014c73@mail.gmail.com> <4A48F5B5.4000002@redhat.com> In-Reply-To: <4A48F5B5.4000002@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jordan Justen , qemu-devel@nongnu.org Avi Kivity wrote: >> I still think the read/write port route would >> * better emulate systems, >> * be more flexible (allowing software the option to read it), >> * and, be easier to implement :) >> >> But, I think the most important part is to make the data accessible >> somehow. So, the monitor access method would work fine as well. > > I don't object to read/write access. If there's read and write access, it needs to be part of the savevm state. Is it per-cpu? If it's write only, then it doesn't need to be persisted in savevm. I'd lean toward write-only unless there was a compelling reason to make it read/write. Regards, Anthony Liguori