From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Bug: Limitation of <=2GB RAM in domU persists with 4.3.0 Date: Mon, 29 Jul 2013 14:04:31 -0400 Message-ID: <20130729180431.GQ5848@phenom.dumpdata.com> References: <2aa84a31b7b17c2ea6d8483a281ad3f5@mail.shatteredsilicon.net> <20130724160639.GB5804@phenom.dumpdata.com> <8426aecf79e7f55c21bbe259014591a2@mail.shatteredsilicon.net> <20130724163102.GA6308@phenom.dumpdata.com> <51F051F1.5050806@bobich.net> <51F19D11.1090200@bobich.net> <51F1A54D.6070906@bobich.net> <1374798084.10269.2.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Gordan Bobic Cc: George Dunlap , Andrew Cooper , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > So, my question is: > 1) If vBAR = pBAR, does the hypervisor still do any translation? > I presume it does because it expects the traffic to pass up > from the root bridge, to the hypervisor and then back, to > ensure security. If indeed it does do this, where could I > optionally disable it, and is there an easy to follow bit of > example code for how to plumb in a boot parameter option for > this? It should. > > 2) Further, I'm finding myself motivated to write that > auto-set (as opposed to hard coded) vBAR=pBAR patch discussed > briefly a week or so ago (have an init script read the BAR > info from dom0 and put it in xenstore, plus a patch to > make pBAR=vBAR reservations built dynamically rather than > statically, based on this data. Now, I'm quite fluent in C, > but my familiarity with Xen soruce code is nearly non-existant > (limited to studying an old unsupported patch every now and then > in order to make it apply to a more recent code release). > Can anyone help me out with a high level view WRT where > this would be best plumbed in (which files and the flow of > control between the affected files)? hvmloader probably and the libxl e820 code. What from a high view needs to happen is that: 1). Need to relax the check in libxl for e820_hole to also do it for HVM guests. Said code just iterates over the host E820 and sanitizes it a bit and makes a E820 hypercall to set it for the guest. 2). Figure out whether the E820 hypercall (which sets the E820 layout for a guest) can be run on HVM guests. I think it could not and Mukesh in his PVH patches posted a patch to enable that - "..Move e820 fields out of pv_domain struct" 2). Hvmloader should do an E820 get machine memory hypercall to see if there is anything there. If there is - that means the toolstack has request a "new" type of E820. Iterate over the E820 and make it look like that. You can look in the Linux arch/x86/xen/setup.c to see how it does that. The complication there is that hvmloader needs to to fit the ACPI code (the guest type one) and such. Presumarily you can just re-use the existing spaces that the host has marked as E820_RESERVED or E820_ACPI.. Then there is the SMBIOS would need to move and the BIOS might need to be relocated - but I think those are relocatable in some form. > > The added bonus of this (if it can be made to work) is that > it might just make unmodified GeForce cards work, too, > which probably makes it worthwhile on it's own. Well, I am more than happy to help you with this. > > >>I guess I could test this easily enough by applying the vBAR = > >>pBAR hack. > > > >Does the e820_host=1 option help? That might be PV only though, I > >can't > >remember... > > Thanks for pointing this one out, I just found this post in the > archives: > http://lists.xen.org/archives/html/xen-users/2012-08/msg00150.html > > With a broken PCIe router, would I also need iommu=soft? No. The iommu=soft is not needed with the recent pvops linux kernels. But broken PCIe router's don't have much to do with the kernel - that is the hypervisor decision whether to allow a guest (either PV or HVM) to have said device. > > Gordan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel