From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKRvr-0005zV-Pa for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:02:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKRvl-0001uB-DR for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:02:07 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:35009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKRvl-0001tF-7n for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:02:01 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NS900KBL5N7OP80@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 29 Jul 2015 15:01:55 +0100 (BST) From: Pavel Fedin References: <015a01d0c85c$b52b61d0$1f822570$@samsung.com> <20150727152658.3f3740f7@nial.brq.redhat.com> <00da01d0c9dc$b39503e0$1abf0ba0$@samsung.com> <00f401d0c9e3$517efba0$f47cf2e0$@samsung.com> <015b01d0c9f0$0981cd20$1c856760$@samsung.com> In-reply-to: Date: Wed, 29 Jul 2015 17:01:53 +0300 Message-id: <01b701d0ca07$208eb6b0$61ac2410$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Peter Maydell' Cc: 'Igor Mammedov' , 'Alexander Graf' , "'Michael S. Tsirkin'" , 'QEMU Developers' , 'Paolo Bonzini' Hello! I have studied the problem. It is a kernel bug and it's still = not fixed, at least in 4.1 > (1) We should confirm whether this really is a guest kernel > bug (as opposed to the device tree QEMU emits not being > in spec) The problem is in of_pci_range_to_resource(): = http://lxr.free-electrons.com/source/drivers/of/address.c#L313 Note the line 333: res->start =3D range->cpu_addr; here is the problem. = The problem occurs if CONFIG_ARM_LPAE is disabled. Inside struct = resource 'start' and 'end' are of resource_size_t type, which is an = alias of phys_addr_t: --- cut --- #ifdef CONFIG_PHYS_ADDR_T_64BIT typedef u64 phys_addr_t; #else typedef u32 phys_addr_t; #endif typedef phys_addr_t resource_size_t; --- cut --- Config option chain is as follows: CONFIG_ARM_LPAE =3D> = CONFIG_ARCH_PHYS_ADDR_T_64BIT =3D> CONFIG_PHYS_ADDR_T_64BIT This function should check that range->cpu_addr fits into 32 bits if = LPAE is disabled. > (2) If it is a kernel bug, submit a patch to fix it Will do it. > (3) Consider a workaround for older guests anyway. The > scope of that workaround would depend on exactly which > guests are affected, which is presumably something we > figured out during step (1). Problem occurs if LPAE is disabled in the kernel. What is your verdict = then? Do we need an option or just ignore those poor guys with such old = configs? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia