From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLJOJ-0001oS-Sn for qemu-devel@nongnu.org; Mon, 29 Jun 2009 12:07:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLJOE-0001jG-Sp for qemu-devel@nongnu.org; Mon, 29 Jun 2009 12:07:35 -0400 Received: from [199.232.76.173] (port=39333 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLJOE-0001ik-IN for qemu-devel@nongnu.org; Mon, 29 Jun 2009 12:07:30 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]:35128) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLJOD-0006GJ-P1 for qemu-devel@nongnu.org; Mon, 29 Jun 2009 12:07:30 -0400 Received: by pzk15 with SMTP id 15so2189760pzk.4 for ; Mon, 29 Jun 2009 09:07:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A48DE4A.7090706@codemonkey.ws> 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> Date: Mon, 29 Jun 2009 09:07:28 -0700 Message-ID: <2a50f7880906290907m60bda19cy53a58c97fd014c73@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Implement PC port80 debug register. From: Jordan Justen Content-Type: multipart/alternative; boundary=000e0cd3108a06939c046d7ee336 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Avi Kivity , qemu-devel@nongnu.org --000e0cd3108a06939c046d7ee336 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony, That seems like a reasonable request. So, a 'info port80' command would be preferable to having i/o port 0x80 be read/write? 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. -Jordan On Mon, Jun 29, 2009 at 8:31 AM, Anthony Liguori wrote: > Jordan Justen wrote: > >> Avi, >> >> Well, I am not sure if this it globally the case for PC motherboards, but >> in my experience, it has been read/write. >> >> At least for a system such as qemu, it make it difficult to use the port80 >> checkpoint of software without being able to read the last value written. >> > > It seems like the more logical thing to do is to save the port80 write and > have it obtainable via the monitor. > > But really, we have other debug mechanisms for BIOSes (like ports 50x/40x). > That seems like a better thing to use if you're writing custom code for > QEMU. > > Regards, > > Anthony Liguori > > --000e0cd3108a06939c046d7ee336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony,

That seems like a reasonable request.

So, a 'inf= o port80' command would be preferable to having i/o port 0x80 be read/w= rite?

I still think the read/write port route would
* better emul= ate 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 ma= ke the data accessible somehow.=A0 So, the monitor access method would work= fine as well.

-Jordan

On Mon, Jun 29, 2009 at 8:31 = AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
Jordan Justen wrote:
Avi,

Well, I am not sure if this it globally the case for PC motherboards, but i= n my experience, it has been read/write.

At least for a system such as qemu, it make it difficult to use the port80 = checkpoint of software without being able to read the last value written.

It seems like the more logical thing to do is to save the port80 write and = have it obtainable via the monitor.

But really, we have other debug mechanisms for BIOSes (like ports 50x/40x).= =A0That seems like a better thing to use if you're writing custom code= for QEMU.

Regards,

Anthony Liguori


--000e0cd3108a06939c046d7ee336--