All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "aorchis@gmail.com" <aorchis@gmail.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: XEN MTRR
Date: Tue, 5 Jun 2012 12:17:37 -0400	[thread overview]
Message-ID: <20120605161737.GC24031@phenom.dumpdata.com> (raw)
In-Reply-To: <CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>

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 <jeremy@goop.org> wrote:
> > 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.  Unfortunately, the changes we did have to integrate Xen'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.  And 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"?  Why does the Nvidia driver reject PAT?
> > Perhaps addressing that would be a more profitable way of getting this
> > working.  In 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.  If 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.  Or 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.  Konrad, 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.

       reply	other threads:[~2012-06-05 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
     [not found] ` <4FCA6B80.6080103@goop.org>
     [not found]   ` <CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
2012-06-05 16:17     ` Konrad Rzeszutek Wilk [this message]
2012-06-07 10:49       ` XEN MTRR aorchis
2012-06-07 15:58         ` Konrad Rzeszutek Wilk
2012-06-07 21:01           ` geaaru
2012-06-08 15:30             ` Konrad Rzeszutek Wilk
2012-06-10 14:04               ` Ge@@ru
2012-06-07 23:39           ` Ben Guthro
2012-06-07 23:44             ` Ben Guthro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120605161737.GC24031@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=aorchis@gmail.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.