[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 2/2] IB/qib: use arch_phys_wc_add()



On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> > 
> > This:
> > > + /* MTRR was used if this is non-zero */
> > > + if (!dd->wc_cookie)
> > >           vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > 
> > And this:
> > > +         dd->wc_cookie = arch_phys_wc_add(pioaddr, piolen);
> > > +         if (dd->wc_cookie < 0)
> > > +                 ret = -EINVAL;
> > 
> > don't agree on what wc_cookie will be on error.
> 
> Can you elaborate? The one below is the one that starts things,
> and arch_phys_wc_add() will return 0 on PAT systems. For non-PAT
> systems it will return a number > 0 *iff* a valid MTRR was added.
> It will return negative onloy on error then.
> 
> The change above is meant to replace a check put in place to see
> if PAT was enabled. The way we replace this is to ensure that
> arch_phys_wc_add() returned 0.
> 
> If you disagree it'd be great if you can elaborate why.

Maybe I'm missing something, but in qib_enable_wc() you store the return
from arch_phys_wc_add into wc_cookie.  That return is negative, so you
return from qib_enable_wc() to qib_init_one(), they see the ret value,
they print out a warning about bad performance, then they clear the
return value and continue with device initialization.

In all of this though, wc_cookie is never cleared and so it still has
the error condition in it.  Then, much later at run time, you call
mmap_piobufs() and you check the contents of wc_cookie, and if it's
non-0 (which is still will be), you do the wrong thing, right?  And what
about at shutdown when you call qib_disable_wc() and your cookie still
has an error code in it as well?

-- 
Doug Ledford <dledford@xxxxxxxxxx>
              GPG KeyID: 0E572FDD


Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.