From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZM9mc-00016O-Fk for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:03:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZM9mZ-0000ft-65 for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:03:38 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:54840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZM9mZ-0000V3-1U for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:03:35 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NSH00M6EVLU7J90@mailout2.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 03 Aug 2015 08:03:30 +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: Mon, 03 Aug 2015 10:03:28 +0300 Message-id: <00b601d0cdba$808e3980$81aaac80$@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' Hi! I have done an additional study... > (1) We should confirm whether this really is a guest kernel > bug (as opposed to the device tree QEMU emits not being > in spec) > (2) If it is a kernel bug, submit a patch to fix it It is a bug, but not major bug. The bug is only that the kernel tries = to map the device anyway, despite it takes wrong, truncated physical = addresses. But, if we fix it, then the only option for the kernel is not = to try to use this device at all. Because, in general case, this would = mean that the device is outside of usable address space, and we cannot = access it, therefore cannot drive it properly. Therefore, the non-LPAE-enabled kernel will not be able to use PCI = controller with high MMIO anyway. > (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). The behavior which i explained above causes boot problems if our = configuration assumes that we boot off emulated PCI device. Because PCI = controller becomes unusable. Therefore, if we want to stay compatible = with such guests (which would be indeed old), we need an option which = allows to turn off high MMIO region. Now the question is: what do we want as default on 32-bit virt? On 64 = bits the default would be obviously "ON", what about 32 bits? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia