From: Anthony Liguori <aliguori@us.ibm.com>
To: Glauber Costa <glommer@redhat.com>
Cc: qemu-devel@nongnu.org,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] vga optmization
Date: Tue, 04 Nov 2008 14:40:47 -0600 [thread overview]
Message-ID: <4910B34F.8000608@us.ibm.com> (raw)
In-Reply-To: <20081104202846.GB27481@poweredge.glommer>
Glauber Costa wrote:
> diff --git a/exec.c b/exec.c
> index ef1072b..2ed5e2b 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1823,6 +1823,17 @@ int cpu_physical_memory_get_dirty_tracking(void)
> return in_migration;
> }
>
> +void qemu_physical_sync_dirty_bitmap(ram_addr_t start_addr, ram_addr_t end_addr)
> +{
> + if (kvm_enabled()) {
> + ram_addr_t addr;
> + kvm_physical_sync_dirty_bitmap(start_addr);
> + for (addr = start_addr; addr < end_addr; addr += TARGET_PAGE_SIZE)
> + phys_ram_dirty[addr >> TARGET_PAGE_BITS] |= kvm_physical_memory_get_dirty(addr);
Might as well push this into kvm-all.c so that this becomes:
if (kvm_enabled())
kvm_physical_sync_dirty_bitmap(start_addr, end_addr);
And this very likely will become a hook one day.
And I think the function should be renamed to
cpu_physical_memory_update_dirty() to be more in line with the rest of
the functions.
>
> + }
> +}
> +
> static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
> {
> ram_addr_t ram_addr;
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index af9c9e6..bc1a3af 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -31,6 +31,7 @@
> #include "pci.h"
> #include "console.h"
> #include "vga_int.h"
> +#include "kvm.h"
>
> /*
> * TODO:
> @@ -248,6 +249,9 @@ typedef struct CirrusVGAState {
> int cirrus_linear_io_addr;
> int cirrus_linear_bitblt_io_addr;
> int cirrus_mmio_io_addr;
> + uint32_t cirrus_lfb_addr;
> + uint32_t cirrus_lfb_end;
> + uint32_t cirrus_lfb_mapped;
> uint32_t cirrus_addr_mask;
> uint32_t linear_mmio_mask;
> uint8_t cirrus_shadow_gr0;
> @@ -2618,6 +2622,69 @@ static CPUWriteMemoryFunc *cirrus_linear_bitblt_write[3] = {
> cirrus_linear_bitblt_writel,
> };
>
> +static void set_vram_mapping(target_phys_addr_t begin, target_phys_addr_t end, ram_addr_t target)
> +{
> + /* align begin and end address */
> + begin = begin & TARGET_PAGE_MASK;
> + end = begin + VGA_RAM_SIZE;
> + end = (end + TARGET_PAGE_SIZE -1 ) & TARGET_PAGE_MASK;
> +
> + cpu_register_physical_memory(begin, end - begin, target);
> +
> + if (kvm_enabled()) {
> + /* XXX: per-slot dirty tracking in qemu may get rid of it */
> + kvm_log_start(begin, end - begin);
>
I feel confident that we can get rid of this. We just need a good
suggestion.
> + }
> +}
> +
> +static void unset_vram_mapping(target_phys_addr_t begin, target_phys_addr_t end)
> +{
> + /* align begin and end address */
> + end = begin + VGA_RAM_SIZE;
> + begin = begin & TARGET_PAGE_MASK;
> + end = (end + TARGET_PAGE_SIZE -1 ) & TARGET_PAGE_MASK;
> +
> + if (kvm_enabled()) {
> + /* XXX: per-slot dirty tracking in qemu may get rid of it */
> + kvm_log_stop(begin, end - begin);
> + }
> + cpu_register_physical_memory(begin, end - begin, IO_MEM_UNASSIGNED);
>
This is a little odd. We only ever toggle the vram mapping from normal
IO_RAM to MMIO. We should never switch it to IO_MEM_UNASSIGNED.
> +int kvm_log_stop(target_phys_addr_t phys_addr, target_phys_addr_t len)
> +{
> +
> + KVMState *s = kvm_state;
> + KVMSlot *mem = kvm_lookup_slot(s, phys_addr);
> +
> + if (mem == NULL) {
> + fprintf(stderr, "BUG: %s: invalid parameters\n", __func__);
> + return -EINVAL;
> + }
> + dprintf("slot %d: disabling logging\n", mem->region.slot);
> +
> + if (mem->logging_count--)
> + return 0;
> +
> + return kvm_dirty_pages_log_change(mem,
> + 0,
> + KVM_MEM_LOG_DIRTY_PAGES);
> +}
> +
> +#define BITMAP_WORD(mem) (sizeof(*(mem)->dirty_bitmap) * 8)
>
this doesn't need to be a macro.
Can you split this patch up a bit? At least one patch containing the
KVM slot changes. Also split out the cirrus verse standard VGA
changes. I think if you switch things around to get rid of
kvm_physical_get_dirty(), you'll find you can malloc the memory for the
dirty bitmap at the time of sync() which should significantly reduce
your overall complexity.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2008-11-04 20:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 17:31 [Qemu-devel] vga optmization Glauber Costa
2008-11-03 17:43 ` Stefano Stabellini
2008-11-03 17:52 ` Glauber Costa
2008-11-03 18:06 ` Stefano Stabellini
2008-11-03 18:03 ` Blue Swirl
2008-11-03 18:14 ` Glauber Costa
2008-11-03 18:41 ` Blue Swirl
2008-11-03 18:47 ` Glauber Costa
2008-11-03 18:13 ` Fabrice Bellard
2008-11-03 18:18 ` Glauber Costa
2008-11-04 7:23 ` Avi Kivity
2008-11-04 9:31 ` andrzej zaborowski
2008-11-04 11:40 ` Stefano Stabellini
2008-11-04 13:43 ` Glauber Costa
2008-11-04 14:51 ` Avi Kivity
2008-11-04 14:52 ` Anthony Liguori
2008-11-04 14:55 ` Glauber Costa
2008-11-04 15:13 ` Stefano Stabellini
2008-11-04 20:42 ` Avi Kivity
2008-11-04 20:51 ` Anthony Liguori
2008-11-04 15:01 ` Stefano Stabellini
2008-11-04 20:28 ` Glauber Costa
2008-11-04 20:40 ` Anthony Liguori [this message]
2008-11-05 14:42 ` Stefano Stabellini
2008-11-07 11:15 ` Glauber Costa
2008-11-07 11:33 ` Stefano Stabellini
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=4910B34F.8000608@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=glommer@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
/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).