All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, Juan Quintela <quintela@trasno.org>,
	kvm-devel <kvm@vger.kernel.org>
Subject: Re: [PATCH 09/10] Exit loop if we have been there too long
Date: Wed, 01 Dec 2010 14:40:12 +0200	[thread overview]
Message-ID: <4CF6422C.3030308@redhat.com> (raw)
In-Reply-To: <4CF50F2C.7090503@codemonkey.ws>

On 11/30/2010 04:50 PM, Anthony Liguori wrote:
>> That's what the patch set I was alluding to did.  Or maybe I imagined 
>> the whole thing.
>
>
> No, it just split the main bitmap into three bitmaps.  I'm suggesting 
> that we have the dirty interface have two implementations, one that 
> refers to the 8-bit bitmap when TCG in use and another one that uses 
> the KVM representation.
>
> TCG really needs multiple dirty bits but KVM doesn't.  A shared 
> implementation really can't be optimal.

Live migration and the framebuffer can certainly share code with kvm and 
tcg:

- tcg or kvm maintain an internal bitmap (kvm in the kernel, tcg updates 
a private bitmap)
- a dirty log client wants to see an updated bitmap; migration on a new 
pass, vga on screen refresh
    - ask the producer (kvm or tcg) to fetch-and-clear a dirty bitmap
    - broadcast it ( |= ) into any active clients (migration or framebuffer)
- everyone's happy

The code dirty thing might need special treatment, we can have a special 
tcg-only bitmap for it.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-12-01 12:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1290552026.git.quintela@redhat.com>
     [not found] ` <9b23b9b4cee242591bdb356c838a9cfb9af033c1.1290552026.git.quintela@redhat.com>
     [not found]   ` <4CF45D67.5010906@codemonkey.ws>
     [not found]     ` <4CF4A478.8080209@redhat.com>
2010-11-30 13:47       ` [PATCH 09/10] Exit loop if we have been there too long Anthony Liguori
2010-11-30 13:58         ` Avi Kivity
2010-11-30 14:17           ` Anthony Liguori
2010-11-30 14:27             ` Avi Kivity
2010-11-30 14:50               ` Anthony Liguori
2010-12-01 12:40                 ` Avi Kivity [this message]
2010-11-30 17:43               ` Juan Quintela
2010-12-01  1:20               ` Takuya Yoshikawa
2010-12-01  1:52                 ` Juan Quintela
2010-12-01  2:22                   ` Takuya Yoshikawa
2010-12-01 12:35                   ` Avi Kivity
2010-12-01 13:45                     ` Juan Quintela
2010-12-02  1:31                     ` Takuya Yoshikawa
2010-12-02  8:37                       ` Avi Kivity
2010-11-30 14:12         ` Paolo Bonzini
2010-11-30 15:00           ` Anthony Liguori
2010-11-30 17:59             ` Juan Quintela

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=4CF6422C.3030308@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=quintela@trasno.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.