On 27 September 2013 17:49, Amos Kong <ak...@redhat.com> 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 <pbonz...@redhat.com>
> Signed-off-by: Amos Kong <ak...@redhat.com>
> ---
> 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?
-- PMM
