From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang2 Subject: Re: [PATCH] passthru: Fix pci bar remapping for =?iso-8859-1?q?passthru=09devices?= Date: Mon, 20 Jul 2009 18:29:42 +0200 Message-ID: <200907201829.42618.wei.wang2@amd.com> References: <200907201603.56725.wei.wang2@amd.com> <200907201647.09059.wei.wang2@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jiang, Yunhong" Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Hi Yunhong Thanks for the comment. Regarding the reason of guest hang, my guess is: gu= est=20 OS might be trying to access guest memory at "0xfe000000" after remapping=20 this address to mmio and guest memory may be corrupted after this access.=20 =46or devices with large mmio, the complement code of mmio block size is mo= re=20 likely to be a real guest RAM. I saw the same issue when I assigned a graph= ic=20 device with 256MB mmio to Linux guest. But devices with small mmio seems to= =20 work well. I did not see the problem on a broadcom NIC with 64K mmio. Thanks, Wei On Monday 20 July 2009 17:48:46 Jiang, Yunhong wrote: > Wei Wang2 wrote: > > Hi Yunhong > > My testing shows that Linux guests will try to probe pci bar with > > MMIO being enabled. When I assign a broadcom NIC with 32MB MMIO a > > Linux guest, guest will hang after remapping a guest address > > Yes, I remember I saw this bug in kernel before. > > I suspect the issue here is the local APIC address, which should not be > intercepted before MMIO/RAM address in native. i.e. the p2m table should > not cover the local APIC address as RAM, but I think your change in the > qemu side is more straightforward (otherwise, we may need consider IOAPIC, > HPET etc, which is complex). > > One thing left is, why it will hang, after all, guest will try to restore > the BAR address later, and at that time, the local apic access can be > intercepted again. > > --jyh > > > "0xfe000000" to physical mmio. However, windows and BSD guests do not > > have this issue. They alway probe mmio size after disabling mmio. > > Thanks, > > Wei > > > > On Monday 20 July 2009 16:26:00 Jiang, Yunhong wrote: > >> I assume guest should disable the MMIO in PCI_COMMAND before writing > >> all "1"s to bar register. Otherwise, what will happen on native if > >> guest try to access 0xFFFFFFF0? And if we do update the P2M, will it > >> cause trouble to Xen HV? > >> > >> Thanks > >> Yunhong Jiang > >> > >> xen-devel-bounces@lists.xensource.com wrote: > >>> Hi, > >>> When guest code tries to get the block size of mmio, it will write > >>> all "1"s into pci bar register and then qemu will return all "0"s > >>> to the don't care bits in the emulated bar register to indicate the > >>> block size > >>> to guest code. > >>> In this case, we should not create p2m mapping in > >>> pt_bar_reg_write() and > >>> pt_exp_rom_bar_reg_write(). Attached patch fixes this issue, > >>> additional comment can be found in the patch. > >>> > >>> Thanks, > >>> Wei > >>> > >>> Signed-off-by: Wei Wang > >>> -- > >>> AMD GmbH, Germany > >>> Operating System Research Center > >>> > >>> Legal Information: > >>> Advanced Micro Devices GmbH > >>> Karl-Hammerschmidt-Str. 34 > >>> 85609 Dornach b. M=FCnchen > >>> > >>> Gesch=E4ftsf=FChrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni > >>> Sitz: Dornach, Gemeinde Aschheim, Landkreis M=FCnchen > >>> Registergericht M=FCnchen, HRB Nr. 43632