From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdcVI-0001z3-Ep for qemu-devel@nongnu.org; Tue, 05 Nov 2013 04:01:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdcV9-0001AP-TU for qemu-devel@nongnu.org; Tue, 05 Nov 2013 04:00:52 -0500 Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:44693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdcV9-00019a-Hk for qemu-devel@nongnu.org; Tue, 05 Nov 2013 04:00:43 -0500 Received: by mail-ee0-f52.google.com with SMTP id e49so1658156eek.11 for ; Tue, 05 Nov 2013 01:00:42 -0800 (PST) Sender: Paolo Bonzini Message-ID: <5278B3B8.5000105@redhat.com> Date: Tue, 05 Nov 2013 10:00:40 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1380300560-21086-1-git-send-email-akong@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] extend limit of physical sections number List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Amos Kong , QEMU Developers , Anthony Liguori Il 05/11/2013 01:36, Peter Maydell ha scritto: > On 27 September 2013 17:49, Amos Kong wrote: >> # qemu -drive file=/disk0,if=none,id=v0,format=qcow2 \ >> -device virtio-blk-pci,drive=v0,id=v00,multifunction=on,addr=0x04.0 >> .... >> >> Launching guest with more than 32 virtio-blk disks, >> qemu will crash, because there are too many BARs. >> >> This patch brings the limit of non-tcg up by a factor >> of 8 (32767 / 4096), i.e. 32*8 = 256. >> >> Signed-off-by: Paolo Bonzini >> Signed-off-by: Amos Kong >> --- >> exec.c | 17 ++++++++++++----- >> 1 file changed, 12 insertions(+), 5 deletions(-) >> >> diff --git a/exec.c b/exec.c >> index 5aef833..f639c01 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -763,11 +763,18 @@ void phys_mem_set_alloc(void *(*alloc)(ram_addr_t)) >> >> static uint16_t phys_section_add(MemoryRegionSection *section) >> { >> - /* The physical section number is ORed with a page-aligned >> - * pointer to produce the iotlb entries. Thus it should >> - * never overflow into the page-aligned value. >> - */ >> - assert(next_map.sections_nb < TARGET_PAGE_SIZE); >> + if (tcg_enabled()) { >> + /* The physical section number is ORed with a page-aligned >> + * pointer to produce the iotlb entries. Thus it should >> + * never overflow into the page-aligned value. >> + */ >> + assert(next_map.sections_nb < TARGET_PAGE_SIZE); >> + } else { >> + /* For KVM or Xen we can use the full range of the ptr field >> + * in PhysPageEntry. >> + */ >> + assert(next_map.sections_nb < SHRT_MAX); >> + } > > This looks really weird. Why should the memory subsystem > care whether we're using TCG or KVM or Xen? Because only TCG stores the section number in the low bits of the iotlb entry. This is exactly what is explained in the comments. Paolo