From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLMCP-0003Q7-La for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:07:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLMCL-0003Og-1u for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:07:29 -0400 Received: from [199.232.76.173] (port=40033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLMCK-0003OS-TF for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:07:24 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]:59866) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLMCK-00028q-B4 for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:07:24 -0400 Received: by pzk15 with SMTP id 15so2259468pzk.4 for ; Mon, 29 Jun 2009 12:07:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <59F78767-705A-4A65-BE35-F7B22BB8CA2E@suse.de> 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> <4A490A62.5030101@codemonkey.ws> <59F78767-705A-4A65-BE35-F7B22BB8CA2E@suse.de> Date: Mon, 29 Jun 2009 12:00:09 -0700 Message-ID: <2a50f7880906291200m53ceea1ctecc1df0ac6010c06@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Implement PC port80 debug register. From: Jordan Justen Content-Type: multipart/alternative; boundary=00504502c91f8d5674046d814cab List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Avi Kivity , qemu-devel@nongnu.org --00504502c91f8d5674046d814cab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alex, Well it was write-only before, so I don't see any harm in keeping it that > way. Or am I mistaken there? > As I noted, I have seen it be read/write on real systems. But, for qemu it was previously write-only and ignored. -Jordan On Mon, Jun 29, 2009 at 11:46 AM, Alexander Graf wrote: > > On 29.06.2009, at 20:39, Anthony Liguori wrote: > > 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. >> > > Well it was write-only before, so I don't see any harm in keeping it that > way. Or am I mistaken there? > > Alex > > --00504502c91f8d5674046d814cab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

Well it was write-only before, so I don't see any harm in keeping it th= at way. Or am I mistaken there?

As I noted, I have seen it be read/write on real systems.=A0 But, for q= emu it was previously write-only and ignored.

-Jordan

On Mon, Jun 29, 2009 at 11:46 AM, Alexander Graf <agraf@suse.de> wrote:
<= div class=3D"h5">
On 29.06.2009, at 20:39, Anthony Liguori wrote:

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= . =A0So, 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 sta= te. =A0Is it per-cpu? =A0If it's write only, then it doesn't need t= o be persisted in savevm.

I'd lean toward write-only unless there was a compelling reason to make= it read/write.

Well it was write-only before, so I don't see any harm in keeping it th= at way. Or am I mistaken there?

Alex


--00504502c91f8d5674046d814cab--