From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKqAa-0001Bg-86 for qemu-devel@nongnu.org; Sun, 07 Oct 2012 08:41:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKqAZ-00042u-8w for qemu-devel@nongnu.org; Sun, 07 Oct 2012 08:41:20 -0400 Message-ID: <50717869.7000802@redhat.com> Date: Sun, 07 Oct 2012 14:41:13 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1349265000-23834-1-git-send-email-Bharat.Bhushan@freescale.com> <1349265000-23834-3-git-send-email-Bharat.Bhushan@freescale.com> <506D81B3.2040401@redhat.com> <6A3DF150A5B70D4F9B66A25E3F7C888D064B2BBD@039-SN2MPN1-022.039d.mgd.msft.net> <506DA3FA.2080404@redhat.com> <6A3DF150A5B70D4F9B66A25E3F7C888D064B30CC@039-SN2MPN1-022.039d.mgd.msft.net> <391CE0AF-0853-4EA5-9983-A9F0AC316C71@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D064B410A@039-SN2MPN1-022.039d.mgd.msft.net> <50715002.4010408@redhat.com> <8E204265-B301-49D0-A89F-E074829E9422@suse.de> In-Reply-To: <8E204265-B301-49D0-A89F-E074829E9422@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" , Bhushan Bharat-R65777 On 10/07/2012 01:57 PM, Alexander Graf wrote: > > > On 07.10.2012, at 11:48, Avi Kivity wrote: > >> On 10/05/2012 01:59 PM, Alexander Graf wrote: >>>>>> Do you mean that we add the "MemoryRegion bar0" in PCIDevice struct. Do the >>>>> same thing that I was doing in e500_pcihost_initfn() in the k->init() (will add >>>>> this) function of "e500-host-bridge" >>>>> >>>>> No, he means that you create a new struct like this: >>>>> >>>>> struct foo { >>>>> PCIDevice p; >>>>> MemoryRegion bar0; >>>>> }; >>>>> >>>>> Please check out any other random PCI device in QEMU. Almost all of them do this >>>>> to store more information than their parent class can hold. >>>> >>>> Just want to be sure I understood you correctly: Do you mean something like this : ( I know I have to switch to QOM mechanism to share parameters) >>>> >>>> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c >>>> index 92b1dc0..a948bc6 100644 >>>> --- a/hw/ppce500_pci.c >>>> +++ b/hw/ppce500_pci.c >>>> @@ -89,6 +89,12 @@ struct PPCE500PCIState { >>>> MemoryRegion iomem; >>>> }; >>>> >>>> +struct BHARAT { >>>> + PCIDevice p; >>>> + void *bar0; >>> >>> MemoryRegion *bar0 >> >> MemoryRegion bar0; > > Why? We want the same region that is mapped outside of the pci device be available as BAR0 too. A MemoryRegion can only have one container. If you want dual maps, use memory_region_init_alias(). It is possible (not trivial though) to extend the memory API to support m:n container:subregion relationships. I don't think it's worthwhile though. -- error compiling committee.c: too many arguments to function