* Xen PV: Sample new PV driver for buffer sharing between domains @ 2018-09-27 5:44 Omkar Bolla 2018-09-27 9:39 ` Lars Kurth 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-09-27 5:44 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --] 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. [-- Attachment #1.2: Type: text/html, Size: 2692 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 5:44 Xen PV: Sample new PV driver for buffer sharing between domains Omkar Bolla @ 2018-09-27 9:39 ` Lars Kurth 2018-09-27 10:07 ` Oleksandr Andrushchenko 0 siblings, 1 reply; 20+ messages in thread From: Lars Kurth @ 2018-09-27 9:39 UTC (permalink / raw) To: Omkar Bolla Cc: Julien Grall, xen-devel, Stefano Stabellini, Oleksandr Andrushchenko [-- Attachment #1.1: Type: text/plain, Size: 1806 bytes --] 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 <omkar.bolla@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/ <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 [-- Attachment #1.2: Type: text/html, Size: 3815 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 9:39 ` Lars Kurth @ 2018-09-27 10:07 ` Oleksandr Andrushchenko 2018-09-27 10:16 ` Juergen Gross 0 siblings, 1 reply; 20+ messages in thread From: Oleksandr Andrushchenko @ 2018-09-27 10:07 UTC (permalink / raw) To: Lars Kurth, Omkar Bolla Cc: Julien Grall, xen-devel, Stefano Stabellini, 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 >> <omkar.bolla@pathpartnertech.com >> <mailto:omkar.bolla@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) >> 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 <mailto: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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 10:07 ` Oleksandr Andrushchenko @ 2018-09-27 10:16 ` Juergen Gross 2018-09-27 10:20 ` Oleksandr Andrushchenko 0 siblings, 1 reply; 20+ messages in thread From: Juergen Gross @ 2018-09-27 10:16 UTC (permalink / raw) To: Oleksandr Andrushchenko, Lars Kurth, Omkar Bolla Cc: Julien Grall, xen-devel, Stefano Stabellini, Oleksandr Andrushchenko 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 >>> <omkar.bolla@pathpartnertech.com >>> <mailto:omkar.bolla@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. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 10:16 ` Juergen Gross @ 2018-09-27 10:20 ` Oleksandr Andrushchenko 2018-09-27 10:34 ` Julien Grall 2018-09-27 10:35 ` Omkar Bolla 0 siblings, 2 replies; 20+ messages in thread From: Oleksandr Andrushchenko @ 2018-09-27 10:20 UTC (permalink / raw) To: Juergen Gross, Oleksandr Andrushchenko, Lars Kurth, Omkar Bolla Cc: Julien Grall, xen-devel, Stefano Stabellini 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 >>>> <omkar.bolla@pathpartnertech.com >>>> <mailto:omkar.bolla@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 10:20 ` Oleksandr Andrushchenko @ 2018-09-27 10:34 ` Julien Grall 2018-09-27 10:35 ` Omkar Bolla 1 sibling, 0 replies; 20+ messages in thread From: Julien Grall @ 2018-09-27 10:34 UTC (permalink / raw) To: Oleksandr Andrushchenko, Juergen Gross, Oleksandr Andrushchenko, Lars Kurth, Omkar Bolla Cc: xen-devel, Stefano Stabellini 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 >>>>> <omkar.bolla@pathpartnertech.com >>>>> <mailto:omkar.bolla@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 10:20 ` Oleksandr Andrushchenko 2018-09-27 10:34 ` Julien Grall @ 2018-09-27 10:35 ` Omkar Bolla 2018-09-27 11:03 ` Juergen Gross 1 sibling, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-09-27 10:35 UTC (permalink / raw) To: Oleksandr_Andrushchenko Cc: jgross, xen-devel, andr2000, lars.kurth.xen, Julien Grall, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 3467 bytes --] 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_Andrushchenko@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 > >>>> <omkar.bolla@pathpartnertech.com > >>>> <mailto:omkar.bolla@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 > -- 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. [-- Attachment #1.2: Type: text/html, Size: 6406 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 10:35 ` Omkar Bolla @ 2018-09-27 11:03 ` Juergen Gross 2018-09-28 12:55 ` Omkar Bolla 0 siblings, 1 reply; 20+ messages in thread From: Juergen Gross @ 2018-09-27 11:03 UTC (permalink / raw) To: Omkar Bolla, Oleksandr_Andrushchenko Cc: andr2000, lars.kurth.xen, Julien Grall, xen-devel, Stefano Stabellini 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-27 11:03 ` Juergen Gross @ 2018-09-28 12:55 ` Omkar Bolla 2018-09-28 13:42 ` Juergen Gross 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-09-28 12:55 UTC (permalink / raw) To: jgross Cc: xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Julien Grall, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 4318 bytes --] 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: ffffffc017fb7000 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: ffffffc0160b4000 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 <jgross@suse.com> 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. [-- Attachment #1.2: Type: text/html, Size: 6986 bytes --] [-- Attachment #2: xen_buf_frontend.c --] [-- Type: text/x-csrc, Size: 3526 bytes --] #include <linux/module.h> /* Needed by all modules */ #include <linux/kernel.h> /* Needed for KERN_ALERT */ #include <xen/xen.h> /* We are doing something with Xen */ #include <xen/xenbus.h> #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 (!info) { xenbus_dev_fatal(dev, -ENOMEM, "allocating frontend structure"); return -ENOMEM; } info->dev = dev; dev_set_drvdata(&dev->dev, info); // info->domid = dev->otherend_id; pr_log("info->domid: %d\n", dev->otherend_id); pr_log("devicetype: %s, nodename: %s, otherend: %s\n", dev->devicetype, dev->nodename, dev->otherend); // xenbus_switch_state(dev, XenbusStateInitialised); return 0; } static int xen_vdevb_fe_remove(struct xenbus_device *dev) { pr_log("\n"); return 0; } // This is where we set up xenstore files and event channels static int frontend_connect(struct xenbus_device *dev) { pr_log("Connecting the frontend now\n"); return 0; } // The function is called on a state change of the backend driver static void xen_vdevb_fe_backend_changed(struct xenbus_device *dev, enum xenbus_state backend_state) { struct vdevbfrnt_info *info = dev_get_drvdata(&dev->dev); //pr_log("info: %p\n", info); pr_log("dev->state: %s-%d, backend_state: %s-%d\n", xenbus_state_array[dev->state], dev->state, xenbus_state_array[backend_state], backend_state); switch (backend_state) { case XenbusStateInitialising: xenbus_switch_state(dev, XenbusStateInitialising); break; case XenbusStateInitialised: case XenbusStateReconfiguring: case XenbusStateReconfigured: case XenbusStateUnknown: break; case XenbusStateInitWait: if (dev->state != XenbusStateInitialising) break; if (frontend_connect(dev) != 0) break; xenbus_switch_state(dev, XenbusStateConnected); break; case XenbusStateConnected: pr_log("Other side says it is connected as well.\n"); break; case XenbusStateClosed: if (dev->state == XenbusStateClosed) break; /* Missed the backend's CLOSING state -- fallthrough */ case XenbusStateClosing: xenbus_frontend_closed(dev); } } // This defines the name of the devices the driver reacts to static const struct xenbus_device_id xen_vdevb_fe_ids[] = { { "vdevb" }, { "" } }; // We set up the callback functions static struct xenbus_driver xen_vdevb_fe_driver = { .ids = xen_vdevb_fe_ids, .probe = xen_vdevb_fe_probe, .remove = xen_vdevb_fe_remove, .otherend_changed = xen_vdevb_fe_backend_changed, }; // On loading this kernel module, we register as a frontend driver static int __init xen_vdevb_fe_init(void) { pr_log("xen_domain_type: %d, xen_domain: %d\n", xen_domain_type,xen_domain()); pr_log("Hello World!\n"); return xenbus_register_frontend(&xen_vdevb_fe_driver); } module_init(xen_vdevb_fe_init); // ...and on unload we unregister static void __exit xen_vdevb_fe_exit(void) { xenbus_unregister_driver(&xen_vdevb_fe_driver); pr_log( "Goodbye world.\n"); } module_exit(xen_vdevb_fe_exit); MODULE_LICENSE("GPL"); MODULE_ALIAS("xen-clk: vdevb"); [-- Attachment #3: xen_buf_backend.c --] [-- Type: text/x-csrc, Size: 6181 bytes --] #include <linux/module.h> /* Needed by all modules */ #include <linux/kernel.h> /* Needed for KERN_ALERT */ #include <xen/xen.h> /* We are doing something with Xen */ #include <xen/xenbus.h> #include "xen_buf.h" struct vdevbbk_info { struct xenbus_device *dev; domid_t domid; unsigned int irq; // struct vscsiif_back_ring ring; int ring_error; spinlock_t ring_lock; atomic_t nr_unreplied_reqs; spinlock_t vdevb_lock; struct list_head vdevb_entry_lists; wait_queue_head_t waiting_to_free; }; // This is where we set up path watchers and event channels static void backend_connect(struct xenbus_device *dev) { pr_log("Connecting the backend now\n"); } // This will destroy event channel handlers static void backend_disconnect(struct xenbus_device *dev) { pr_log("Connecting the backend now\n"); } // We try to switch to the next state from a previous one static void set_backend_state(struct xenbus_device *dev, enum xenbus_state state) { //pr_log("dev->state: %s-%d, state: %s-%d\n", xenbus_state_array[dev->state], dev->state, xenbus_state_array[state], state); while (dev->state != state) { switch (dev->state) { case XenbusStateInitialising: switch (state) { case XenbusStateInitWait: case XenbusStateConnected: case XenbusStateClosing: xenbus_switch_state(dev, XenbusStateInitWait); break; case XenbusStateClosed: xenbus_switch_state(dev, XenbusStateClosed); break; default: BUG(); } break; case XenbusStateClosed: switch (state) { case XenbusStateInitWait: case XenbusStateConnected: xenbus_switch_state(dev, XenbusStateInitWait); break; case XenbusStateClosing: xenbus_switch_state(dev, XenbusStateClosing); break; default: BUG(); } break; case XenbusStateInitWait: switch (state) { case XenbusStateConnected: backend_connect(dev); xenbus_switch_state(dev, XenbusStateConnected); break; case XenbusStateClosing: case XenbusStateClosed: xenbus_switch_state(dev, XenbusStateClosing); break; default: BUG(); } break; case XenbusStateConnected: switch (state) { case XenbusStateInitWait: case XenbusStateClosing: case XenbusStateClosed: backend_disconnect(dev); xenbus_switch_state(dev, XenbusStateClosing); break; default: BUG(); } break; case XenbusStateClosing: switch (state) { case XenbusStateInitWait: case XenbusStateConnected: case XenbusStateClosed: xenbus_switch_state(dev, XenbusStateClosed); break; default: BUG(); } break; default: BUG(); } } } // The function is called on activation of the device static int xen_vdevb_be_probe(struct xenbus_device *dev, const struct xenbus_device_id *id) { struct vdevbbk_info *info = NULL; int ret = 0; 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 vdevbbk_info), GFP_KERNEL); if (!info) { xenbus_dev_fatal(dev, -ENOMEM, "allocating backend structure"); return -ENOMEM; } info->dev = dev; dev_set_drvdata(&dev->dev, info); info->domid = dev->otherend_id; pr_log("info->domid: %d\n", info->domid); pr_log("devicetype: %s, nodename: %s, otherend: %s\n", dev->devicetype, dev->nodename, dev->otherend); #if 0 spin_lock_init(&info->ring_lock); info->ring_error = 0; atomic_set(&info->nr_unreplied_reqs, 0); init_waitqueue_head(&info->waiting_to_free); info->irq = 0; INIT_LIST_HEAD(&info->vdevb_entry_lists); spin_lock_init(&info->vdevb_lock); #endif ret = xenbus_printf(XBT_NIL, dev->nodename, "vdevb-version", "%s", "0.1"); if (ret) xenbus_dev_error(dev, ret, "writing vdevb-version"); ret = xenbus_switch_state(dev, XenbusStateInitialising); if (ret) goto error; return 0; error: pr_warn("%s failed\n", __func__); kfree(info); dev_set_drvdata(&dev->dev, NULL); return ret; } static int xen_vdevb_be_remove(struct xenbus_device *dev) { pr_log("\n"); return 0; } // The function is called on a state change of the frontend driver static void xen_vdevb_be_frontend_changed(struct xenbus_device *dev, enum xenbus_state frontend_state) { struct vdevbbk_info *info = dev_get_drvdata(&dev->dev); pr_log("dev->state: %s-%d, frontend_state: %s-%d\n", xenbus_state_array[dev->state], dev->state, xenbus_state_array[frontend_state], frontend_state); switch (frontend_state) { case XenbusStateInitialising: set_backend_state(dev, XenbusStateInitWait); break; case XenbusStateInitialised: break; case XenbusStateConnected: set_backend_state(dev, XenbusStateConnected); break; case XenbusStateClosing: set_backend_state(dev, XenbusStateClosing); break; case XenbusStateClosed: set_backend_state(dev, XenbusStateClosed); if (xenbus_dev_is_online(dev)) break; /* fall through if not online */ case XenbusStateUnknown: set_backend_state(dev, XenbusStateClosed); device_unregister(&dev->dev); break; default: xenbus_dev_fatal(dev, -EINVAL, "saw state %s (%d) at frontend", xenbus_strstate(frontend_state), frontend_state); break; } } // This defines the name of the devices the driver reacts to static const struct xenbus_device_id xen_vdevb_be_ids[] = { { "vdevb" }, { "" } }; // We set up the callback functions static struct xenbus_driver xen_vdevb_be_driver = { .ids = xen_vdevb_be_ids, .probe = xen_vdevb_be_probe, .remove = xen_vdevb_be_remove, .otherend_changed = xen_vdevb_be_frontend_changed, }; // On loading this kernel module, we register as a frontend driver static int __init xen_vdevb_be_init(void) { pr_log("xen_domain_type: %d, xen_domain: %d\n", xen_domain_type,xen_domain()); pr_log("Hello World!\n"); return xenbus_register_backend(&xen_vdevb_be_driver); } module_init(xen_vdevb_be_init); // ...and on unload we unregister static void __exit xen_vdevb_be_exit(void) { xenbus_unregister_driver(&xen_vdevb_be_driver); pr_log("Goodbye world.\n"); } module_exit(xen_vdevb_be_exit); MODULE_LICENSE("GPL"); MODULE_ALIAS("xen-clk-backend :vdevb"); [-- Attachment #4: xen_buf.h --] [-- Type: text/x-chdr, Size: 1128 bytes --] #ifndef __XEN_BUF__ #define pr_log(fmt, ...) { \ pr_info("[XEN_BUF]%s(): %d: "fmt, __func__, __LINE__, ##__VA_ARGS__); \ } static char *xenbus_state_array[] = { "XenbusStateUnknown", "XenbusStateInitialising", "XenbusStateInitWait", /* Finished early initialisation, but waiting for information from the peer or hotplug scripts. */ "XenbusStateInitialised", /* Initialised and waiting for a connection from the peer. */ "XenbusStateConnected", "XenbusStateClosing", /* The device is being closed due to an error or an unplug event. */ "XenbusStateClosed", /* * Reconfiguring: The device is being reconfigured. */ "XenbusStateReconfiguring", "XenbusStateReconfigured", }; #endif /* __XEN_BUF__ */ [-- Attachment #5: activate.sh --] [-- Type: application/x-shellscript, Size: 936 bytes --] [-- Attachment #6: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-28 12:55 ` Omkar Bolla @ 2018-09-28 13:42 ` Juergen Gross 2018-10-02 10:03 ` Omkar Bolla 0 siblings, 1 reply; 20+ messages in thread From: Juergen Gross @ 2018-09-28 13:42 UTC (permalink / raw) To: Omkar Bolla Cc: xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Julien Grall, Stefano Stabellini 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-09-28 13:42 ` Juergen Gross @ 2018-10-02 10:03 ` Omkar Bolla 2018-10-03 9:53 ` Julien Grall 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-10-02 10:03 UTC (permalink / raw) To: jgross Cc: xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Julien Grall, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 2760 bytes --] 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 <jgross@suse.com> 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. [-- Attachment #1.2: Type: text/html, Size: 3913 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-02 10:03 ` Omkar Bolla @ 2018-10-03 9:53 ` Julien Grall 2018-10-08 9:12 ` Omkar Bolla 0 siblings, 1 reply; 20+ messages in thread From: Julien Grall @ 2018-10-03 9:53 UTC (permalink / raw) To: Omkar Bolla, jgross Cc: Oleksandr Andrushchenko, Lars Kurth, xen-devel, Stefano Stabellini, Oleksandr_Andrushchenko 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-03 9:53 ` Julien Grall @ 2018-10-08 9:12 ` Omkar Bolla 2018-10-08 10:30 ` Julien Grall 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-10-08 9:12 UTC (permalink / raw) To: Julien Grall Cc: jgross, xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 2680 bytes --] Hi, Sorry for late response, On Wed, Oct 3, 2018 at 3:23 PM Julien Grall <julien.grall@arm.com> 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. [-- Attachment #1.2: Type: text/html, Size: 4412 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-08 9:12 ` Omkar Bolla @ 2018-10-08 10:30 ` Julien Grall 2018-10-17 12:24 ` Omkar Bolla 0 siblings, 1 reply; 20+ messages in thread From: Julien Grall @ 2018-10-08 10:30 UTC (permalink / raw) To: Omkar Bolla Cc: jgross, xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-08 10:30 ` Julien Grall @ 2018-10-17 12:24 ` Omkar Bolla 2018-10-31 19:41 ` Julien Grall 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-10-17 12:24 UTC (permalink / raw) To: Julien Grall Cc: jgross, xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 1676 bytes --] 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 <julien.grall@arm.com> 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. [-- Attachment #1.2: Type: text/html, Size: 2739 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-17 12:24 ` Omkar Bolla @ 2018-10-31 19:41 ` Julien Grall 2018-11-01 9:15 ` Omkar Bolla 0 siblings, 1 reply; 20+ messages in thread From: Julien Grall @ 2018-10-31 19:41 UTC (permalink / raw) To: Omkar Bolla Cc: jgross, xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-10-31 19:41 ` Julien Grall @ 2018-11-01 9:15 ` Omkar Bolla 2018-11-01 21:49 ` Julien Grall 0 siblings, 1 reply; 20+ messages in thread From: Omkar Bolla @ 2018-11-01 9:15 UTC (permalink / raw) To: Julien Grall Cc: jgross, xen-devel, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 15485 bytes --] 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 0xE8600000 0x0 0x80000>, <0x0 0xFFF35000 0 0x1000>, <0x0 0xFFF0A000 0 0x1000>, <0x0 0xFFF31000 0 0x1000>, <0x0 0xE86C0000 0 0x10000>; #endif //reg = <0x0 0x10004000 0x0 0x80000>, reg = <0x0 0x10004000 0x0 0x80000>, <0x0 0x10084000 0 0x1000>, <0x0 0x10085000 0 0x1000>, <0x0 0x10086000 0 0x1000>, <0x0 0x100C4000 0 0x10000>; // <0x0 0x10087000 0 0x10000>; interrupts = <0 245 4>; clocks = <&clk_xen HI3660_ACLK_GATE_DSS>, <&clk_xen HI3660_PCLK_GATE_DSS>, <&clk_xen HI3660_CLK_GATE_EDC0>, <&clk_xen HI3660_CLK_GATE_LDI0>, <&clk_xen HI3660_CLK_GATE_LDI1>, <&clk_xen HI3660_CLK_GATE_DSS_AXI_MM>, <&clk_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 = <&dsi_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 0x80000>, <0 0x10084000 0 0x1000>; clocks = <&clk_xen HI3660_CLK_GATE_TXDPHY0_REF>, <&clk_xen HI3660_CLK_GATE_TXDPHY1_REF>, <&clk_xen HI3660_CLK_GATE_TXDPHY0_CFG>, <&clk_xen HI3660_CLK_GATE_TXDPHY1_CFG>, <&clk_xen HI3660_PCLK_GATE_DSI0>, <&clk_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@0x00000" ] ################# 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: rrrrrrrrrrrr: start: 0x10004000, sz = 0x80000 [ 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: ffffff800bd01000 [ 3.215126] [DISPLAY] dsi_parse_dt(): 1541: [ 3.215136] OF: rrrrrrrrrrrr: start: 0x10084000, sz = 0x1000 [ 3.215169] [DISPLAY] dsi_parse_dt(): 1548: [ 4.159087] [DISPLAY] dsi_parse_dt(): 1563: [ 4.159092] [DISPLAY] dsi_parse_dt(): 1568: [ 4.159132] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_ref,1 [ 4.159163] [D][XEN_VCLK]xen_vclk_xfer(): 164: ******************************************* [ 4.159399] [D][XEN_VCLK]xen_vclk_xfer(): 170: ******************************************* [ 4.159626] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to domain-0 [ 4.160218] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from domain 0 fired!!! [ 4.160359] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 [ 4.160532] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 [ 4.160542] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done [ 4.160545] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... [ 4.160554] [DISPLAY] dsi_parse_dt(): 1575: [ 4.160560] [D][XEN_VCLK]vclk_round_rate(): 224: called... [ 4.160567] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_ref,4,19200000 [ 4.160570] [D][XEN_VCLK]xen_vclk_xfer(): 164: ******************************************* [ 4.161095] [D][XEN_VCLK]xen_vclk_xfer(): 170: ******************************************* [ 4.161331] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to domain-0 [ 4.161946] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from domain 0 fired!!! [ 4.162120] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 [ 4.162284] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 [ 4.162295] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done [ 4.162301] [DISPLAY] dsi_parse_dt(): 1583: [ 4.162314] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_cfg,1 [ 4.162316] [D][XEN_VCLK]xen_vclk_xfer(): 164: ******************************************* [ 4.162641] [D][XEN_VCLK]xen_vclk_xfer(): 170: ******************************************* [ 4.162984] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to domain-0 [ 4.163596] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from domain 0 fired!!! [ 4.167753] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 [ 4.167955] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 [ 4.167968] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done [ 4.167971] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... [ 4.167979] [DISPLAY] dsi_parse_dt(): 1593: [ 4.167982] [D][XEN_VCLK]vclk_round_rate(): 224: called... [ 4.167985] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_cfg,4,19200000 [ 4.167992] [D][XEN_VCLK]xen_vclk_xfer(): 164: ******************************************* [ 4.168244] [D][XEN_VCLK]xen_vclk_xfer(): 170: ******************************************* [ 4.168476] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to domain-0 [ 4.169101] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from domain 0 fired!!! [ 4.169262] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 [ 4.169448] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 [ 4.169491] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done [ 4.169510] [DISPLAY] dsi_parse_dt(): 1601: [ 4.169535] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: pclk_dsi0,1 [ 4.169554] [D][XEN_VCLK]xen_vclk_xfer(): 164: ******************************************* [ 4.169803] [D][XEN_VCLK]xen_vclk_xfer(): 170: ******************************************* [ 4.170019] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to domain-0 [ 4.170619] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from domain 0 fired!!! [ 4.170779] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 [ 4.170965] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 [ 4.170978] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done [ 4.170981] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... [ 4.170989] [DISPLAY] dsi_parse_dt(): 1611: [ 4.170992] [DISPLAY] dsi_probe(): 1654: Before component add [ 4.170997] [DISPLAY] compare_of(): 242: [ 4.171002] [DISPLAY] kirin_drm_bind(): 257: [ 4.171004] [drm] +. [ 4.171386] [DISPLAY] kirin_drm_kms_init(): 105: [ 4.171391] [drm] +. [ 4.212543] [DISPLAY] kirin_drm_mode_config_init(): 91: [ 4.212547] [DISPLAY] dss_drm_init(): 638: [ 4.212563] [drm] +. [ 4.212585] [DISPLAY] dss_dts_parse(): 513: [ 4.212603] [DISPLAY] dss_dts_parse(): 530: of device: /passthrough/dpe@10004000 [ 4.212635] [DISPLAY] dss_dts_parse(): 531: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 4.212661] [DISPLAY] dss_dts_parse(): 532: ctx->base: ffffff800bd00000 [ 4.212688] Unhandled fault: ttbr address size fault (0x96000000) at 0xffffff800bd01000 [ 4.212708] Mem abort info: [ 4.212720] Exception class = DABT (current EL), IL = 32 bits [ 4.212738] SET = 0, FnV = 0 [ 4.212751] EA = 0, S1PTW = 0 [ 4.212763] Data abort info: [ 4.212776] ISV = 0, ISS = 0x00000000 [ 4.212789] CM = 0, WnR = 0 [ 4.212806] Internal error: : 96000000 [#1] PREEMPT SMP [ 4.212821] Modules linked in: [ 4.212839] CPU: 7 PID: 99 Comm: kworker/7:1 Tainted: G S 4.14.0-rc7 #456 [ 4.212857] Hardware name: XENVM-4.8 (DT) [ 4.212878] Workqueue: events deferred_probe_work_func [ 4.212893] task: ffffffc01abe6000 task.stack: ffffff8009878000 [ 4.212916] PC is at dss_drm_init+0x1a8/0x680 [ 4.212931] LR is at dss_drm_init+0x1a0/0x680 [ 4.212945] pc : [<ffffff80087061d0>] lr : [<ffffff80087061c8>] pstate: 40000045 [ 4.212963] sp : ffffff800987ba20 [ 4.212973] x29: ffffff800987ba30 x28: ffffffc01bff42e8 [ 4.212990] x27: ffffff800bd01000 x26: ffffffc018d25760 [ 4.213006] x25: ffffff80090f8c70 x24: ffffffc017212800 [ 4.213023] x23: ffffff8008e32000 x22: ffffff80090f8000 [ 4.213039] x21: ffffff8008e32748 x20: ffffffc018d25018 [ 4.213055] x19: ffffffc01abdf810 x18: 0000000000000010 [ 4.213071] x17: 000000000000000e x16: 0000000000000020 [ 4.213087] x15: ffffffffffffffff x14: ffffff80894c6157 [ 4.213104] x13: ffffff80094c6165 x12: ffffff8009379000 [ 4.213120] x11: 0000000005f5e0ff x10: ffffff800987b6f0 [ 4.257555] x9 : 00000000ffffffd0 x8 : 000000000000004b [ 4.257573] x7 : 000000000000000c x6 : 00000000000001ee [ 4.257591] x5 : 0000000000007ceb x4 : 0000000000000000 [ 4.257608] x3 : ffffff800934a000 x2 : 0000000000000000 [ 4.257625] x1 : 0000000000000000 x0 : 000000000000003b [ 4.257644] Process kworker/7:1 (pid: 99, stack limit = 0xffffff8009878000) [ 4.257661] Call trace: [ 4.257672] Exception stack(0xffffff800987b8e0 to 0xffffff800987ba20) [ 4.257691] b8e0: 000000000000003b 0000000000000000 0000000000000000 ffffff800934a000 [ 4.257713] b900: 0000000000000000 0000000000007ceb 00000000000001ee 000000000000000c [ 4.257734] b920: 000000000000004b 00000000ffffffd0 ffffff800987b6f0 0000000005f5e0ff [ 4.257756] b940: ffffff8009379000 ffffff80094c6165 ffffff80894c6157 ffffffffffffffff [ 4.257777] b960: 0000000000000020 000000000000000e 0000000000000010 ffffffc01abdf810 [ 4.257799] b980: ffffffc018d25018 ffffff8008e32748 ffffff80090f8000 ffffff8008e32000 [ 4.257821] b9a0: ffffffc017212800 ffffff80090f8c70 ffffffc018d25760 ffffff800bd01000 [ 4.257842] b9c0: ffffffc01bff42e8 ffffff800987ba30 ffffff80087061c8 ffffff800987ba20 [ 4.257864] b9e0: ffffff80087061d0 0000000040000045 0000000000000214 ffffff800bd00000 [ 4.257885] ba00: ffffffffffffffff 0000000000007c9f ffffff800987ba30 ffffff80087061d0 [ 4.257908] [<ffffff80087061d0>] dss_drm_init+0x1a8/0x680 [ 4.257926] [<ffffff8008705490>] kirin_drm_bind+0x128/0x310 [ 4.257945] [<ffffff8008740c88>] try_to_bring_up_master+0x180/0x1e0 [ 4.257965] [<ffffff8008740d8c>] component_add+0xa4/0x170 [ 4.257981] [<ffffff800870b574>] dsi_probe+0x52c/0x5a0 [ 4.258000] [<ffffff8008749d60>] platform_drv_probe+0x60/0xc0 [ 4.258018] [<ffffff8008747a94>] driver_probe_device+0x234/0x2e0 [ 4.258037] [<ffffff8008747cb0>] __device_attach_driver+0xa0/0xe8 [ 4.258056] [<ffffff80087459d0>] bus_for_each_drv+0x58/0xa8 [ 4.258072] [<ffffff80087476e8>] __device_attach+0xc8/0x138 [ 4.302470] [<ffffff8008747d74>] device_initial_probe+0x24/0x30 [ 4.302490] [<ffffff8008746ae4>] bus_probe_device+0x9c/0xa8 [ 4.302506] [<ffffff8008746fcc>] deferred_probe_work_func+0xac/0x150 [ 4.302528] [<ffffff80080efd98>] process_one_work+0x1d8/0x490 [ 4.302547] [<ffffff80080f0298>] worker_thread+0x248/0x478 [ 4.302565] [<ffffff80080f6728>] kthread+0x138/0x140 [ 4.302584] [<ffffff8008084d7c>] ret_from_fork+0x10/0x1c [ 4.302601] Code: f90037a4 97e8a1ea f943a69b 9140077b (b940037b) [ 4.302621] ---[ end trace d64c23a811313502 ]--- [ 4.302638] Kernel panic - not syncing: Fatal exception [ 4.302656] SMP: stopping secondary CPUs [ 4.332694] Kernel Offset: disabled [ 4.332708] CPU features: 0x002004 [ 4.332720] Memory Limit: none [ 4.332736] Rebooting in 5 seconds.. ============================================================================ How to fix this IO addr size fault, I think some problem in dts or debian.cfg to map Physical addresses to GFNs Please help me to come out of this problem. Thanks Omkar B On Thu, Nov 1, 2018 at 1:11 AM Julien Grall <julien.grall@arm.com> wrote: > > > 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 > -- 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. [-- Attachment #1.2: Type: text/html, Size: 33703 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-11-01 9:15 ` Omkar Bolla @ 2018-11-01 21:49 ` Julien Grall 2018-11-02 5:25 ` Omkar Bolla 2018-11-02 8:47 ` Wei Liu 0 siblings, 2 replies; 20+ messages in thread From: Julien Grall @ 2018-11-01 21:49 UTC (permalink / raw) To: Omkar Bolla Cc: jgross, xen-devel, Wei Liu, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini (+ 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 <myguest> > > 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 0xE8600000 0x0 0x80000>, > <0x0 0xFFF35000 0 0x1000>, > <0x0 0xFFF0A000 0 0x1000>, > <0x0 0xFFF31000 0 0x1000>, > <0x0 0xE86C0000 0 0x10000>; > #endif > //reg = <0x0 0x10004000 0x0 0x80000>, > reg = <0x0 0x10004000 0x0 0x80000>, > <0x0 0x10084000 0 0x1000>, > <0x0 0x10085000 0 0x1000>, > <0x0 0x10086000 0 0x1000>, > <0x0 0x100C4000 0 0x10000>; > // <0x0 0x10087000 0 0x10000>; > > interrupts = <0 245 4>; > > clocks = <&clk_xen HI3660_ACLK_GATE_DSS>, > <&clk_xen HI3660_PCLK_GATE_DSS>, > <&clk_xen HI3660_CLK_GATE_EDC0>, > <&clk_xen HI3660_CLK_GATE_LDI0>, > <&clk_xen HI3660_CLK_GATE_LDI1>, > <&clk_xen HI3660_CLK_GATE_DSS_AXI_MM>, > <&clk_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 = <&dsi_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 0x80000>, > <0 0x10084000 0 0x1000>; > > clocks = <&clk_xen HI3660_CLK_GATE_TXDPHY0_REF>, > <&clk_xen HI3660_CLK_GATE_TXDPHY1_REF>, > <&clk_xen HI3660_CLK_GATE_TXDPHY0_CFG>, > <&clk_xen HI3660_CLK_GATE_TXDPHY1_CFG>, > <&clk_xen HI3660_PCLK_GATE_DSI0>, > <&clk_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@0x00000" ] > > ################# 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 Who is going the remap? The guest? Also, can you expand what you mean by it crash the second time. Is it during the remap, or access the new mapped region? > ============================================================================ > [ 3.215021] OF: rrrrrrrrrrrr: start: 0x10004000, sz = 0x80000 > [ 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: ffffff800bd01000 > [ 3.215126] [DISPLAY] dsi_parse_dt(): 1541: > [ 3.215136] OF: rrrrrrrrrrrr: start: 0x10084000, sz = 0x1000 > [ 3.215169] [DISPLAY] dsi_parse_dt(): 1548: > [ 4.159087] [DISPLAY] dsi_parse_dt(): 1563: > [ 4.159092] [DISPLAY] dsi_parse_dt(): 1568: > [ 4.159132] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_ref,1 > [ 4.159163] [D][XEN_VCLK]xen_vclk_xfer(): 164: > ******************************************* > [ 4.159399] [D][XEN_VCLK]xen_vclk_xfer(): 170: > ******************************************* > [ 4.159626] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > domain-0 > [ 4.160218] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > domain 0 fired!!! > [ 4.160359] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > [ 4.160532] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > [ 4.160542] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > [ 4.160545] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... > [ 4.160554] [DISPLAY] dsi_parse_dt(): 1575: > [ 4.160560] [D][XEN_VCLK]vclk_round_rate(): 224: called... > [ 4.160567] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > clk_txdphy0_ref,4,19200000 > [ 4.160570] [D][XEN_VCLK]xen_vclk_xfer(): 164: > ******************************************* > [ 4.161095] [D][XEN_VCLK]xen_vclk_xfer(): 170: > ******************************************* > [ 4.161331] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > domain-0 > [ 4.161946] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > domain 0 fired!!! > [ 4.162120] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > [ 4.162284] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > [ 4.162295] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > [ 4.162301] [DISPLAY] dsi_parse_dt(): 1583: > [ 4.162314] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: clk_txdphy0_cfg,1 > [ 4.162316] [D][XEN_VCLK]xen_vclk_xfer(): 164: > ******************************************* > [ 4.162641] [D][XEN_VCLK]xen_vclk_xfer(): 170: > ******************************************* > [ 4.162984] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > domain-0 > [ 4.163596] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > domain 0 fired!!! > [ 4.167753] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > [ 4.167955] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > [ 4.167968] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > [ 4.167971] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... > [ 4.167979] [DISPLAY] dsi_parse_dt(): 1593: > [ 4.167982] [D][XEN_VCLK]vclk_round_rate(): 224: called... > [ 4.167985] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > clk_txdphy0_cfg,4,19200000 > [ 4.167992] [D][XEN_VCLK]xen_vclk_xfer(): 164: > ******************************************* > [ 4.168244] [D][XEN_VCLK]xen_vclk_xfer(): 170: > ******************************************* > [ 4.168476] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > domain-0 > [ 4.169101] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > domain 0 fired!!! > [ 4.169262] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > [ 4.169448] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > [ 4.169491] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > [ 4.169510] [DISPLAY] dsi_parse_dt(): 1601: > [ 4.169535] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: pclk_dsi0,1 > [ 4.169554] [D][XEN_VCLK]xen_vclk_xfer(): 164: > ******************************************* > [ 4.169803] [D][XEN_VCLK]xen_vclk_xfer(): 170: > ******************************************* > [ 4.170019] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > domain-0 > [ 4.170619] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > domain 0 fired!!! > [ 4.170779] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > [ 4.170965] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > [ 4.170978] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > [ 4.170981] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer done... > [ 4.170989] [DISPLAY] dsi_parse_dt(): 1611: > [ 4.170992] [DISPLAY] dsi_probe(): 1654: Before component add > [ 4.170997] [DISPLAY] compare_of(): 242: > [ 4.171002] [DISPLAY] kirin_drm_bind(): 257: > [ 4.171004] [drm] +. > [ 4.171386] [DISPLAY] kirin_drm_kms_init(): 105: > [ 4.171391] [drm] +. > [ 4.212543] [DISPLAY] kirin_drm_mode_config_init(): 91: > [ 4.212547] [DISPLAY] dss_drm_init(): 638: > [ 4.212563] [drm] +. > [ 4.212585] [DISPLAY] dss_dts_parse(): 513: > [ 4.212603] [DISPLAY] dss_dts_parse(): 530: of device: > /passthrough/dpe@10004000 > [ 4.212635] [DISPLAY] dss_dts_parse(): 531: > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [ 4.212661] [DISPLAY] dss_dts_parse(): 532: ctx->base: ffffff800bd00000 > [ 4.212688] Unhandled fault: ttbr address size fault (0x96000000) at > 0xffffff800bd01000 IIRC, this error usually happen when the region is not mapped in stage-2. On Xen debug-build (CONFIG_DEBUG=y in .config) you should get some log if there was a data abort in stage-2. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-11-01 21:49 ` Julien Grall @ 2018-11-02 5:25 ` Omkar Bolla 2018-11-02 8:47 ` Wei Liu 1 sibling, 0 replies; 20+ messages in thread From: Omkar Bolla @ 2018-11-02 5:25 UTC (permalink / raw) To: Julien Grall Cc: jgross, xen-devel, wei.liu2, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Lars Kurth, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 21545 bytes --] 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 <myguest> > 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 0xE8600000 0x0 0x80000>, > > <0x0 0xFFF35000 0 0x1000>, > > <0x0 0xFFF0A000 0 0x1000>, > > <0x0 0xFFF31000 0 0x1000>, > > <0x0 0xE86C0000 0 0x10000>; > > #endif > > //reg = <0x0 0x10004000 0x0 0x80000>, > > reg = <0x0 0x10004000 0x0 0x80000>, > > <0x0 0x10084000 0 0x1000>, > > <0x0 0x10085000 0 0x1000>, > > <0x0 0x10086000 0 0x1000>, > > <0x0 0x100C4000 0 0x10000>; > > // <0x0 0x10087000 0 0x10000>; > > > > interrupts = <0 245 4>; > > > > clocks = <&clk_xen HI3660_ACLK_GATE_DSS>, > > <&clk_xen HI3660_PCLK_GATE_DSS>, > > <&clk_xen HI3660_CLK_GATE_EDC0>, > > <&clk_xen HI3660_CLK_GATE_LDI0>, > > <&clk_xen HI3660_CLK_GATE_LDI1>, > > <&clk_xen HI3660_CLK_GATE_DSS_AXI_MM>, > > <&clk_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 = <&dsi_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 0x80000>, > > <0 0x10084000 0 0x1000>; > > > > clocks = <&clk_xen HI3660_CLK_GATE_TXDPHY0_REF>, > > <&clk_xen HI3660_CLK_GATE_TXDPHY1_REF>, > > <&clk_xen HI3660_CLK_GATE_TXDPHY0_CFG>, > > <&clk_xen HI3660_CLK_GATE_TXDPHY1_CFG>, > > <&clk_xen HI3660_PCLK_GATE_DSI0>, > > <&clk_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@0x00000" ] > > > > ################# 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 > > Who is going the remap? The guest? Also, can you expand what you mean by > it crash the second time. Is it during the remap, or access the new > mapped region? > Here, Guest(domain-U) is remapping in display driver. In display driver remapping is successful and yesterday i found when i try to access remapped region domain-U giving that crash, "Unhandled fault: ttbr address size fault" > > > > ============================================================================ > > [ 3.215021] OF: rrrrrrrrrrrr: start: 0x10004000, sz = 0x80000 > > [ 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: > ffffff800bd01000 > > [ 3.215126] [DISPLAY] dsi_parse_dt(): 1541: > > [ 3.215136] OF: rrrrrrrrrrrr: start: 0x10084000, sz = 0x1000 > > [ 3.215169] [DISPLAY] dsi_parse_dt(): 1548: > > [ 4.159087] [DISPLAY] dsi_parse_dt(): 1563: > > [ 4.159092] [DISPLAY] dsi_parse_dt(): 1568: > > [ 4.159132] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > clk_txdphy0_ref,1 > > [ 4.159163] [D][XEN_VCLK]xen_vclk_xfer(): 164: > > ******************************************* > > [ 4.159399] [D][XEN_VCLK]xen_vclk_xfer(): 170: > > ******************************************* > > [ 4.159626] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > > domain-0 > > [ 4.160218] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > > domain 0 fired!!! > > [ 4.160359] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > > [ 4.160532] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > > [ 4.160542] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > > [ 4.160545] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer > done... > > [ 4.160554] [DISPLAY] dsi_parse_dt(): 1575: > > [ 4.160560] [D][XEN_VCLK]vclk_round_rate(): 224: called... > > [ 4.160567] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > > clk_txdphy0_ref,4,19200000 > > [ 4.160570] [D][XEN_VCLK]xen_vclk_xfer(): 164: > > ******************************************* > > [ 4.161095] [D][XEN_VCLK]xen_vclk_xfer(): 170: > > ******************************************* > > [ 4.161331] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > > domain-0 > > [ 4.161946] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > > domain 0 fired!!! > > [ 4.162120] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > > [ 4.162284] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > > [ 4.162295] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > > [ 4.162301] [DISPLAY] dsi_parse_dt(): 1583: > > [ 4.162314] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > clk_txdphy0_cfg,1 > > [ 4.162316] [D][XEN_VCLK]xen_vclk_xfer(): 164: > > ******************************************* > > [ 4.162641] [D][XEN_VCLK]xen_vclk_xfer(): 170: > > ******************************************* > > [ 4.162984] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > > domain-0 > > [ 4.163596] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > > domain 0 fired!!! > > [ 4.167753] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > > [ 4.167955] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > > [ 4.167968] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > > [ 4.167971] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer > done... > > [ 4.167979] [DISPLAY] dsi_parse_dt(): 1593: > > [ 4.167982] [D][XEN_VCLK]vclk_round_rate(): 224: called... > > [ 4.167985] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: > > clk_txdphy0_cfg,4,19200000 > > [ 4.167992] [D][XEN_VCLK]xen_vclk_xfer(): 164: > > ******************************************* > > [ 4.168244] [D][XEN_VCLK]xen_vclk_xfer(): 170: > > ******************************************* > > [ 4.168476] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > > domain-0 > > [ 4.169101] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > > domain 0 fired!!! > > [ 4.169262] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > > [ 4.169448] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > > [ 4.169491] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > > [ 4.169510] [DISPLAY] dsi_parse_dt(): 1601: > > [ 4.169535] [D][XEN_VCLK]xen_vclk_xfer(): 163: buffer: pclk_dsi0,1 > > [ 4.169554] [D][XEN_VCLK]xen_vclk_xfer(): 164: > > ******************************************* > > [ 4.169803] [D][XEN_VCLK]xen_vclk_xfer(): 170: > > ******************************************* > > [ 4.170019] [D][XEN_VCLK]xen_vclk_xfer(): 176: Sending IRQ_DATA to > > domain-0 > > [ 4.170619] [D][XEN_VCLK]xen_vclk_interrupt(): 446: IRQ(13) from > > domain 0 fired!!! > > [ 4.170779] [D][XEN_VCLK]vclk_fe_bh(): 394: irq_status: 0x3 > > [ 4.170965] [D][XEN_VCLK]vclk_fe_bh(): 407: ACK Recieved from dom-0 > > [ 4.170978] [D][XEN_VCLK]xen_vclk_xfer(): 179: Xfer Done > > [ 4.170981] [D][XEN_VCLK]xen_of_clk_src_onecell_get(): 286: Xfer > done... > > [ 4.170989] [DISPLAY] dsi_parse_dt(): 1611: > > [ 4.170992] [DISPLAY] dsi_probe(): 1654: Before component add > > [ 4.170997] [DISPLAY] compare_of(): 242: > > [ 4.171002] [DISPLAY] kirin_drm_bind(): 257: > > [ 4.171004] [drm] +. > > [ 4.171386] [DISPLAY] kirin_drm_kms_init(): 105: > > [ 4.171391] [drm] +. > > [ 4.212543] [DISPLAY] kirin_drm_mode_config_init(): 91: > > [ 4.212547] [DISPLAY] dss_drm_init(): 638: > > [ 4.212563] [drm] +. > > [ 4.212585] [DISPLAY] dss_dts_parse(): 513: > > [ 4.212603] [DISPLAY] dss_dts_parse(): 530: of device: > > /passthrough/dpe@10004000 > > [ 4.212635] [DISPLAY] dss_dts_parse(): 531: > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [ 4.212661] [DISPLAY] dss_dts_parse(): 532: ctx->base: > ffffff800bd00000 > > [ 4.212688] Unhandled fault: ttbr address size fault (0x96000000) at > > 0xffffff800bd01000 > > IIRC, this error usually happen when the region is not mapped in > stage-2. On Xen debug-build (CONFIG_DEBUG=y in .config) you should get > some log if there was a data abort in stage-2. > > I enabled (CONFIG_DEBUG=y in .config) in xenbits src, I dont have any log from xen. also checked 'xl dmesg' but no log from xen. How to find GFNs from xen? I mean, xen maps region from RAM memory of domain-u or maps to memory of Domain-0 and give access to domain-u? I am sharing log of xl dmesg after enabling guest log level: ====================================== root@hikey960:/debian# xl dmesg (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000000000000 - 000000001abfffff (XEN) RAM: 000000001ad88000 - 0000000031ffffff (XEN) RAM: 0000000032101000 - 000000003dffffff (XEN) RAM: 0000000040000000 - 000000004aee9fff (XEN) RAM: 0000000089cc0000 - 00000000b8427fff (XEN) RAM: 00000000b9af0000 - 00000000b9baffff (XEN) RAM: 00000000b9c50000 - 00000000b9c54fff (XEN) RAM: 00000000b9c56000 - 00000000b9d4ffff (XEN) RAM: 00000000ba114000 - 00000000ba11bfff (XEN) RAM: 00000000ba11c000 - 00000000bdbf1fff (XEN) RAM: 00000000bdbf2000 - 00000000bdca2fff (XEN) RAM: 00000000bdca3000 - 00000000bdd58fff (XEN) RAM: 00000000bdd59000 - 00000000bef4ffff (XEN) RAM: 00000000bef50000 - 00000000bef54fff (XEN) RAM: 00000000bef55000 - 00000000bf0dffff (XEN) RAM: 00000000bf0e0000 - 00000000bf12ffff (XEN) RAM: 00000000bf180000 - 00000000bf188fff (XEN) RAM: 00000000bf189000 - 00000000bfffffff (XEN) RAM: 00000000c0000000 - 00000000dfffffff (XEN) RAM: 0000000200000000 - 000000021fffffff (XEN) (XEN) MODULE[0]: 00000000b8428000 - 00000000b8436000 Device Tree (XEN) MODULE[1]: 00000000b8544000 - 00000000b997ca00 Kernel console=tty0 console=hvc0 root=/dev/sdd14 rootwait rw rootfstype=ext4 efi=noruntime video=HDMI-A -1:1280x720@60 (XEN) (XEN) Command line: loglvl=all console=dtuart dtuart=/soc/serial@fff32000 dom0_mem=512M efi=no-rs guest_loglvl=all (XEN) Placing Xen at 0x000000001aa00000-0x000000001ac00000 (XEN) Update BOOTMOD_XEN from 00000000b8436000-00000000b8536d81 => 000000001aa00000-000000001ab00d81 (XEN) Domain heap initialised (XEN) Platform: Generic System (XEN) Looking for dtuart at "/soc/serial@fff32000", options "" Xen 4.8.5-pre (XEN) Xen version 4.8.5-pre (omkar.bolla@) (aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.05) 7.1.1 20170510) debug=n Fri Nov 2 10:40:45 IST 2018 (XEN) Latest ChangeSet: (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using PSCI-1.1 for SMP bringup (XEN) SMP: Allowing 8 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=00000000e82b1000 (XEN) gic_cpu_addr=00000000e82b2000 (XEN) gic_hyp_addr=00000000e82b4000 (XEN) gic_vcpu_addr=00000000e82b6000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 (XEN) CPU 3 booted. (XEN) Bringing up CPU4 (XEN) CPU 4 booted. (XEN) Bringing up CPU5 (XEN) CPU 5 booted. (XEN) Bringing up CPU6 (XEN) CPU 6 booted. (XEN) Bringing up CPU7 (XEN) CPU 7 booted. (XEN) Brought up 8 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) I/O virtualisation disabled (XEN) build-id: baea0accc1a90dbddfdab8bcec069906a9b45ba6 (XEN) alternatives: Patching with alt table 00000000400a4868 -> 00000000400a4c04 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000b8544000 (XEN) Allocating 1:1 mappings totalling 512MB for dom0: (XEN) BANK[0] 0x000000c0000000-0x000000e0000000 (512MB) (XEN) Grant table range: 0x0000001aa00000-0x0000001aa5f000 (XEN) /framebuffer@E8600000 passthrough = 0 nirq = 5 naddr = 7 (XEN) - MMIO: 00e8600000 - 00e8680000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00fff35000 - 00fff36000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00fff0a000 - 00fff0b000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00e8a09000 - 00e8a0a000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00e86c0000 - 00e86d0000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00fff02000 - 00fff03000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) - MMIO: 00fff31000 - 00fff32000 P2MType=5 (XEN) Device Node: /framebuffer@E8600000 (XEN) /mali@E82C0000 passthrough = 0 nirq = 3 naddr = 1 (XEN) - MMIO: 00e82c0000 - 00e82c4000 P2MType=5 (XEN) Device Node: /mali@E82C0000 (XEN) /dpe@E8600000 passthrough = 0 nirq = 1 naddr = 5 (XEN) - MMIO: 00e8600000 - 00e8680000 P2MType=5 (XEN) Device Node: /dpe@E8600000 (XEN) - MMIO: 00fff35000 - 00fff36000 P2MType=5 (XEN) Device Node: /dpe@E8600000 (XEN) - MMIO: 00fff0a000 - 00fff0b000 P2MType=5 (XEN) Device Node: /dpe@E8600000 (XEN) - MMIO: 00fff31000 - 00fff32000 P2MType=5 (XEN) Device Node: /dpe@E8600000 (XEN) - MMIO: 00e86c0000 - 00e86d0000 P2MType=5 (XEN) Device Node: /dpe@E8600000 (XEN) /dsi@E8601000 passthrough = 0 nirq = 0 naddr = 2 (XEN) - MMIO: 00e8601000 - 00e8680000 P2MType=5 (XEN) Device Node: /dsi@E8601000 (XEN) - MMIO: 00fff35000 - 00fff36000 P2MType=5 (XEN) Device Node: /dsi@E8601000 (XEN) Loading zImage from 00000000b8544000 to 00000000c0080000-00000000c14b8a00 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x00000000c8000000-0x00000000c800a8a1 (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs (XEN) .........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 272kB init memory. (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER28 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER32 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER36 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER40 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER44 (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v1: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v2: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v3: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v4: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v5: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v6: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d0v7: vGICD: unhandled word write 0xffffffff to ICACTIVER0 ------------------------------------------------------------------------------- (XEN) memory_map:add: dom1 gfn=10084 mfn=fff35 nr=1 ------------------------------------------------------------------------------- (XEN) d1v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v1: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v2: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v3: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v4: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v5: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v6: vGICD: unhandled word write 0xffffffff to ICACTIVER0 (XEN) d1v7: vGICD: unhandled word write 0xffffffff to ICACTIVER0 ====================================== After enabling guest log level, It is showing only one io region mapped instead of all. Why? > 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. [-- Attachment #1.2: Type: text/html, Size: 32688 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen PV: Sample new PV driver for buffer sharing between domains 2018-11-01 21:49 ` Julien Grall 2018-11-02 5:25 ` Omkar Bolla @ 2018-11-02 8:47 ` Wei Liu 1 sibling, 0 replies; 20+ messages in thread From: Wei Liu @ 2018-11-02 8:47 UTC (permalink / raw) To: Julien Grall Cc: jgross, xen-devel, Wei Liu, Oleksandr_Andrushchenko, Oleksandr Andrushchenko, Omkar Bolla, Lars Kurth, Stefano Stabellini On Thu, Nov 01, 2018 at 09:49:13PM +0000, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-11-02 8:47 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-27 5:44 Xen PV: Sample new PV driver for buffer sharing between domains Omkar Bolla 2018-09-27 9:39 ` Lars Kurth 2018-09-27 10:07 ` Oleksandr Andrushchenko 2018-09-27 10:16 ` Juergen Gross 2018-09-27 10:20 ` Oleksandr Andrushchenko 2018-09-27 10:34 ` Julien Grall 2018-09-27 10:35 ` Omkar Bolla 2018-09-27 11:03 ` Juergen Gross 2018-09-28 12:55 ` Omkar Bolla 2018-09-28 13:42 ` Juergen Gross 2018-10-02 10:03 ` Omkar Bolla 2018-10-03 9:53 ` Julien Grall 2018-10-08 9:12 ` Omkar Bolla 2018-10-08 10:30 ` Julien Grall 2018-10-17 12:24 ` Omkar Bolla 2018-10-31 19:41 ` Julien Grall 2018-11-01 9:15 ` Omkar Bolla 2018-11-01 21:49 ` Julien Grall 2018-11-02 5:25 ` Omkar Bolla 2018-11-02 8:47 ` Wei Liu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.