Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-11-02 Thread Wei Liu 
On Thu, Nov 01, 2018 at 09:49:13PM +, Julien Grall wrote:
> (+ Wei)
> 
> On 11/1/18 9:15 AM, Omkar Bolla wrote:
> > Hi,
> > 
> > > May I ask why you need the dependency on the rootfs?
> > 
> > I am trying to pass-through the display to guest domain. to do through
> > driver needs clocks. I have written simple basic clock pv frontend and
> > backend.
> > So I thought these clocks must be initialised before display driver
> > initialisation.
> 
> The graphic driver should request the clock, right? So Linux will make sure
> to have the clock before initializing the display.
> 
> > 
> > But if I start both domain and clocks script one after another, clock
> > got initialised properly. Problem solved.
> > But still i have some doubt, is it possible to do some thing in xenbits
> > src to start automatically when we start underprivileged domain?
> 
> I am not entirely sure if we have a way to run a script during domain
> creation. Wei, do you know if that's possible?

There is the hotplug script mechanism which may or may not be what you
need.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-11-01 Thread Omkar Bolla 
Hi,
>
> > I am trying to pass-through the display to guest domain. to do through
> > driver needs clocks. I have written simple basic clock pv frontend and
> > backend.
> > So I thought these clocks must be initialised before display driver
> > initialisation.
>
> The graphic driver should request the clock, right? So Linux will make
> sure to have the clock before initializing the display.
>

We are not using graphics(GPU), I think drm takes care of graphics. And all
clocks needed for display I enabled using clocks PV. Clocks i have checked
in host domain all got enabled properly.


> >
> > But if I start both domain and clocks script one after another, clock
> > got initialised properly. Problem solved.
> > But still i have some doubt, is it possible to do some thing in xenbits
> > src to start automatically when we start underprivileged domain?
>
> I am not entirely sure if we have a way to run a script during domain
> creation. Wei, do you know if that's possible?
>
> A workaround would be to create the domain paused, call the script and
> then unpause it.
>
> 42sh> xl create -p ...
> 42sh> ./myscript.sh
> 42sh> xl unpause 
>

Now, I am doing same way pause and unpauase domain to start PV and it is
working.

>
> >
> > I have one more question about pass-through
> > To implement pass through I took reference from below link
> > https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf
> >
> > I added 'xen-passthrough' to actual dom0 dtb and created new dtb with
> > below nodes in passthrough node
> >
> 
> > dpe: dpe@10004000 {
> > compatible = "hisilicon,hi3660-dpe";
> > status = "ok";
> > #if 0
> > //ACTUAL REG PROPERTY of DISPLAY
> >  reg = <0x0 0xE860 0x0 0x8>,
> >  <0x0 0xFFF35000 0 0x1000>,
> >  <0x0 0xFFF0A000 0 0x1000>,
> >  <0x0 0xFFF31000 0 0x1000>,
> >  <0x0 0xE86C 0 0x1>;
> > #endif
> > //reg = <0x0 0x10004000 0x0 0x8>,
> > reg = <0x0 0x10004000 0x0 0x8>,
> ><0x0 0x10084000 0 0x1000>,
> ><0x0 0x10085000 0 0x1000>,
> ><0x0 0x10086000 0 0x1000>,
> ><0x0 0x100C4000 0 0x1>;
> > //  <0x0 0x10087000 0 0x1>;
> >
> > interrupts = <0 245 4>;
> >
> > clocks = <_xen HI3660_ACLK_GATE_DSS>,
> > <_xen HI3660_PCLK_GATE_DSS>,
> > <_xen HI3660_CLK_GATE_EDC0>,
> > <_xen HI3660_CLK_GATE_LDI0>,
> > <_xen HI3660_CLK_GATE_LDI1>,
> > <_xen HI3660_CLK_GATE_DSS_AXI_MM>,
> > <_xen HI3660_PCLK_GATE_MMBUF>;
> > clock-names = "aclk_dss",
> > "pclk_dss",
> > "clk_edc0",
> > "clk_ldi0",
> > "clk_ldi1",
> > "clk_dss_axi_mm",
> > "pclk_mmbuf";
> >
> > dma-coherent;
> >
> > port {
> > dpe_out: endpoint {
> > remote-endpoint = <_in>;
> > };
> > };
> > };
> >
> > dsi: dsi@10097000 {
> > compatible = "hisilicon,hi3660-dsi";
> > status = "ok";
> > #if 0
> > //ACTUAL REG PROPERTY of DISPLAY
> > reg = <0 0xE8601000 0 0x7F000>,
> >  <0 0xFFF35000 0 0x1000>;
> > #endif
> > //reg = <0 0x10097000 0 0x7F000>,
> > //<0 0x10116000 0 0x1000>;
> > reg = <0 0x10004000 0 0x8>,
> > <0 0x10084000 0 0x1000>;
> >
> > clocks = <_xen HI3660_CLK_GATE_TXDPHY0_REF>,
> > <_xen HI3660_CLK_GATE_TXDPHY1_REF>,
> > <_xen HI3660_CLK_GATE_TXDPHY0_CFG>,
> > <_xen HI3660_CLK_GATE_TXDPHY1_CFG>,
> > <_xen HI3660_PCLK_GATE_DSI0>,
> > <_xen HI3660_PCLK_GATE_DSI1>;
> > clock-names = "clk_txdphy0_ref",
> > "clk_txdphy1_ref",
> > "clk_txdphy0_cfg",
> > "clk_txdphy1_cfg",
> > "pclk_dsi0",
> > "pclk_dsi1";
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > };
> > #endif
> > clocks {
> > compatible = "simple-bus";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > clk_xen: xen_clk@0 {
> > compatible = "xen,xen-vclk";
> > #clock-cells = <1>;
> > };
> > };
> >
> 
> > Below is my 'debian.cfg' file:
> >
> 
> > kernel = "/debian/Image"
> > device_tree="/debian/domu.dtb"
> > memory = 512
> > vcpus = 8
> > cpus = "all"
> > name="debian"
> >
> > # DPE 
> > #iomem = [ "0xE8600,0x80@0x10004", "0xFFF35,1@0x10084",
> > "0xFFF0A,1@0x10085", "0xFFF31,1@0x10086", "0xE86C0,10@0x10087"]
> > #iomem = [ "0xE8600,0x80", "0xFFF35,1", "0xFFF0A,1", "0xFFF31,1",
> > "0xE86C0,10"]
> > irqs = [ 277 ]
> >
> > iomem = [ "0xE8600,80@0x10004" ]
> >
> > iomem = [ "0xFFF35,1@0x10084" ]
> > iomem = [ "0xFFF0A,1@0x10085" ]
> > iomem = [ "0xFFF31,1@0x10086" ]
> > iomem = [ "0xE86C0,10@0x100C4"]
> > #iomem = [ "0xE86C0,10@0x10087"]
> > #iomem = [ "0xE8600,80@0x0" ]
> >
> > # DPE 
> > # DSI 
> > #iomem = [ "0xE8601,0x7F", "0xFFF35,1"]
> > #iomem = [

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-11-01 Thread Julien Grall 

(+ Wei)

On 11/1/18 9:15 AM, Omkar Bolla wrote:

Hi,


May I ask why you need the dependency on the rootfs?


I am trying to pass-through the display to guest domain. to do through 
driver needs clocks. I have written simple basic clock pv frontend and 
backend.
So I thought these clocks must be initialised before display driver 
initialisation.


The graphic driver should request the clock, right? So Linux will make 
sure to have the clock before initializing the display.




But if I start both domain and clocks script one after another, clock 
got initialised properly. Problem solved.
But still i have some doubt, is it possible to do some thing in xenbits 
src to start automatically when we start underprivileged domain?


I am not entirely sure if we have a way to run a script during domain 
creation. Wei, do you know if that's possible?


A workaround would be to create the domain paused, call the script and 
then unpause it.


42sh> xl create -p ...
42sh> ./myscript.sh
42sh> xl unpause 



I have one more question about pass-through
To implement pass through I took reference from below link
https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf

I added 'xen-passthrough' to actual dom0 dtb and created new dtb with 
below nodes in passthrough node


dpe: dpe@10004000 {
compatible = "hisilicon,hi3660-dpe";
status = "ok";
#if 0
//ACTUAL REG PROPERTY of DISPLAY
                         reg = <0x0 0xE860 0x0 0x8>,
                                         <0x0 0xFFF35000 0 0x1000>,
                                         <0x0 0xFFF0A000 0 0x1000>,
                                         <0x0 0xFFF31000 0 0x1000>,
                                         <0x0 0xE86C 0 0x1>;
#endif
//reg = <0x0 0x10004000 0x0 0x8>,
reg = <0x0 0x10004000 0x0 0x8>,
       <0x0 0x10084000 0 0x1000>,
       <0x0 0x10085000 0 0x1000>,
       <0x0 0x10086000 0 0x1000>,
       <0x0 0x100C4000 0 0x1>;
//      <0x0 0x10087000 0 0x1>;

interrupts = <0 245 4>;

clocks = <_xen HI3660_ACLK_GATE_DSS>,
<_xen HI3660_PCLK_GATE_DSS>,
<_xen HI3660_CLK_GATE_EDC0>,
<_xen HI3660_CLK_GATE_LDI0>,
<_xen HI3660_CLK_GATE_LDI1>,
<_xen HI3660_CLK_GATE_DSS_AXI_MM>,
<_xen HI3660_PCLK_GATE_MMBUF>;
clock-names = "aclk_dss",
"pclk_dss",
"clk_edc0",
"clk_ldi0",
"clk_ldi1",
"clk_dss_axi_mm",
"pclk_mmbuf";

dma-coherent;

port {
dpe_out: endpoint {
remote-endpoint = <_in>;
};
};
};

dsi: dsi@10097000 {
compatible = "hisilicon,hi3660-dsi";
status = "ok";
#if 0
//ACTUAL REG PROPERTY of DISPLAY
reg = <0 0xE8601000 0 0x7F000>,
                                         <0 0xFFF35000 0 0x1000>;
#endif
//reg = <0 0x10097000 0 0x7F000>,
//<0 0x10116000 0 0x1000>;
reg = <0 0x10004000 0 0x8>,
<0 0x10084000 0 0x1000>;

clocks = <_xen HI3660_CLK_GATE_TXDPHY0_REF>,
<_xen HI3660_CLK_GATE_TXDPHY1_REF>,
<_xen HI3660_CLK_GATE_TXDPHY0_CFG>,
<_xen HI3660_CLK_GATE_TXDPHY1_CFG>,
<_xen HI3660_PCLK_GATE_DSI0>,
<_xen HI3660_PCLK_GATE_DSI1>;
clock-names = "clk_txdphy0_ref",
"clk_txdphy1_ref",
"clk_txdphy0_cfg",
"clk_txdphy1_cfg",
"pclk_dsi0",
"pclk_dsi1";

#address-cells = <1>;
#size-cells = <0>;

};
#endif
clocks {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges;
clk_xen: xen_clk@0 {
compatible = "xen,xen-vclk";
#clock-cells = <1>;
};
};

Below is my 'debian.cfg' file:

kernel = "/debian/Image"
device_tree="/debian/domu.dtb"
memory = 512
vcpus = 8
cpus = "all"
name="debian"

# DPE 
#iomem = [ "0xE8600,0x80@0x10004", "0xFFF35,1@0x10084", 
"0xFFF0A,1@0x10085", "0xFFF31,1@0x10086", "0xE86C0,10@0x10087"]
#iomem = [ "0xE8600,0x80", "0xFFF35,1", "0xFFF0A,1", "0xFFF31,1", 
"0xE86C0,10"]

irqs = [ 277 ]

iomem = [ "0xE8600,80@0x10004" ]

iomem = [ "0xFFF35,1@0x10084" ]
iomem = [ "0xFFF0A,1@0x10085" ]
iomem = [ "0xFFF31,1@0x10086" ]
iomem = [ "0xE86C0,10@0x100C4"]
#iomem = [ "0xE86C0,10@0x10087"]
#iomem = [ "0xE8600,80@0x0" ]

# DPE 
# DSI 
#iomem = [ "0xE8601,0x7F", "0xFFF35,1"]
#iomem = [ "0xE8601,0x7F@0x10097", "0xFFF35,1@0x10116", 
"0xE8601,0x7F@0x10195"]


#iomem = [ "0xE8601,7F@0x10097" ]
#iomem = [ "0xFFF35,1@0x10116" ]


iomem = [ "0xE8601,7F@0x10005" ]
iomem = [ "0xFFF35,1@0x10084" ]
# DSI 

#vif = ['mac=00:16:3e:64:b8:40,bridge=xenbr0']
#nics = 1
#vif = [ 'eth0=00:60:00:00:00:01' ]

disk = ['/dev/loop1,raw,xvda,w']
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda rootfstype=ext4 
rw video=HDMI-A-1:1280x720@60"


Here I am using same io space(GFNs) for DPE and DSI nodes, and having 
same below error

and tried with different GFNs and giving same error.

But adding this, Every

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-11-01 Thread Omkar Bolla 
Hi,

> May I ask why you need the dependency on the rootfs?

I am trying to pass-through the display to guest domain. to do through
driver needs clocks. I have written simple basic clock pv frontend and
backend.
So I thought these clocks must be initialised before display driver
initialisation.

But if I start both domain and clocks script one after another, clock got
initialised properly. Problem solved.
But still i have some doubt, is it possible to do some thing in xenbits src
to start automatically when we start underprivileged domain?

I have one more question about pass-through
To implement pass through I took reference from below link
https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf

I added 'xen-passthrough' to actual dom0 dtb and created new dtb with below
nodes in passthrough node

dpe: dpe@10004000 {
compatible = "hisilicon,hi3660-dpe";
status = "ok";
#if 0
//ACTUAL REG PROPERTY of DISPLAY
reg = <0x0 0xE860 0x0 0x8>,
<0x0 0xFFF35000 0 0x1000>,
<0x0 0xFFF0A000 0 0x1000>,
<0x0 0xFFF31000 0 0x1000>,
<0x0 0xE86C 0 0x1>;
#endif
//reg = <0x0 0x10004000 0x0 0x8>,
reg = <0x0 0x10004000 0x0 0x8>,
  <0x0 0x10084000 0 0x1000>,
  <0x0 0x10085000 0 0x1000>,
  <0x0 0x10086000 0 0x1000>,
  <0x0 0x100C4000 0 0x1>;
//   <0x0 0x10087000 0 0x1>;

interrupts = <0 245 4>;

clocks = <_xen HI3660_ACLK_GATE_DSS>,
<_xen HI3660_PCLK_GATE_DSS>,
<_xen HI3660_CLK_GATE_EDC0>,
<_xen HI3660_CLK_GATE_LDI0>,
<_xen HI3660_CLK_GATE_LDI1>,
<_xen HI3660_CLK_GATE_DSS_AXI_MM>,
<_xen HI3660_PCLK_GATE_MMBUF>;
clock-names = "aclk_dss",
"pclk_dss",
"clk_edc0",
"clk_ldi0",
"clk_ldi1",
"clk_dss_axi_mm",
"pclk_mmbuf";

dma-coherent;

port {
dpe_out: endpoint {
remote-endpoint = <_in>;
};
};
};

dsi: dsi@10097000 {
compatible = "hisilicon,hi3660-dsi";
status = "ok";
#if 0
//ACTUAL REG PROPERTY of DISPLAY
reg = <0 0xE8601000 0 0x7F000>,
<0 0xFFF35000 0 0x1000>;
#endif
// reg = <0 0x10097000 0 0x7F000>,
// <0 0x10116000 0 0x1000>;
reg = <0 0x10004000 0 0x8>,
<0 0x10084000 0 0x1000>;

clocks = <_xen HI3660_CLK_GATE_TXDPHY0_REF>,
<_xen HI3660_CLK_GATE_TXDPHY1_REF>,
<_xen HI3660_CLK_GATE_TXDPHY0_CFG>,
<_xen HI3660_CLK_GATE_TXDPHY1_CFG>,
<_xen HI3660_PCLK_GATE_DSI0>,
<_xen HI3660_PCLK_GATE_DSI1>;
clock-names = "clk_txdphy0_ref",
"clk_txdphy1_ref",
"clk_txdphy0_cfg",
"clk_txdphy1_cfg",
"pclk_dsi0",
"pclk_dsi1";

#address-cells = <1>;
#size-cells = <0>;

};
#endif
clocks {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges;
clk_xen: xen_clk@0 {
compatible = "xen,xen-vclk";
#clock-cells = <1>;
};
};

Below is my 'debian.cfg' file:

kernel = "/debian/Image"
device_tree="/debian/domu.dtb"
memory = 512
vcpus = 8
cpus = "all"
name="debian"

# DPE 
#iomem = [ "0xE8600,0x80@0x10004", "0xFFF35,1@0x10084", "0xFFF0A,1@0x10085",
"0xFFF31,1@0x10086", "0xE86C0,10@0x10087"]
#iomem = [ "0xE8600,0x80", "0xFFF35,1", "0xFFF0A,1", "0xFFF31,1",
"0xE86C0,10"]
irqs = [ 277 ]

iomem = [ "0xE8600,80@0x10004" ]

iomem = [ "0xFFF35,1@0x10084" ]
iomem = [ "0xFFF0A,1@0x10085" ]
iomem = [ "0xFFF31,1@0x10086" ]
iomem = [ "0xE86C0,10@0x100C4"]
#iomem = [ "0xE86C0,10@0x10087"]
#iomem = [ "0xE8600,80@0x0" ]

# DPE 
# DSI 
#iomem = [ "0xE8601,0x7F", "0xFFF35,1"]
#iomem = [ "0xE8601,0x7F@0x10097", "0xFFF35,1@0x10116",
"0xE8601,0x7F@0x10195"]

#iomem = [ "0xE8601,7F@0x10097" ]
#iomem = [ "0xFFF35,1@0x10116" ]


iomem = [ "0xE8601,7F@0x10005" ]
iomem = [ "0xFFF35,1@0x10084" ]
# DSI 

#vif = ['mac=00:16:3e:64:b8:40,bridge=xenbr0']
#nics = 1
#vif = [ 'eth0=00:60:00:00:00:01' ]

disk = ['/dev/loop1,raw,xvda,w']
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda rootfstype=ext4 rw
video=HDMI-A-1:1280x720@60"

Here I am using same io space(GFNs) for DPE and DSI nodes, and having same
below error
and tried with different GFNs and giving same error.

But adding this, Every thing is good but when i am trying to remap iomem
second time, having below error

[3.215021] OF: : start: 0x10004000, sz = 0x8
[3.215062] [DISPLAY] dsi_parse_dt(): 1536: of device:
/passthrough/dsi@10097000
[3.215083] [DISPLAY] dsi_parse_dt(): 1537:
+
[3.215108] [DISPLAY] dsi_parse_dt(): 1540: ctx->base:

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-31 Thread Julien Grall 



On 10/17/18 1:24 PM, Omkar Bolla wrote:

Hi,


Hi Omkar,


I have started finding which patch introduced Armv8 Secondary CPUs issue.

I just want to start PV vdevb before domainU debian rootfs mount. Is it 
possible?


May I ask why you need the dependency on the rootfs?

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-17 Thread Omkar Bolla 
Hi,

I have started finding which patch introduced Armv8 Secondary CPUs issue.

I just want to start PV vdevb before domainU debian rootfs mount. Is it
possible?

Thanks,
Omkar B


On Mon, Oct 8, 2018 at 4:00 PM Julien Grall  wrote:

>
>
> On 08/10/2018 10:12, Omkar Bolla wrote:
> > Hi,
>
> Hi,
>
> > This is also okay, but problem here is I am using 4.8 stable  xen
> > because it  is working on Hkey960(ArmV8)
>
> This is because you can't bring up secondary CPUs on the Hikey with Xen
> 4.11 [1], right? It would be nice to find where the bug was introduced
> because Xen 4.8 is out of support and does not contain the latest fixes
> (such as Meltdown/Spectre).
>
> > Is there any other way to share buffer dynamically?
> You would have to write your own PV drivers or port the series to Xen 4.8.
>
> Cheers,
>
> [1]
> https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21576.html
>
> --
> Julien Grall
>

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-08 Thread Julien Grall 



On 08/10/2018 10:12, Omkar Bolla wrote:

Hi,


Hi,

This is also okay, but problem here is I am using 4.8 stable  xen 
because it  is working on Hkey960(ArmV8)


This is because you can't bring up secondary CPUs on the Hikey with Xen 
4.11 [1], right? It would be nice to find where the bug was introduced 
because Xen 4.8 is out of support and does not contain the latest fixes 
(such as Meltdown/Spectre).



Is there any other way to share buffer dynamically?

You would have to write your own PV drivers or port the series to Xen 4.8.

Cheers,

[1] 
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21576.html


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-08 Thread Omkar Bolla 
Hi,

Sorry for late response,

On Wed, Oct 3, 2018 at 3:23 PM Julien Grall  wrote:

>
>
> On 10/02/2018 11:03 AM, Omkar Bolla wrote:
> > Hi,
> >
> > Thanks,
> > Basic state change is working now, after using above script.
> >
> > As I said, I want to share buffer between two domains.
> > Could you please suggest outlines, how can I share buffer between 2
> > domains(Guest and Host)?
>
> My question on a previous e-mail was left unanswered. Do you have
> requirements to share the buffer dynamically?
>
> Yes, I want to share buffer dynamically but not more than 1024 bytes.

> If not, you may want to have a look at "Allow setting up shared memory
> areas between VMs from xl config files" [2]. We aim to merge it in the
> next Xen release.
>
> Cheers,
>
> [2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg00883.html
>
> This is also okay, but problem here is I am using 4.8 stable  xen because
it  is working on Hkey960(ArmV8)
Is there any other way to share buffer dynamically?

> This message contains confidential information and is intended only for
> > the individual(s) named.If you are not the intended recipient, you are
> > notified that disclosing, copying, distributing or taking any action in
> > reliance on the contents of this mail and attached file/s is strictly
> > prohibited. Please notify the sender immediately and delete this e-mail
> > from your system. E-mail transmission cannot be guaranteed to be secured
> > or error-free as information could be intercepted, corrupted, lost,
> > destroyed, arrive late or incomplete, or contain viruses. The sender
> > therefore does not accept liability for any errors or omissions in the
> > contents of this message, which arise as a result of e-mail transmission.
> >
>
> Please configure your client to remove your disclaimer company.
>
I am looking into settings, to remove disclaimer.

>
> Cheers,
>
> --
> Julien Grall
>

Thanks,
Omkar B

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-03 Thread Julien Grall 



On 10/02/2018 11:03 AM, Omkar Bolla wrote:

Hi,

Thanks,
Basic state change is working now, after using above script.

As I said, I want to share buffer between two domains.
Could you please suggest outlines, how can I share buffer between 2 
domains(Guest and Host)?


My question on a previous e-mail was left unanswered. Do you have 
requirements to share the buffer dynamically?


If not, you may want to have a look at "Allow setting up shared memory 
areas between VMs from xl config files" [2]. We aim to merge it in the 
next Xen release.


Cheers,

[2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg00883.html

This message contains confidential information and is intended only for 
the individual(s) named.If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this mail and attached file/s is strictly  
prohibited. Please notify the sender immediately and delete this e-mail 
from your system. E-mail transmission cannot be guaranteed to be secured 
or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.




Please configure your client to remove your disclaimer company.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-10-02 Thread Omkar Bolla 
Hi,

Thanks,
Basic state change is working now, after using above script.

As I said, I want to share buffer between two domains.
Could you please suggest outlines, how can I share buffer between 2
domains(Guest and Host)?

Thanks,
Omkar B

On Fri, Sep 28, 2018 at 7:12 PM Juergen Gross  wrote:

> On 28/09/2018 14:55, Omkar Bolla wrote:
> > Hi,
> > I tried to run script after pause the domain and unpause domain after
> > run script. But I ended up with same error
>
> I looked at the script again, it is wrong. The permissions should
> be set for each node under the root path of the respective domains,
> the first permission should be "n$domid" ($domid is the owner who
> can always read/write, the n is "no access" for all domains not
> explicitly listed), the second permission should be "r$domid" as
> the other side should be able to read only.
>
> In order to do it correctly the script should be:
>
> #!/bin/bash
>
> DOMU_ID=$1
>
> if [ -z "$DOMU_ID"  ]; then
>   echo "Usage: $0 [domU ID]]"
>   echo
>   echo "Connects the new device, with dom0 as backend, domU as frontend"
>   exit 1
> fi
>
> # Pause domU as a script can't write an entry and set permission
> # in a single operation.
> xl pause $DOMU_ID
>
> DEVICE=mydevice
> DOMU_KEY=/local/domain/$DOMU_ID/device/$DEVICE/0
> DOM0_KEY=/local/domain/0/backend/$DEVICE/$DOMU_ID/0
>
> # Tell the domU about the new device and its backend
> xenstore-write $DOMU_KEY/backend-id 0
> xenstore-write $DOMU_KEY/backend
> "/local/domain/0/backend/$DEVICE/$DOMU_ID/0"
>
> # Tell the dom0 about the new device and its frontend
> xenstore-write $DOM0_KEY/frontend-id $DOMU_ID
> xenstore-write $DOM0_KEY/frontend "/local/domain/$DOMU_ID/device/$DEVICE/0"
>
> # Activate the device, dom0 needs to be activated last
> xenstore-write $DOMU_KEY/state 1
> xenstore-write $DOM0_KEY/state 1
>
> # Make sure the domU can read the dom0 data
> xenstore-chmod -r $DOM0_KEY n0 r$DOMU_ID
> xenstore-chmod -r $DOMU_KEY n$DOMU_ID r0
>
> xl unpause $DOMU_ID
>
>
> Juergen
>

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-28 Thread Juergen Gross 
On 28/09/2018 14:55, Omkar Bolla wrote:
> Hi,
> I tried to run script after pause the domain and unpause domain after
> run script. But I ended up with same error

I looked at the script again, it is wrong. The permissions should
be set for each node under the root path of the respective domains,
the first permission should be "n$domid" ($domid is the owner who
can always read/write, the n is "no access" for all domains not
explicitly listed), the second permission should be "r$domid" as
the other side should be able to read only.

In order to do it correctly the script should be:

#!/bin/bash

DOMU_ID=$1

if [ -z "$DOMU_ID"  ]; then
  echo "Usage: $0 [domU ID]]"
  echo
  echo "Connects the new device, with dom0 as backend, domU as frontend"
  exit 1
fi

# Pause domU as a script can't write an entry and set permission
# in a single operation.
xl pause $DOMU_ID

DEVICE=mydevice
DOMU_KEY=/local/domain/$DOMU_ID/device/$DEVICE/0
DOM0_KEY=/local/domain/0/backend/$DEVICE/$DOMU_ID/0

# Tell the domU about the new device and its backend
xenstore-write $DOMU_KEY/backend-id 0
xenstore-write $DOMU_KEY/backend
"/local/domain/0/backend/$DEVICE/$DOMU_ID/0"

# Tell the dom0 about the new device and its frontend
xenstore-write $DOM0_KEY/frontend-id $DOMU_ID
xenstore-write $DOM0_KEY/frontend "/local/domain/$DOMU_ID/device/$DEVICE/0"

# Activate the device, dom0 needs to be activated last
xenstore-write $DOMU_KEY/state 1
xenstore-write $DOM0_KEY/state 1

# Make sure the domU can read the dom0 data
xenstore-chmod -r $DOM0_KEY n0 r$DOMU_ID
xenstore-chmod -r $DOMU_KEY n$DOMU_ID r0

xl unpause $DOMU_ID


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-28 Thread Omkar Bolla 
Hi,
I tried to run script after pause the domain and unpause domain after run
script. But I ended up with same error

Below I shared  PV device log, and attached my FE and BE driver and script
that i used,
root@hikey960:/debian#
[XEN_BUF]xen_vdevb_be_probe(): 124: Probe called. We are good to go.
[  165.087419] [XEN_BUF]xen_vdevb_be_probe(): 125:  ffc017fb7000 1
[  165.093759] [XEN_BUF]xen_vdevb_be_probe(): 137: info->domid: 1
[  165.099641] [XEN_BUF]xen_vdevb_be_probe(): 138: devicetype: vdevb,
nodename: backend/vdevb/1/0, otherend: /local/domain/1/device/vdevb/0
[  165.112939] [XEN_BUF]xen_vdevb_be_frontend_changed(): 177: dev->state:
XenbusStateInitialising-1, frontend_state: XenbusStateInitialising-1

root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian# xl console debian
[   22.243570] [XEN_BUF]xen_vdevb_fe_probe(): 24: Probe called. We are good
to go.
[   22.243606] [XEN_BUF]xen_vdevb_fe_probe(): 25:  ffc0160b4000 0
[   22.243620] [XEN_BUF]xen_vdevb_fe_probe(): 38: info->domid: 0
[   22.243633] [XEN_BUF]xen_vdevb_fe_probe(): 39: devicetype: vdevb,
nodename: device/vdevb/0, otherend: /local/domain/0/backend/vdevb/1/0
[   22.244669] [XEN_BUF]xen_vdevb_fe_backend_changed(): 64: dev->state:
XenbusStateInitialising-1, backend_state: XenbusStateInitWait-2
[   22.244701] [XEN_BUF]frontend_connect(): 53: Connecting the frontend now
[   22.245866] vdevb vdevb-0: 13 writing new state
[   22.246085] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
[   22.250005] vdevb vdevb-0: 13 writing new state
[   22.250220] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
root@hikey960:~#


Thanks,
Omkar  B


On Thu, Sep 27, 2018 at 4:33 PM Juergen Gross  wrote:

> On 27/09/2018 12:35, Omkar Bolla wrote:
> > Hi,
> >
> > Sorry, I forgot, I used code from github chapter [2] from that link, and
> > I just changed name "mydevice"  to "vdevb"
>
> Okay.
>
> >
> >> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> >> are not sufficient to write the needed entries.
> > Where I have to provide access rights, i.e from Kernel code or from from
> > command line in domain-0 or modify in xen source?
>
> I guess you have your frontend already loaded when running the
> script creating the Xenstore entries?
>
> This would explain the problem: as soon as the entries are written
> the frontend will react. At this point the access rights are not setup
> properly, this is done a little bit later in the script.
>
> Possible solutions are to either load the frontend driver only after
> setting up the Xenstore entries, or to pause the domain while doing
> so and unpause it afterwards (or start the domain paused, create the
> Xenstore entries, and unpause the domain).
>
> The really correct way to do it would be to setup Xenstore in a single
> transaction (write all the entries and set access rights).
>
> > Any thing that I have to do/change in xenbits xen-4.8 sources code, to
> > add new PV device?
>
> Only if you want to include domain config file entries for your device.
>
> >
> >> Did you modify Xen tools (xl/libxl) for adding the new device type?
> > No, is it needed to modify some thing in xl/libxl for adding new device
> > type?
>
> This was just a question to learn how Xenstore is being initialized
> in your scenario.
>
> >
> >> If not you need to setup the Xenstore nodes manually.
> > Setup manually Xenstore means, using commands?
>
> Yes, like your script does.
>
>
> Juergen
>

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
#include   /* Needed by all modules */
#include   /* Needed for KERN_ALERT */

#include/* We are doing something with Xen */
#include 

#include "xen_buf.h"

struct vdevbfrnt_info {
	struct xenbus_device *dev;
	unsigned int evtchn;
	unsigned int irq;

	grant_ref_t ring_ref;
	
};
// The function is called on activation of the device
static int xen_vdevb_fe_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
{
	struct vdevbfrnt_info *info = NULL;
	
	
	pr_log("Probe called. We are good to go.\n");
	pr_log(" %p %d\n", dev, dev->otherend_id);

	/* Allocating memory for private structure */
	info = kzalloc(sizeof(struct vdevbfrnt_info), GFP_KERNEL);
	if

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Juergen Gross 
On 27/09/2018 12:35, Omkar Bolla wrote:
> Hi,
> 
> Sorry, I forgot, I used code from github chapter [2] from that link, and
> I just changed name "mydevice"  to "vdevb"

Okay.

> 
>> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
>> are not sufficient to write the needed entries.
> Where I have to provide access rights, i.e from Kernel code or from from
> command line in domain-0 or modify in xen source?

I guess you have your frontend already loaded when running the
script creating the Xenstore entries?

This would explain the problem: as soon as the entries are written
the frontend will react. At this point the access rights are not setup
properly, this is done a little bit later in the script.

Possible solutions are to either load the frontend driver only after
setting up the Xenstore entries, or to pause the domain while doing
so and unpause it afterwards (or start the domain paused, create the
Xenstore entries, and unpause the domain).

The really correct way to do it would be to setup Xenstore in a single
transaction (write all the entries and set access rights).

> Any thing that I have to do/change in xenbits xen-4.8 sources code, to
> add new PV device?

Only if you want to include domain config file entries for your device.

> 
>> Did you modify Xen tools (xl/libxl) for adding the new device type?
> No, is it needed to modify some thing in xl/libxl for adding new device
> type?

This was just a question to learn how Xenstore is being initialized
in your scenario.

> 
>> If not you need to setup the Xenstore nodes manually.
> Setup manually Xenstore means, using commands?

Yes, like your script does.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Omkar Bolla 
Hi,

Sorry, I forgot, I used code from github chapter [2] from that link, and
I just changed name "mydevice"  to "vdevb"

> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> are not sufficient to write the needed entries.
Where I have to provide access rights, i.e from Kernel code or from from
command line in domain-0 or modify in xen source?
Any thing that I have to do/change in xenbits xen-4.8 sources code, to add
new PV device?

> Did you modify Xen tools (xl/libxl) for adding the new device type?
No, is it needed to modify some thing in xl/libxl for adding new device
type?

> If not you need to setup the Xenstore nodes manually.
Setup manually Xenstore means, using commands?

Thanks,
Omkar B




On Thu, Sep 27, 2018 at 3:50 PM Oleksandr Andrushchenko <
oleksandr_andrushche...@epam.com> wrote:

> On 09/27/2018 01:16 PM, Juergen Gross wrote:
> > On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:
> >> Hi,
> >> On 09/27/2018 12:39 PM, Lars Kurth wrote:
> >>> Adding a few people who have recently been working on PV drivers, as
> >>> well as Julien
> >>> Lars
> >>>
>  On 27 Sep 2018, at 06:44, Omkar Bolla
>    > wrote:
> 
>  Hi,
> 
>  I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
>  platform(ARMv8) and using Xen-4.8 stable release. Here I want to
>  create a PV frontend and backend to share memory between Domain-0 and
>  Domain-U.
> 
> 
> 
>  I used below link to create frontend and backend,
>  https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
> >> The link above has another link to github [1] with 2 chapters. And it
> >> looks like you have
> >> already modified the sources ("mydevice" -> "vdevb" at least).
> >> So, what are the sources you are using?
> >>
> >> You could probably take a look at the relatively small vkbd frontend
> >> driver [2]
> >> to get some hints.
>  But I am facing below errors while adding device vdevb to xenstore.
>  Below errors I am getting from xenbus_switch_state().
>  vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
>  writing new state)
> > Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> > are not sufficient to write the needed entries.
> >
> > Did you modify Xen tools (xl/libxl) for adding the new device type?
> > If not you need to setup the Xenstore nodes manually.
> There is a script [1] which comes with the example implementation,
> so I believe Omkar uses it with "mydevice" -> "vdevb" change
> >
> >
> > Juergen
> [1]
>
> https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh
>

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Julien Grall 

Hi,

On 09/27/2018 11:20 AM, Oleksandr Andrushchenko wrote:

On 09/27/2018 01:16 PM, Juergen Gross wrote:

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:

Adding a few people who have recently been working on PV drivers, as
well as Julien
Lars


On 27 Sep 2018, at 06:44, Omkar Bolla
mailto:omkar.bo...@pathpartnertech.com>> wrote:

Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
platform(ARMv8) and using Xen-4.8 stable release. Here I want to
create a PV frontend and backend to share memory between Domain-0 and
Domain-U.


Do you need to share the buffer dynamically? If not, you may want to 
have a look at "Allow setting up shared memory areas between VMs from xl 
config files" [2]. We aim to merge it in the next Xen release.


Cheers,

[2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg00883.html

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Oleksandr Andrushchenko 

On 09/27/2018 01:16 PM, Juergen Gross wrote:

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:

Adding a few people who have recently been working on PV drivers, as
well as Julien
Lars


On 27 Sep 2018, at 06:44, Omkar Bolla
mailto:omkar.bo...@pathpartnertech.com>> wrote:

Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
platform(ARMv8) and using Xen-4.8 stable release. Here I want to
create a PV frontend and backend to share memory between Domain-0 and
Domain-U.



I used below link to create frontend and backend,
https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/

The link above has another link to github [1] with 2 chapters. And it
looks like you have
already modified the sources ("mydevice" -> "vdevb" at least).
So, what are the sources you are using?

You could probably take a look at the relatively small vkbd frontend
driver [2]
to get some hints.

But I am facing below errors while adding device vdevb to xenstore.
Below errors I am getting from xenbus_switch_state().
vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
writing new state)

Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
are not sufficient to write the needed entries.

Did you modify Xen tools (xl/libxl) for adding the new device type?
If not you need to setup the Xenstore nodes manually.

There is a script [1] which comes with the example implementation,
so I believe Omkar uses it with "mydevice" -> "vdevb" change



Juergen
[1] 
https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Juergen Gross 
On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:
> Hi,
> On 09/27/2018 12:39 PM, Lars Kurth wrote:
>> Adding a few people who have recently been working on PV drivers, as
>> well as Julien
>> Lars
>>
>>> On 27 Sep 2018, at 06:44, Omkar Bolla
>>> >> > wrote:
>>>
>>> Hi,
>>>
>>> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
>>> platform(ARMv8) and using Xen-4.8 stable release. Here I want to
>>> create a PV frontend and backend to share memory between Domain-0 and
>>> Domain-U.
>>>
>>>
>>>
>>> I used below link to create frontend and backend,
>>> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
> The link above has another link to github [1] with 2 chapters. And it
> looks like you have
> already modified the sources ("mydevice" -> "vdevb" at least).
> So, what are the sources you are using?
> 
> You could probably take a look at the relatively small vkbd frontend
> driver [2]
> to get some hints.
>>>
>>> But I am facing below errors while adding device vdevb to xenstore.
>>> Below errors I am getting from xenbus_switch_state().
>>> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
>>> writing new state)

Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
are not sufficient to write the needed entries.

Did you modify Xen tools (xl/libxl) for adding the new device type?
If not you need to setup the Xenstore nodes manually.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Oleksandr Andrushchenko 

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:
Adding a few people who have recently been working on PV drivers, as 
well as Julien

Lars

On 27 Sep 2018, at 06:44, Omkar Bolla 
> wrote:


Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 
platform(ARMv8) and using Xen-4.8 stable release. Here I want to 
create a PV frontend and backend to share memory between Domain-0 and 
Domain-U.




I used below link to create frontend and backend,
https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
The link above has another link to github [1] with 2 chapters. And it 
looks like you have

already modified the sources ("mydevice" -> "vdevb" at least).
So, what are the sources you are using?

You could probably take a look at the relatively small vkbd frontend 
driver [2]

to get some hints.


But I am facing below errors while adding device vdevb to xenstore.
Below errors I am getting from xenbus_switch_state().
vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 
writing new state)


If the sources are known then we would need the full scenario which 
leads to the failure.
Could you please also add some debug logs into every function of the 
driver so we see what

and when happens on both backend and frontend sides?

Please suggest me, How to create PV drivers.

I would go with any existing driver in the kernel as an example

Thanks,
Omkar B

This message contains confidential information and is intended only 
for the individual(s) named.If you are not the intended recipient, 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this mail and attached file/s 
is strictly prohibited. Please notify the sender immediately and 
delete this e-mail from your system. E-mail transmission cannot be 
guaranteed to be secured or error-free as information could be 
intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message, which 
arise as a result of e-mail transmission.


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org 
https://lists.xenproject.org/mailman/listinfo/xen-devel




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[1] https://github.com/badboy/xen-split-driver-example
[2] 
https://elixir.bootlin.com/linux/latest/source/drivers/input/misc/xen-kbdfront.c
[3] 
https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

2018-09-27 Thread Lars Kurth 
Adding a few people who have recently been working on PV drivers, as well as 
Julien
Lars

> On 27 Sep 2018, at 06:44, Omkar Bolla  wrote:
> 
> Hi,
> 
> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 
> platform(ARMv8) and using Xen-4.8 stable release. Here I want to create a PV 
> frontend and backend to share memory between Domain-0 and Domain-U. 
> 
> 
> 
> I used below link to create frontend and backend,
> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/ 
> 
> 
> But I am facing below errors while adding device vdevb to xenstore. 
> Below errors I am getting from xenbus_switch_state().
> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 writing new 
> state)
> 
> Please suggest me, How to create PV drivers.
> 
> Thanks,
> Omkar B
> 
> This message contains confidential information and is intended only for the 
> individual(s) named. If you are not the intended recipient, you are notified 
> that disclosing, copying, distributing or taking any action in reliance on 
> the contents of this mail and attached file/s is strictly prohibited. Please 
> notify the sender immediately and delete this e-mail from your system. E-mail 
> transmission cannot be guaranteed to be secured or error-free as information 
> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
> or contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of e-mail transmission.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel