From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrBFc-0005xA-G6 for qemu-devel@nongnu.org; Fri, 04 Jan 2013 12:40:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrBFb-0000YR-9x for qemu-devel@nongnu.org; Fri, 04 Jan 2013 12:40:12 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:41689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrBFb-0000Il-39 for qemu-devel@nongnu.org; Fri, 04 Jan 2013 12:40:11 -0500 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Jan 2013 10:40:00 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 153681FF0027 for ; Fri, 4 Jan 2013 10:39:46 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r04Hdsd8039142 for ; Fri, 4 Jan 2013 10:39:54 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r04HdonO031270 for ; Fri, 4 Jan 2013 10:39:50 -0700 Message-ID: <50E713E5.6070500@linux.vnet.ibm.com> Date: Fri, 04 Jan 2013 12:39:49 -0500 From: "Jason J. Herne" MIME-Version: 1.0 References: <1356098191-4998-1-git-send-email-jjherne@us.ibm.com> <133FEF92-3C4F-48C8-BF67-E50066EEEF45@suse.de> <50E5D29B.6060804@linux.vnet.ibm.com> <20130104013812.GB23746@amt.cnet> <6A3DF150A5B70D4F9B66A25E3F7C888D06542905@039-SN2MPN1-022.039d.mgd.msft.net> <292DDE3D-7B6F-400E-954B-49CA3E284FDB@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D06542EA8@039-SN2MPN1-022.039d.mgd.msft.net> <6A3DF150A5B70D4F9B66A25E3F7C888D06542EF7@039-SN2MPN1-022.039d.mgd.msft.net> <9B2CB541-8806-4BDF-A523-FD597BDFA08B@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D06542FCA@039-SN2MPN1-022.039d.mgd.msft.net> <6501413C-7526-42DB-8824-C0638F59985A@suse.de> <50E6F479.4090002@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 7/7] KVM regsync: Fix do_kvm_cpu_synchronize_state data integrity issue Reply-To: jjherne@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Christian Borntraeger , Anthony Liguori , Marcelo Tosatti , "qemu-devel@nongnu.org qemu-devel" , Bhushan Bharat-R65777 On 01/04/2013 11:27 AM, Alexander Graf wrote: > > On 04.01.2013, at 16:25, Jason J. Herne wrote: > >> If I've followed the conversation correctly this is what needs to be done: >> >> 1. Remove the level parameters from kvm_arch_get_registers and kvm_arch_put_registers. >> >> 2. Add a new bitmap parameter to kvm_arch_get_registers and kvm_arch_put_registers. > > I would combine these into "replace levels with bitmap". > >> 3. Define a bit that correlates to our current notion of "all runtime registers". This bit, and all bits in this bitmap, would be architecture specific. > > Why would that bit be architecture specific? "All runtime registers" == "registers that gdb can access" IIRC. The implementation on what exactly that means obviously is architecture specific, but the bit itself would not be, as the gdbstub wants to be able to synchronize in arch independent code. > >> 4. Remove the cpustate->kvm_sync_dirty field. Replace it with a bitmap that tracks which bits are dirty and need to be synced back to KVM-land. >> >> 5. As we do today, we'll assume registers are dirty and turn on their corresponding bit in this new bitmap whenever we "get" the registers from KVM. > > Yes. Changing these semantics is nothing for today :). > >> 6. Add other bits as needed on a case by case basis. >> >> Does this seem to match what was discussed, and what we want to do? > > It's probably the best way forward, keeping everyone happy. > > Please coordinate with Bharat on who actually wants to sit down to implement this. Or if you're quick you might be able to beat him to it regardless thanks to time zones :). > Hi Bharat, How would you like to handle these changes? I can do them, or you could if you prefer. Please let me know. -- -- Jason J. Herne (jjherne@linux.vnet.ibm.com)