[Xen-devel] [seabios test] 36524: regressions - FAIL
flight 36524 seabios real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36524/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 35697 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass version targeted for testing: seabios a1ac8861049a5ffefc26ca294293ad666954fcc8 baseline version: seabios d23eba6ea3d429ed8a4a34bae7faad20ce44d8a1 People who touched revisions under test: Gerd Hoffmann kra...@redhat.com Kevin O'Connor ke...@koconnor.net Marcel Apfelbaum marce...@redhat.com Marcel Apfelbaum mar...@redhat.com Paolo Bonzini pbonz...@redhat.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass
[Xen-devel] [PATCH] tools/libxl: Fix the errno
After commit 6d896e13, we should pass -errno on read failure. Signed-off-by: Wen Congyang we...@cn.fujitsu.com --- tools/libxl/libxl_aoutils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 0d4c8af..b93f0e4 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -262,7 +262,7 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, assert(ferror(dc-log)); assert(errno); LOGE(ERROR, error logging %s, dc-copywhat); -datacopier_callback(egc, dc, 0, errno); +datacopier_callback(egc, dc, 0, -errno); return; } } -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 9/9] qspinlock, x86, kvm: Implement KVM support for paravirt qspinlock
On 03/20/2015 02:38 AM, Waiman Long wrote: On 03/19/2015 06:01 AM, Peter Zijlstra wrote: [...] You are probably right. The initial apply_paravirt() was done before the SMP boot. Subsequent ones were at kernel module load time. I put a counter in the __native_queue_spin_unlock() and it registered 26949 unlock calls in a 16-cpu guest before it got patched out. because even printks take lock.. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ocaml libxl bindings and KeyedUnion
Some change commited to staging earlier this week breaks ocaml bindings, as shown below. I think it was introduced between a68d1b65bb1bbb9b8db2d82695d32ac09c52a2d7..d4ea77c9d7b314001ff4e2eb7618b45f11551371: NotImplementedError: Cannot handle KeyedUnion fields which are not Structs But now that I look at it, may it be my pvscsi change by any chance? https://github.com/olafhering/xen/commit/f0de53755f628efe64cd60d4511a9667485eba62 diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 48cd9af..2bd050d 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -556,12 +556,21 @@ libxl_vscsi_hctl = Struct(vscsi_hctl, [ (lun, uint32), ]) +libxl_vscsi_pdev = Struct(vscsi_pdev, [ +(p_devname,string), +(u, KeyedUnion(None, libxl_vscsi_pdev_type, type, +[ + (invalid, None), + (dev, libxl_vscsi_hctl), + (wwn, string), + (hctl, libxl_vscsi_hctl), +])), +]) + libxl_vscsi_dev = Struct(vscsi_dev, [ (vscsi_dev_id, libxl_devid), (remove, bool), -(p_devname,string), -(pdev_type,libxl_vscsi_pdev_type), -(pdev, libxl_vscsi_hctl), +(pdev, libxl_vscsi_pdev), (vdev, libxl_vscsi_hctl), ]) @@ -624,8 +633,7 @@ libxl_vscsiinfo = Struct(vscsiinfo, [ (frontend, string), (frontend_id, uint32), (devid, libxl_devid), -(p_devname, string), -(pdev, libxl_vscsi_hctl), +(pdev, libxl_vscsi_pdev), (vdev, libxl_vscsi_hctl), (vscsi_dev_id, libxl_devid), (feature_host, bool), Olaf ocamlc -g -I ../xb/ -w F -warn-error F -c -o xsraw.cmi xsraw.mli ocamlc -g -I ../xb/ -w F -warn-error F -c -o xsraw.cmo xsraw.ml ocamlc -g -I ../xb/ -w F -warn-error F -c -o xst.cmi xst.mli ocamlc -g -I ../xb/ -w F -warn-error F -c -o xst.cmo xst.ml ocamlc -g -I ../xb/ -w F -warn-error F -c -o xs.cmi xs.mli ocamlc -g -I ../xb/ -w F -warn-error F -c -o xs.cmo xs.ml ocamlc -pack -o xenstore.cmo queueop.cmo xsraw.cmo xst.cmo xs.cmo ocamlc -g -I ../xb/ -w F -warn-error F -a -o xenstore.cmaxenstore.cmo ocamlopt -g -ccopt-Wl,-rpath,/opt/xen/upstream/staging-wip/lib64 -dtypes -I ../xb/ -cc gcc -w F -warn-error F -for-pack Xenstore -c -o queueop.cmx queueop.ml ocamlopt -g -ccopt-Wl,-rpath,/opt/xen/upstream/staging-wip/lib64 -dtypes -I ../xb/ -cc gcc -w F -warn-error F -for-pack Xenstore -c -o xsraw.cmx xsraw.ml ocamlopt -g -ccopt-Wl,-rpath,/opt/xen/upstream/staging-wip/lib64 -dtypes -I ../xb/ -cc gcc -w F -warn-error F -for-pack Xenstore -c -o xst.cmx xst.ml ocamlopt -g -ccopt-Wl,-rpath,/opt/xen/upstream/staging-wip/lib64 -dtypes -I ../xb/ -cc gcc -w F -warn-error F -for-pack Xenstore -c -o xs.cmx xs.ml ocamlopt -pack -o xenstore.cmx queueop.cmx xsraw.cmx xst.cmx xs.cmx ocamlopt -g -ccopt-Wl,-rpath,/opt/xen/upstream/staging-wip/lib64 -dtypes -I ../xb/ -cc gcc -w F -warn-error F -for-pack Xenstore -a -o xenstore.cmxa xenstore.cmx sed 's/@VERSION@/4.1/g' META.in META.new mv -f META.new META mkdir -p /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml ocamlfind remove -destdir /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml xenstore ocamlfind: [WARNING] No such directory: /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore ocamlfind install -destdir /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml -ldconf ignore xenstore META xenstore.cma xenstore.cmxa xenstore.cmo xenstore.cmi xenstore.cmx *.a Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.a Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.cmx Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.cmi Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.cmo Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.cmxa Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/xenstore.cma Installed /work/olaf/13.1/github/olafhering/xen.git/dist/install//opt/xen/upstream/staging-wip/lib64/ocaml/xenstore/META make[7]: Leaving directory `/work/olaf/13.1/github/olafhering/xen.git/tools/ocaml/libs/xs' make[6]: Leaving directory `/work/olaf/13.1/github/olafhering/xen.git/tools/ocaml/libs' make[6]: Entering directory `/work/olaf/13.1/github/olafhering/xen.git/tools/ocaml/libs' make -C xl install make[7]: Entering directory `/work/olaf/13.1/github/olafhering/xen.git/tools/ocaml/libs/xl'
Re: [Xen-devel] [PATCH] tools/libxl: Fix the errno
On 03/20/2015 08:17 AM, Wen Congyang wrote: After commit 6d896e13, we should pass -errno on read failure. Signed-off-by: Wen Congyang we...@cn.fujitsu.com --- tools/libxl/libxl_aoutils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 0d4c8af..b93f0e4 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -262,7 +262,7 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, assert(ferror(dc-log)); assert(errno); LOGE(ERROR, error logging %s, dc-copywhat); -datacopier_callback(egc, dc, 0, errno); +datacopier_callback(egc, dc, 0, -errno); return; } } Acked-by: Ross Lagerwall ross.lagerw...@citrix.com -- Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix the errno
On 03/20/2015 04:25 PM, Ross Lagerwall wrote:
On 03/20/2015 08:17 AM, Wen Congyang wrote:
After commit 6d896e13, we should pass -errno on read failure.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
tools/libxl/libxl_aoutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 0d4c8af..b93f0e4 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -262,7 +262,7 @@ static void datacopier_readable(libxl__egc *egc,
libxl__ev_fd *ev,
assert(ferror(dc-log));
assert(errno);
LOGE(ERROR, error logging %s, dc-copywhat);
-datacopier_callback(egc, dc, 0, errno);
+datacopier_callback(egc, dc, 0, -errno);
return;
}
}
Acked-by: Ross Lagerwall ross.lagerw...@citrix.com
I forgot another place, it should be:
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 0d4c8af..965afc3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -249,7 +249,7 @@ static void datacopier_readable(libxl__egc *egc,
libxl__ev_fd *ev,
if (errno == EWOULDBLOCK) break;
LOGE(ERROR, error reading %s during copy of %s,
dc-readwhat, dc-copywhat);
-datacopier_callback(egc, dc, 0, errno);
+datacopier_callback(egc, dc, 0, -errno);
return;
}
if (r == 0) {
@@ -262,7 +262,7 @@ static void datacopier_readable(libxl__egc *egc,
libxl__ev_fd *ev,
assert(ferror(dc-log));
assert(errno);
LOGE(ERROR, error logging %s, dc-copywhat);
-datacopier_callback(egc, dc, 0, errno);
+datacopier_callback(egc, dc, 0, -errno);
return;
}
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/13] libxc: Check xc_domain_maximum_gpfn for negative return values
On Thu, 2015-03-19 at 14:54 -0400, Konrad Rzeszutek Wilk wrote: On Thu, Mar 19, 2015 at 04:47:58PM +, Ian Campbell wrote: On Wed, 2015-03-18 at 20:24 -0400, Konrad Rzeszutek Wilk wrote: Instead of assuming everything is always OK. We stash the gpfns value as an parameter. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- tools/libxc/xc_core_arm.c| 17 ++--- tools/libxc/xc_core_x86.c| 24 tools/libxc/xc_domain_save.c | 8 +++- 3 files changed, 41 insertions(+), 8 deletions(-) diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c index 16508e7..26cec04 100644 --- a/tools/libxc/xc_core_arm.c +++ b/tools/libxc/xc_core_arm.c @@ -31,9 +31,16 @@ xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt, } -static int nr_gpfns(xc_interface *xch, domid_t domid) +static int nr_gpfns(xc_interface *xch, domid_t domid, unsigned long *gpfns) You didn't fancy merging the two versions of this then ;-) I was not sure where you would want to put them. xc_private looks like the best place, but perhaps it should be in an new file? I also suggested just changing the interface of xc_domain_maximum_gpfn, in which case it can stay in xc_domain.c. TBH there seems little point in xc_domain_maximum_gpfn if all callers are using a wrapper, so I think I'd advocate this approach. If you want to stick with a wrapper for some reason then xc_private.c would be an ok choice (its a dumping ground already), or xc_misc.c seems to have a bunch of not dissimilar functionality in it. I think a new file would be overkill. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2][PATCH 2/2] libxl: introduce gfx_passthru_kind
On Fri, 2015-03-20 at 18:08 +0800, Chen, Tiejun wrote:
+if (!xlu_cfg_get_string(config, gfx_passthru_kind, buf, 0)) {
+if (libxl_gfx_passthru_kind_from_string(buf,
+
b_info-u.hvm.gfx_passthru_kind)) {
+fprintf(stderr,
+ERROR: invalid value \%s\ for
\gfx_passthru_kind\\n,
+buf);
+exit (1);
+}
+}
This unnecessary bit seems to have crept back in.
Don't forget to update the manpages if you haven't already.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: close the logfile_w and null file descriptors in libxl__spawn_qdisk_backend() error path
I think this patch is identical to the one I just acked. FWIW in the future there is no need to submit the same patch multiple times. We will ask you to resend if it is necessary. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/29] libxl: Cancelling asynchronous operations
On Tue, Mar 03, 2015 at 12:08:04PM +, Ian Campbell wrote: I wouldn't recommend testing it yet until I've at least smoke tested it to see that things still work if you don't cancel them. Would review of the series be useful and/or appreciated at this stage? Perhaps the first half dozen or so look like preparatory cleanups which I could sensibly look at? Yes, that would be great. I've read through the whole series fairly carefully, and it looks sensible, but you will be better placed to see whether it fits well with the rest of libxl. Thanks, Euan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier)
On Fri, Mar 20, 2015 at 12:08:48PM +0200, Vitaly Chernooky wrote: On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-Górecki marma...@invisiblethingslab.com wrote: On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote: David, On Thu, Mar 19, 2015 at 3:00 PM, David Vrabel david.vra...@citrix.com wrote: On 19/03/15 12:10, Iurii Konovalenko wrote: Hi, guys! When I read, that I am not alone and that issue depends on kernel version, I decided to continue investigation. And I found why our threads locks on read/write operations. On Linux kernel 3.14+ syscalls of file read and write changed a bit: fdget() function was replaced by fdget_pos() - it is fdget() function plus additional position mutex lock for files with FMODE_ATOMIC_POS (files for inodes with S_IFREG flag set - regular nodes). As I thought our xen files are not regular and nonseekable, I hoped this flag is not set. But it is set. It is because our file system is created by function simple_fill_super(), and inside it this flag is hardly set: inode-i_mode = S_IFREG | files-mode; So, as a fast hack I made a patch: just made copy of this function for xen, which does not set this flag. It works for me. Could you please check if it works for you. I still can't get this to deadlock, but why not clear FMODE_ATOMIC_POS in xenbus_file_open() ? Because it is not the root of issue. FMODE_ATOMIC_POS is just one of results of bug. Iurii has fixed the root of issue but in suboptimal way. So we just need to have found optimal way. I can just confirm that: 1. (unsurprisingly) the bug is still present in 4.0-rc4 2. both proposed fixes are effective I'm not sure if removing S_IFREG completely is a good idea, I guess there will be much more side effects... What about another idea: xenbus_file_open uses nonseekable_open - this looks like a good place to clear FMODE_ATOMIC_POS if present? It doesn't make sense to get a lock for position on nonseekable file, right? The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition requires from regular files to be seekable. But Linux kernel looks like Linus has own opinion on it :((( Maybe the better idea would be to change filetype of xenbus (and others) to S_IFIFO or something like this (but keep the file type present, instead of removing it completely). Regarding the implementation, maybe simple_fill_super can be modified to not add S_IFREG if other file type is already present in files-mode? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? pgpmVlTHd92Mu.pgp Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ocaml libxl bindings and KeyedUnion
On Fri, 2015-03-20 at 09:10 +0100, Olaf Hering wrote: Some change commited to staging earlier this week breaks ocaml bindings, as shown below. I think it was introduced between a68d1b65bb1bbb9b8db2d82695d32ac09c52a2d7..d4ea77c9d7b314001ff4e2eb7618b45f11551371: NotImplementedError: Cannot handle KeyedUnion fields which are not Structs I don't see anything in that range which I would expect to cause anything like this so... But now that I look at it, may it be my pvscsi change by any chance? https://github.com/olafhering/xen/commit/f0de53755f628efe64cd60d4511a9667485eba62 ... yes, probably. Although surely it would have been easier for you to confirm this yourself than asking everyone to speculate, especially if you are going to start your mail blaming something in staging. diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 48cd9af..2bd050d 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -556,12 +556,21 @@ libxl_vscsi_hctl = Struct(vscsi_hctl, [ (lun, uint32), ]) +libxl_vscsi_pdev = Struct(vscsi_pdev, [ +(p_devname,string), +(u, KeyedUnion(None, libxl_vscsi_pdev_type, type, +[ + (invalid, None), + (dev, libxl_vscsi_hctl), + (wwn, string), + (hctl, libxl_vscsi_hctl), Following the other examples in libxl_types.idl this would need to be something like: (invalid, None), (dev, Struct(None, [(libxl_vscsi_hctl, dev)])), (wwn, Struct(None, [(string, wwn)])), (hctl, Struct(None, [(libxl_vscsi_hctl, hctl)])), ^(*) ^(**) Or you could teach the IDL machinery and code generators about non-struct members of keyed unions but a) that will be a lot of faff and b) it will make it hard to extend any one of the members in the future. The name at (*) must be the enum member, which I've duplicated at (**) but you might like to thing about whether (**) would have a better name in the context of e.g. vscsi_dev-u.dev.dev or vscsi_dev-u.wwn.wwn. Aside: What is the difference between dev and hctl in this context? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2][PATCH 2/2] libxl: introduce gfx_passthru_kind
On Fri, 2015-03-20 at 09:04 +0800, Chen, Tiejun wrote:
Refactor again,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8599a6a..05c8916 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -409,6 +409,23 @@ static char *dm_spice_options(libxl__gc *gc,
return opt;
}
+static enum libxl_gfx_passthru_kind
+libxl__detect_gfx_passthru_kind(libxl__gc *gc,
+const libxl_domain_config *guest_config)
+{
+const libxl_domain_build_info *b_info = guest_config-b_info;
+
+if (b_info-u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT)
+return b_info-u.hvm.gfx_passthru_kind;
+
+if (libxl__is_igd_vga_passthru(gc, guest_config)) {
+return LIBXL_GFX_PASSTHRU_KIND_IGD;
+}
+
+LOG(ERROR, Unable to detect graphics passthru kind);
+return LIBXL_GFX_PASSTHRU_KIND_DEFAULT;
+}
+
static char ** libxl__build_device_model_args_new(libxl__gc *gc,
const char *dm, int guest_domid,
const libxl_domain_config
*guest_config,
@@ -757,6 +771,21 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
machinearg, max_ram_below_4g);
}
}
+
+if (libxl_defbool_val(b_info-u.hvm.gfx_passthru)) {
+enum libxl_gfx_passthru_kind gfx_passthru_kind =
+libxl__detect_gfx_passthru_kind(gc,
guest_config);
+switch (gfx_passthru_kind) {
+case LIBXL_GFX_PASSTHRU_KIND_IGD:
+machinearg = GCSPRINTF(%s,igd-passthru=on, machinearg);
+break;
+case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
+LOG(ERROR, unable to detect required gfx_passthru_kind);
In this case you will now have logged twice. I'd suggest logging only
here and not in the helper.
+default:
And this case is subtly different to LIBXL_GFX_PASSTHRU_KIND_DEFAULT
since it would indicate some sort of corruption. So, I would drop the
logging on failure in libxl__detect_gfx_passthru_kind and here do:
case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
LOG(ERROR, unable to detect required gfx_passthru_kind);
return NULL;
default:
LOG(ERROR, invalid value for gfx_passthru_kind);
return NULL;
Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xe timer
On Fri, 2015-03-20 at 00:41 +0100, HANNAS YAYA Issa wrote: when I compile xen the timer run only once. I believe Xen timers are one-shot only. If you want a periodic timer then you will need to rearm it at the end of your handler. Check the plt_overflow_timer for an example of this sort of thing. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 21/33] xen/passthrough: Introduce iommu_construct
On 19.03.15 at 20:29, julien.gr...@linaro.org wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -187,6 +187,32 @@ void iommu_teardown(struct domain *d)
tasklet_schedule(iommu_pt_cleanup_tasklet);
}
+int iommu_construct(struct domain *d)
+{
+int rc = 0;
+
+if ( need_iommu(d) 0 )
+return 0;
+
+if ( !iommu_use_hap_pt(d) )
+{
+rc = arch_iommu_populate_page_table(d);
+if ( rc )
+return rc;
+}
Please limit the scope of rc to the body of this if(). With that
Acked-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 26/33] xen/passthrough: Extend XEN_DOMCTL_*assign_device to support DT device
On 19.03.15 at 20:29, julien.gr...@linaro.org wrote: @@ -344,6 +344,13 @@ int iommu_do_domctl( ret = iommu_do_pci_domctl(domctl, d, u_domctl); #endif +#ifdef HAS_DEVICE_TREE +if ( ret != -ENODEV) +return ret; + +ret = iommu_do_dt_domctl(domctl, d, u_domctl); +#endif + return ret; } I think inverting the if() condition and avoiding the extra return path would be better, particularly in case any new code would get added between the #endif and the final return. With that done Acked-by: Jan Beulich jbeul...@suse.com for the non-ARM, non-tools parts. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix the errno
On Fri, 2015-03-20 at 11:03 +, Ian Campbell wrote: Do the new callers actually need the number of bytes read/written or was this just something which seemed like a good idea since it was in hand? If it isn't needed In fact, irrespective of the needs of the future callers lets go back to the old semantics of errnoval for now, since it should be a quick and easy patch, I think. Then if it is actually needed we can sort out the propagation of the number of bytes read in a new patch as part of that series. then lets go back to the old semantics and pass 0 on EOF or bytes_to_read have been read (essentially 0 bytes left to read), I expect the recipient of the callback should know (or could remember) the initial value of bytes_to_read? Otherwise I think the only sensible approach would be to add a new parameter to the callback for the number of bytes and but errnoval back to the old semantics. Or perhaps requiring a separater callback vs. pollhup_callback could solve this too, they would have different prototypes. Please can one of you look into this ASAP, otherwise I think we should revert until it can get fixed. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier)
David, On Fri, Mar 20, 2015 at 12:46 PM, David Vrabel david.vra...@citrix.com wrote: On 20/03/15 10:38, Vitaly Chernooky wrote: So I have finished my investigation and suggest to discuss the simple attaches patch. Looks ok to me. But this needs to go via the filesystem maintainers, Cc'ing Linus on it. Just add Linus to cc? May be to continue mailing thread mentioned above will be better? WIth best regards, You should explain the deadlock in more detail in the commit message and mention that it fixes a regression and which commit introduced the regression. Ok, Another solution would be to replace the file with a symlink to /dev/xen/xenbus. David -- Vitaly Chernooky | Senior Developer - Product Engineering and Development GlobalLogic P +380.44.4929695 ext.1136 M +380.63.6011802 S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 36522: regressions - FAIL
flight 36522 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36522/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail REGR. vs. 35893 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-localmigrate/x10 fail REGR. vs. 35893 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 35893 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: qemuucd232acfa0d70002fed89e9293f04afda577a513 baseline version: qemuu576a94d8bcaa1bb07a81d9ffd2cf76095a66ad9a People who touched revisions under test: Alberto Garcia be...@igalia.com Alex Williamson alex.william...@redhat.com Alexander Graf ag...@suse.de Alexey Kardashevskiy a...@ozlabs.ru Alistair Francis alistair.fran...@xilinx.com Alistair Francis alistai...@gmail.com Alistair Francis alist...@alistair23.me Amit Shah amit.s...@redhat.com Andreas Färber afaer...@suse.de Andrew Jones drjo...@redhat.com Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Anthony Liguori aligu...@amazon.com Ard Biesheuvel ard.biesheu...@linaro.org Bastian Koppelmann kbast...@mail.uni-paderborn.de Benjamin Herrenschmidt b...@kernel.crashing.org Bill Paul wp...@windriver.com Borislav Petkov b...@suse.de Brad Campbell lists2...@fnarfbargle.com Christian Borntraeger borntrae...@de.ibm.com Claudio Fontana claudio.font...@huawei.com Cole Robinson crobi...@redhat.com Cornelia Huck cornelia.h...@de.ibm.com Cyril Bur cyril@au1.ibm.com Daniel P. Berrange berra...@redhat.com David Gibson da...@gibson.dropbear.id.au David Hildenbrand d...@linux.vnet.ibm.com Denis V. Lunev d...@openvz.org Dominik Dingel din...@linux.vnet.ibm.com Dr. David Alan Gilbert dgilb...@redhat.com Eduardo Habkost ehabk...@redhat.com Ekaterina Tumanova tuman...@linux.vnet.ibm.com Eric Auger eric.au...@linaro.org Eugene (jno) Dvurechenski j...@linux.vnet.ibm.com Fabien Chouteau chout...@adacore.com Fam Zheng f...@redhat.com Frank Blaschka blasc...@linux.vnet.ibm.com Frediano Ziglio fredd...@gmail.com Gabriel L. Somlo gso...@gmail.com Gabriel Somlo so...@cmu.edu Gavin Shan gws...@linux.vnet.ibm.com Gerd Hoffmann kra...@redhat.com Gonglei arei.gong...@huawei.com Greg Kurz gk...@linux.vnet.ibm.com Haifeng Gao gaohaifeng@huawei.com Henk Poley henkpo...@gmail.com Hervé Poussineau hpous...@reactos.org Hitoshi Mitake mitake.hito...@lab.ntt.co.jp Igor Mammedov imamm...@redhat.com Jan Kiszka jan.kis...@siemens.com Jason J. Herne jjhe...@linux.vnet.ibm.com Jason J. Herne jjhe...@us.ibm.com Jeff Cody jc...@redhat.com Jens Freimann jf...@linux.vnet.ibm.com Jeremy White jwh...@codeweavers.com John Snow js...@redhat.com Jorge
Re: [Xen-devel] [PATCH] SeaBios/vTPM: Enable Xen stubdom vTPM for HVM virtual machine
On 03/19/2015 08:56 AM, Ian Campbell wrote: On Tue, 2015-03-10 at 08:16 -0400, Quan Xu wrote: @@ -151,6 +152,8 @@ device_hardware_setup(void) esp_scsi_setup(); megasas_setup(); pvscsi_setup(); +if (runningOnXen()) +vtpm4hvm_setup(); Is there anything which is actually Xen specific about the driver in tpm.[ch]? Would it be better to just probe for it, perhaps gates by a Kconfig option which enables TPM support. I also think the probing should be done. That code can also be recycled from what I posted earlier. It's gated by a Kconfig option, so it doesn't fill up the 128k ROM. Stefan And following that train of thought I think you could reasonable drop 4hvm from the name. And possibly even the leading v, since I suppose seabios shouldn't really care if the tpm is emulated or real so long as it looks like a real tpm. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier)
On 20/03/15 10:38, Vitaly Chernooky wrote: So I have finished my investigation and suggest to discuss the simple attaches patch. Looks ok to me. But this needs to go via the filesystem maintainers, Cc'ing Linus on it. You should explain the deadlock in more detail in the commit message and mention that it fixes a regression and which commit introduced the regression. Another solution would be to replace the file with a symlink to /dev/xen/xenbus. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix the errno
On Fri, 2015-03-20 at 16:17 +0800, Wen Congyang wrote: After commit 6d896e13, we should pass -errno on read failure. Hrm, this means that 6d896e13 was a more subtle interface change than I was expecting (I'd forgotten that errno wasn't negative in userspace). This means that someone needs to audit all of the callbacks and check that they do the right thing. But... I'm not at all convinced that this is true for the bootloader ones: They treat -1 as pollhup, which is not the same as -EPERM, which is because the same callback is reused as callback_pollhup, with a comment: /* pollhup gets called with errnoval==-1 which is not otherwise * possible since errnos are nonnegative, so it's unambiguous */ which is now no longer true. Do the new callers actually need the number of bytes read/written or was this just something which seemed like a good idea since it was in hand? If it isn't needed then lets go back to the old semantics and pass 0 on EOF or bytes_to_read have been read (essentially 0 bytes left to read), I expect the recipient of the callback should know (or could remember) the initial value of bytes_to_read? Otherwise I think the only sensible approach would be to add a new parameter to the callback for the number of bytes and but errnoval back to the old semantics. Or perhaps requiring a separater callback vs. pollhup_callback could solve this too, they would have different prototypes. Please can one of you look into this ASAP, otherwise I think we should revert until it can get fixed. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v4 5/5] Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()
On 03/10/2015 08:14 AM, Quan Xu wrote:
make sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init()
Signed-off-by: Quan Xu quan...@intel.com
---
vl.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/vl.c b/vl.c
index f6b3546..0bbdaa1 100644
--- a/vl.c
+++ b/vl.c
@@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-#ifdef CONFIG_TPM
-if (tpm_init() 0) {
-exit(1);
-}
-#endif
-
/* init the bluetooth world */
if (foreach_device_config(DEV_BT, bt_parse))
exit(1);
@@ -4225,6 +4219,17 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+/*
+ * For compatible with Xen stubdom vTPM driver, make
+ * sure QEMU machine class is initialized and QEMU has
+ * registered Xen stubdom vTPM driver.
+ */
+#ifdef CONFIG_TPM
+if (tpm_init() 0) {
+exit(1);
+}
+#endif
+
/* init generic devices */
if (qemu_opts_foreach(qemu_find_opts(device), device_init_func, NULL,
1) != 0)
exit(1);
Reviewed-by: Stefan Berger stef...@linux.vnet.ibm.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 3/5] libxl: add pvusb API
On 3/7/2015 at 12:50 AM, in message
caflbxzzfzl2f4qnuwgbpza8v1ffgvvkbgn+gco6ceekvbf6...@mail.gmail.com, George
Dunlap george.dun...@eu.citrix.com wrote:
On Mon, Jan 19, 2015 at 8:28 AM, Chunyan Liu cy...@suse.com wrote:
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..2e89244 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
+int libxl_intf_to_device_usb(libxl_ctx *ctx, uint32_t domid,
+char *intf, libxl_device_usb *usb)
+LIBXL_EXTERNAL_CALLERS_ONLY;
I guess this function will go away?
With using bus:addr instead of sysfs interface, this will be removed.
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
new file mode 100644
index 000..830a846
--- /dev/null
+++ b/tools/libxl/libxl_usb.c
@@ -0,0 +1,1277 @@
+static int libxl__usbport_add_xenstore(libxl__gc *gc,
+ xs_transaction_t tran,
+ uint32_t domid,
+ libxl_device_usbctrl *usbctrl)
Would it be too much to ask to have all the pvusb-specific stuff in a
separate file -- say, libxl_pvusb.c or something? That would make
it a lot easier when I add in the HVM USB stuff.
Sure.
(Just to be clear, I'm asking as a favor -- it's policy that the first
mover gets to have it easier, and people who want to come and add
something later are the ones who have to do the refactoring.)
+{
+char *path;
+int i;
+
+path = GCSPRINTF(%s/backend/vusb/%d/%d/port,
+ libxl__xs_get_dompath(gc, 0), domid, usbctrl-devid);
+
+libxl__xs_mkdir(gc, tran, path, NULL, 0);
+
+for (i = 1; i = usbctrl-num_ports; i++) {
+if (libxl__xs_write_checked(gc, tran, GCSPRINTF(%s/%d, path, i),
))
+return ERROR_FAIL;
+}
+
+return 0;
+}
+
+static int libxl__usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
+ libxl_device_usbctrl *usbctrl)
+{
+libxl_ctx *ctx = libxl__gc_owner(gc);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+xs_transaction_t tran;
+int rc = 0;
+
+GCNEW(device);
+rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device);
+if (rc) goto out;
+
+front = flexarray_make(gc, 4, 1);
+back = flexarray_make(gc, 12, 1);
+
+flexarray_append(back, frontend-id);
+flexarray_append(back, libxl__sprintf(gc, %d, domid));
+flexarray_append(back, online);
+flexarray_append(back, 1);
+flexarray_append(back, state);
+flexarray_append(back, libxl__sprintf(gc, %d, 1));
+flexarray_append(back, usb-ver);
+flexarray_append(back, libxl__sprintf(gc, %d,
usbctrl-usb_version));
+flexarray_append(back, num-ports);
+flexarray_append(back, libxl__sprintf(gc, %d, usbctrl-num_ports));
So how much of this is pvusb-specific, and how much would be shared
between DEVICEMODEL? Because this bit looks specifically like the
stuff used to set up the pvusb connection...
To share with qemu emulated usb controller? I think pvusb backend driver will
probe things under backend/vusb/* and setup connection with pvusb frontend
driver, qemu emulated usb controller should not be placed there at all maybe.
+flexarray_append(back, type);
+switch(usbctrl-type) {
+case LIBXL_USBCTRL_TYPE_PV:{
+flexarray_append(back, PVUSB);
+break;
+}
+case LIBXL_USBCTRL_TYPE_DEVICEMODEL: {
+flexarray_append(back, IOEMU);
+break;
+}
+default:
+/* not supported */
+rc = ERROR_FAIL;
+goto out;
+}
...but this looks like it's trying to be shared between PVUSB and
DEVICEMODEL. I'm pretty sure this isn't going to work long-run,
because if we were to write all this stuff for a devicemodel, wouldn't
the pvusb back-end take this as setting up a new pvusb port?
Yes, I think you are right. This place should only allow pvusb type.
Qemu emulated usb controller should not be stored here.
Also, you don't seem to be storing or retreiving usbctrl-name here --
if we want that to be part of the interface we need to use it. (I
think we wanted that so that it could default to something like pv-0,
emul-1, c).
First I wonder usbctrl-name is really needed. If just for interface, we can
use devid (index), it could be 0, 1, and with usb-list one knows info like:
0 is pv, 1 is emulated. But if it helps a lot with a 'name', surely we can
add :)
In general, I don't think libxl should be storing stuff in the pvusb
front/back xenstore directories not related to that protocol. We
should store extraneous information in a libxl-specific directory.
You can see
[Xen-devel] [xen-4.3-testing test] 36551: regressions - trouble: blocked/fail/pass/preparing/queued/running
flight 36551 xen-4.3-testing running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36551/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386none executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued build-i3865 xen-build fail REGR. vs. 36483 test-amd64-i386-libvirt none executed queued build-i386-pvops 2 hosts-allocate running [st=running!] test-amd64-i386-pv none executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-i386-xl none executed queued test-amd64-i386-rhel6hvm-amdnone executed queued test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued test-armhf-armhf-xl-multivcpu 2 hosts-allocate running [st=running!] test-amd64-i386-freebsd10-i386none executed queued test-amd64-i386-freebsd10-amd64none executed queued test-armhf-armhf-xl 5 xen-boot running [st=running!] build-armhf-libvirt 5 libvirt-build fail REGR. vs. 36483 build-amd64 5 xen-build fail REGR. vs. 36483 test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-i386-xl-win7-amd64none executed queued test-amd64-i386-xend-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-i386-xend-winxpsp3none executed queued test-amd64-i386-pairnone executed queued Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a build-i386-rumpuserxen1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-amd64-amd64-pv 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a version targeted for testing: xen c58b16ef1572176cf2f6a424b527b5ed4bb73f17 baseline version: xen 1cf1e6024bfec941e10fe7308b04c9da1a7e74e4 People who touched revisions under test: Jan Beulich jbeul...@suse.com
Re: [Xen-devel] [PATCH v2] xentop: add support for qdisks
On Thu, 2015-03-19 at 11:50 -0600, Charles Arnold wrote: Whether the interface exists (even in buggy form) or not in older versions is important because if it doesn't exist then that would be a build failure, which we would want to avoid. Right. The tree feature was added in version 2.0.0 (again according to the ChangeLog file). I guess you would prefer not making this a requirement in tools/configure given the statement below. Right, I think we don't want to make a global requirement for yajl = 2.0.0 (or 2.0.3) just yet so making xenstat fallback gracefully is probably the best option. Whereas a functional failure would perhaps be tolerable. However, given the existing HAVE_YAJL_YAJL_VERSION_H define I think the code could easily check if the YAJL library is good enough at compile time and stub itself out -- i.e. not report qdisk stats if the yajl doesn't do the job. Ok, I'll do it this way. Thanks. FWIW if HAVE_YAJL_YAJL_VERSION_H is not set then you can assume v1 (as libxl_json.h does). My second concern here is with the use of /var/run/xen/qmp-libxl-%i from outside of libxl. I can't remember if qemu is safe against multiple users of the socket. ISTR asking Anthony this before, but I don't recall the answer, sorry :-( Even if it is strictly speaking ok it seems a bit warty to do it, but perhaps for an in-tree user like libxenstat it is tolerable. Alternatively we could (relatively) easily arrange for their to be a second qemp-libxenstat-%i socket, assuming the qemu overhead of a second one is sane. As a test I modified libxl to create a qmp-libxenstat-%i socket and updated libxenstat to use it instead of qmp-libxl-%i. It works fine although I don't know if there is any performance penalty for having a second socket. I am ok with going with this solution if this is preferred. I'm fine with this unless someone gives a good reason not to do it. Oh, I see my comments above were actually on the old code you were moving. I'll look at fixing this up based on your realloc comments above. Thanks! Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xentop: add support for qdisks
On Thu, 2015-03-19 at 13:20 -0600, Charles Arnold wrote: On 3/19/2015 at 12:09 PM, Anthony PERARD anthony.per...@citrix.com wrote: On Wed, Mar 18, 2015 at 04:12:26PM +, Ian Campbell wrote: My second concern here is with the use of /var/run/xen/qmp-libxl-%i from outside of libxl. I can't remember if qemu is safe against multiple users of the socket. ISTR asking Anthony this before, but I don't recall the answer, sorry :-( Last time I checked, only one client at a time can connect to the socket. If a second user want to connect to the socket, it will be blocked until the first one disconnect. This seems correct based on some of my testing. In rare cases (perhaps not so rare for VMs under heavy I/O load), reading the socket to get the stats times out and so xentop will report '0' for the read/write stats until the next read attempt that succeeds. It looks as if we do need a second socket to qemu. I will include that in the next patch version. Yep, it sounds like it is a requirement, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2][PATCH 2/2] libxl: introduce gfx_passthru_kind
+case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
+LOG(ERROR, unable to detect required gfx_passthru_kind);
In this case you will now have logged twice. I'd suggest logging only
here and not in the helper.
+default:
And this case is subtly different to LIBXL_GFX_PASSTHRU_KIND_DEFAULT
since it would indicate some sort of corruption. So, I would drop the
logging on failure in libxl__detect_gfx_passthru_kind and here do:
case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
LOG(ERROR, unable to detect required gfx_passthru_kind);
return NULL;
default:
LOG(ERROR, invalid value for gfx_passthru_kind);
return NULL;
Okay, I update this patch. If this is fine to you I'd like to send this
whole series.
---
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_dm.c | 36 +---
tools/libxl/libxl_internal.h | 4
tools/libxl/libxl_types.idl | 6 ++
tools/libxl/xl_cmdimpl.c | 23 +--
5 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6bbc52d..62b3ae5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -720,6 +720,12 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
libxl_mac *src);
#define LIBXL_HAVE_PSR_MBM 1
#endif
+/*
+ * libxl_domain_build_info has the u.hvm.gfx_passthru_kind field and
+ * the libxl_gfx_passthru_kind enumeration is defined.
+*/
+#define LIBXL_HAVE_GFX_PASSTHRU_KIND
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8599a6a..bf72103 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -409,6 +409,22 @@ static char *dm_spice_options(libxl__gc *gc,
return opt;
}
+static enum libxl_gfx_passthru_kind
+libxl__detect_gfx_passthru_kind(libxl__gc *gc,
+const libxl_domain_config *guest_config)
+{
+const libxl_domain_build_info *b_info = guest_config-b_info;
+
+if (b_info-u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT)
+return b_info-u.hvm.gfx_passthru_kind;
+
+if (libxl__is_igd_vga_passthru(gc, guest_config)) {
+return LIBXL_GFX_PASSTHRU_KIND_IGD;
+}
+
+return LIBXL_GFX_PASSTHRU_KIND_DEFAULT;
+}
+
static char ** libxl__build_device_model_args_new(libxl__gc *gc,
const char *dm, int guest_domid,
const libxl_domain_config
*guest_config,
@@ -710,9 +726,6 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
flexarray_append(dm_args, -net);
flexarray_append(dm_args, none);
}
-if (libxl_defbool_val(b_info-u.hvm.gfx_passthru)) {
-flexarray_append(dm_args, -gfx_passthru);
-}
} else {
if (!sdl !vnc) {
flexarray_append(dm_args, -nographic);
@@ -757,6 +770,23 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
machinearg, max_ram_below_4g);
}
}
+
+if (libxl_defbool_val(b_info-u.hvm.gfx_passthru)) {
+enum libxl_gfx_passthru_kind gfx_passthru_kind =
+libxl__detect_gfx_passthru_kind(gc,
guest_config);
+switch (gfx_passthru_kind) {
+case LIBXL_GFX_PASSTHRU_KIND_IGD:
+machinearg = GCSPRINTF(%s,igd-passthru=on, machinearg);
+break;
+case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
+LOG(ERROR, unable to detect required gfx_passthru_kind);
+return NULL;
+default:
+LOG(ERROR, invalid value for gfx_passthru_kind);
+return NULL;
+}
+}
+
flexarray_append(dm_args, machinearg);
for (i = 0; b_info-extra_hvm b_info-extra_hvm[i] != NULL;
i++)
flexarray_append(dm_args, b_info-extra_hvm[i]);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c97c62d..26a01cb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3632,6 +3632,10 @@ static inline void
libxl__update_config_vtpm(libxl__gc *gc,
*/
void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
const libxl_bitmap *sptr);
+
+bool libxl__is_igd_vga_passthru(libxl__gc *gc,
+const libxl_domain_config *d_config);
+
#endif
/*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 47af340..76642a8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -140,6 +140,11 @@ libxl_tsc_mode = Enumeration(tsc_mode, [
(3, native_paravirt),
])
Re: [Xen-devel] Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier)
On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-Górecki marma...@invisiblethingslab.com wrote: On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote: David, On Thu, Mar 19, 2015 at 3:00 PM, David Vrabel david.vra...@citrix.com wrote: On 19/03/15 12:10, Iurii Konovalenko wrote: Hi, guys! When I read, that I am not alone and that issue depends on kernel version, I decided to continue investigation. And I found why our threads locks on read/write operations. On Linux kernel 3.14+ syscalls of file read and write changed a bit: fdget() function was replaced by fdget_pos() - it is fdget() function plus additional position mutex lock for files with FMODE_ATOMIC_POS (files for inodes with S_IFREG flag set - regular nodes). As I thought our xen files are not regular and nonseekable, I hoped this flag is not set. But it is set. It is because our file system is created by function simple_fill_super(), and inside it this flag is hardly set: inode-i_mode = S_IFREG | files-mode; So, as a fast hack I made a patch: just made copy of this function for xen, which does not set this flag. It works for me. Could you please check if it works for you. I still can't get this to deadlock, but why not clear FMODE_ATOMIC_POS in xenbus_file_open() ? Because it is not the root of issue. FMODE_ATOMIC_POS is just one of results of bug. Iurii has fixed the root of issue but in suboptimal way. So we just need to have found optimal way. I can just confirm that: 1. (unsurprisingly) the bug is still present in 4.0-rc4 2. both proposed fixes are effective I'm not sure if removing S_IFREG completely is a good idea, I guess there will be much more side effects... What about another idea: xenbus_file_open uses nonseekable_open - this looks like a good place to clear FMODE_ATOMIC_POS if present? It doesn't make sense to get a lock for position on nonseekable file, right? The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition requires from regular files to be seekable. But Linux kernel looks like Linus has own opinion on it :((( With best regards, -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.63.6011802* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] libxl/libxl_qmp.c: fix error handling in qmp_open
On Thu, Mar 19, 2015 at 12:55:12PM +, PRAMOD DEVENDRA wrote: From: Pramod Devendra pramod.deven...@citrix.com 1. Make sure sun_path does not overflow 2. Close qmp_fd on error 3. Use goto out for error handling Signed-off-by: Pramod Devendra pramod.deven...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Stefano Stabellini stefano.stabell...@eu.citrix.com CC: Ian Campbell ian.campb...@citrix.com CC: Wei Liu wei.l...@citrix.com Acked-by: Wei Liu wei.l...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools/libxl: close the logfile_w and null file descriptors in libxl__spawn_qdisk_backend() error path
On Thu, Mar 19, 2015 at 05:51:15AM +, Koushik Chakravarty wrote:
Signed-off-by: Koushik Chakravarty koushik.chakrava...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_dm.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cb006df..2678be2 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1508,7 +1508,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
flexarray_t *dm_args;
char **args;
const char *dm;
-int logfile_w, null, rc;
+int logfile_w, null = -1, rc;
uint32_t domid = dmss-guest_domid;
/* Always use qemu-xen as device model */
@@ -1534,6 +1534,10 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
goto error;
}
null = open(/dev/null, O_RDONLY);
+if (null 0) {
+ rc = ERROR_FAIL;
+ goto error;
+}
dmss-guest_config = NULL;
/*
@@ -1568,6 +1572,8 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
error:
assert(rc);
+if (logfile_w = 0) close(logfile_w);
+if (null = 0) close(null);
dmss-callback(egc, dmss, rc);
return;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full framebuffer
including the MMIO space *and* ___then___ use an MTRR with
MTRR_TYPE_WRCOMB on the full PCI BAR... and finally hole
in an MTRR_TYPE_UNCACHABLE MTRR only for MMIO.
This is a terrible fucking work around, and should by no means
be necessary however evidence through a large series of conversion
of drivers to ioremap_wc() for the framebuffer shows that around
the time MTRR started becoming popular devices did not have things
lined up for easily separating the framebuffer and MMIO register
access. In some cases a driver requires significant intrusive
changes in order to make the split for an ioremap() for MMIO registers
and another ioremap_wc() for the framebuffer, at other times a
bit of careful study of the driver suffices. This example driver
falls into the later category.
We can replace the MTRR MTRR_TYPE_UNCACHABLE
work around by using ioremap_nocache(), the length of the
MMIO space should already be correct. The other part we
need to correct is ensuring we ioremap() for the framebuffer
only the required size. Since the ioremap() happens early
on probe for PCI devices before aty_init() where we typically
adjust the length and know how to do it, we can fix this by
pegging the bus type as PCI on PCI probe, and finally fudging
and framebuffer length just as we do on aty_init().
The last thing we do must do to remain sane is ensure we
use the info-fix.smem_start and info-fix.smem_len for
the framebuffer MTRR as we know that is always well adjusted.
The *one* concern here would be if the MTRR is not in units
of 4K __but__ we already know that in the PCI case this cannot
happen, in the shared space setting the MTRR would be up to
0x7ff000 and assuming a 4K page:
; 0x7ff000 / 0x1000
2047
Also, internally when MTRR is used mtrr_add() will use mtrr_check()
and that should splat a warning when the MTRR base and size are
not compatible with what is expected for MTRR usage.
This fix lets us nuke the MTRR_TYPE_UNCACHABLE MTRR hole.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 28 ++--
2 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 1f39a62..89ec439 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -184,7 +184,6 @@ struct atyfb_par {
spinlock_t int_lock;
#ifdef CONFIG_MTRR
int mtrr_aper;
- int mtrr_reg;
#endif
u32 mem_cntl;
struct crtc saved_crtc;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start + 0x80 -
-GUI_RESERVE, GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE, 1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
[Xen-devel] [PATCH v1 19/47] video: fbdev: vesafb: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index a2261d0..5bc94d3 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -19,10 +19,9 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/screen_info.h
+#include linux/io.h
#include video/vga.h
-#include asm/io.h
-#include asm/mtrr.h
#define dac_reg(0x3c8)
#define dac_val(0x3c9)
@@ -179,16 +178,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static void vesafb_destroy(struct fb_info *info)
{
-#ifdef CONFIG_MTRR
struct vesafb_par *par = info-par;
-#endif
fb_dealloc_cmap(info-cmap);
-
-#ifdef CONFIG_MTRR
- if (par-wc_cookie = 0)
- mtrr_del(par-wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(par-wc_cookie);
if (info-screen_base)
iounmap(info-screen_base);
release_mem_region(info-apertures-ranges[0].base,
info-apertures-ranges[0].size);
@@ -419,7 +412,6 @@ static int vesafb_probe(struct platform_device *dev)
request_region(0x3c0, 32, vesafb);
if (mtrr == 3) {
-#ifdef CONFIG_MTRR
unsigned int temp_size = size_total;
/* Find the largest power-of-two */
@@ -427,18 +419,16 @@ static int vesafb_probe(struct platform_device *dev)
/* Try and find a power of two to add */
do {
- par-wc_cookie = mtrr_add(vesafb_fix.smem_start,
- temp_size,
- MTRR_TYPE_WRCOMB, 1);
+ par-wc_cookie =
+ arch_phys_wc_add(vesafb_fix.smem_start,
+temp_size);
temp_size = 1;
- } while (temp_size = PAGE_SIZE par-wc_cookie == -EINVAL);
-#endif
+ } while (temp_size = PAGE_SIZE par-wc_cookie 0);
+
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
} else {
-#ifdef CONFIG_MTRR
if (mtrr mtrr != 3)
WARN_ONCE(1, Only MTRR_TYPE_WRCOMB (3)
[Xen-devel] [PATCH v1 25/47] video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/radeon_base.c | 29 ++---
drivers/video/fbdev/aty/radeonfb.h| 2 +-
2 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index 26d80a4..922e8fc 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -85,10 +85,6 @@
#endif /* CONFIG_PPC_OF */
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/radeon.h
#include linux/radeonfb.h
@@ -271,9 +267,7 @@ static bool mirror = 0;
static int panel_yres = 0;
static bool force_dfp = 0;
static bool force_measure_pll = 0;
-#ifdef CONFIG_MTRR
static bool nomtrr = 0;
-#endif
static bool force_sleep;
static bool ignore_devlist;
#ifdef CONFIG_PMAC_BACKLIGHT
@@ -2260,8 +2254,8 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo-mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
rinfo-video_ram);
do {
- rinfo-fb_base = ioremap (rinfo-fb_base_phys,
- rinfo-mapped_vram);
+ rinfo-fb_base = ioremap_wc(rinfo-fb_base_phys,
+ rinfo-mapped_vram);
} while (rinfo-fb_base == NULL
((rinfo-mapped_vram /= 2) = MIN_MAPPED_VRAM));
@@ -2359,11 +2353,9 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
goto err_unmap_fb;
}
-#ifdef CONFIG_MTRR
- rinfo-mtrr_hdl = nomtrr ? -1 : mtrr_add(rinfo-fb_base_phys,
-rinfo-video_ram,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ if (!nomtrr)
+ rinfo-wc_cookie = arch_phys_wc_add(rinfo-fb_base_phys,
+ rinfo-video_ram);
if (backlight)
radeonfb_bl_init(rinfo);
@@ -2428,12 +2420,7 @@ static void radeonfb_pci_unregister(struct pci_dev *pdev)
#endif
del_timer_sync(rinfo-lvds_timer);
-
-#ifdef CONFIG_MTRR
- if (rinfo-mtrr_hdl = 0)
- mtrr_del(rinfo-mtrr_hdl, 0, 0);
-#endif
-
+ arch_phys_wc_del(rinfo-wc_cookie);
unregister_framebuffer(info);
radeonfb_bl_exit(rinfo);
@@ -2489,10 +2476,8 @@ static int __init radeonfb_setup (char *options)
panel_yres = simple_strtoul((this_opt+11), NULL, 0);
} else if
[Xen-devel] [PATCH v1 32/47] video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR and ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/nvidia/nv_type.h | 7 +--
drivers/video/fbdev/nvidia/nvidia.c | 37 ++--
2 files changed, 7 insertions(+), 37 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_type.h
b/drivers/video/fbdev/nvidia/nv_type.h
index c03f7f5..6ff321a 100644
--- a/drivers/video/fbdev/nvidia/nv_type.h
+++ b/drivers/video/fbdev/nvidia/nv_type.h
@@ -148,12 +148,7 @@ struct nvidia_par {
u32 forceCRTC;
u32 open_count;
u8 DDCBase;
-#ifdef CONFIG_MTRR
- struct {
- int vram;
- int vram_valid;
- } mtrr;
-#endif
+ int wc_cookie;
struct nvidia_i2c_chan chan[3];
volatile u32 __iomem *REGS;
diff --git a/drivers/video/fbdev/nvidia/nvidia.c
b/drivers/video/fbdev/nvidia/nvidia.c
index def0412..781f5e7 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -21,9 +21,6 @@
#include linux/pci.h
#include linux/console.h
#include linux/backlight.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -80,9 +77,7 @@ static int paneltweak = 0;
static int vram = 0;
static int bpp = 8;
static int reverse_i2c;
-#ifdef CONFIG_MTRR
static bool nomtrr = false;
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
@@ -1365,7 +1360,8 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
par-ScratchBufferStart = par-FbUsableSize - par-ScratchBufferSize;
par-CursorStart = par-FbUsableSize + (32 * 1024);
- info-screen_base = ioremap(nvidiafb_fix.smem_start, par-FbMapSize);
+ info-screen_base = ioremap_wc(nvidiafb_fix.smem_start,
+ par-FbMapSize);
info-screen_size = par-FbUsableSize;
nvidiafb_fix.smem_len = par-RamAmountKBytes * 1024;
@@ -1376,20 +1372,9 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
par-FbStart = info-screen_base;
-#ifdef CONFIG_MTRR
- if (!nomtrr) {
- par-mtrr.vram = mtrr_add(nvidiafb_fix.smem_start,
- par-RamAmountKBytes * 1024,
- MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr.vram 0) {
- printk(KERN_ERR PFX unable to setup MTRR\n);
- } else
[Xen-devel] [PATCH v1 38/47] video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++--
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e1..5bb0153 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
#include linux/pci.h
#include asm/io.h
#include linux/uaccess.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include video/kyro.h
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
static char *mode_option = NULL;
static int nopan = 0;
static int nowrap = 1;
-#ifdef CONFIG_MTRR
static int nomtrr = 0;
-#endif
/* PCI driver prototypes */
static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, nowrap) == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, nomtrr) == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
currentpar-regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+ if (!currentpar-regbase)
+ goto out_free_fb;
- info-screen_base = ioremap_nocache(kyro_fix.smem_start,
- kyro_fix.smem_len);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 0);
+ if (!info-screen_base)
+ goto out_unmap_regs;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- currentpar-mtrr_handle =
- mtrr_add(kyro_fix.smem_start,
-kyro_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ currentpar-wc_cookie = arch_phys_wc_add(kyro_fix.smem_start,
+kyro_fix.smem_len);
kyro_fix.ypanstep = nopan ? 0 : 1;
kyro_fix.ywrapstep = nowrap ? 0 : 1;
@@ -745,8 +737,10 @@ static int kyrofb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
out_unmap:
- iounmap(currentpar-regbase);
[Xen-devel] [PATCH v1 45/47] video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com The driver doesn't use mtrr_add() or arch_phys_wc_add() but since we know the framebuffer is isolated already on an ioremap() we can take advantage of write combining for performance where possible. In this case there are a few motivations for this: a) Take advantage of PAT when available b) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e) Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- drivers/video/fbdev/geode/gxfb_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c index 124d7c7..ec9fc9a 100644 --- a/drivers/video/fbdev/geode/gxfb_core.c +++ b/drivers/video/fbdev/geode/gxfb_core.c @@ -263,7 +263,8 @@ static int gxfb_map_video_memory(struct fb_info *info, struct pci_dev *dev) info-fix.smem_start = pci_resource_start(dev, 0); info-fix.smem_len = vram ? vram : gx_frame_buffer_size(); - info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len); + info-screen_base = ioremap_wc(info-fix.smem_start, + info-fix.smem_len); if (!info-screen_base) return -ENOMEM; -- 2.3.2.209.gd67f9d5.dirty ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 44/47] video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/atmel_lcdfb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
b/drivers/video/fbdev/atmel_lcdfb.c
index 94a8d04..abadc49 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1266,7 +1266,8 @@ static int __init atmel_lcdfb_probe(struct
platform_device *pdev)
goto stop_clk;
}
- info-screen_base = ioremap(info-fix.smem_start,
info-fix.smem_len);
+ info-screen_base = ioremap_wc(info-fix.smem_start,
+ info-fix.smem_len);
if (!info-screen_base) {
ret = -ENOMEM;
goto release_intmem;
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/47] mtrr/x86/drivers: bury MTRR
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com When a system has PAT support enabled you don't need to be using MTRRs. Andy had added arch_phys_wc_add() long ago to help with this but not all drivers were converted over. We have to take care to only convert drivers where we know that the proper ioremap_wc() API has been used. Doing this requires a bit of work on verifying the driver split out the ioremap'd areas -- and if not doing that ourselves. Verifying a driver uses the same areas can be hard but with a bit of love Coccinelle can help with that. We're motivated to change drivers for a few reasons: 1) Take advantage of PAT when available 2) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e) Nice! --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: fix dom0 balloon logic
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error. Meanwhile, dom0 continued to balloon. Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed. The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().
In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing. It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made. See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt
http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html
If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway. Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS. It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.
xl was patched to accommodate the change in libxl_wait_for_memory_target()
with xen.git commit 883b30a0. This patch does the same in the libxl
driver. While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c. It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_domain.c | 57
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 407a9bd..ff78133 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1121,38 +1121,41 @@ libxlDomainFreeMem(libxlDomainObjPrivatePtr priv,
libxl_domain_config *d_config)
{
uint32_t needed_mem;
uint32_t free_mem;
-size_t i;
-int ret = -1;
+int ret;
int tries = 3;
int wait_secs = 10;
-if ((ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
-needed_mem)) = 0) {
-for (i = 0; i tries; ++i) {
-if ((ret = libxl_get_free_memory(priv-ctx, free_mem)) 0)
-break;
+ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
+ needed_mem);
+if (ret 0)
+goto error;
-if (free_mem = needed_mem) {
-ret = 0;
-break;
-}
+do {
+ret = libxl_get_free_memory(priv-ctx, free_mem);
+if (ret 0)
+goto error;
-if ((ret = libxl_set_memory_target(priv-ctx, 0,
- free_mem - needed_mem,
- /* relative */ 1, 0)) 0)
-break;
+if (free_mem = needed_mem)
+return 0;
-ret = libxl_wait_for_free_memory(priv-ctx, 0, needed_mem,
- wait_secs);
-if (ret == 0 || ret != ERROR_NOMEM)
-break;
+ret = libxl_set_memory_target(priv-ctx, 0,
+ free_mem - needed_mem,
+ /* relative */ 1, 0);
+if (ret 0)
+goto error;
-if ((ret = libxl_wait_for_memory_target(priv-ctx, 0, 1)) 0)
-break;
-}
-}
+ret = libxl_wait_for_free_memory(priv-ctx, 0, needed_mem,
+ wait_secs);
+if (ret 0)
+goto error;
-return ret;
+tries--;
+} while (tries 0);
+
+ error:
+virReportSystemError(ret, %s,
+ _(Failed to balloon domain0 memory));
+return -1;
}
static void
@@ -1271,12 +1274,8 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
virDomainObjPtr vm,
priv-ctx, d_config) 0)
goto endjob;
-if (cfg-autoballoon libxlDomainFreeMem(priv, d_config) 0) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
- _(libxenlight failed to get free memory for domain
'%s'),
- d_config.c_info.name);
+if
[Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on PATs with errata, another situation is observed on
old device drivers where devices had combined MMIO
register access with whatever area they typically
later wanted to end up using MTRR for on the same
PCI BAR. This situation can still be addressed by
splitting up ioremap'd PCI BAR into two ioremap'd
calls, one for MMIO registers, and another for whatever
is desirable for write-combining -- in order to
accomplish this though quite a bit of driver
restructuring is required.
Device drivers which are known to require large
amount of re-work in order to split ioremap'd areas
can use __arch_phys_wc_add() to avoid regressions
when PAT is enabled.
For a good example driver where things are neatly
split up on a PCI BAR refer the infiniband qib
driver. For a good example of a driver where good
amount of work is required refer to the infiniband
ipath driver.
This is *only* a transitive API -- and as such no new
drivers are ever expected to use this.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/io.h | 4
arch/x86/kernel/cpu/mtrr/main.c | 36 +---
include/linux/io.h | 4
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34a5b93..a144d05 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -338,6 +338,10 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec
*vec1,
#define IO_SPACE_LIMIT 0x
#ifdef CONFIG_MTRR
+extern int __must_check __arch_phys_wc_add(unsigned long base,
+ unsigned long size);
+#define __arch_phys_wc_add __arch_phys_wc_add
+
extern int __must_check arch_phys_wc_add(unsigned long base,
unsigned long size);
extern void arch_phys_wc_del(int handle);
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 7db9c47..5ae830b 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -538,23 +538,24 @@ int mtrr_del(int reg, unsigned long base, unsigned long
size)
EXPORT_SYMBOL(mtrr_del);
/**
- * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
+ * __arch_phys_wc_add - add a WC MTRR even if PAT is available
* @base: Physical base address
* @size: Size of region
*
- * If PAT is available, this does nothing. If PAT is unavailable, it
- * attempts to add a WC MTRR covering size bytes starting at base and
- * logs an error if this fails.
+ * We typically do not want to use MTRR if PAT is available but there
+ * are some drivers which require significant work to get this to work
+ * properly. This call should only be used by those drivers where it is
+ * clear that hard work is required to modify them to use arch_phys_wc_add()
*
* Drivers must store the return value to pass to mtrr_del_wc_if_needed,
* but drivers should not try to interpret that return value.
*/
-int arch_phys_wc_add(unsigned long base, unsigned long size)
+int __arch_phys_wc_add(unsigned long base, unsigned long size)
{
int ret;
- if (pat_enabled || !mtrr_enabled)
- return 0; /* Success! (We don't need to do anything.) */
+ if (!mtrr_enabled)
+ return 0;
ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
if (ret 0) {
@@ -564,6 +565,27 @@ int arch_phys_wc_add(unsigned long base, unsigned long
size)
}
return ret + MTRR_TO_PHYS_WC_OFFSET;
}
+EXPORT_SYMBOL_GPL(__arch_phys_wc_add);
+
+/**
+ * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
+ * @base: Physical base address
+ * @size: Size of region
+ *
+ * If PAT is available, this does nothing. If PAT is unavailable, it
+ * attempts to add a WC MTRR covering size bytes starting at base and
+ * logs an error if this fails.
+ *
+ * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
+ * but drivers should not try to interpret that return value.
+ */
+int arch_phys_wc_add(unsigned long base, unsigned long size)
+{
+ if (pat_enabled || !mtrr_enabled)
+ return 0; /* Success! (We don't need to do anything.) */
+
+ return __arch_phys_wc_add(base,
[Xen-devel] [PATCH v1 11/47] IB/qib: add acounting for MTRR
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
index 81b225f..fe0850a 100644
--- a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
+++ b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
@@ -118,7 +118,7 @@ int qib_enable_wc(struct qib_devdata *dd)
if (!ret) {
int cookie;
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
qib_devinfo(dd-pcidev,
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 24/47] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/arkfb.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e..6a317de 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = 640x480-8@60;
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR((c) 2007 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(fbdev driver for ARK 2000PV);
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, Default video mode
('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
-
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
/* Error handling */
@@ -1092,14 +1073,7 @@ static void ark_pci_remove(struct
[Xen-devel] [PATCH v1 30/47] video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/neofb.c | 26 +++---
include/video/neomagic.h| 5 +
2 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c
index 44f99a6..db023a9 100644
--- a/drivers/video/fbdev/neofb.c
+++ b/drivers/video/fbdev/neofb.c
@@ -71,11 +71,6 @@
#include asm/io.h
#include asm/irq.h
#include asm/pgtable.h
-
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/vga.h
#include video/neomagic.h
@@ -1710,6 +1705,7 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
int video_len)
{
//unsigned long addr;
+ struct neofb_par *par = info-par;
DBG(neo_map_video);
@@ -1723,7 +1719,7 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
}
info-screen_base =
- ioremap(info-fix.smem_start, info-fix.smem_len);
+ ioremap_wc(info-fix.smem_start, info-fix.smem_len);
if (!info-screen_base) {
printk(neofb: unable to map screen memory\n);
release_mem_region(info-fix.smem_start,
@@ -1733,11 +1729,8 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
printk(KERN_INFO neofb: mapped framebuffer at %p\n,
info-screen_base);
-#ifdef CONFIG_MTRR
- ((struct neofb_par *)(info-par))-mtrr =
- mtrr_add(info-fix.smem_start, pci_resource_len(dev, 0),
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ pci_resource_len(dev, 0));
/* Clear framebuffer, it's all white in memory after boot */
memset_io(info-screen_base, 0, info-fix.smem_len);
@@ -1754,16 +1747,11 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
static void neo_unmap_video(struct fb_info *info)
{
- DBG(neo_unmap_video);
+ struct neofb_par *par = info-par;
-#ifdef CONFIG_MTRR
- {
- struct neofb_par *par = info-par;
+ DBG(neo_unmap_video);
- mtrr_del(par-mtrr, info-fix.smem_start,
-info-fix.smem_len);
- }
-#endif
+ arch_phys_wc_del(par-wc_cookie);
iounmap(info-screen_base);
info-screen_base = NULL;
diff --git a/include/video/neomagic.h b/include/video/neomagic.h
index bc5013e..91e225a 100644
[Xen-devel] [PATCH v1 07/47] video: fbdev: atyfb: move framebuffer length fudging to helper
From: Luis R. Rodriguez mcg...@suse.com
The size of the framebuffer to be used needs to
be fudged to account for the different type of
devices that are out there. This captures what
is required to do well, we'll resuse this later.
This has no functional changes.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb_base.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8789e48..16936bb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -427,6 +427,20 @@ static struct {
#endif /* CONFIG_FB_ATY_CT */
};
+/*
+ * Last page of 8 MB (4 MB on ISA) aperture is MMIO,
+ * unless the auxiliary register aperture is used.
+ */
+static void aty_fudge_framebuffer_len(struct fb_info *info)
+{
+ struct atyfb_par *par = (struct atyfb_par *) info-par;
+
+ if (!par-aux_start
+ (info-fix.smem_len == 0x80 ||
+(par-bus_type == ISA info-fix.smem_len == 0x40)))
+ info-fix.smem_len -= GUI_RESERVE;
+}
+
static int correct_chipset(struct atyfb_par *par)
{
u8 rev;
@@ -2603,14 +2617,7 @@ static int aty_init(struct fb_info *info)
if (par-pll_ops-resume_pll)
par-pll_ops-resume_pll(info, par-pll);
- /*
-* Last page of 8 MB (4 MB on ISA) aperture is MMIO,
-* unless the auxiliary register aperture is used.
-*/
- if (!par-aux_start
- (info-fix.smem_len == 0x80 ||
-(par-bus_type == ISA info-fix.smem_len == 0x40)))
- info-fix.smem_len -= GUI_RESERVE;
+ aty_fudge_framebuffer_len(info);
/*
* Disable register access through the linear aperture
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 16/47] fusion: use __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Juergen Gross jgr...@suse.com
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-s...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/message/fusion/mptbase.c | 19 ---
drivers/message/fusion/mptbase.h | 2 +-
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 187f836..c7b1a55 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -59,10 +59,6 @@
#include linux/delay.h
#include linux/interrupt.h /* needed for in_interrupt() proto */
#include linux/dma-mapping.h
-#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include linux/kthread.h
#include scsi/scsi_host.h
@@ -2820,11 +2816,8 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
pci_disable_device(ioc-pcidev);
pci_release_selected_regions(ioc-pcidev, ioc-bars);
-#if defined(CONFIG_MTRR) 0
- if (ioc-mtrr_reg 0) {
- mtrr_del(ioc-mtrr_reg, 0, 0);
- dprintk(ioc, printk(MYIOC_s_INFO_FMT MTRR region
de-registered\n, ioc-name));
- }
+#if 0
+ __arch_phys_wc_del(ioc-wc_cookie);
#endif
/* Zap the adapter lookup ptr! */
@@ -4512,17 +4505,13 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
ioc-req_frames_low_dma = (u32) (alloc_dma 0x);
-#if defined(CONFIG_MTRR) 0
+#if 0
/*
* Enable Write Combining MTRR for IOC's memory region.
* (at least as much as we can; size and base must be
* multiples of 4 kiB
*/
- ioc-mtrr_reg = mtrr_add(ioc-req_frames_dma,
-sz,
-MTRR_TYPE_WRCOMB, 1);
- dprintk(ioc, printk(MYIOC_s_DEBUG_FMT MTRR region registered
(base:size=%08x:%x)\n,
- ioc-name, ioc-req_frames_dma, sz));
+ ioc-wc_cookie = arch_phys_wc_add(ioc-req_frames_dma, sz);
#endif
for (i = 0; i ioc-req_depth; i++) {
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8f14090..f0bff11 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -671,7 +671,7 @@ typedef struct _MPT_ADAPTER
u8 *HostPageBuffer; /* SAS - host page buffer
support */
u32 HostPageBuffer_sz;
dma_addr_t HostPageBuffer_dma;
- int mtrr_reg;
+ int wc_cookie;
struct pci_dev *pcidev;/* struct pci_dev pointer */
int bars; /* bitmask of BAR's that must
be configured */
int msi_enable;
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 22/47] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/staging/sm750fb/sm750.c| 34 --
drivers/staging/sm750fb/sm750.h| 3 ---
drivers/staging/sm750fb/sm750_hw.c | 3 +--
3 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..ea59471 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
#includelinux/vmalloc.h
#includelinux/pagemap.h
#include linux/console.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include asm/fb.h
#include sm750.h
#include sm750_hw.h
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*,struct
pci_dev*);
/* common var for all device */
static int g_hwcursor = 1;
static int g_noaccel = 0;
-#ifdef CONFIG_MTRR
static int g_nomtrr = 0;
-#endif
static const char * g_fbmode[] = {NULL,NULL};
static const char * g_def_fbmode = 800x600-16@60;
static char * g_settings = NULL;
@@ -1102,11 +1097,8 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
pr_info(share-revid = %02x\n,share-revid);
share-pdev = pdev;
-#ifdef CONFIG_MTRR
share-mtrr_off = g_nomtrr;
share-mtrr.vram = 0;
- share-mtrr.vram_added = 0;
-#endif
share-accel_off = g_noaccel;
share-dual = g_dualview;
spin_lock_init(share-slock);
@@ -1134,22 +1126,9 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
goto err_map;
}
-#ifdef CONFIG_MTRR
- if(!share-mtrr_off){
- pr_info(enable mtrr\n);
- share-mtrr.vram = mtrr_add(share-vidmem_start,
- share-vidmem_size,
- MTRR_TYPE_WRCOMB,1);
-
- if(share-mtrr.vram 0){
- /* don't block driver with the failure of MTRR */
- pr_err(Unable to setup MTRR.\n);
- }else{
- share-mtrr.vram_added = 1;
- pr_info(MTRR added succesfully\n);
- }
- }
-#endif
+ if (!share-mtrr_off)
+ share-mtrr.vram = arch_phys_wc_add(share-vidmem_start,
+ share-vidmem_size);
memset(share-pvMem,0,share-vidmem_size);
@@ -1250,10 +1229,7 @@ static void __exit lynxfb_pci_remove(struct pci_dev *
pdev)
/* release frame buffer*/
[Xen-devel] [PATCH v1 27/47] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gbefb.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index f48ea7e..ef81215 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -22,9 +22,6 @@
#include linux/module.h
#include linux/io.h
-#ifdef CONFIG_X86
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_MIPS
#include asm/addrspace.h
#endif
@@ -1176,8 +1173,8 @@ static int gbefb_probe(struct platform_device *p_dev)
if (gbe_mem_phys) {
/* memory was allocated at boot time */
- gbe_mem = devm_ioremap_nocache(p_dev-dev, gbe_mem_phys,
- gbe_mem_size);
+ gbe_mem = devm_ioremap_wc(p_dev-dev, gbe_mem_phys,
+ gbe_mem_size);
if (!gbe_mem) {
printk(KERN_ERR gbefb: couldn't map framebuffer\n);
ret = -ENOMEM;
@@ -1188,8 +1185,8 @@ static int gbefb_probe(struct platform_device *p_dev)
} else {
/* try to allocate memory with the classical allocator
* this has high chance to fail on low memory machines */
- gbe_mem = dma_alloc_coherent(NULL, gbe_mem_size, gbe_dma_addr,
-GFP_KERNEL);
+ gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
+gbe_dma_addr, GFP_KERNEL);
if (!gbe_mem) {
printk(KERN_ERR gbefb: couldn't allocate framebuffer
memory\n);
ret = -ENOMEM;
@@ -1199,10 +1196,7 @@ static int gbefb_probe(struct platform_device *p_dev)
gbe_mem_phys = (unsigned long) gbe_dma_addr;
}
-#ifdef CONFIG_X86
- info-wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ info-wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
/* map framebuffer memory into tiles table */
for (i = 0; i (gbe_mem_size TILE_SHIFT); i++)
@@ -1242,10 +1236,7 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
-#ifdef CONFIG_MTRR
- if (info-wc_cookie = 0)
- mtrr_del(info-wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(info-wc_cookie);
if (gbe_dma_addr)
Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support
Hello Vijay,
On 19/03/2015 14:38, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Virtual ITS command processing support to
Virtual ITS driver. Also add API's to in physical
ITS driver to send commands from Virtual ITS driver.
In this patch, following are done
-Physical ITS driver will allocate physical LPI for
virtual LPI request.
Please indent the same way as the other item.
- The Device ID is used to find the ITS on which it is attached
and ITS command is sent on that physical ITS.
- Commands like SYNC and INVALL does not have device id. So these
commands are sent on all Physical ITS nodes.
- The vTA(virtual target address) is considered unique way to map
to Physical target address and collection ids.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v2: - put unused code under #if0/endif
- changes to redistributor is moved to separate patch
- Fixed comments from RFC version
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/gic-v3-its.c | 185 -
xen/arch/arm/vgic-v3-its.c| 879 +
xen/include/asm-arm/domain.h |9 +
xen/include/asm-arm/gic-its.h | 86 +++-
5 files changed, 1156 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 66ea264..81a3317 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += traps.o
obj-y += vgic.o vgic-v2.o
obj-$(CONFIG_ARM_64) += vgic-v3.o
obj-$(CONFIG_ARM_64) += gic-v3-its.o
+obj-$(CONFIG_ARM_64) += vgic-v3-its.o
obj-y += vtimer.o
obj-y += vuart.o
obj-y += hvm.o
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 242cf65..a9aab73 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -56,6 +56,14 @@
#define its_warn(fmt, ...)\
+//#define DEBUG_GIC_ITS
+
+#ifdef DEBUG_GIC_ITS
+# define DPRINTK(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 0)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 0)
@@ -68,6 +76,7 @@
struct its_collection {
u64 target_address;
u16 col_id;
+ u16 valid;
};
/*
@@ -80,14 +89,19 @@ struct its_node {
struct list_headentry;
void __iomem*base;
unsigned long phys_base;
+ unsigned long phys_size;
struct its_cmd_block*cmd_base;
struct its_cmd_block*cmd_write;
void*tables[GITS_BASER_NR_REGS];
struct its_collection *collections;
u64 flags;
u32 ite_size;
+ u32 nr_collections;
+ struct dt_device_node *dt_node;
};
+uint32_t pta_type;
+
The physical target address is defined per-ITS. Therefore it should be
moved in the its_node.
#define ITS_ITT_ALIGN SZ_256
static LIST_HEAD(its_nodes);
@@ -127,6 +141,123 @@ struct its_cmd_desc {
};
};
+uint32_t its_get_pta_type(void)
+{
That would require its_get_pta_type to take an its_node in parameter.
+ return pta_type;
+}
+
+struct its_node * its_get_phys_node(uint32_t dev_id)
+{
+ struct its_node *its;
+
+ /* TODO: For now return ITS0 node.
+* Need Query PCI helper function to get on which
+* ITS node the device is attached
+*/
+ list_for_each_entry(its, its_nodes, entry) {
+ return its;
+ }
+
+ return NULL;
+}
+
+static int its_search_rdist_address(struct domain *d, uint64_t ta,
+ uint32_t *col_id)
+{
+ int i, rg;
+ paddr_t start, end;
+
+ for (rg = 0; rg d-arch.vgic.nr_regions; rg++) {
+ i = 0;
+ start = d-arch.vgic.rdist_regions[rg].base;
+ end = d-arch.vgic.rdist_regions[rg].base +
+ d-arch.vgic.rdist_regions[rg].size;
+ while ((( start + i * d-arch.vgic.rdist_stride) end)) {
+ if ((start + i * d-arch.vgic.rdist_stride) == ta) {
+ DPRINTK(ITS: Found pta 0x%lx\n, ta);
+ *col_id = i;
+ return 0;
+ }
+ i++;
+ }
+ }
+ return 1;
+}
+
If you consider col_id == vcpu_id, you may want to give a look to
get_vcpu_from_rdist.
+int its_get_physical_cid(struct domain *d, uint32_t *col_id, uint64_t ta)
The function returns either 1 or 0. I would use bool_t.
After looking to the code of this function, this looks more a vITS
specific function rather than an ITS one.
+{
+ int i;
+ struct its_collection *col;
+
+ /*
+
[Xen-devel] [PATCH v1 31/47] video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/s3fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a..13b1090 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include linux/i2c.h
#include linux/i2c-algo-bit.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, Enable S3 fast text mode (1=enable, 0=disable,
default=1));
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
@@ -1405,14 +1391,7 @@ static void
[Xen-devel] [PATCH v1 00/47] mtrr/x86/drivers: bury MTRR
From: Luis R. Rodriguez mcg...@suse.com When a system has PAT support enabled you don't need to be using MTRRs. Andy had added arch_phys_wc_add() long ago to help with this but not all drivers were converted over. We have to take care to only convert drivers where we know that the proper ioremap_wc() API has been used. Doing this requires a bit of work on verifying the driver split out the ioremap'd areas -- and if not doing that ourselves. Verifying a driver uses the same areas can be hard but with a bit of love Coccinelle can help with that. We're motivated to change drivers for a few reasons: 1) Take advantage of PAT when available 2) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e) 3) Bury MTRR code away from drivers as it is architecture specific While working on the conversion I noticed a few things. a) Run time disabling of MTRR Some systems can technically have both PAT and MTRR enabled and even if they support it, a system may end up not enabling MTRR. There are a few reasons why this can happen but the code right now doesn't address this well. This leads to another point: PAT code right now is not a first class citizen on x86 -- pat_init() depends on MTRR code so we can't actually enable PAT without building MTRR. Doing this requires quite a bit more work so let this serve as a starting point for conversation if we want to address that. b) Driver work and required ioremap split In order to take advantage of PAT device drivers that were using MTRR must make sure that the area that was using MTRR is ioremap'd separately. Fortunately a lot of drivers already do this, but there's quite a bit of drivers that require some love to get that happen. This leaves us needing to expose an last resort API to annotate this and also avoid a regression on performance for systems that may have PAT but can't yet move away from using MTRR. To find the drivers that need love check out __arch_phys_wc_add(). For a good example driver where the work was done refer to the atyfb driver fixes. c) Missing APIs for write-combining There's a few API calls missing to take advantage of write-combining, this series add those. d) Further framebuffer driver MTRR usage simplication We can simplify MTRR usage by having the framebuffer core add the MTRR by passing a flag when register_framebuffer() is called, this could for instance be done on very few drivers where the smem_len and smem_start are both used for the ioremap_wc() and also for the arch_phys_wc_add(). Coccinelle can be easily used to do a transformation here. I didn't do that here given that it does not work for all device drivers *and* DRM drivers already have something similar. Lastly this technically could also be done on some other generic helper --- but figured its best we review that here. One reason to *not* do this is that tons of framebuffer drivers have mtrr options exposed -- we'd need to generalize those and provide a port ... or deal with the fact that we are going to remove all that. Luis R. Rodriguez (47): x86: mtrr: annotate mtrr_type_lookup() is only implemented on generic_mtrr_ops x86: mtrr: generalize run time disabling of MTRR devres: add devm_ioremap_wc() pci: add pci_ioremap_wc_bar() pci: add pci_iomap_wc() variants mtrr: add __arch_phys_wc_add() video: fbdev: atyfb: move framebuffer length fudging to helper video: fbdev: atyfb: clarify ioremap() base and length used vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc() IB/qib: add acounting for MTRR IB/qib: use arch_phys_wc_add() IB/ipath: add counting for MTRR IB/ipath: use __arch_phys_wc_add() [media] media: ivtv: use __arch_phys_wc_add() fusion: use __arch_phys_wc_add() video: fbdev: vesafb: only support MTRR_TYPE_WRCOMB vidoe: fbdev: vesafb: add missing mtrr_del() for added MTRR video: fbdev: vesafb: use arch_phys_wc_add() mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index() ethernet: myri10ge: use arch_phys_wc_add() staging: sm750fb: use arch_phys_wc_add() and ioremap_wc() staging: xgifb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc() video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: gbefb: add missing mtrr_del() calls video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc() video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc() video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc() video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc() video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc() video: fbdev:
[Xen-devel] [PATCH v1 05/47] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers, sometimes we can address
the changes in drivers, other times the change requires
intrusive changes.
Although there is also arch_phys_wc_add() that makes use of
architecture specific write-combinging alternatives (MTRR on
x86 when a system does not have PAT) we void polluting
pci_iomap() space with it and force drivers and subsystems
that want to use it to be explicit.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
include/asm-generic/pci_iomap.h | 14 ++
lib/pci_iomap.c | 61 +
2 files changed, 75 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87..b1e17fc 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long
max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar,
unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f1..30b65ae 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way. When possible write combining
+ * is used.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR from offset to the end, pass %0 here.
+ * */
+void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
+int bar,
+
[Xen-devel] [PATCH v1 12/47] IB/qib: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Dennis Dalessandro dennis.dalessan...@intel.com
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
index fe0850a..6d61ef9 100644
--- a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
+++ b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
@@ -116,21 +116,9 @@ int qib_enable_wc(struct qib_devdata *dd)
}
if (!ret) {
- int cookie;
-
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
- if (cookie 0) {
- {
- qib_devinfo(dd-pcidev,
-mtrr_add() WC for PIO bufs failed
(%d)\n,
-cookie);
- ret = -EINVAL;
- }
- } else {
- dd-wc_cookie = cookie;
- dd-wc_base = (unsigned long) pioaddr;
- dd-wc_len = (unsigned long) piolen;
- }
+ dd-wc_cookie = arch_phys_wc_add(pioaddr, piolen);
+ if (dd-wc_cookie 0)
+ ret = -EINVAL;
}
return ret;
@@ -142,18 +130,7 @@ int qib_enable_wc(struct qib_devdata *dd)
*/
void qib_disable_wc(struct qib_devdata *dd)
{
- if (dd-wc_cookie) {
- int r;
-
- r = mtrr_del(dd-wc_cookie, dd-wc_base,
-dd-wc_len);
- if (r 0)
- qib_devinfo(dd-pcidev,
-mtrr_del(%lx, %lx, %lx) failed: %d\n,
-dd-wc_cookie, dd-wc_base,
-dd-wc_len, r);
- dd-wc_cookie = 0; /* even on failure */
- }
+ arch_phys_wc_del(dd-wc_cookie);
}
/**
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 29/47] video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same ioremap()'d area for the MTRR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/matrox/matroxfb_base.c | 36 +++---
drivers/video/fbdev/matrox/matroxfb_base.h | 27 +-
2 files changed, 14 insertions(+), 49 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 62539ca..2f70365 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -370,12 +370,9 @@ static void matroxfb_remove(struct matrox_fb_info *minfo,
int dummy)
matroxfb_unregister_device(minfo);
unregister_framebuffer(minfo-fbcon);
matroxfb_g450_shutdown(minfo);
-#ifdef CONFIG_MTRR
- if (minfo-mtrr.vram_valid)
- mtrr_del(minfo-mtrr.vram, minfo-video.base, minfo-video.len);
-#endif
- mga_iounmap(minfo-mmio.vbase);
- mga_iounmap(minfo-video.vbase);
+ arch_phys_wc_del(minfo-wc_cookie);
+ iounmap(minfo-mmio.vbase.vaddr);
+ iounmap(minfo-video.vbase.vaddr);
release_mem_region(minfo-video.base, minfo-video.len_maximum);
release_mem_region(minfo-mmio.base, 16384);
kfree(minfo);
@@ -1256,9 +1253,7 @@ static int nobios;/*
matroxfb:nobios */
static int noinit = 1; /* matroxfb:init */
static int inverse;/* matroxfb:inverse */
static int sgram; /* matroxfb:sgram */
-#ifdef CONFIG_MTRR
static int mtrr = 1; /* matroxfb:nomtrr */
-#endif
static int grayscale; /* matroxfb:grayscale */
static int dev = -1; /* matroxfb:dev:x */
static unsigned int vesa = ~0; /* matroxfb:vesa:x */
@@ -1717,14 +1712,17 @@ static int initMatrox2(struct matrox_fb_info *minfo,
struct board *b)
if (mem (mem memsize))
memsize = mem;
err = -ENOMEM;
- if (mga_ioremap(ctrlptr_phys, 16384, MGA_IOREMAP_MMIO,
minfo-mmio.vbase)) {
+
+ minfo-mmio.vbase.vaddr = ioremap_nocache(ctrlptr_phys, 16384);
+ if (!minfo-mmio.vbase.vaddr) {
printk(KERN_ERR matroxfb: cannot ioremap(%lX, 16384), matroxfb
disabled\n, ctrlptr_phys);
goto failVideoMR;
}
minfo-mmio.base = ctrlptr_phys;
minfo-mmio.len = 16384;
minfo-video.base = video_base_phys;
- if (mga_ioremap(video_base_phys, memsize, MGA_IOREMAP_FB,
[Xen-devel] [PATCH v1 34/47] video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/sis/sis.h | 2 +-
drivers/video/fbdev/sis/sis_main.c | 27 ++-
2 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis.h b/drivers/video/fbdev/sis/sis.h
index 1987f1b7..ea1d1c9 100644
--- a/drivers/video/fbdev/sis/sis.h
+++ b/drivers/video/fbdev/sis/sis.h
@@ -458,7 +458,7 @@ struct sis_video_info {
unsigned char *bios_abase;
- int mtrr;
+ int wc_cookie;
u32 sisfb_mem;
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index fcf610e..e923038 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -53,9 +53,6 @@
#include linux/types.h
#include linux/uaccess.h
#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include sis.h
#include sis_main.h
@@ -4130,13 +4127,13 @@ static void sisfb_post_map_vram(struct sis_video_info
*ivideo,
if (*mapsize (min 20))
return;
- ivideo-video_vbase = ioremap(ivideo-video_base, (*mapsize));
+ ivideo-video_vbase = ioremap_wc(ivideo-video_base, (*mapsize));
if(!ivideo-video_vbase) {
printk(KERN_ERR
sisfb: Unable to map maximum video RAM for size
detection\n);
(*mapsize) = 1;
- while((!(ivideo-video_vbase = ioremap(ivideo-video_base,
(*mapsize) {
+ while((!(ivideo-video_vbase = ioremap_wc(ivideo-video_base,
(*mapsize) {
(*mapsize) = 1;
if((*mapsize) (min 20))
break;
@@ -6186,7 +6183,7 @@ static int sisfb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto error_2;
}
- ivideo-video_vbase = ioremap(ivideo-video_base, ivideo-video_size);
+ ivideo-video_vbase = ioremap_wc(ivideo-video_base,
ivideo-video_size);
ivideo-SiS_Pr.VideoMemoryAddress = ivideo-video_vbase;
if(!ivideo-video_vbase) {
printk(KERN_ERR sisfb: Fatal error: Unable to map framebuffer
memory\n);
@@ -6254,8 +6251,6 @@ error_3: vfree(ivideo-bios_abase);
ivideo-SiS_Pr.VideoMemoryAddress += ivideo-video_offset;
ivideo-SiS_Pr.VideoMemorySize = ivideo-sisfb_mem;
- ivideo-mtrr = -1;
-
ivideo-vbflags = 0;
[Xen-devel] [PATCH v1 35/47] video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/aty128fb.c | 36 ++--
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index aedf2fb..f41955b 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -80,10 +80,6 @@
#include asm/btext.h
#endif /* CONFIG_BOOTX_TEXT */
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/aty128.h
/* Debug flag */
@@ -399,10 +395,7 @@ static int default_cmode = CMODE_8;
static int default_crt_on = 0;
static int default_lcd_on = 1;
-
-#ifdef CONFIG_MTRR
static bool mtrr = true;
-#endif
#ifdef CONFIG_FB_ATY128_BACKLIGHT
#ifdef CONFIG_PMAC_BACKLIGHT
@@ -456,9 +449,7 @@ struct aty128fb_par {
u32 vram_size; /* onboard video ram */
int chip_gen;
const struct aty128_meminfo *mem; /* onboard mem info*/
-#ifdef CONFIG_MTRR
- struct { int vram; int vram_valid; } mtrr;
-#endif
+ int wc_cookie;
int blitter_may_be_busy;
int fifo_slots; /* free slots in FIFO (64 max) */
@@ -1725,12 +1716,10 @@ static int aty128fb_setup(char *options)
#endif
continue;
}
-#ifdef CONFIG_MTRR
if(!strncmp(this_opt, nomtrr, 6)) {
mtrr = 0;
continue;
}
-#endif
#ifdef CONFIG_PPC_PMAC
/* vmode and cmode deprecated */
if (!strncmp(this_opt, vmode:, 6)) {
@@ -2133,7 +2122,7 @@ static int aty128_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
par-vram_size = aty_ld_le32(CNFG_MEMSIZE) 0x03FF;
/* Virtualize the framebuffer */
- info-screen_base = ioremap(fb_addr, par-vram_size);
+ info-screen_base = ioremap_wc(fb_addr, par-vram_size);
if (!info-screen_base)
goto err_unmap_out;
@@ -2170,15 +2159,9 @@ static int aty128_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (!aty128_init(pdev, ent))
goto err_out;
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr.vram = mtrr_add(info-fix.smem_start,
- par-vram_size, MTRR_TYPE_WRCOMB, 1);
- par-mtrr.vram_valid = 1;
- /* let there be speed */
- printk(KERN_INFO aty128fb: Rage128 MTRR set to ON\n);
- }
[Xen-devel] [PATCH v1 39/47] video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/pm2fb.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 3b85b64..aa8d288 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -38,10 +38,6 @@
#include linux/fb.h
#include linux/init.h
#include linux/pci.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/permedia2.h
#include video/cvisionppc.h
@@ -81,10 +77,7 @@ static char *mode_option;
static bool lowhsync;
static bool lowvsync;
static bool noaccel;
-/* mtrr option */
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
/*
* The hardware state of the graphics card that isn't part of the
@@ -100,7 +93,7 @@ struct pm2fb_par
u32 mem_control;/* MemControl reg at probe */
u32 boot_address; /* BootAddress reg at probe */
u32 palette[16];
- int mtrr_handle;
+ int wc_cookie;
};
/*
@@ -1637,21 +1630,16 @@ static int pm2fb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto err_exit_mmio;
}
info-screen_base =
- ioremap_nocache(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
+ ioremap_wc(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_WARNING pm2fb: Can't ioremap smem area.\n);
release_mem_region(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
goto err_exit_mmio;
}
-#ifdef CONFIG_MTRR
- default_par-mtrr_handle = -1;
if (!nomtrr)
- default_par-mtrr_handle =
- mtrr_add(pm2fb_fix.smem_start,
-pm2fb_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ default_par-wc_cookie = arch_phys_wc_add(pm2fb_fix.smem_start,
+ pm2fb_fix.smem_len);
info-fbops = pm2fb_ops;
info-fix = pm2fb_fix;
@@ -1733,12 +1721,7 @@ static void pm2fb_remove(struct pci_dev *pdev)
struct pm2fb_par *par = info-par;
unregister_framebuffer(info);
-
-#ifdef CONFIG_MTRR
- if (par-mtrr_handle = 0)
- mtrr_del(par-mtrr_handle, info-fix.smem_start,
-
[Xen-devel] [PATCH v1 43/47] video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vt8623fb.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index ea7f056..60f24828 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = 640x480-8@60;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR((c) 2006 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, Default video mode e.g. '648x480-8@60' (deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
/* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
info-fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+
[Xen-devel] [PATCH v1 10/47] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 41 +---
2 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 89ec439..63c4842 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -182,9 +182,7 @@ struct atyfb_par {
unsigned long irq_flags;
unsigned int irq;
spinlock_t int_lock;
-#ifdef CONFIG_MTRR
- int mtrr_aper;
-#endif
+ int wc_cookie;
u32 mem_cntl;
struct crtc saved_crtc;
union aty_pll saved_pll;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8875e56..af278bb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -98,9 +98,6 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include asm/backlight.h
#endif
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
/*
* Debug flags.
@@ -303,9 +300,7 @@ static struct fb_ops atyfb_ops = {
};
static bool noaccel;
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
static int vram;
static int pll;
static int mclk;
@@ -2628,14 +2623,9 @@ static int aty_init(struct fb_info *info)
aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL, par) |
BUS_APER_REG_DIS, par);
-#ifdef CONFIG_MTRR
- par-mtrr_aper = -1;
- if (!nomtrr) {
- par-mtrr_aper = mtrr_add(info-fix.smem_start,
- info-fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (!nomtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
info-fbops = atyfb_ops;
info-pseudo_palette = par-pseudo_palette;
@@ -2763,13 +2753,8 @@ aty_init_exit:
/* restore video mode */
aty_set_crtc(par, par-saved_crtc);
par-pll_ops-set_pll(info, par-saved_pll);
+ arch_phys_wc_del(par-wc_cookie);
-#ifdef CONFIG_MTRR
- if (par-mtrr_aper = 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
-#endif
return ret;
}
@@ -3478,7 +3463,8 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
Re: [Xen-devel] [PATCH v1 03/47] devres: add devm_ioremap_wc()
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Looks good to me.
---
Documentation/driver-model/devres.txt | 1 +
include/linux/io.h| 2 ++
lib/devres.c | 29 +
3 files changed, 32 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index e1e2bbd..831a536 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -276,6 +276,7 @@ IOMAP
devm_ioport_unmap()
devm_ioremap()
devm_ioremap_nocache()
+ devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_iounmap()
pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index 4cc299c..91101a1 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -72,6 +72,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t
offset,
resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..2eb2bfe 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,35 @@ void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL_GPL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
2.3.2.209.gd67f9d5.dirty
--
Andy Lutomirski
AMA Capital Management, LLC
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? If so, can we ioremap + set_page_xyz instead? --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 18/47] vidoe: fbdev: vesafb: add missing mtrr_del() for added MTRR
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 191156b..a2261d0 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -29,6 +29,10 @@
/* - */
+struct vesafb_par {
+ int wc_cookie;
+};
+
static struct fb_var_screeninfo vesafb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -175,7 +179,16 @@ static int vesafb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static void vesafb_destroy(struct fb_info *info)
{
+#ifdef CONFIG_MTRR
+ struct vesafb_par *par = info-par;
+#endif
+
fb_dealloc_cmap(info-cmap);
+
+#ifdef CONFIG_MTRR
+ if (par-wc_cookie = 0)
+ mtrr_del(par-wc_cookie, 0, 0);
+#endif
if (info-screen_base)
iounmap(info-screen_base);
release_mem_region(info-apertures-ranges[0].base,
info-apertures-ranges[0].size);
@@ -228,6 +241,7 @@ static int vesafb_setup(char *options)
static int vesafb_probe(struct platform_device *dev)
{
struct fb_info *info;
+ struct vesafb_par *par;
int i, err;
unsigned int size_vmode;
unsigned int size_remap;
@@ -297,8 +311,8 @@ static int vesafb_probe(struct platform_device *dev)
return -ENOMEM;
}
platform_set_drvdata(dev, info);
- info-pseudo_palette = info-par;
- info-par = NULL;
+ info-pseudo_palette = NULL;
+ par = info-par;
/* set vesafb aperture size for generic probing */
info-apertures = alloc_apertures(1);
@@ -407,17 +421,17 @@ static int vesafb_probe(struct platform_device *dev)
if (mtrr == 3) {
#ifdef CONFIG_MTRR
unsigned int temp_size = size_total;
- int rc;
/* Find the largest power-of-two */
temp_size = roundup_pow_of_two(temp_size);
/* Try and find a power of two to add */
do {
- rc = mtrr_add(vesafb_fix.smem_start, temp_size,
- MTRR_TYPE_WRCOMB, 1);
+ par-wc_cookie = mtrr_add(vesafb_fix.smem_start,
+ temp_size,
+ MTRR_TYPE_WRCOMB, 1);
temp_size = 1;
- } while (temp_size = PAGE_SIZE rc == -EINVAL);
+ } while (temp_size = PAGE_SIZE par-wc_cookie == -EINVAL);
#endif
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
} else {
@@ -462,6 +476,10 @@ static int vesafb_probe(struct platform_device *dev)
fb_info(info, %s frame buffer device\n, info-fix.id);
return 0;
err:
+#ifdef CONFIG_MTRR
+ if (par-wc_cookie = 0)
+ mtrr_del(par-wc_cookie, 0, 0);
+#endif
if (info-screen_base)
iounmap(info-screen_base);
framebuffer_release(info);
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 23/47] staging: xgifb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/staging/xgifb/XGI_main_26.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c
b/drivers/staging/xgifb/XGI_main_26.c
index 74e8820..943d463 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -8,10 +8,7 @@
#include linux/sizes.h
#include linux/module.h
-
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
+#include linux/pci.h
#include XGI_main.h
#include vb_init.h
@@ -1770,7 +1767,7 @@ static int xgifb_probe(struct pci_dev *pdev,
}
xgifb_info-video_vbase = hw_info-pjVideoMemoryAddress =
- ioremap(xgifb_info-video_base, xgifb_info-video_size);
+ ioremap_wc(xgifb_info-video_base, xgifb_info-video_size);
xgifb_info-mmio_vbase = ioremap(xgifb_info-mmio_base,
xgifb_info-mmio_size);
@@ -2014,12 +2011,8 @@ static int xgifb_probe(struct pci_dev *pdev,
fb_alloc_cmap(fb_info-cmap, 256, 0);
-#ifdef CONFIG_MTRR
- xgifb_info-mtrr = mtrr_add(xgifb_info-video_base,
- xgifb_info-video_size, MTRR_TYPE_WRCOMB, 1);
- if (xgifb_info-mtrr = 0)
- dev_info(pdev-dev, Added MTRR\n);
-#endif
+ xgifb_info-mtrr = arch_phys_wc_add(xgifb_info-video_base,
+ xgifb_info-video_size);
if (register_framebuffer(fb_info) 0) {
ret = -EINVAL;
@@ -2031,11 +2024,7 @@ static int xgifb_probe(struct pci_dev *pdev,
return 0;
error_mtrr:
-#ifdef CONFIG_MTRR
- if (xgifb_info-mtrr = 0)
- mtrr_del(xgifb_info-mtrr, xgifb_info-video_base,
- xgifb_info-video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info-mtrr);
error_1:
iounmap(xgifb_info-mmio_vbase);
iounmap(xgifb_info-video_vbase);
@@ -2059,11 +2048,7 @@ static void xgifb_remove(struct pci_dev *pdev)
struct fb_info *fb_info = xgifb_info-fb_info;
unregister_framebuffer(fb_info);
-#ifdef CONFIG_MTRR
- if (xgifb_info-mtrr = 0)
- mtrr_del(xgifb_info-mtrr, xgifb_info-video_base,
- xgifb_info-video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info-mtrr);
iounmap(xgifb_info-mmio_vbase);
iounmap(xgifb_info-video_vbase);
[Xen-devel] [PATCH v1 04/47] pci: add pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81f06e8..6afd507 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -137,6 +137,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
pci_resource_len(pdev, bar));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
+ return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
#define PCI_FIND_CAP_TTL 48
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 211e9da..c235b09 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1667,6 +1667,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_ext_cfg_avail(void);
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
#ifdef CONFIG_PCI_IOV
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 04/47] pci: add pci_ioremap_wc_bar()
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81f06e8..6afd507 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -137,6 +137,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
pci_resource_len(pdev, bar));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
if (WARN_ON(...))?
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 20/47] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()
From: Luis R. Rodriguez mcg...@suse.com
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/io.h | 2 ++
arch/x86/include/asm/mtrr.h | 5 -
arch/x86/kernel/cpu/mtrr/main.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 14 +-
include/linux/io.h | 6 ++
5 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index a144d05..5e3f1f2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -346,6 +346,8 @@ extern int __must_check arch_phys_wc_add(unsigned long base,
unsigned long size);
extern void arch_phys_wc_del(int handle);
#define arch_phys_wc_add arch_phys_wc_add
+extern int arch_phys_wc_index(int handle);
+#define arch_phys_wc_index arch_phys_wc_index
#endif
#endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index cade917..380bb4b 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -49,7 +49,6 @@ extern void mtrr_aps_init(void);
extern void mtrr_bp_restore(void);
extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
extern int amd_special_default_mtrr(void);
-extern int phys_wc_to_mtrr_index(int handle);
# else
static const int mtrr_enabled;
static inline u8 mtrr_type_lookup(u64 addr, u64 end)
@@ -86,10 +85,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long
end_pfn)
static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
{
}
-static inline int phys_wc_to_mtrr_index(int handle)
-{
- return -1;
-}
#define mtrr_ap_init() do {} while (0)
#define mtrr_bp_init() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 5ae830b..b68b671 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -607,7 +607,7 @@ void arch_phys_wc_del(int handle)
EXPORT_SYMBOL(arch_phys_wc_del);
/*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * arch_phys_wc_index - translates arch_phys_wc_add's return value
* @handle: Return value from arch_phys_wc_add
*
* This will turn the return value from arch_phys_wc_add into an mtrr
@@ -617,14 +617,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
* in printk line. Alas there is an illegitimate use in some ancient
* drm ioctls.
*/
-int phys_wc_to_mtrr_index(int handle)
+int arch_phys_wc_index(int handle)
{
if (handle MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
}
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(arch_phys_wc_index);
/*
* HACK ALERT!
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a6d773a..e597cdd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,9 +36,6 @@
#include linux/pci.h
#include linux/export.h
-#ifdef CONFIG_X86
-#include asm/mtrr.h
-#endif
static int drm_version(struct drm_device *dev, void *data,
struct drm_file *file_priv);
@@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
map-type = r_list-map-type;
map-flags = r_list-map-flags;
map-handle = (void *)(unsigned long) r_list-user_token;
-
-#ifdef CONFIG_X86
- /*
-* There appears to be exactly one user of the mtrr index: dritest.
-* It's easy enough to keep it working on non-PAT systems.
-*/
- map-mtrr = phys_wc_to_mtrr_index(r_list-map-mtrr);
-#else
- map-mtrr = -1;
-#endif
+ map-mtrr = arch_phys_wc_index(r_list-map-mtrr);
mutex_unlock(dev-struct_mutex);
diff --git a/include/linux/io.h b/include/linux/io.h
index ecc51c3..1676437 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -115,6 +115,12 @@ static inline void arch_phys_wc_del(int handle)
#define __arch_phys_wc_add arch_phys_wc_add
#endif
+#ifndef arch_phys_wc_index
+static inline int arch_phys_wc_index(int handle)
+{
+ return -1;
+}
+#define arch_phys_wc_index arch_phys_wc_index
#endif
#endif /* _LINUX_IO_H */
--
2.3.2.209.gd67f9d5.dirty
[Xen-devel] [PATCH v1 40/47] video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/pm3fb.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/pm3fb.c b/drivers/video/fbdev/pm3fb.c
index 77b99ed..6ff5077 100644
--- a/drivers/video/fbdev/pm3fb.c
+++ b/drivers/video/fbdev/pm3fb.c
@@ -32,9 +32,6 @@
#include linux/fb.h
#include linux/init.h
#include linux/pci.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include video/pm3fb.h
@@ -58,11 +55,7 @@
static int hwcursor = 1;
static char *mode_option;
static bool noaccel;
-
-/* mtrr option */
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
/*
* This structure defines the hardware state of the graphics card. Normally
@@ -76,7 +69,7 @@ struct pm3_par {
u32 video; /* video flags before blanking */
u32 base; /* screen base in 128 bits unit */
u32 palette[16];
- int mtrr_handle;
+ int wc_cookie;
};
/*
@@ -1374,8 +1367,8 @@ static int pm3fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
printk(KERN_WARNING pm3fb: Can't reserve smem.\n);
goto err_exit_mmio;
}
- info-screen_base =
- ioremap_nocache(pm3fb_fix.smem_start, pm3fb_fix.smem_len);
+ info-screen_base = ioremap_wc(pm3fb_fix.smem_start,
+ pm3fb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_WARNING pm3fb: Can't ioremap smem area.\n);
release_mem_region(pm3fb_fix.smem_start, pm3fb_fix.smem_len);
@@ -1383,12 +1376,9 @@ static int pm3fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
}
info-screen_size = pm3fb_fix.smem_len;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- par-mtrr_handle = mtrr_add(pm3fb_fix.smem_start,
- pm3fb_fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-wc_cookie = arch_phys_wc_add(pm3fb_fix.smem_start,
+ pm3fb_fix.smem_len);
info-fbops = pm3fb_ops;
par-video = PM3_READ_REG(par, PM3VideoControl);
@@ -1478,11 +1468,7 @@ static void pm3fb_remove(struct pci_dev *dev)
unregister_framebuffer(info);
fb_dealloc_cmap(info-cmap);
[Xen-devel] [PATCH v1 46/47] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..f19133a 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
info-fix.smem_start = fb_phys;
info-fix.smem_len = pci_resource_len(pdev, 1);
- info-screen_base = pci_ioremap_bar(pdev, 1);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info-screen_base) {
dev_err(pdev-dev, gxt4500: cannot map framebuffer\n);
goto err_unmap_regs;
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
From: Luis R. Rodriguez mcg...@suse.com
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This can happen
for instance on Xen where MTRR is not supported but
PAT is, this can happen now on Linux as of commit
47591df50 by Juergen introduced as of v3.19.
Technically we should assume the proper CPU
bits would be set to disable MTRR but we can't
always rely on this. At least on the Xen Hypervisor
for instance only X86_FEATURE_MTRR was disabled
as of Xen 4.4 through Xen commit 586ab6a [0],
but not X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR,
or X86_FEATURE_CYRIX_ARR for instance.
x86 mtrr code relies on quite a bit of checks for
mtrr_if being set to check to see if MTRR did get
set up, instead of using that lets provide a generic
setter which when set we know MTRR is enabled. This
also adds a few checks where they were not before
which could potentially safeguard ourselves against
incorrect usage of MTRR where this was not desirable.
Where possible match error codes as if MTRR was
disabled on arch/x86/include/asm/mtrr.h.
Lastly, since disabling MTRR can happen at run time
and we could end up with PAT enabled best record now
on our logs when MTRR is disabled.
[0] ~/devel/xen (git::stable-4.5)$ git describe --contains 586ab6a
4.4.0-rc1~18
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: bhelg...@google.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/mtrr.h| 2 ++
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
arch/x86/kernel/cpu/mtrr/if.c | 3 +++
arch/x86/kernel/cpu/mtrr/main.c| 31 ++-
5 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index f768f62..cade917 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -31,6 +31,7 @@
* arch_phys_wc_add and arch_phys_wc_del.
*/
# ifdef CONFIG_MTRR
+extern int mtrr_enabled;
extern u8 mtrr_type_lookup(u64 addr, u64 end);
extern void mtrr_save_fixed_ranges(void *);
extern void mtrr_save_state(void);
@@ -50,6 +51,7 @@ extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
extern int amd_special_default_mtrr(void);
extern int phys_wc_to_mtrr_index(int handle);
# else
+static const int mtrr_enabled;
static inline u8 mtrr_type_lookup(u64 addr, u64 end)
{
/*
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 5f90b85..784dc55 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -880,7 +880,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
* Make sure we only trim uncachable memory on machines that
* support the Intel MTRR architecture:
*/
- if (!is_cpu(INTEL) || disable_mtrr_trim)
+ if (!is_cpu(INTEL) || disable_mtrr_trim || !mtrr_enabled)
return 0;
rdmsr(MSR_MTRRdefType, def, dummy);
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 09c82de..df321b2 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -116,7 +116,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64
*partial_end, int *repeat)
u8 prev_match, curr_match;
*repeat = 0;
- if (!mtrr_state_set)
+ /* generic_mtrr_ops is only set for generic_mtrr_ops */
+ if (!mtrr_state_set || !mtrr_enabled)
return 0xFF;
if (!mtrr_state.enabled)
@@ -290,7 +291,7 @@ static void get_fixed_ranges(mtrr_type *frs)
void mtrr_save_fixed_ranges(void *info)
{
- if (cpu_has_mtrr)
+ if (mtrr_enabled cpu_has_mtrr)
get_fixed_ranges(mtrr_state.fixed_ranges);
}
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index d76f13d..e9e001a 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -436,6 +436,9 @@ static int __init mtrr_if_init(void)
{
struct cpuinfo_x86 *c = boot_cpu_data;
+ if (!mtrr_enabled)
+
[Xen-devel] [PATCH v1 21/47] ethernet: myri10ge: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Hyong-Youb Kim hy...@myri.com
Cc: net...@vger.kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 36 ++--
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 1412f5a..01e4069 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -69,11 +69,7 @@
#include net/ip.h
#include net/tcp.h
#include asm/byteorder.h
-#include asm/io.h
#include asm/processor.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include net/busy_poll.h
#include myri10ge_mcp.h
@@ -242,8 +238,7 @@ struct myri10ge_priv {
unsigned int rdma_tags_available;
int intr_coal_delay;
__be32 __iomem *intr_coal_delay_ptr;
- int mtrr;
- int wc_enabled;
+ int wc_cookie;
int down_cnt;
wait_queue_head_t down_wq;
struct work_struct watchdog_work;
@@ -1984,7 +1979,6 @@ myri10ge_get_ethtool_stats(struct net_device *netdev,
data[i] = ((u64 *)link_stats)[i];
data[i++] = (unsigned int)mgp-tx_boundary;
- data[i++] = (unsigned int)mgp-wc_enabled;
data[i++] = (unsigned int)mgp-pdev-irq;
data[i++] = (unsigned int)mgp-msi_enabled;
data[i++] = (unsigned int)mgp-msix_enabled;
@@ -4040,14 +4034,7 @@ static int myri10ge_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
mgp-board_span = pci_resource_len(pdev, 0);
mgp-iomem_base = pci_resource_start(pdev, 0);
- mgp-mtrr = -1;
- mgp-wc_enabled = 0;
-#ifdef CONFIG_MTRR
- mgp-mtrr = mtrr_add(mgp-iomem_base, mgp-board_span,
-MTRR_TYPE_WRCOMB, 1);
- if (mgp-mtrr = 0)
- mgp-wc_enabled = 1;
-#endif
+ mgp-wc_cookie = arch_phys_wc_add(mgp-iomem_base, mgp-board_span);
mgp-sram = ioremap_wc(mgp-iomem_base, mgp-board_span);
if (mgp-sram == NULL) {
dev_err(pdev-dev, ioremap failed for %ld bytes at 0x%lx\n,
@@ -4146,14 +4133,14 @@ static int myri10ge_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
goto abort_with_state;
}
if (mgp-msix_enabled)
- dev_info(dev, %d MSI-X IRQs, tx bndry %d, fw %s, WC %s\n,
+ dev_info(dev, %d MSI-X IRQs, tx bndry %d, fw %s, MTRR %s, WC
Enabled\n,
mgp-num_slices, mgp-tx_boundary, mgp-fw_name,
-(mgp-wc_enabled ? Enabled : Disabled));
+(mgp-wc_cookie 0 ? Enabled : Disabled));
else
- dev_info(dev, %s IRQ %d, tx bndry %d, fw %s, WC %s\n,
+ dev_info(dev, %s IRQ %d, tx bndry %d, fw %s, MTRR %s, WC
Enabled\n,
mgp-msi_enabled ? MSI : xPIC,
pdev-irq, mgp-tx_boundary, mgp-fw_name,
-(mgp-wc_enabled ? Enabled : Disabled));
+(mgp-wc_cookie 0 ? Enabled : Disabled));
board_number++;
return 0;
@@ -4175,10 +4162,7 @@ abort_with_ioremap:
iounmap(mgp-sram);
abort_with_mtrr:
-#ifdef CONFIG_MTRR
- if (mgp-mtrr = 0)
- mtrr_del(mgp-mtrr, mgp-iomem_base, mgp-board_span);
-#endif
+ arch_phys_wc_del(mgp-wc_cookie);
dma_free_coherent(pdev-dev, sizeof(*mgp-cmd),
mgp-cmd, mgp-cmd_bus);
@@ -4220,11 +4204,7 @@ static void myri10ge_remove(struct pci_dev *pdev)
pci_restore_state(pdev);
iounmap(mgp-sram);
-
-#ifdef CONFIG_MTRR
- if (mgp-mtrr = 0)
- mtrr_del(mgp-mtrr, mgp-iomem_base, mgp-board_span);
-#endif
+ arch_phys_wc_del(mgp-wc_cookie);
myri10ge_free_slices(mgp);
kfree(mgp-msix_vectors);
dma_free_coherent(pdev-dev, sizeof(*mgp-cmd),
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 26/47] video: fbdev: gbefb: add missing mtrr_del() calls
From: Luis R. Rodriguez mcg...@suse.com
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gbefb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 6d9ef39..f48ea7e 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -38,6 +38,7 @@ static struct sgi_gbe *gbe;
struct gbefb_par {
struct fb_var_screeninfo var;
struct gbe_timing_info timing;
+ int wc_cookie;
int valid;
};
@@ -1199,7 +1200,8 @@ static int gbefb_probe(struct platform_device *p_dev)
}
#ifdef CONFIG_X86
- mtrr_add(gbe_mem_phys, gbe_mem_size, MTRR_TYPE_WRCOMB, 1);
+ info-wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
+ MTRR_TYPE_WRCOMB, 1);
#endif
/* map framebuffer memory into tiles table */
@@ -1240,6 +1242,10 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
+#ifdef CONFIG_MTRR
+ if (info-wc_cookie = 0)
+ mtrr_del(info-wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
out_tiles_free:
@@ -1259,6 +1265,10 @@ static int gbefb_remove(struct platform_device* p_dev)
unregister_framebuffer(info);
gbe_turn_off();
+#ifdef CONFIG_MTRR
+ if (info-wc_cookie = 0)
+ mtrr_del(info-wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 36/47] video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for MTRR is used for the ioremap() area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/i810/i810.h | 3 +--
drivers/video/fbdev/i810/i810_main.c | 11 +++
drivers/video/fbdev/i810/i810_main.h | 26 --
3 files changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810.h b/drivers/video/fbdev/i810/i810.h
index 1414b73..7b1c002 100644
--- a/drivers/video/fbdev/i810/i810.h
+++ b/drivers/video/fbdev/i810/i810.h
@@ -199,7 +199,6 @@
#define HAS_FONTCACHE 8
/* driver flags */
-#define HAS_MTRR1
#define HAS_ACCELERATION2
#define ALWAYS_SYNC 4
#define LOCKUP 8
@@ -281,7 +280,7 @@ struct i810fb_par {
u32 ovract;
u32 cur_state;
u32 ddc_num;
- int mtrr_reg;
+ int wc_cookie;
u16 bltcntl;
u8 interlace;
};
diff --git a/drivers/video/fbdev/i810/i810_main.c
b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..025b882 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -41,6 +41,7 @@
#include linux/resource.h
#include linux/unistd.h
#include linux/console.h
+#include linux/io.h
#include asm/io.h
#include asm/div64.h
@@ -1816,7 +1817,9 @@ static void i810_init_device(struct i810fb_par *par)
u8 reg;
u8 __iomem *mmio = par-mmio_start_virtual;
- if (mtrr) set_mtrr(par);
+ if (mtrr)
+ par-wc_cookie= arch_phys_wc_add((u32) par-aperture.physical,
+par-aperture.size);
i810_init_cursor(par);
@@ -1865,8 +1868,8 @@ static int i810_allocate_pci_resource(struct i810fb_par
*par,
}
par-res_flags |= FRAMEBUFFER_REQ;
- par-aperture.virtual = ioremap_nocache(par-aperture.physical,
- par-aperture.size);
+ par-aperture.virtual = ioremap_wc(par-aperture.physical,
+ par-aperture.size);
if (!par-aperture.virtual) {
printk(i810fb_init: cannot
[Xen-devel] [xen-4.4-testing test] 36527: tolerable FAIL - PUSHED
flight 36527 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36527/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 36516 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 9 guest-start fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass version targeted for testing: xen 39f513ba5dd45c80575ab68ea234d94d358736f6 baseline version: xen 04ac29f0c38236840ed852b4fc0933d388a0e776 People who touched revisions under test: Jan Beulich jbeul...@suse.com jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail
[Xen-devel] [PATCH v1 41/47] video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/riva/fbdev.c | 39 +++
drivers/video/fbdev/riva/rivafb.h | 4 +---
2 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index be73727..854b86d 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -41,9 +41,6 @@
#include linux/pci.h
#include linux/backlight.h
#include linux/bitrev.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -208,9 +205,7 @@ MODULE_DEVICE_TABLE(pci, rivafb_pci_tbl);
static int flatpanel = -1; /* Autodetect later */
static int forceCRTC = -1;
static bool noaccel = 0;
-#ifdef CONFIG_MTRR
static bool nomtrr = 0;
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
@@ -2013,28 +2008,18 @@ static int rivafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
rivafb_fix.smem_len = riva_get_memlen(default_par) * 1024;
default_par-dclk_max = riva_get_maxdclk(default_par) * 1000;
- info-screen_base = ioremap(rivafb_fix.smem_start,
- rivafb_fix.smem_len);
+ info-screen_base = ioremap_wc(rivafb_fix.smem_start,
+ rivafb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_ERR PFX cannot ioremap FB base\n);
ret = -EIO;
goto err_iounmap_pramin;
}
-#ifdef CONFIG_MTRR
- if (!nomtrr) {
- default_par-mtrr.vram = mtrr_add(rivafb_fix.smem_start,
- rivafb_fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
- if (default_par-mtrr.vram 0) {
- printk(KERN_ERR PFX unable to setup MTRR\n);
- } else {
- default_par-mtrr.vram_valid = 1;
- /* let there be speed */
- printk(KERN_INFO PFX RIVA MTRR set to ON\n);
- }
- }
-#endif /* CONFIG_MTRR */
+ if (!nomtrr)
+ default_par-wc_cookie =
+ arch_phys_wc_add(rivafb_fix.smem_start,
+rivafb_fix.smem_len);
info-fbops = riva_fb_ops;
info-fix = rivafb_fix;
@@ -2108,13
[Xen-devel] [PATCH v1 47/47] mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
From: Luis R. Rodriguez mcg...@suse.com The crusade to replace mtrr_add() with architecture agnostic arch_phys_wc_add() is complete, this will ensure write-combining implementations (PAT on x86) is taken advantage instead of using MTRR. With the crusade done now, hide direct MTRR access for drivers. Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/kernel/cpu/mtrr/main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index b68b671..f0e19db 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -446,7 +446,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type, return mtrr_add_page(base PAGE_SHIFT, size PAGE_SHIFT, type, increment); } -EXPORT_SYMBOL(mtrr_add); /** * mtrr_del_page - delete a memory type region @@ -535,7 +534,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size) return -EINVAL; return mtrr_del_page(reg, base PAGE_SHIFT, size PAGE_SHIFT); } -EXPORT_SYMBOL(mtrr_del); /** * __arch_phys_wc_add - add a WC MTRR even if PAT is available -- 2.3.2.209.gd67f9d5.dirty ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 08/47] video: fbdev: atyfb: clarify ioremap() base and length used
From: Luis R. Rodriguez mcg...@suse.com
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI we *know* this defaults to 0x80.
atyfb_setup_generic() is *only* used on PCI probe.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 16936bb..8025624 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3489,7 +3489,9 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
/* Map in frame buffer */
info-fix.smem_start = addr;
- info-screen_base = ioremap(addr, 0x80);
+ info-fix.smem_len = 0x80;
+
+ info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len);
if (info-screen_base == NULL) {
ret = -ENOMEM;
goto atyfb_setup_generic_fail;
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full framebuffer
including the MMIO space *and* ___then___ use an MTRR with
MTRR_TYPE_WRCOMB on the full PCI BAR... and finally hole
in an MTRR_TYPE_UNCACHABLE MTRR only for MMIO.
This is a terrible fucking work around, and should by no means
be necessary however evidence through a large series of conversion
of drivers to ioremap_wc() for the framebuffer shows that around
the time MTRR started becoming popular devices did not have things
lined up for easily separating the framebuffer and MMIO register
access. In some cases a driver requires significant intrusive
changes in order to make the split for an ioremap() for MMIO registers
and another ioremap_wc() for the framebuffer, at other times a
bit of careful study of the driver suffices. This example driver
falls into the later category.
We can replace the MTRR MTRR_TYPE_UNCACHABLE
work around by using ioremap_nocache(), the length of the
MMIO space should already be correct. The other part we
need to correct is ensuring we ioremap() for the framebuffer
only the required size. Since the ioremap() happens early
on probe for PCI devices before aty_init() where we typically
adjust the length and know how to do it, we can fix this by
pegging the bus type as PCI on PCI probe, and finally fudging
and framebuffer length just as we do on aty_init().
The last thing we do must do to remain sane is ensure we
use the info-fix.smem_start and info-fix.smem_len for
the framebuffer MTRR as we know that is always well adjusted.
The *one* concern here would be if the MTRR is not in units
of 4K __but__ we already know that in the PCI case this cannot
happen, in the shared space setting the MTRR would be up to
0x7ff000 and assuming a 4K page:
; 0x7ff000 / 0x1000
2047
Also, internally when MTRR is used mtrr_add() will use mtrr_check()
and that should splat a warning when the MTRR base and size are
not compatible with what is expected for MTRR usage.
This fix lets us nuke the MTRR_TYPE_UNCACHABLE MTRR hole.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 28 ++--
2 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 1f39a62..89ec439 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -184,7 +184,6 @@ struct atyfb_par {
spinlock_t int_lock;
#ifdef CONFIG_MTRR
int mtrr_aper;
- int mtrr_reg;
#endif
u32 mem_cntl;
struct crtc saved_crtc;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start + 0x80 -
-GUI_RESERVE, GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE, 1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
-
[Xen-devel] [rumpuserxen test] 36570: regressions - FAIL
flight 36570 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36570/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 330fd2d7cfe2d9ef35a3e5571ad6eed71a2ec094 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 515 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 17/47] video: fbdev: vesafb: only support MTRR_TYPE_WRCOMB
From: Luis R. Rodriguez mcg...@suse.com
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs and
can replace it in a much cleaner way, where so long as the
proper ioremap_wc() or variant API is used the right thing will
be done behind the scenes. This is the only driver left using the
other MTRR types -- and since there is no good reason for it now
rip them out.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 62
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index d79a0ac..191156b 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -404,60 +404,30 @@ static int vesafb_probe(struct platform_device *dev)
* region already (FIXME) */
request_region(0x3c0, 32, vesafb);
+ if (mtrr == 3) {
#ifdef CONFIG_MTRR
- if (mtrr) {
unsigned int temp_size = size_total;
- unsigned int type = 0;
+ int rc;
- switch (mtrr) {
- case 1:
- type = MTRR_TYPE_UNCACHABLE;
- break;
- case 2:
- type = MTRR_TYPE_WRBACK;
- break;
- case 3:
- type = MTRR_TYPE_WRCOMB;
- break;
- case 4:
- type = MTRR_TYPE_WRTHROUGH;
- break;
- default:
- type = 0;
- break;
- }
-
- if (type) {
- int rc;
-
- /* Find the largest power-of-two */
- temp_size = roundup_pow_of_two(temp_size);
+ /* Find the largest power-of-two */
+ temp_size = roundup_pow_of_two(temp_size);
- /* Try and find a power of two to add */
- do {
- rc = mtrr_add(vesafb_fix.smem_start, temp_size,
- type, 1);
- temp_size = 1;
- } while (temp_size = PAGE_SIZE rc == -EINVAL);
- }
- }
+ /* Try and find a power of two to add */
+ do {
+ rc = mtrr_add(vesafb_fix.smem_start, temp_size,
+ MTRR_TYPE_WRCOMB, 1);
+ temp_size = 1;
+ } while (temp_size = PAGE_SIZE rc == -EINVAL);
#endif
-
- switch (mtrr) {
- case 1: /* uncachable */
- info-screen_base = ioremap_nocache(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 2: /* write-back */
- info-screen_base = ioremap_cache(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 3: /* write-combining */
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 4: /* write-through */
- default:
+ } else {
+#ifdef CONFIG_MTRR
+ if (mtrr mtrr != 3)
+ WARN_ONCE(1, Only MTRR_TYPE_WRCOMB (3) make sense\n);
+#endif
info-screen_base = ioremap(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
}
+
if (!info-screen_base) {
printk(KERN_ERR
vesafb: abort, cannot ioremap video memory 0x%x @
0x%lx\n,
--
2.3.2.209.gd67f9d5.dirty
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 33/47] video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/savage/savagefb.h| 4 +---
drivers/video/fbdev/savage/savagefb_driver.c | 17 +++--
2 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/video/fbdev/savage/savagefb.h
b/drivers/video/fbdev/savage/savagefb.h
index 8ff4ab1..aba04af 100644
--- a/drivers/video/fbdev/savage/savagefb.h
+++ b/drivers/video/fbdev/savage/savagefb.h
@@ -213,9 +213,7 @@ struct savagefb_par {
void __iomem *vbase;
u32pbase;
u32len;
-#ifdef CONFIG_MTRR
- intmtrr;
-#endif
+ intwc_cookie;
} video;
struct {
diff --git a/drivers/video/fbdev/savage/savagefb_driver.c
b/drivers/video/fbdev/savage/savagefb_driver.c
index 4dbf45f..6c77ab0 100644
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -57,10 +57,6 @@
#include asm/irq.h
#include asm/pgtable.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include savagefb.h
@@ -1775,7 +1771,7 @@ static int savage_map_video(struct fb_info *info, int
video_len)
par-video.pbase = pci_resource_start(par-pcidev, resource);
par-video.len = video_len;
- par-video.vbase = ioremap(par-video.pbase, par-video.len);
+ par-video.vbase = ioremap_wc(par-video.pbase, par-video.len);
if (!par-video.vbase) {
printk(savagefb: unable to map screen memory\n);
@@ -1787,11 +1783,7 @@ static int savage_map_video(struct fb_info *info, int
video_len)
info-fix.smem_start = par-video.pbase;
info-fix.smem_len = par-video.len - par-cob_size;
info-screen_base= par-video.vbase;
-
-#ifdef CONFIG_MTRR
- par-video.mtrr = mtrr_add(par-video.pbase, video_len,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-video.wc_cookie = arch_phys_wc_add(par-video.pbase, video_len);
/* Clear framebuffer, it's all white in memory after boot */
memset_io(par-video.vbase, 0, par-video.len);
@@ -1806,10 +1798,7 @@ static void savage_unmap_video(struct fb_info *info)
DBG(savage_unmap_video);
if (par-video.vbase) {
-#ifdef CONFIG_MTRR
- mtrr_del(par-video.mtrr, par-video.pbase, par-video.len);
-#endif
-
+ arch_phys_wc_del(par-video.wc_cookie);
iounmap(par-video.vbase);
[Xen-devel] [PATCH v1 37/47] video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/i740fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204..452e116 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
#include linux/console.h
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include i740_reg.h
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
- int mtrr_reg;
-#endif
+ int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
goto err_request_regions;
}
- info-screen_base = pci_ioremap_bar(dev, 0);
+ info-screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info-screen_base) {
dev_err(info-device, error remapping base\n);
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const
struct pci_device_id *ent)
fb_info(info, %s frame buffer device\n, info-fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
- info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
err_reg_framebuffer:
@@ -1177,13 +1164,7 @@ static void i740fb_remove(struct pci_dev *dev)
if (info) {
struct i740fb_par *par = info-par;
-
-#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
-#endif
+ arch_phys_wc_del(par-wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(info-cmap);
if (par-ddc_registered)
@@ -1287,10 +1268,8 @@ static int __init i740fb_setup(char *options)
while ((opt = strsep(options, ,)) != NULL) {
if (!*opt)
[Xen-devel] [PATCH v1 42/47] video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/tdfxfb.c | 41 ++---
include/video/tdfx.h | 2 +-
2 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index f761fe3..621fa44 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -78,24 +78,6 @@
#define DPRINTK(a, b...) pr_debug(fb: %s: a, __func__ , ## b)
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#else
-/* duplicate asm/mtrr.h defines to work on archs without mtrr */
-#define MTRR_TYPE_WRCOMB 1
-
-static inline int mtrr_add(unsigned long base, unsigned long size,
- unsigned int type, char increment)
-{
-return -ENODEV;
-}
-static inline int mtrr_del(int reg, unsigned long base,
- unsigned long size)
-{
-return -ENODEV;
-}
-#endif
-
#define BANSHEE_MAX_PIXCLOCK 27
#define VOODOO3_MAX_PIXCLOCK 30
#define VOODOO5_MAX_PIXCLOCK 35
@@ -167,7 +149,6 @@ static int nopan;
static int nowrap = 1; /* not implemented (yet) */
static int hwcursor = 1;
static char *mode_option;
-/* mtrr option */
static bool nomtrr;
/* -
@@ -1454,8 +1435,8 @@ static int tdfxfb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto out_err_regbase;
}
- info-screen_base = ioremap_nocache(info-fix.smem_start,
- info-fix.smem_len);
+ info-screen_base = ioremap_wc(info-fix.smem_start,
+ info-fix.smem_len);
if (!info-screen_base) {
printk(KERN_ERR fb: Can't remap %s framebuffer.\n,
info-fix.id);
@@ -1473,11 +1454,9 @@ static int tdfxfb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
printk(KERN_INFO fb: %s memory = %dK\n, info-fix.id,
info-fix.smem_len 10);
- default_par-mtrr_handle = -1;
if (!nomtrr)
- default_par-mtrr_handle =
- mtrr_add(info-fix.smem_start, info-fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
+ default_par-wc_cookie= arch_phys_wc_add(info-fix.smem_start,
+info-fix.smem_len);
[Xen-devel] [Patch V2 2/2] xen: before ballooning hotplugged memory, set frames to invalid
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be invalid instead of identity in the
p2m list before they can be added.
Suggested-by: David Vrabel david.vra...@citrix.com
Signed-off-by: Juergen Gross jgr...@suse.com
---
drivers/xen/balloon.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0b52d92..65fedb8 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -229,6 +229,19 @@ static enum bp_state reserve_additional_memory(long credit)
balloon_hotplug = round_up(balloon_hotplug, PAGES_PER_SECTION);
nid = memory_add_physaddr_to_nid(hotplug_start_paddr);
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ unsigned long pfn, i;
+
+ pfn = PFN_DOWN(hotplug_start_paddr);
+ for (i = 0; i balloon_hotplug; i++)
+ if (!set_phys_to_machine(pfn + i, INVALID_P2M_ENTRY)) {
+ pr_warn(set_phys_to_machine() failed, no
memory added\n);
+ return BP_ECANCELED;
+ }
+ }
+#endif
+
rc = add_memory(nid, hotplug_start_paddr, balloon_hotplug
PAGE_SHIFT);
if (rc) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [Patch V2 0/2] xen: fix regressions regarding memory hotplug in pv domains
Fix some regressions introduced in 3.16 and 3.19. Changes in V2: - use range in Kconfig instead of BUILD_BUG_ON_MSG() as suggested by Boris Ostrovsky and Paul Bolle - simplify ifdeffery regarding P2M_LIMIT in patch 1 as requested by David Vrabel - changed test for failure of set_phys_to_machine() in patch 2 as requested by David Vrabel and Daniel Kiper - only call set_phys_to_machine() for pv domains as requested by Daniel Kiper Juergen Gross (2): xen: prepare p2m list for memory hotplug xen: before ballooning hotplugged memory, set frames to invalid arch/x86/xen/p2m.c| 10 +- drivers/xen/Kconfig | 14 ++ drivers/xen/balloon.c | 13 + 3 files changed, 36 insertions(+), 1 deletion(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Patch V2 1/2] xen: prepare p2m list for memory hotplug
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv-domain: as the virtual space for the p2m list
is allocated for the to be expected memory size of the domain only,
hotplugged memory above that size will not be usable by the domain.
Correct this by using a configurable size for the p2m list in case of
memory hotplug enabled (default supported memory size is 512 GB for
64 bit domains and 4 GB for 32 bit domains).
Signed-off-by: Juergen Gross jgr...@suse.com
---
arch/x86/xen/p2m.c | 10 +-
drivers/xen/Kconfig | 14 ++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9f93af5..b47124d 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -91,6 +91,12 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
unsigned long xen_max_p2m_pfn __read_mostly;
EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
+#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
+#define P2M_LIMIT CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
+#else
+#define P2M_LIMIT 0
+#endif
+
static DEFINE_SPINLOCK(p2m_update_lock);
static unsigned long *p2m_mid_missing_mfn;
@@ -385,9 +391,11 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
void __init xen_vmalloc_p2m_tree(void)
{
static struct vm_struct vm;
+ unsigned long p2m_limit;
+ p2m_limit = (phys_addr_t)P2M_LIMIT * 1024 * 1024 * 1024 / PAGE_SIZE;
vm.flags = VM_ALLOC;
- vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+ vm.size = ALIGN(sizeof(unsigned long) * max(xen_max_p2m_pfn, p2m_limit),
PMD_SIZE * PMDS_PER_MID_PAGE);
vm_area_register_early(vm, PMD_SIZE * PMDS_PER_MID_PAGE);
pr_notice(p2m virtual area at %p, size is %lx\n, vm.addr, vm.size);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..0f1b509 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -55,6 +55,20 @@ config XEN_BALLOON_MEMORY_HOTPLUG
In that case step 3 should be omitted.
+config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
+ int
+ default 512 if X86_64
+ default 4 if X86_32
+ range 0 64 if X86_32
+ depends on XEN_HAVE_PVMMU
+ depends on XEN_BALLOON_MEMORY_HOTPLUG
+ help
+ Upper limit in GBs a pv domain can be expanded to using memory
+ hotplug.
+
+ This value is used to allocate enough space in internal tables needed
+ for physical memory administration.
+
config XEN_SCRUB_PAGES
bool Scrub pages before returning them to system
depends on XEN_BALLOON
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/22] xen/arm: Add ITS support
Hi Vijay, On 19/03/2015 14:37, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Add ITS support for arm. Following major features are supported - GICv3 ITS support for arm64 platform - Supports multi ITS node - LPI descriptors are allocated on-demand - Only ITS Dom0 is supported Tested with single ITS node. It would have been nice to give a link to your github in this cover letter too. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/8] libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc
On Thu, Mar 19, 2015 at 05:54:03PM -0400, Boris Ostrovsky wrote:
xc_numainfo() is not expected to be used on a hot path and therefore
hypercall buffer management can be pushed into libxc. This will simplify
life for callers.
Also update error logging macros.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
Changes in v5:
* Adjust to new interface (as described in changelog for patch 4/8)
tools/libxc/include/xenctrl.h |4 ++-
tools/libxc/xc_misc.c | 41 -
tools/libxl/libxl.c | 52
-
tools/python/xen/lowlevel/xc/xc.c | 38 ++-
4 files changed, 68 insertions(+), 67 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 14d22ce..54540e7 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1228,6 +1228,7 @@ int xc_send_debug_keys(xc_interface *xch, char *keys);
typedef xen_sysctl_physinfo_t xc_physinfo_t;
typedef xen_sysctl_cputopo_t xc_cputopo_t;
typedef xen_sysctl_numainfo_t xc_numainfo_t;
+typedef xen_sysctl_meminfo_t xc_meminfo_t;
typedef uint32_t xc_cpu_to_node_t;
typedef uint32_t xc_cpu_to_socket_t;
@@ -1239,7 +1240,8 @@ typedef uint32_t xc_node_to_node_dist_t;
int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
int xc_cputopoinfo(xc_interface *xch, unsigned *max_cpus,
xc_cputopo_t *cputopo);
-int xc_numainfo(xc_interface *xch, xc_numainfo_t *info);
+int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
+xc_meminfo_t *meminfo, uint32_t *distance);
int xc_sched_id(xc_interface *xch,
int *sched_id);
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 411128e..607ae61 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -209,22 +209,49 @@ out:
return ret;
}
-int xc_numainfo(xc_interface *xch,
-xc_numainfo_t *put_info)
+int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
+xc_meminfo_t *meminfo, uint32_t *distance)
{
int ret;
DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(meminfo, *max_nodes * sizeof(*meminfo),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(distance,
+ *max_nodes * *max_nodes * sizeof(*distance),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-sysctl.cmd = XEN_SYSCTL_numainfo;
+if (meminfo distance) {
The syntax in xc_misc.c looks mostly to be of the
'if ( meminfo distance )
{
' type.
+if ((ret = xc_hypercall_bounce_pre(xch, meminfo)))
+goto out;
+if ((ret = xc_hypercall_bounce_pre(xch, distance)))
+goto out;
-memcpy(sysctl.u.numainfo, put_info, sizeof(*put_info));
+sysctl.u.numainfo.num_nodes = *max_nodes;
+set_xen_guest_handle(sysctl.u.numainfo.meminfo, meminfo);
+set_xen_guest_handle(sysctl.u.numainfo.distance, distance);
+} else if (meminfo || distance) {
+errno = EINVAL;
+return -1;
+} else {
+set_xen_guest_handle(sysctl.u.numainfo.meminfo,
+ HYPERCALL_BUFFER_NULL);
+set_xen_guest_handle(sysctl.u.numainfo.distance,
+ HYPERCALL_BUFFER_NULL);
+}
+sysctl.cmd = XEN_SYSCTL_numainfo;
if ((ret = do_sysctl(xch, sysctl)) != 0)
-return ret;
+goto out;
-memcpy(put_info, sysctl.u.numainfo, sizeof(*put_info));
+*max_nodes = sysctl.u.numainfo.num_nodes;
-return 0;
+out:
+if (meminfo distance) {
+xc_hypercall_bounce_post(xch, meminfo);
+xc_hypercall_bounce_post(xch, distance);
+}
+
+return ret;
}
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2b7d19c..ee97a54 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5094,62 +5094,44 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx
*ctx, int *nb_cpu_out)
libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
{
GC_INIT(ctx);
-xc_numainfo_t ninfo;
-DECLARE_HYPERCALL_BUFFER(xen_sysctl_meminfo_t, meminfo);
-DECLARE_HYPERCALL_BUFFER(uint32_t, distance);
+xc_meminfo_t *meminfo;
+uint32_t *distance;
libxl_numainfo *ret = NULL;
int i, j;
+unsigned num_nodes;
-set_xen_guest_handle(ninfo.meminfo, HYPERCALL_BUFFER_NULL);
-set_xen_guest_handle(ninfo.distance, HYPERCALL_BUFFER_NULL);
-if ( xc_numainfo(ctx-xch, ninfo) != 0)
-{
-LIBXL__LOG(ctx, XTL_ERROR, Unable to determine number of NODES);
-ret = NULL;
+if (xc_numainfo(ctx-xch, num_nodes, NULL, NULL)) {
I think for this one you need 'if ( xc_numa.. )
{'
+LOGEV(ERROR, errno, Unable to determine number of nodes);
goto out;
}
-meminfo =
Re: [Xen-devel] [PATCH v5 6/8] libxl/libxc: Move libxl_get_cpu_topology()'s hypercall buffer management to libxc
On Fri, 2015-03-20 at 10:24 -0400, Boris Ostrovsky wrote:
On 03/20/2015 09:54 AM, Ian Campbell wrote:
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
+if (cputopo) {
+if ((ret = xc_hypercall_bounce_pre(xch, cputopo)))
I think this guy will tolerate a NULL here (and on post), so I
think/hope you can get away without this conditional stuff. Can you give
it a go please.
I'll see if this works. (I can't mentally unwrap all these macros, I'll
need to test it. Or at least run it through pre-processor)
The important function is xc__hypercall_bounce_pre which handles
b-ubuf==NULL.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
-Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: Friday, March 20, 2015 8:20 PM To: Pang, LongtaoX Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com; Hu, Robert Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote: Add xen-devel in mail loop. Here is what I wrong in reply to the private version without noticing that it was private. On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: Friday, March 20, 2015 12:27 AM To: Pang, LongtaoX Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com; Hu, Robert Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: From: longtao.pang longtaox.p...@intel.com 1. Designate vif model to 'e1000', otherwise, with default device model, the L1 eth0 interface disappear, hence xenbridge cannot work. Maybe this limitation can be removed later after some fix it. For now, we have to accomodate to it. You have done this unconditionally, which means it affects all guests. You need to make this configurable by the caller, probably by plumbing it through in $xopts (a hash of extra options). I see now you were told this last time around by Ian J, please don't just resend such things without change either fix them, make an argument for doing it your way or ask for clarification if you don't understand the requested change. Thanks for your advice, I will try it. But, do you have any idea about below issue that confused me? After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp driver(Realtek RTL-8139), that cause L1 guest's network unavailable, and I have to specify 'model=e1000' to make L1's network available. The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS). Could just be a bug in Debian's kernel. Without more information it's rather hard to say. 2. Since reboot L1 guest VM will take more time to boot up, we increase multi-times for reboot-confirm-booted if test nested job, and the multi value is stored as a runvar in 'ts-nested-setup' script. Added another function 'guest_editconfig_cd' and expose it, this function bascically changes guest boot device sequence, alter its on_reboot behavior to restart and enabled nestedhvm feature. This looks like two items run together? The multi_reboot_time thing sounds ok, but it should be called reboot_time_factor or something like that. In fact I see that Ian suggested previously that it should have the host ident in it, that makes sense to me. I will try it. Also, how do you handle below question after reboot host OS during running OSSTest job? After finishing L0 and L1 host installation, the OSs will take a lot time(about 150s) to start MTA service and NTP service. I know that, the poll_loop timeout is 40s of 'reboot-confirm-booted', that's why timeout happened when calling 'host_reboot' function after reboot host OS. I'm afraid I don't know what you are asking here. When rebooting Debian L0 or Debian L1 guest, during booting, it will take a lot of time(about 150s) to starting MTA and NTP service, and then boot into Debian OS. But, only boot into OS completely, ' osstest-confirm-booted' shell script in '/etc/init.d' will start and generate 'reboot-confirm-booted' file at '/dev/shm' directory, only if the ' reboot-confirm-booted' file exist, then the function of 'host_reboot' is called successfully. As 'host_reboot' function in TestSupport.pm, the 'poll_loop' timeout is 40s, in my osstest env, after reboot L0 or L1 and then calling 'host_reboot' function, always cause the 'poll_loop' timeout and exit test. The editconfig_cd thing -- yet another thing which Ian questioned and which it was agreed you would change but you haven't. For this question, I have sent a mail about it.(2015-03-04) After finishing L1 guest VM installation, we need to change L1 guest boot sequence from ISO image to hard disk, we need modify the boot=cd , Do you? As Ian asked before, why is guest_editconfig_nocd not sufficient? It removes the CD from the virtual drive, meaning that boot=dc will fail to boot from d and fallthru to c. also need to enable 'nestedhvm' feature in hvm configure file, This certainly doesn't belong in a function called guest_editconfig_cd, since it has nothing to do with cds at all. Anyway, it's not clear why you need to edit this into the nestedhvm configuration, instead of adding it when the configuration is created via more_prepareguest_hvm. What harm is there in enabling this during guest install? I will try it. Ian.
Re: [Xen-devel] [PATCH v5 7/8] libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc
On Fri, 2015-03-20 at 10:10 -0400, Boris Ostrovsky wrote: I actually think it's the other way around: when I made the first change in 4/8 I added spaces, which this file's style generally doesn't use. Which, conveniently, is different from the style used by xc_misc.c Right, libxc uses the Xen coding style (top-level CODING_STYLE) while libxl uses its own (tools/libxc/CODING_STYLE). In some cases for very loose values of uses though, sorry. And I am quite confused about curly bracket positions. They are all over the place (pun intended). In libxc they go on the next line (Xen style) in libxl they go on the same line (libxl style). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 5/8] sysctl: Add sysctl interface for querying PCI topology
On Thu, Mar 19, 2015 at 05:54:01PM -0400, Boris Ostrovsky wrote:
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Changes in v5:
* Increment ti-first_dev in the loop
* Make node in xen_sysctl_pcitopoinfo a uint32
* Move sysctl to follow hearder file's order
* Update comments in sysctl.h
xen/common/sysctl.c | 61
+++
xen/include/public/sysctl.h | 28 +++
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index acaeeb2..c73dfc9 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -399,6 +399,67 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
break;
#endif
+#ifdef HAS_PCI
+case XEN_SYSCTL_pcitopoinfo:
+{
+xen_sysctl_pcitopoinfo_t *ti = op-u.pcitopoinfo;
+
+if ( guest_handle_is_null(ti-devs) ||
+ guest_handle_is_null(ti-nodes) ||
+ (ti-first_dev ti-num_devs) )
+{
+ret = -EINVAL;
+break;
+}
+
+while ( ti-first_dev ti-num_devs )
+{
+physdev_pci_device_t dev;
+uint32_t node;
+struct pci_dev *pdev;
+
+if ( copy_from_guest_offset(dev, ti-devs, ti-first_dev, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+spin_lock(pcidevs_lock);
+pdev = pci_get_pdev(dev.seg, dev.bus, dev.devfn);
+if ( !pdev || (pdev-node == NUMA_NO_NODE) )
+node = XEN_INVALID_NODE_ID;
+else
+node = pdev-node;
+spin_unlock(pcidevs_lock);
+
+if ( copy_to_guest_offset(ti-nodes, ti-first_dev, node, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+ti-first_dev++;
+
+if ( hypercall_preempt_check() )
+break;
+}
+
+if ( !ret )
+{
+if ( __copy_field_to_guest(u_sysctl, op,
u.pcitopoinfo.first_dev) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( ti-first_dev ti-num_devs )
+ret = hypercall_create_continuation(__HYPERVISOR_sysctl,
+h, u_sysctl);
+}
+}
+break;
+#endif
+
default:
ret = arch_do_sysctl(op, u_sysctl);
copyback = 0;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 7e0d5fe..ceb8ac8 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -33,6 +33,7 @@
#include xen.h
#include domctl.h
+#include physdev.h
#define XEN_SYSCTL_INTERFACE_VERSION 0x000C
@@ -668,6 +669,31 @@ struct xen_sysctl_psr_cmt_op {
typedef struct xen_sysctl_psr_cmt_op xen_sysctl_psr_cmt_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_psr_cmt_op_t);
+/* XEN_SYSCTL_pcitopoinfo */
+struct xen_sysctl_pcitopoinfo {
+/* IN: Number of elements in 'pcitopo' and 'nodes' arrays */
+uint32_t num_devs;
+
+/*
+ * IN/OUT: First element of pcitopo array that needs to be processed by
+ * hypervisor.
+ * This is used by hypercall continuations, callers must set it to zero.
+ */
+uint32_t first_dev;
+
+/* IN: list of devices */
+XEN_GUEST_HANDLE_64(physdev_pci_device_t) devs;
+
+/*
+ * OUT: node identifier for each device.
+ * If information for a particular device is not avalable then set
+ * to XEN_INVALID_NODE_ID.
+ */
+XEN_GUEST_HANDLE_64(uint32) nodes;
+};
+typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
+
struct xen_sysctl {
uint32_t cmd;
#define XEN_SYSCTL_readconsole1
@@ -690,12 +716,14 @@ struct xen_sysctl {
#define XEN_SYSCTL_scheduler_op 19
#define XEN_SYSCTL_coverage_op 20
#define XEN_SYSCTL_psr_cmt_op21
+#define XEN_SYSCTL_pcitopoinfo 22
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
struct xen_sysctl_tbuf_op tbuf_op;
struct xen_sysctl_physinfo physinfo;
struct xen_sysctl_cputopoinfo cputopoinfo;
+struct xen_sysctl_pcitopoinfo pcitopoinfo;
struct xen_sysctl_numainfo numainfo;
struct xen_sysctl_sched_id sched_id;
struct xen_sysctl_perfc_op perfc_op;
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch V2 2/2] xen: before ballooning hotplugged memory, set frames to invalid
On 03/20/2015 02:46 PM, Daniel Kiper wrote:
On Fri, Mar 20, 2015 at 01:55:39PM +0100, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be invalid instead of identity in the
p2m list before they can be added.
Suggested-by: David Vrabel david.vra...@citrix.com
Signed-off-by: Juergen Gross jgr...@suse.com
In general...
Reviewed-by: Daniel Kiper daniel.ki...@oracle.com
... but...
---
drivers/xen/balloon.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0b52d92..65fedb8 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -229,6 +229,19 @@ static enum bp_state reserve_additional_memory(long credit)
balloon_hotplug = round_up(balloon_hotplug, PAGES_PER_SECTION);
nid = memory_add_physaddr_to_nid(hotplug_start_paddr);
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ unsigned long pfn, i;
+
+ pfn = PFN_DOWN(hotplug_start_paddr);
+ for (i = 0; i balloon_hotplug; i++)
+ if (!set_phys_to_machine(pfn + i, INVALID_P2M_ENTRY)) {
+ pr_warn(set_phys_to_machine() failed, no memory
added\n);
+ return BP_ECANCELED;
+ }
+ }
+#endif
Should not we fill everything above maxmem with
INVALID_P2M_ENTRY at boot time?
In this case we shouldn't report identity for pfns above maxmem, too.
Otherwise we could change behaviour of the kernel regarding PCI
passthrough just by changing CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
which doesn't sound right.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/8] sysctl: Make XEN_SYSCTL_numainfo a little more efficient
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote: A number of changes to XEN_SYSCTL_numainfo interface: * Make sysctl NUMA topology query use fewer copies by combining some fields into a single structure and copying distances for each node in a single copy. * NULL meminfo and distance handles are a request for maximum number of nodes (num_nodes). If those handles are valid and num_nodes is is smaller than the number of nodes in the system then -ENOBUFS is returned (and correct num_nodes is provided) * Instead of using max_node_index for passing number of nodes keep this value in num_nodes: almost all uses of max_node_index required adding or subtracting one to eventually get to number of nodes anyway. * Replace INVALID_NUMAINFO_ID with XEN_INVALID_MEM_SZ and add XEN_INVALID_NODE_DIST. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/8] numa: __node_distance() should return u8
On Thu, Mar 19, 2015 at 05:53:57PM -0400, Boris Ostrovsky wrote:
SLIT values are byte-sized and some of them (0-9 and 255) have
special meaning. Adjust __node_distance() to reflect this and
modify scrub_heap_pages() and do_sysctl() to deal with
__node_distance() returning an invalid SLIT entry.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Changes in v5:
* XEN_SYSCTL_numainfo knows about NUMA_NO_DISTANCE
* Cleaner changes in __node_distance()
xen/arch/x86/srat.c| 13 ++---
xen/common/page_alloc.c|4 ++--
xen/common/sysctl.c|6 +-
xen/include/asm-x86/numa.h |2 +-
xen/include/xen/numa.h |3 ++-
5 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index dfabba3..92c89a5 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -496,14 +496,21 @@ static unsigned node_to_pxm(nodeid_t n)
return 0;
}
-int __node_distance(nodeid_t a, nodeid_t b)
+u8 __node_distance(nodeid_t a, nodeid_t b)
{
- int index;
+ unsigned index;
+ u8 slit_val;
if (!acpi_slit)
return a == b ? 10 : 20;
index = acpi_slit-locality_count * node_to_pxm(a);
- return acpi_slit-entry[index + node_to_pxm(b)];
+ slit_val = acpi_slit-entry[index + node_to_pxm(b)];
+
+ /* ACPI defines 0xff as an unreachable node and 0-9 are undefined */
+ if ((slit_val == 0xff) || (slit_val = 9))
+ return NUMA_NO_DISTANCE;
+ else
+ return slit_val;
}
EXPORT_SYMBOL(__node_distance);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index d999296..bfb356e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1434,13 +1434,13 @@ void __init scrub_heap_pages(void)
/* Figure out which NODE CPUs are close. */
for_each_online_node ( j )
{
-int distance;
+u8 distance;
if ( cpumask_empty(node_to_cpumask(j)) )
continue;
distance = __node_distance(i, j);
-if ( distance last_distance )
+if ( (distance last_distance) (distance !=
NUMA_NO_DISTANCE) )
{
last_distance = distance;
best_node = j;
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..6fdd029 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -304,7 +304,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
{
uint32_t distance = ~0u;
if ( node_online(i) node_online(j) )
-distance = __node_distance(i, j);
+{
+u8 d = __node_distance(i, j);
+if ( d != NUMA_NO_DISTANCE )
+distance = d;
+}
if ( copy_to_guest_offset(
ni-node_to_node_distance,
i*(max_node_index+1) + j, distance, 1) )
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index cc5b5d1..7a489d3 100644
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -85,6 +85,6 @@ extern int valid_numa_range(u64 start, u64 end, nodeid_t
node);
#endif
void srat_parse_regions(u64 addr);
-extern int __node_distance(nodeid_t a, nodeid_t b);
+extern u8 __node_distance(nodeid_t a, nodeid_t b);
#endif
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index ac4b391..7aef1a8 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -7,7 +7,8 @@
#define NODES_SHIFT 0
#endif
-#define NUMA_NO_NODE0xFF
+#define NUMA_NO_NODE 0xFF
+#define NUMA_NO_DISTANCE 0xFF
#define MAX_NUMNODES(1 NODES_SHIFT)
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] swap out guest physical page
On Fri, 2015-03-20 at 13:09 +0100, HANNAS YAYA Issa wrote: Hi Is it possible to swap out guest physical page from hypervisor in xen The keyword you need in the context of Xen is paging not swap, with that you should be able to find docs in the source tree and the wiki etc. Paging happens from a userspace utility in a control domain, not from within the hypervisor (which has no real useful i/o devices to swap to). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote: Add xen-devel in mail loop. Here is what I wrong in reply to the private version without noticing that it was private. On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: Friday, March 20, 2015 12:27 AM To: Pang, LongtaoX Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com; Hu, Robert Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: From: longtao.pang longtaox.p...@intel.com 1. Designate vif model to 'e1000', otherwise, with default device model, the L1 eth0 interface disappear, hence xenbridge cannot work. Maybe this limitation can be removed later after some fix it. For now, we have to accomodate to it. You have done this unconditionally, which means it affects all guests. You need to make this configurable by the caller, probably by plumbing it through in $xopts (a hash of extra options). I see now you were told this last time around by Ian J, please don't just resend such things without change either fix them, make an argument for doing it your way or ask for clarification if you don't understand the requested change. Thanks for your advice, I will try it. But, do you have any idea about below issue that confused me? After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp driver(Realtek RTL-8139), that cause L1 guest's network unavailable, and I have to specify 'model=e1000' to make L1's network available. The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS). Could just be a bug in Debian's kernel. Without more information it's rather hard to say. 2. Since reboot L1 guest VM will take more time to boot up, we increase multi-times for reboot-confirm-booted if test nested job, and the multi value is stored as a runvar in 'ts-nested-setup' script. Added another function 'guest_editconfig_cd' and expose it, this function bascically changes guest boot device sequence, alter its on_reboot behavior to restart and enabled nestedhvm feature. This looks like two items run together? The multi_reboot_time thing sounds ok, but it should be called reboot_time_factor or something like that. In fact I see that Ian suggested previously that it should have the host ident in it, that makes sense to me. I will try it. Also, how do you handle below question after reboot host OS during running OSSTest job? After finishing L0 and L1 host installation, the OSs will take a lot time(about 150s) to start MTA service and NTP service. I know that, the poll_loop timeout is 40s of 'reboot-confirm-booted', that's why timeout happened when calling 'host_reboot' function after reboot host OS. I'm afraid I don't know what you are asking here. The editconfig_cd thing -- yet another thing which Ian questioned and which it was agreed you would change but you haven't. For this question, I have sent a mail about it.(2015-03-04) After finishing L1 guest VM installation, we need to change L1 guest boot sequence from ISO image to hard disk, we need modify the boot=cd , Do you? As Ian asked before, why is guest_editconfig_nocd not sufficient? It removes the CD from the virtual drive, meaning that boot=dc will fail to boot from d and fallthru to c. also need to enable 'nestedhvm' feature in hvm configure file, This certainly doesn't belong in a function called guest_editconfig_cd, since it has nothing to do with cds at all. Anyway, it's not clear why you need to edit this into the nestedhvm configuration, instead of adding it when the configuration is created via more_prepareguest_hvm. What harm is there in enabling this during guest install? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/8] libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 411128e..607ae61 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -209,22 +209,49 @@ out:
return ret;
}
-int xc_numainfo(xc_interface *xch,
-xc_numainfo_t *put_info)
+int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
+xc_meminfo_t *meminfo, uint32_t *distance)
{
int ret;
DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(meminfo, *max_nodes * sizeof(*meminfo),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(distance,
+ *max_nodes * *max_nodes * sizeof(*distance),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-sysctl.cmd = XEN_SYSCTL_numainfo;
+if (meminfo distance) {
+if ((ret = xc_hypercall_bounce_pre(xch, meminfo)))
+goto out;
+if ((ret = xc_hypercall_bounce_pre(xch, distance)))
+goto out;
Same comment about handling NULL as before.
In addition what if only one of meminfo and distance is NULL? Is that
valid or do you need a !!meminfo ^ !!distance check?
Rests looks ok.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/8] libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc
On 03/20/2015 09:56 AM, Ian Campbell wrote:
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 411128e..607ae61 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -209,22 +209,49 @@ out:
return ret;
}
-int xc_numainfo(xc_interface *xch,
-xc_numainfo_t *put_info)
+int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
+xc_meminfo_t *meminfo, uint32_t *distance)
{
int ret;
DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(meminfo, *max_nodes * sizeof(*meminfo),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(distance,
+ *max_nodes * *max_nodes * sizeof(*distance),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-sysctl.cmd = XEN_SYSCTL_numainfo;
+if (meminfo distance) {
+if ((ret = xc_hypercall_bounce_pre(xch, meminfo)))
+goto out;
+if ((ret = xc_hypercall_bounce_pre(xch, distance)))
+goto out;
Same comment about handling NULL as before.
In addition what if only one of meminfo and distance is NULL? Is that
valid or do you need a !!meminfo ^ !!distance check?
I want to treat this as as an error here, which is why I have
} else if (meminfo || distance) {
errno = EINVAL;
return -1;
}
because the hypervisor will only attempt to copy numainfo things when
both are valid. Otherwise (i.e. even if only one is a NULL) it will
assume that this is a request for size. The alternative would be to add
another error there, which I decided not to do.
-boris
Rests looks ok.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/13] libxc: Check xc_domain_maximum_gpfn for negative return values
On Fri, Mar 20, 2015 at 09:48:08AM +, Ian Campbell wrote: On Thu, 2015-03-19 at 14:54 -0400, Konrad Rzeszutek Wilk wrote: On Thu, Mar 19, 2015 at 04:47:58PM +, Ian Campbell wrote: On Wed, 2015-03-18 at 20:24 -0400, Konrad Rzeszutek Wilk wrote: Instead of assuming everything is always OK. We stash the gpfns value as an parameter. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- tools/libxc/xc_core_arm.c| 17 ++--- tools/libxc/xc_core_x86.c| 24 tools/libxc/xc_domain_save.c | 8 +++- 3 files changed, 41 insertions(+), 8 deletions(-) diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c index 16508e7..26cec04 100644 --- a/tools/libxc/xc_core_arm.c +++ b/tools/libxc/xc_core_arm.c @@ -31,9 +31,16 @@ xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt, } -static int nr_gpfns(xc_interface *xch, domid_t domid) +static int nr_gpfns(xc_interface *xch, domid_t domid, unsigned long *gpfns) You didn't fancy merging the two versions of this then ;-) I was not sure where you would want to put them. xc_private looks like the best place, but perhaps it should be in an new file? I also suggested just changing the interface of xc_domain_maximum_gpfn, in which case it can stay in xc_domain.c. TBH there seems little point in xc_domain_maximum_gpfn if all callers are using a wrapper, so I think I'd advocate this approach. Duh, that would be much simpler. Let me respin a patch for that. If you want to stick with a wrapper for some reason then xc_private.c would be an ok choice (its a dumping ground already), or xc_misc.c seems to have a bunch of not dissimilar functionality in it. I think a new file would be overkill. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch V2 2/2] xen: before ballooning hotplugged memory, set frames to invalid
On 03/20/2015 02:44 PM, Boris Ostrovsky wrote:
On 03/20/2015 08:55 AM, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be invalid instead of identity in the
p2m list before they can be added.
Suggested-by: David Vrabel david.vra...@citrix.com
Signed-off-by: Juergen Gross jgr...@suse.com
---
drivers/xen/balloon.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0b52d92..65fedb8 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -229,6 +229,19 @@ static enum bp_state
reserve_additional_memory(long credit)
balloon_hotplug = round_up(balloon_hotplug, PAGES_PER_SECTION);
nid = memory_add_physaddr_to_nid(hotplug_start_paddr);
+#ifdef CONFIG_XEN_HAVE_PVMMU
+if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+unsigned long pfn, i;
+
+pfn = PFN_DOWN(hotplug_start_paddr);
+for (i = 0; i balloon_hotplug; i++)
+if (!set_phys_to_machine(pfn + i, INVALID_P2M_ENTRY)) {
+pr_warn(set_phys_to_machine() failed, no memory
added\n);
+return BP_ECANCELED;
I should have asked last time --- should we restore [0..i-1] mapping
back to identity on error here? I wonder whether leaving those frames as
invalid (when they are expected to be 'identity') could cause problems
in the future.
The only reason why set_phys_to_machine() can fail is a lack of memory
(which in this case would really be funny: adding memory fails due to a
lack of memory). In case a retry succeeds everything is fine as setting
an invalid entry to invalid again does no harm. In case the invalid
entry does any harm it would have done so without set_phys_to_machine()
failing. So I see no reason to restore the identity entries.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
