From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3UfJ-0008Uy-1T for qemu-devel@nongnu.org; Thu, 29 Oct 2009 09:03:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3UfE-0008Tx-0L for qemu-devel@nongnu.org; Thu, 29 Oct 2009 09:03:44 -0400 Received: from [199.232.76.173] (port=56916 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3UfD-0008Tu-Mf for qemu-devel@nongnu.org; Thu, 29 Oct 2009 09:03:39 -0400 Received: from fg-out-1718.google.com ([72.14.220.158]:42427) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3UfD-0007Bm-4V for qemu-devel@nongnu.org; Thu, 29 Oct 2009 09:03:39 -0400 Received: by fg-out-1718.google.com with SMTP id 16so2140489fgg.10 for ; Thu, 29 Oct 2009 06:03:38 -0700 (PDT) Message-ID: <4AE99312.4020902@gmail.com> Date: Thu, 29 Oct 2009 14:05:22 +0100 From: =?ISO-8859-1?Q?M=E0rius_Mont=F3n?= MIME-Version: 1.0 References: <4ADED9A0.3000605@gmail.com> <4AE70C35.6050909@gmail.com> <20091027151640.GH5526@csclub.uwaterloo.ca> <4AE97CBA.80600@gmail.com> <20091029121221.GA3478@redhat.com> In-Reply-To: <20091029121221.GA3478@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] Re: PCI address question List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org Michael S. Tsirkin wrote: > On Thu, Oct 29, 2009 at 12:30:02PM +0100, Màrius Montón wrote: > >> Lennart Sorensen wrote: >> >> On Tue, Oct 27, 2009 at 04:05:25PM +0100, Màrius Montón wrote: >> >> >> Màrius Montón wrote: >> >> >> Hello, >> >> For my PCI device to QEMU, I need the real address the PCI bus is using >> to access my device. For a IO BAR (PCI_ADDRESS_SPACE_IO), I receive the >> real address (like 0xc200 or similar), but when registering a >> PCI_ADDRESS_SPACE_MEM I only receive the offset to the BAR. >> >> How I can receive or obtaint the real address on each access to my device? >> >> Cjeers, >> >> Màrius >> >> >> >> nobody can tell me anything? :( >> >> >> Add the offset to the address in the bar? >> >> The problem is how to know what bar is accessing in case I have only one >> function for all BARs. >> > > I expect that's unusual: different BARs usually have different > functionality. Just implement different functions and pass > calls on to a shared helper? > > It is because I'm trying to add PCI devices from a configuration file (no hot-plug), and this way was the easies way I found... any idea? >> After all the OS is allowed to change your BAR if it wants to. >> So internally the only thing that makes sense to a PCI device is the >> offset from it's base address. >> >> You listen to addresses at your IO range, and at your memory BAR range. >> What you do when you see a request for your range then depends on the >> offset that address had from the current base. This would also be true >> for the IO. >> >> I know all PCI internals, but I don't understand why for IO I receive all >> address and only the offset for MEM BARs (or I'm wrong?) >> >> Màrius >> > > PCI only calls a map method. I think this gets a 32 bit address, not BAR offset: > > r->addr = new_addr; > if (r->addr != -1) { > r->map_func(d, i, r->addr, r->size, r->type); > } > > > I may study that functions Màrius