All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Avi Kivity <avi@redhat.com>,
	Ian.Jackson@eu.citrix.com, kvm@vger.kernel.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Qemu-devel] Re: [PATCH 5/5] cache slot lookup
Date: Thu, 18 Dec 2008 11:00:14 +0000	[thread overview]
Message-ID: <20081218110014.GI23277@redhat.com> (raw)
In-Reply-To: <20081218104850.GB19123@poweredge.glommer>

On Thu, Dec 18, 2008 at 08:48:50AM -0200, Glauber Costa wrote:
> On Thu, Dec 18, 2008 at 11:41:24AM +0200, Avi Kivity wrote:
> > Glauber Costa wrote:
> >> record slot used in last lookup. For the common mmio case,
> >> we'll usually access the same memory slot repeatedly.
> >>   
> >
> >> --- a/kvm-all.c
> >> +++ b/kvm-all.c
> >> @@ -75,16 +75,25 @@ static KVMSlot *kvm_alloc_slot(KVMState *s)
> >>      return NULL;
> >>  }
> >>  +static KVMSlot *last_slot = NULL;
> >> +
> >>  static KVMSlot *kvm_lookup_slot(KVMState *s, target_phys_addr_t start_addr)
> >>  {
> >>      int i;
> >>  +
> >> +    if (last_slot && (start_addr >= last_slot->start_addr &&
> >> +            start_addr < (last_slot->start_addr + last_slot->memory_size)))
> >> +        return last_slot;
> >> +
> >>      for (i = 0; i < ARRAY_SIZE(s->slots); i++) {
> >>          KVMSlot *mem = &s->slots[i];
> >>           if (start_addr >= mem->start_addr &&
> >> -            start_addr < (mem->start_addr + mem->memory_size))
> >> +            start_addr < (mem->start_addr + mem->memory_size)) {
> >> +            last_slot = mem;
> >>              return mem;
> >> +        }
> >>      }
> >>  
> >
> > This wasn't introduced by this patch, but the comparison is broken ion  
> > i386 hosts, where target_phys_addr_t is 32 bits wide.  mem->start_addr +  
> > mem->memory_size can overflow (this in fact happens for the bios slot at  
> > 4G-128K)
>
> AFAIK, the assumption is that kvm will always be qemu-system-x86_64, due to
> migration issues. Then, _target_ phys_addr_t is always 64 bit wide.
> If it's not the case, then this is really a problem.

Migration compatability is a problem for mgmt apps to solve & merely
saying to use qemu-system-x86_64 everywhere is a tiny insignificant 
piece of the problem. AFAIK, current Fedora packages build a 32-bit 
'qemu' for KVM on i386  and a qemu-system-x86_64' for x86_64, which
happens to be called 'qemu-kvm' on both, to avoid clash with the base
QEMU binary names.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Ian.Jackson@eu.citrix.com, Avi Kivity <avi@redhat.com>,
	kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Qemu-devel] Re: [PATCH 5/5] cache slot lookup
Date: Thu, 18 Dec 2008 11:00:14 +0000	[thread overview]
Message-ID: <20081218110014.GI23277@redhat.com> (raw)
In-Reply-To: <20081218104850.GB19123@poweredge.glommer>

On Thu, Dec 18, 2008 at 08:48:50AM -0200, Glauber Costa wrote:
> On Thu, Dec 18, 2008 at 11:41:24AM +0200, Avi Kivity wrote:
> > Glauber Costa wrote:
> >> record slot used in last lookup. For the common mmio case,
> >> we'll usually access the same memory slot repeatedly.
> >>   
> >
> >> --- a/kvm-all.c
> >> +++ b/kvm-all.c
> >> @@ -75,16 +75,25 @@ static KVMSlot *kvm_alloc_slot(KVMState *s)
> >>      return NULL;
> >>  }
> >>  +static KVMSlot *last_slot = NULL;
> >> +
> >>  static KVMSlot *kvm_lookup_slot(KVMState *s, target_phys_addr_t start_addr)
> >>  {
> >>      int i;
> >>  +
> >> +    if (last_slot && (start_addr >= last_slot->start_addr &&
> >> +            start_addr < (last_slot->start_addr + last_slot->memory_size)))
> >> +        return last_slot;
> >> +
> >>      for (i = 0; i < ARRAY_SIZE(s->slots); i++) {
> >>          KVMSlot *mem = &s->slots[i];
> >>           if (start_addr >= mem->start_addr &&
> >> -            start_addr < (mem->start_addr + mem->memory_size))
> >> +            start_addr < (mem->start_addr + mem->memory_size)) {
> >> +            last_slot = mem;
> >>              return mem;
> >> +        }
> >>      }
> >>  
> >
> > This wasn't introduced by this patch, but the comparison is broken ion  
> > i386 hosts, where target_phys_addr_t is 32 bits wide.  mem->start_addr +  
> > mem->memory_size can overflow (this in fact happens for the bios slot at  
> > 4G-128K)
>
> AFAIK, the assumption is that kvm will always be qemu-system-x86_64, due to
> migration issues. Then, _target_ phys_addr_t is always 64 bit wide.
> If it's not the case, then this is really a problem.

Migration compatability is a problem for mgmt apps to solve & merely
saying to use qemu-system-x86_64 everywhere is a tiny insignificant 
piece of the problem. AFAIK, current Fedora packages build a 32-bit 
'qemu' for KVM on i386  and a qemu-system-x86_64' for x86_64, which
happens to be called 'qemu-kvm' on both, to avoid clash with the base
QEMU binary names.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2008-12-18 11:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 20:46 [PATCH 0/5] Replace tcg memory functions Glauber Costa
2008-12-17 20:46 ` [Qemu-devel] " Glauber Costa
2008-12-17 20:46 ` [PATCH 1/5] re-register whole area upon lfb unmap Glauber Costa
2008-12-17 20:46   ` [Qemu-devel] " Glauber Costa
2008-12-17 20:46   ` [PATCH 2/5] isolate io handling routing Glauber Costa
2008-12-17 20:46     ` [Qemu-devel] " Glauber Costa
2008-12-17 20:47     ` [PATCH 3/5] replace cpu_physical_memory_rw Glauber Costa
2008-12-17 20:47       ` [Qemu-devel] " Glauber Costa
2008-12-17 20:47       ` [PATCH 4/5] hook cpu_register_physical_mem Glauber Costa
2008-12-17 20:47         ` [Qemu-devel] " Glauber Costa
2008-12-17 20:47         ` [PATCH 5/5] cache slot lookup Glauber Costa
2008-12-17 20:47           ` [Qemu-devel] " Glauber Costa
2008-12-18  9:41           ` Avi Kivity
2008-12-18  9:41             ` [Qemu-devel] " Avi Kivity
2008-12-18 10:48             ` Glauber Costa
2008-12-18 10:48               ` [Qemu-devel] " Glauber Costa
2008-12-18 11:00               ` Daniel P. Berrange [this message]
2008-12-18 11:00                 ` Daniel P. Berrange
2008-12-18 11:07                 ` Glauber Costa
2008-12-18 11:24               ` Avi Kivity
2008-12-18 11:24                 ` [Qemu-devel] " Avi Kivity
2008-12-17 20:56       ` [PATCH 3/5] replace cpu_physical_memory_rw Anthony Liguori
2008-12-17 20:56         ` [Qemu-devel] " Anthony Liguori
2008-12-17 21:00         ` Glauber Costa
2008-12-17 21:00           ` [Qemu-devel] " Glauber Costa
2008-12-17 20:54     ` [PATCH 2/5] isolate io handling routing Anthony Liguori
2008-12-17 20:54       ` [Qemu-devel] " Anthony Liguori
2008-12-17 20:53   ` [PATCH 1/5] re-register whole area upon lfb unmap Anthony Liguori
2008-12-17 20:53     ` [Qemu-devel] " Anthony Liguori
2008-12-25 20:08     ` andrzej zaborowski
2008-12-25 20:08       ` andrzej zaborowski
2008-12-22 17:10 ` [Qemu-devel] [PATCH 0/5] Replace tcg memory functions Ian Jackson
2008-12-22 17:18   ` Glauber Costa
2008-12-22 17:18     ` Glauber Costa
2008-12-22 17:22     ` Ian Jackson
2008-12-22 17:22       ` Ian Jackson

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=20081218110014.GI23277@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --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 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.