qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Glauber Costa" <glommer@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 5/6] Introduce kvm logging interface.
Date: Wed, 19 Nov 2008 15:23:36 -0200	[thread overview]
Message-ID: <5d6222a80811190923o1e83d188kfb258a676811d9c5@mail.gmail.com> (raw)
In-Reply-To: <49242E53.6000802@codemonkey.ws>

On Wed, Nov 19, 2008 at 1:18 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Glauber Costa wrote:
>>
>> Introduce functions to stop and start logging of memory regions.
>> We select region based on its start address.
>>
>> Signed-off-by: Glauber Costa <glommer@redhat.com>
>> ---
>>  kvm-all.c |  153
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  kvm.h     |    5 ++
>>  2 files changed, 158 insertions(+), 0 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 9700e50..c522205 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -32,8 +32,13 @@
>>     do { } while (0)
>>  #endif
>>  +#define warning(fmt, ...) \
>> +    do { dprintf("%s:%d" fmt, __func__, __LINE__, ## __VA_ARGS__); }
>> while (0)
>>
>
> I don't think this macro really serves a purpose.  You can just add "%s:%d:
> " to the beginning of dprintf() if you want.

Are you okay with all dprintfs having these info? This is very
valuable info, so I'd
like to have it. I  can send a separate patch.

>>
>
> Note that start and stop are identical except for a different printf().  The
> call a common helper function.  Why not fold everything into
> kvm_dirty_pages_log_change() and make that the public interface
> (kvm_set_log).

I personally believe kvm_set_log is a very bad interface. It's nicer
to read "start"
and "stop" instead, but I can definitely do this internally.

>
>> +static inline int lookup_bitmap_phys(unsigned long *dirty, unsigned nr)
>> +{
>> +    unsigned word = nr / (sizeof(*dirty) * 8);
>> +    unsigned bit = nr % (sizeof(*dirty) * 8);
>> +    int ret;
>> +
>> +    ret = (dirty[word] >> bit) & 1;
>> +    return ret;
>> +}
>> +
>> +/**
>> + * kvm_physical_sync_dirty_bitmap - Grab dirty bitmap from kernel space
>> + * If a phys_offset parameter is given, this function updates qemu's
>> dirty
>> + * bitmap using cpu_physical_memory_set_dirty(). This means all bits are
>> set
>> + * to dirty.
>> + *
>> + * @start_add: start of logged region. This is what we use to search the
>> memslot
>> + * @end_addr: end of logged region. Only matters if we are updating qemu
>> dirty bitmap.
>> + * @phys_offset: the phys_offset we want to use for qemu dirty bitmap
>> update. Passing
>> + *               NULL makes the update not happen. In this case, we only
>> grab the bitmap
>> + *               from kernel.
>> + */
>> +void kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
>> target_phys_addr_t end_addr,
>> +                                    ram_addr_t phys_offset)
>>
>
> This interface is weird and broken.  If we wanted to use this for live
> migration, we would end up passing phys_offset=0 but that has a special
> meaning here.
>
> But why are we passing phys_offset at all?  Why can't we do the lookup here?
Because, if you remember, the last time I sent a patch _without_ it,
you complained
that we can't really trust any translation based on userspace_addr.
Which is fine,
because it is fundamentally broken long term.

So, we need to be specific about what area are we writting the dirty bitmap too.
If the zero is the problem, we can have the interface to always write
to the given location,
and disregard 0 as a special meaning field.


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

  reply	other threads:[~2008-11-19 17:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 15:26 [Qemu-devel] [PATCH 0/6] New shot at VGA optimization Glauber Costa
2008-11-19 14:23 ` Avi Kivity
2008-11-19 14:34   ` Glauber Costa
2008-11-19 15:26 ` [Qemu-devel] [PATCH 1/6] kvm: memory aliasing support for kvm Glauber Costa
2008-11-19 15:07   ` Anthony Liguori
2008-11-19 15:26   ` [Qemu-devel] [PATCH 2/6] better type checking for vga Glauber Costa
2008-11-19 15:08     ` Anthony Liguori
2008-11-19 15:26     ` [Qemu-devel] [PATCH 3/6] move vga_io_address to VGA State Glauber Costa
2008-11-19 15:26       ` [Qemu-devel] [PATCH 4/6] kvm: de-register mem region for MMIO Glauber Costa
2008-11-19 15:10         ` Anthony Liguori
2008-11-19 15:26         ` [Qemu-devel] [PATCH 5/6] Introduce kvm logging interface Glauber Costa
2008-11-19 15:18           ` Anthony Liguori
2008-11-19 17:23             ` Glauber Costa [this message]
2008-11-19 17:51               ` Anthony Liguori
2008-11-19 15:26           ` [Qemu-devel] [PATCH 6/6] kvm: vga optimization Glauber Costa
2008-11-19 15:23             ` Anthony Liguori
2008-11-19 17:19               ` Glauber Costa
2008-11-19 17:26                 ` Anthony Liguori

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=5d6222a80811190923o1e83d188kfb258a676811d9c5@mail.gmail.com \
    --to=glommer@gmail.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).