From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: XEN MTRR Date: Tue, 5 Jun 2012 12:17:37 -0400 Message-ID: <20120605161737.GC24031@phenom.dumpdata.com> References: <4FCA6B80.6080103@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: "aorchis@gmail.com" Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote: > Hi Jeremy and Konrad, CC-ing xen-devel. > = > Basically the driver NVIDIA provided is a binary blob and recent > versions does not work with the PAT layout of XEN so it falls back to > MTRR to provide write combining (please correct me if I'm wrong). OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date NVidia driver? I've had reports that it works OK. > However there is no MTRR support on XEN so the driver hard crashed my > machine (I can't ssh into the box anymore). > = > Moreover, there is problem with the open source driver 'nouveau' for > NVIDIA card (also has something to do with PAT layout of XEN) which > causes memory corruption. Huh? Can you point me to a bugzilla please? There was a corruption issue where you can pass in 'nopat' on the command line. > = > I found several patches for XEN which supposedly provide basic MTRR > support for XEN however there is still no /proc/mtrr. Jeremy, can you > tell me if you had been able to get /proc/mtrr on XEN dom0? > = > Thanks for your time. > = > Damien. > = > = > On Sun, Jun 3, 2012 at 5:37 AM, Jeremy Fitzhardinge wro= te: > > On 06/02/2012 03:13 AM, aorchis@gmail.com wrote: > >> Hi Jeremy, > >> > >> Is there any way I can get back MTRR support in XEN in 3.0 kernel? To > >> make a long story short, NVIDIA binary driver rejects PAT in XEN and > >> it falls back to using MTRR but MTRR in XEN was taken out a long time > >> ago so now there's no way to get the NVIDIA binary blob running under > >> a linux XEN dom0. I was about to tear my hair out looking for > >> solutions high and low. > > > > Hi! > > > > Firstly, Konrad is probably the person you should send this to these > > days, since I'm not managing to get much Xen stuff done. > > > > Secondly, hm. =A0Unfortunately, the changes we did have to integrate Xe= n's > > MTRR machinery with Linux have been solidly rejected by the upstream > > maintainers several times, so I think its unlikely that they will ever > > make it into the mainline kernel. =A0And it doesn't seem to have really > > made a difference because PAT does subsume MTRR for at least all the in > > kernel users, as far as I know. > > > > What do you mean by "[the] NVIDIA binary driver rejects PAT in XEN and > > it falls back to using MTRR"? =A0Why does the Nvidia driver reject PAT? > > Perhaps addressing that would be a more profitable way of getting this > > working. =A0In the past we've talked about changing Xen's PAT mapping to > > match the kernel's (or make it configurable), but for now we're > > remapping between the PAT schemes in the pte pvops. =A0If the NVIDIA > > driver is using that mechanism to set ptes (as it must to get anywhere > > in a pvops kernel), then it should be fine with the remapping. =A0Or its > > possible they're having problems with reading a pte back and mapping > > from Xen->Linux PAT formats, which is a problem some of the in-kernel > > drivers also had. =A0Konrad, how did that turn out in the end? Attic. I've turned it off since we had corruption issues (the WC didn't turn back into WB b/c of page_attr using the pte_flag instead of pte_var). Peter was talking about some software PAT lookup code but I hadn't focused on that. There is also some performance numbers to run and collect.