qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jason J. Herne" <jjherne@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"qemu-devel@nongnu.org qemu-devel" <qemu-devel@nongnu.org>,
	Bhushan Bharat-R65777 <R65777@freescale.com>
Subject: Re: [Qemu-devel] [PATCH 7/7] KVM regsync: Fix do_kvm_cpu_synchronize_state data integrity issue
Date: Mon, 07 Jan 2013 10:43:02 -0500	[thread overview]
Message-ID: <50EAED06.5050501@linux.vnet.ibm.com> (raw)
In-Reply-To: <E86C860D-E5B6-4A6C-B421-B4725E495180@suse.de>

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.
>

How do we want to define these bits?  is it logical to break up the 
registers into smaller categories and then use masks to create 
RUNTIME_STATE, FULL_STATE, RESET_STATE?  If so, how should we define 
them?  Would they be arch specific and then we'd create the _STATE masks 
for each architecture?

If we do simply define a bit for each of the above three states instead, 
they should probably be 100% mutually exclusive to provide the best 
protection against complicated data synchronization issues (like the 
original 7/7 patch was trying to prevent).  Also, if we can assume 100% 
mutual exclusion the sync logic becomes trivial:

static void do_kvm_cpu_synchronize_state(void *arg)
{
     struct kvm_cpu_syncstate_args *args = arg;

     /* Do not sync regs that are already dirty */
     int regs_to_get = args->regmap & ~cpu->kvm_vcpu_dirty;

     kvm_arch_get_registers(args->cpu, regs_to_get);
     args->cpu->kvm_vcpu_dirty |= regs_to_get;
}

Thoughts?



-- 
-- Jason J. Herne (jjherne@linux.vnet.ibm.com)

  parent reply	other threads:[~2013-01-07 15:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 13:56 [Qemu-devel] [PATCH 7/7] KVM regsync: Fix do_kvm_cpu_synchronize_state data integrity issue Jason J. Herne
2013-01-03 13:56 ` Alexander Graf
2013-01-03 18:48   ` Jason J. Herne
2013-01-03 19:09     ` Alexander Graf
2013-01-04  1:38       ` Marcelo Tosatti
2013-01-04  4:22         ` Bhushan Bharat-R65777
2013-01-04  8:40           ` Alexander Graf
2013-01-04  8:57             ` Bhushan Bharat-R65777
2013-01-04  9:01               ` Alexander Graf
2013-01-04 10:23             ` Bhushan Bharat-R65777
2013-01-04 10:29               ` Alexander Graf
2013-01-04 10:32                 ` Bhushan Bharat-R65777
2013-01-04 10:36                   ` Alexander Graf
2013-01-04 11:01                     ` Bhushan Bharat-R65777
2013-01-04 11:03                       ` Alexander Graf
2013-01-04 15:25                         ` Jason J. Herne
2013-01-04 16:27                           ` Alexander Graf
2013-01-04 17:39                             ` Jason J. Herne
2013-01-06 14:43                               ` Bhushan Bharat-R65777
2013-01-07 15:43                             ` Jason J. Herne [this message]
2013-01-07 15:49                               ` Alexander Graf
2013-01-07 18:19                                 ` Jason J. Herne
2013-01-07 18:42                                   ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50EAED06.5050501@linux.vnet.ibm.com \
    --to=jjherne@linux.vnet.ibm.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).