[Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan <van.freenix@xxxxxxxxx>]

Introduce pvclk interface which is useful when doing device passthrough
on ARM platform.

To ARM platform, saying embedded SoCs, clock management hardware IP
is controlled by Dom0, DomU does not have clocksource. So we need a
paravirtualized clock source to let DomU can handle device that are
passed through from Dom0.

Signed-off-by: Peng Fan <van.freenix@xxxxxxxxx>
Cc: George Dunlap <george.dunlap@xxxxxxxxxx>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
Cc: Julien Grall <julien.grall@xxxxxxxxxx>
Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
---

V2:
The V1 thread:
http://lists.xen.org/archives/html/xen-devel/2016-01/msg01860.html
The V1 thread binds the interface part to the implementation for linux kernel.
This V2 only contains the pvclk interface part.

In this patch:
Backend,
/local/domain/<X>/backend/vclk/<Y>/nr-clks
/local/domain/<X>/backend/vclk/<Y>/<Z>/name
Y is frontend domid, Z is clk id, name is the clk name.

Frontend,
/local/domain/<X>/device/vclk/clk-ring-ref
/local/domain/<X>/device/vclk/event-channel
/local/domain/<X>/device/vclk/<Y>/name
Y is the clk id.

My original idea is to pass clk name which is parsed from dts.
And not expose clk name to xenstore. DomU pass the name to Dom0,
Dom0 use the name to find correct clk and operate on the clk.

Not sure whether I am right or not, please advise.
I have no knowledge of ACPI, just following Ian's
comment on V1, I add the clk id and expose the info to xenstore,
but discard the devid/bus. If devid/bus is needed, I think we
can encoded it into the clk id part in future.
Exposing the info to xenstore means we need to add entry in xl
configuration file like this: vclks =  ["id:clkname", "id:clkname"] -->
vclks = ["1:uart2-root-clk", "3:gpu-root-clk"]. And the libxl pvclk
should parse the vclks entry and fill the contents to xenstore backend nodes.
The frontend xenstore node will be created, by driver probe function 
when DomU booting or by libxl pvclk before DomU boots.
To my use case, Dom0 and DomU both use device tree, I need to build
the mapping table between id and name, since I use name to lookup
the clk in backend, like this:
"clk = __clk_loopkup(clkname); clk_prepare_enable(clk)". Maybe ACPI
is another different case.

 xen/include/public/io/clkif.h | 129 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 xen/include/public/io/clkif.h

diff --git a/xen/include/public/io/clkif.h b/xen/include/public/io/clkif.h
new file mode 100644
index 0000000..f6f9f20
--- /dev/null
+++ b/xen/include/public/io/clkif.h
@@ -0,0 +1,129 @@
+/*
+ * clkif.h
+ *
+ * CLK I/O interface for Xen guest OSes.
+ *
+ * Copyright (C) 2016, Peng Fan <van.freenix@xxxxxxxxx>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_IO_CLKIF_H__
+#define __XEN_PUBLIC_IO_CLKIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ * The two halves of an Xen pvclk driver utilize nodes within the
+ * XenStore to communicate and negotiate operating parameters.
+ *
+ * Backend:
+ * /local/domain/<X>/backend/vclk/<Y>/nr-clks
+ * /local/domain/<X>/backend/vclk/<Y>/<Z>/name
+ *
+ * X - The backend domid
+ * Y - The frontend domid
+ * Z - The clk id
+ * name - The clk name
+ *
+ * Backend example:
+ * /local/domain/0/backend/vclk/1/nr-clks   --> value 2
+ * /local/domain/0/backend/vclk/1/0/name --> uart2-root-clk
+ * /local/domain/0/backend/vclk/1/1/name --> gpu-root-clk
+ *
+ * /local/domain/0/backend/vclk/2/nr-clks   --> value 1
+ * /local/domain/0/backend/vclk/2/0/name --> lcdif-per-clk
+ *
+ * Frontend:
+ * /local/domain/<X>/device/vclk/clk-ring-ref
+ * /local/domain/<X>/device/vclk/event-channel
+ * /local/domain/<X>/device/vclk/<Y>/name
+ *
+ * Frontend example:
+ * /local/domain/1/device/vclk/0/name --> uart2-root-clk
+ * /local/domain/1/device/vclk/1/name --> gpu-root-clk
+ *
+ * /local/domain/2/device/vclk/0/name -->lcdif-per-clk
+ */
+
+/*
+ * Define the CMDs for communication between frontend and backend
+ *
+ * If the Guest OSes want to ask the privileged OS to operate on
+ * a specific clk, the Guest OSes should pass the CMD to the privileged
+ * OS.The privileged OS will do corresponding clk operation for the
+ * specific clk, according to the CMD from the Guest OSes.
+ *
+ * XEN_CLK_ENABLE: enable clock
+ * XEN_CLK_DISABLE: disable clock
+ * XEN_CLK_PREPARE: prepare a clock source
+ * XEN_CLK_UNPREPARE: undo preparation for a clock souce
+ * XEN_CLK_GET_RATE: get rate of clock
+ * XEN_CLK_SET_RATE: set rate of clock
+ */
+enum {
+       XEN_CLK_ENABLE,
+       XEN_CLK_DISABLE,
+       XEN_CLK_PREPARE,
+       XEN_CLK_UNPREPARE,
+       XEN_CLK_GET_RATE,
+       XEN_CLK_SET_RATE,
+       XEN_CLK_END,
+};
+
+/*
+ * Frontend request
+ *
+ * cmd: command for operation on clk, should be XEN_CLK_[xx],
+ *     excluding XEN_CLK_END. id is the
+ * id: clk id
+ * rate: clock rate. Used for set rate.
+ */
+struct xen_clkif_request {
+       uint32_t cmd;
+       uint32_t id;
+       uint64_t rate;
+};
+typedef struct xen_clkif_request xen_clkif_request_t;
+
+/*
+ * Backend response
+ *
+ * cmd: command for operation on clk, same with the cmd in request.
+ * id: clk id, same with the id in request.
+ * success: indicate failure or success for the cmd.
+ * rate: clock rate. Used for get rate.
+ *
+ * cmd and id are filled by backend and passed to frontend to
+ * let frontend check whether the response is for the current
+ * request or not.
+ */
+struct xen_clkif_response {
+       uint32_t cmd;
+       uint32_t id;
+       uint32_t success;
+       uint64_t rate;
+};
+typedef struct xen_clkif_response xen_clkif_response_t;
+
+DEFINE_RING_TYPES(xen_clkif, struct xen_clkif_request, struct 
xen_clkif_response);
+#define XEN_CLK_RING_SIZE __CONST_RING_SIZE(xen_clkif, PAGE_SIZE)
+
+#endif /* __XEN_PUBLIC_IO_CLKIF_H__ */
-- 
2.6.2


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