From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLM7C-0001uY-Dd for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:02:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLM78-0001sv-NY for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:02:06 -0400 Received: from [199.232.76.173] (port=51970 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLM78-0001so-Hj for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:02:02 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]:56147) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLM77-0000aq-BF for qemu-devel@nongnu.org; Mon, 29 Jun 2009 15:02:01 -0400 Received: by pzk15 with SMTP id 15so2257542pzk.4 for ; Mon, 29 Jun 2009 12:02:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A490A62.5030101@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> <2a50f7880906290907m60bda19cy53a58c97fd014c73@mail.gmail.com> <4A48F5B5.4000002@redhat.com> <4A490A62.5030101@codemonkey.ws> Date: Mon, 29 Jun 2009 12:02:00 -0700 Message-ID: <2a50f7880906291202s6b33cfcdi8aada9de383a3219@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Implement PC port80 debug register. From: Jordan Justen Content-Type: multipart/alternative; boundary=000e0cd3108a2d2569046d81536d 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 --000e0cd3108a2d2569046d81536d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony, 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 did implement and test the savevm/loadvm functionality. -Jordan On Mon, Jun 29, 2009 at 11:39 AM, 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. > > Regards, > > Anthony Liguori > > --000e0cd3108a2d2569046d81536d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony,

I= f there's read and write access, it needs to be part of the savevm state. =A0Is it per-cpu? =A0If it's write only, then it doesn't nee= d to be persisted in savevm.

I did implement and test the savevm/loadvm functionality.

-Jorda= n

On Mon, Jun 29, 2009 at 11:39 AM, Antho= ny Liguori <a= nthony@codemonkey.ws> 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.

Regards,

Anthony Liguori


--000e0cd3108a2d2569046d81536d--