From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EfL-0006Vb-Hx for qemu-devel@nongnu.org; Tue, 14 Jan 2014 19:49:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3EfF-0004Xk-DP for qemu-devel@nongnu.org; Tue, 14 Jan 2014 19:49:07 -0500 Received: from mail-pd0-f180.google.com ([209.85.192.180]:35447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EfF-0004Xb-7A for qemu-devel@nongnu.org; Tue, 14 Jan 2014 19:49:01 -0500 Received: by mail-pd0-f180.google.com with SMTP id q10so370538pdj.39 for ; Tue, 14 Jan 2014 16:48:59 -0800 (PST) Message-ID: <52D5DAF4.9050102@ozlabs.ru> Date: Wed, 15 Jan 2014 11:48:52 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1389288287.3209.231.camel@bling.home> <20140109180003.GA6819@redhat.com> <1389293278.3209.248.camel@bling.home> <1389294206.3209.249.camel@bling.home> <20140109215632.GB9385@redhat.com> <1389307342.3209.269.camel@bling.home> <20140110125504.GF10700@redhat.com> <1389367896.3209.291.camel@bling.home> <20140112075419.GB22644@redhat.com> <87ob3eaczl.fsf@pixel.localdomain> <20140114140530.GA28712@redhat.com> In-Reply-To: <20140114140530.GA28712@redhat.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 14/28] exec: make address spaces 64-bit wide List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Mike Day Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, agraf@suse.de, Luiz Capitulino , Alex Williamson , Paolo Bonzini , david@gibson.dropbear.id.au On 01/15/2014 01:05 AM, Michael S. Tsirkin wrote: > On Tue, Jan 14, 2014 at 08:50:54AM -0500, Mike Day wrote: >> >> "Michael S. Tsirkin" writes: >> >>> On Fri, Jan 10, 2014 at 08:31:36AM -0700, Alex Williamson wrote: >> >>> Short term, just assume 48 bits on x86. >>> >>> We need to figure out what's the limitation on ppc and arm - >>> maybe there's none and it can address full 64 bit range. >>> >>> Cc some people who might know about these platforms. >> >> The document you need is here: >> >> http://goo.gl/fJYxdN >> >> "PCI Bus Binding To: IEEE Std 1275-1994" >> >> The short answer is that Power (OpenFirmware-to-PCI) supports both MMIO >> and Memory mappings for BARs. >> >> Also, both 32-bit and 64-bit BARs are required to be supported. It is >> legal to construct a 64-bit BAR by masking all the high bits to >> zero. Presumably it would be OK to mask the 16 high bits to zero as >> well, constructing a 48-bit address. >> >> Mike >> >> -- >> Mike Day | "Endurance is a Virtue" > > The question was whether addresses such as > 0xfffffffffec00000 can be a valid BAR value on these > platforms, whether it's accessible to the CPU and > to other PCI devices. On ppc64, the guest address is limited by 60 bits (2Alex: even PA from HPT has the same limit) but there is no actual limit for PCI bus addresses. The actual hardware has some (less than 60 bits but close) limits but since we do not emulate any real PHB in qemu-spapr and do para-virtualization, we do not have to put limits there and BARs like 0xfffffffffec00000 should be allowed (but we do not really expect them to be as big though). -- Alexey