From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Venqb-0007f7-Mb for qemu-devel@nongnu.org; Fri, 08 Nov 2013 10:19:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VenqV-0001fa-IZ for qemu-devel@nongnu.org; Fri, 08 Nov 2013 10:19:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VenqV-0001eW-2L for qemu-devel@nongnu.org; Fri, 08 Nov 2013 10:19:39 -0500 Message-ID: <1383923800.2527.95.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Fri, 08 Nov 2013 17:16:40 +0200 In-Reply-To: References: <1383511723-11228-1-git-send-email-marcel.a@redhat.com> <527C023F.2060506@redhat.com> <1383859470.2527.64.camel@localhost.localdomain> <527C06B5.2020401@redhat.com> <1383860314.2527.72.camel@localhost.localdomain> <527C9B4C.9000405@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Michael S. Tsirkin" , Jan Kiszka , "edk2-devel@lists.sourceforge.net" , qemu-devel , Jordan Justen , Anthony Liguori , Paolo Bonzini , Laszlo Ersek , afaerber , Richard Henderson On Fri, 2013-11-08 at 10:44 +0000, Peter Maydell wrote: > On 8 November 2013 08:05, Paolo Bonzini wrote: > > Il 07/11/2013 22:51, Peter Maydell ha scritto: > >>> > 1. Not all architectures have the behavior: "Address space that is not RAM(and friends) > >>> > is for sure PCI". Only x86 behaves like this (I think). > >> > >> More specifically, the x86 pc behaves like this. Other > >> x86 based systems could in theory behave differently > >> (not that we actually model any, I think). > > > > After Marcel's patch, we have changed behavior for at least all boards > > that pass get_system_memory() to pci_register_bus or pci_bus_new: > > > > * mips/gt64xxx_pci.c > > > > * pci-host/bonito.c > > > > * pci-host/ppce500.c > > > > * ppc/ppc4xx_pci.c > > > > * sh4/sh_pci.c > > Oh, right. Ideally those boards should not do that (I fixed > the versatile pci controller not to do that a while back) but > it's a long standing behaviour so it would be better had we > not broken it. > > I think it should in general be fixable by just having those > pci controllers create an empty memory region to pass in, > like versatile: > > memory_region_init(&s->pci_io_space, OBJECT(s), "pci_io", 1ULL << 32); > memory_region_init(&s->pci_mem_space, OBJECT(s), "pci_mem", 1ULL << 32); > > pci_bus_new_inplace(&s->pci_bus, sizeof(s->pci_bus), DEVICE(obj), "pci", > &s->pci_mem_space, &s->pci_io_space, > PCI_DEVFN(11, 0), TYPE_PCI_BUS); > > That doesn't affect where PCI DMA goes. It might also > require mapping an alias into that region at wherever > the pci hole is on those boards. > > Kind of awkward to do and test at this point in the release cycle though. > > > These now will not go anymore through unassigned_mem_ops, which is a > > behavioral change for MIPS boards (gt64xxx_pci and bonito) at least. > > > > Furthermore, the default behavior of the memory API _is_ read > > all-ones/ignore writes, so I'm not sure what's the benefit of adding a > > separate region for master abort... > > It gives you a place set the appropriate PCI controller or device > register status bits on abort by a PCI device access, IIRC. Right, thanks for pointing this out. This was indeed the patches direction. But even the first patch has meaning by itself and not just a preparation. As I mentioned in other mail in this thread "read all-ones/ignore writes" is not implemented yet asbeacuse unassigned_mem_ops has no read/write methods and valid.accepts returns false. Thanks, Marcel > > -- PMM >