From xen-devel-bounces@lists.xen.org Thu Sep 26 21:13:10 2013 Received: (at maildrop) by bugs.xenproject.org; 26 Sep 2013 20:13:10 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VPHvy-0005V9-IU for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 26 Sep 2013 21:13:10 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPHso-0005MZ-Fr; Thu, 26 Sep 2013 20:09:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPHsm-0005MM-M1 for xen-devel@lists.xen.org; Thu, 26 Sep 2013 20:09:52 +0000 Received: from [85.158.139.211:65251] by server-16.bemta-5.messagelabs.com id 6A/AB-03533-F8494425; Thu, 26 Sep 2013 20:09:51 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-206.messagelabs.com!1380226190!4872399!1 X-Originating-IP: [62.142.5.108] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA4ID0+IDk1NzA3\n X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12745 invoked from network); 26 Sep 2013 20:09:51 -0000 Received: from emh02.mail.saunalahti.fi (HELO emh02.mail.saunalahti.fi) (62.142.5.108) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2013 20:09:51 -0000 Received: from ydin.reaktio.net (reaktio.net [85.76.255.15]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 69EB581817; Thu, 26 Sep 2013 23:09:49 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 1D4A136C0A0; Thu, 26 Sep 2013 23:09:49 +0300 (EEST) Date: Thu, 26 Sep 2013 23:09:49 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Stefano Stabellini Message-ID: <20130926200948.GP2924@reaktio.net> References: <513739DD.8050507@eu.citrix.com> <513868F0.6020104@eu.citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Hanweidong , George Dunlap , "xudong.hao@intel.com" , Yanqiangjun , Luonengjun , Wangzhenguo , Yangxiaowei , "Gonglei \(Arei\)" , Anthony Perard , "xen-devel@lists.xen.org" , "xiantao.zhang@intel.com" Subject: Re: [Xen-devel] GPU passthrough issue when VM is configured with 4G memory / Xen 4.4 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello, George: I think this one is missing from the Xen 4.4 status emails? (see below) On Wed, May 29, 2013 at 05:18:24PM +0100, Stefano Stabellini wrote: > > Thank you very much for your detailed analysis of the problem. > > After reading this, I wonder how is possible that qemu-xen-traditional > does not have this issue, considering that AFAIK there is no way for > hvmloader to tell qemu-xen-traditional where the PCI hole starts. > > The only difference between upstream QEMU and qemu-xen-traditional is > that the former would start the PCI hole at 0xf0000000 while the latter > would start the PCI hole at 0xe0000000. > > So I would expect that your test, where hvmloader is updating the PCI > hole region to start at 0x80000000, would fail on qemu-xen-traditional > too. > > Of course having the PCI hole starting unconditionally at 0xf0000000 > makes it much easier to run into problems than starting it at > 0xe0000000. > > > Assuming that everything above is correct, this is what I would do: > > 1) modify upstream QEMU to start the PCI hole at 0xe0000000, to match > qemu-xen-unstable in terms of configuration and not to introduce any > regressions. Do this for the Xen 4.3 release. > > 2) for Xen 4.4 rework the two patches above and improve > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not > enough, it also needs to be able to resize the system memory region > (xen.ram) to make room for the bigger pci_hole I think this second part hasn't been done/fixed yet? Feel free to correct me if it has been done already :) Thanks, -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel