Re: [Xen-devel] Emulation of xen ARM on qemux86_64
Hi Pranay, As I say in my previous e-mail: "I'm not familiar with QEMU, but in general case - you can't just take image (for example RCAR-H3) and run it inside QEMU - a some things might be different - uart, gic, timer, etc. And i'm not sure about support of HW virtualization on QEMU - looks like your are asking about emulation ARM HW virtualization on X86_64 platform." I don't think that it is possible to emulate ARM HW virtualization on x86_64 platform via QEMU. So - in my opinion - layers such as you are asking doesn't existing for QEMU. According to [1] looks like ARM Ltd provides emulator, called ARMv8 Foundation Model - that is supports Xen [2]. But I never used it and looks like its not free and has some limited trial period. [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions [2] https://developer.arm.com/products/system-design/fixed-virtual-platforms With the best regards, Iurii On Tue, May 23, 2017 at 4:17 PM, pranay kukreti wrote: > > > > Hi, > Thank you for the quick response. > What I wanted to know is that if there is any yocto layer support for > XEN-ARM on QEMU machine, which could be used for testing purposes. Like for > RCAR there is a [1] Meta-platform-xen layer which provides support for > RCAR. Same way, is there a layer which can be used for QEMU? > [1] https://github.com/qbeeukraine/meta-platform-xen > regards, > Pranay Kukreti > VIT university, Vellore. > > > On Monday, 22 May 2017, 22:55, Iurii Mykhalskyi < > iurii.mykhals...@globallogic.com> wrote: > > > Hi Pranay, > > I'm not familiar with QEMU, but in general case - you can't just take > image (for example RCAR-H3) and run it inside QEMU - a some things might be > different - uart, gic, timer, etc. > And i'm not sure about support of HW virtualization on QEMU - looks like > your are asking about emulation ARM HW virtualization on X86_64 platform. > > If you want to play with virtualization, try to get some widely available > board - Allwinner based or some OMAP4/5 based boards, etc [1] > > For debug purposes we are mostly using printk and sometimes blinking LEDS > :) > > With the best regards, > Iurii > > [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_ > Virtualization_Extensions > > > On Mon, May 22, 2017 at 8:08 PM, Iurii Konovalenko globallogic.com> wrote: > > + Iurii Mykhalkyi > > Best regards. > > Iurii Konovalenko | Associate Manager, Engineering > GlobalLogic > P +3.8044.492 ext. 4704 M +38.099.932.2909 > S yufuntik > www.globallogic.com > http://www.globallogic.com/ email_disclaimer.txt > <http://www.globallogic.com/email_disclaimer.txt> > > On Mon, May 22, 2017 at 8:38 AM, pranay kukreti > wrote: > > Hi, > > > I am new to xen-arm development on yocto-project. Right now i don't have > the hardware, but i was able to create an image of xen-arm for RCAR-H3. I > wanted to see how xen-arm works, so was wondering if xen-arm can be > implemented to be used with a qemu machine. If so please let me know where > can i find the resources. Also which debugger would you recommend to be > used with the RCAR-H3. > It would be really kind of you if you could solve my queries. > Thanks, > Pranay Kukreti > VIT University, Vellore. > > > > > > > -- > > Iurii Mykhalskyi | Lead Software Engineer > GlobalLogic > P +38.044.492.9695x3664 M +38.096.311.5467 <+380%2096%20311%205467> S > mad-nemoi > www.globallogic.com > <http://www.globallogic.com/> > http://www.globallogic.com/email_disclaimer.txt > > > -- Iurii Mykhalskyi | Lead Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Emulation of xen ARM on qemux86_64
Hi Pranay, I'm not familiar with QEMU, but in general case - you can't just take image (for example RCAR-H3) and run it inside QEMU - a some things might be different - uart, gic, timer, etc. And i'm not sure about support of HW virtualization on QEMU - looks like your are asking about emulation ARM HW virtualization on X86_64 platform. If you want to play with virtualization, try to get some widely available board - Allwinner based or some OMAP4/5 based boards, etc [1] For debug purposes we are mostly using printk and sometimes blinking LEDS :) With the best regards, Iurii [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions On Mon, May 22, 2017 at 8:08 PM, Iurii Konovalenko < iurii.konovale...@globallogic.com> wrote: > + Iurii Mykhalkyi > > Best regards. > > Iurii Konovalenko | Associate Manager, Engineering > GlobalLogic > P +3.8044.492 ext. 4704 M +38.099.932.2909 <+380%2099%20932%202909> > S yufuntik > www.globallogic.com > http://www.globallogic.com/email_disclaimer.txt > > On Mon, May 22, 2017 at 8:38 AM, pranay kukreti > wrote: > >> Hi, >> >> >> I am new to xen-arm development on yocto-project. Right now i don't have >> the hardware, but i was able to create an image of xen-arm for RCAR-H3. I >> wanted to see how xen-arm works, so was wondering if xen-arm can be >> implemented to be used with a qemu machine. If so please let me know where >> can i find the resources. Also which debugger would you recommend to be >> used with the RCAR-H3. >> It would be really kind of you if you could solve my queries. >> Thanks, >> Pranay Kukreti >> VIT University, Vellore. >> >> >> > -- Iurii Mykhalskyi | Lead Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on lager for DOMU
Hi George, I didn't test official Renesas yocto layer for Lager board. But general approach to bring-up xen-tools in Dom0 rootfs are follow: 1. clone meta-virtualization layer along with other layers 2. Append xen-base package into default package list (e.g. core-image-minimal or weston-image-minimal). 3. In addition you need to add Xen specific options to Dom0 kernel config (please refer to [1] as reference). After that please refer to Oleksandr mail about DomU start-up. [1] https://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs With the best regards, Iurii On Fri, Jan 27, 2017 at 9:46 AM, Oleksandr Andrushchenko wrote: > On 01/26/2017 09:11 PM, Julien Grall wrote: > >> >> >> On 24/01/2017 13:05, George John wrote: >> >>> Hi all, >>> >> >> Hello, >> >> >> I was able to bring up Dom0 in lager board by steps followed by charles. >>> What could be the steps I could follow to bring up DomU in xen for lager >>> board.?.. >>> >> >> You can give a look to: >> - https://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs >> - https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization >> _Extensions#DomU_kernel_and_DTS >> >> Alternatively, you can find a distribution where the kernel has Xen >> options enabled. >> > For testing and some development on ARM64 I use Ubuntu for DomU [2], [3] > >> It may be the case in Yocto, or you can look at centos (see [1]). >> >> How to bring xen-utils in the filesystem(yocto build) of Dom0 >> >>> linux for configuring DomU. >>> >> >> I don't know much about Yocto. I have CCed Iurri who I think is using >> Yocto. It might be able to help you here. >> >> Cheers, >> >> [1] https://blog.xenproject.org/2015/10/05/xen-in-centos-7-aarch64/ >> >> [2] https://github.com/xen-troops/manifests/wiki/DomU-Ubuntu-on-H3-M3 > [3] https://help.ubuntu.com/community/Xen > -- Iurii Mykhalskyi | Lead Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Dear all, Thanks for all your replies. I'll keep them in mind while preparing next patch sets. With the best regards, Iurii Mykhalskyi On Fri, Nov 25, 2016 at 11:13 AM, Andrii Anisov wrote: > Dear Iurii, > > It was my mistake: > > Following: > >> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > >> build issue, described here [2]. I haven't found any better solution > except > >> this one. > > > > Is not needed. > > The issue does not appear with the current master HEAD. > > With clean build I still face the issue described here: > https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html. > > Sincerely, > Andrii Anisov. > -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ARM] Handling CMA pool device nodes in Dom0
Hello!
I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X) support
in Xen mainline.
Salvator-X has several CMA pool nodes, for example:
1:
adsp_reserved: linux,adsp {
compatible = "shared-dma-pool";
reusable;
reg = <0x 0x5700 0x0 0x0100>;
};
2:
linux,cma {
compatible = "shared-dma-pool";
reusable;
reg = <0x 0x5800 0x0 0x1800>;
linux,cma-default;
};
During Dom0 allocation, we can't guarantee, that allocated memory will
contain mentioned regions.
In second сase, we can actually hardcode mapped region by using separate
DTS for Dom0 with changed memory regions.
But for first one, this in not an option - this pool is used for audio DSP
and its firmware relies on this addresses.
What is the correct way to solve this situation?
Does Xen has some mechanism to handle such cases?
Thank you.
--
Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Dear Andrii and all, On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov wrote: > Iurii, > > About the following: > > > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > > build issue, described here [2]. I haven't found any better solution > except > > this one. > > Please review this [1] thread. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2016- > 11/msg01921.html I have made typos, Description to 2 & 3 items should exchanged vise-versa. But I don't agree with this patch - ACPI sould be enable only for ARM64 platforms - in your patch it can be enable for both platforms, depending on CONFIG_ACPI flag state. > > > Sincerely, > Andrii Anisov. > Thanks for your comments. With the best regards, Iurii Mykhalskyi -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Dear all, Andrii, thanks for the remark - I'll rework this patch. Julien, I have updated yocto layer [1] to use the most recent stable Xen version - Xen 4.8-rc6 Looks like used patches for Xen should be described more briefly: 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch - Early console introduction for Salvator-X board 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix build issue, described here [2]. I haven't found any better solution except this one. 3. 0003-HACK-Fix-compilation-issues.patch - is a hack to avoid acpi compilation issue on arm64 platform. Looks like Andrii faces same problem [3] [4]. 4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not essential, but xsm might be usefull for some use-cases. 5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch - Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if Dom0 will be allocated at over 4GB space - DMA operation will fail. According to xen-devel list [5], this patch planned to be included in Xen 4.9. 6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box, but by default Xen traps such calls, so we have to allow such actions. [1] https://github.com/qbeeukraine/meta-platform-xen [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html [3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html [4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html [5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html In last email you have written: > Also, it is not clear to me why you need a specific device tree and hacked DOM0 linux (see [2]) on this board for Xen. This would need some documentation on the wiki. Yes, this need some explanation. I'll update related wiki page in few hours. Thanks for all of your comments. With the best regards, Iurii Mykhalskyi On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov wrote: > Well, > > > This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/ > minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/ > 0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch > > Is a total mess. > It seems you've lost some code and related history during porting the > original patch. > > Sincerely, > Andrii Anisov. > > On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov > wrote: > >> Dear Iurii, >> >> This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/m >> inimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002- >> arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch >> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the >> arch_fixup_fdt() function, which, as per you idea, is not needed to be >> built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so >> the code works. >> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right >> to drop whole the function. >> >> But the problem in that piece of code still exists: >> >>- u-boot updates the first memory node in the dtb with all memory >>banks it found in the board code, does not take into consideration other >>memory nodes >>- as a result memory banks in device tree are duplicated >>- unlike the kernel which tolerates that mess from u-boot, XEN does >>not accept memory banks are duplicated and crashes. >> >> Putting all memory banks into one memory node in the device tree is the >> simplest workaround. >> I'm not really sure where should be a proper fix. Should it be on u-boot >> or XEN side? >> >> Sincerely, >> Andrii Anisov. >> >> > -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Hello guys, I have created wiki page for Salvator-X board: https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X And update related yocto layer: https://github.com/qbeeukraine/meta-platform-xen Please review & leave your comments. I am planning to update this layer with Xen 4.8 support in nearly future. With the best regards, Iurii Mykhalskyi On Thu, Nov 10, 2016 at 11:34 AM, Dirk Behme wrote: > On 10.11.2016 10:25, Iurii Mykhalskyi wrote: > >> Hello Dirk, >> >> On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme > <mailto:dirk.be...@de.bosch.com>> wrote: >> >> On 09.11.2016 13:14, Julien Grall wrote: >> >> Hello, >> >> On 09/11/16 07:14, Dirk Behme wrote: >> >> On 08.11.2016 16:41, Iurii Mykhalskyi wrote: >> >> Hello Dirk, >> >> I have made only single change - I recompile ATF to >> leave CPU in EL2 >> mode and reflash it. >> >> >> >> Yes, this is what I meant with 'modifying firmware' ;) >> >> You are loading Xen with U-Boot running in EL2, then? >> >> With this modification, do all other use cases still work? >> E.g. load and >> boot U-Boot and native Linux kernel without Xen? >> >> >> Yes, when Linux is booting from EL2, it will drop to EL1 (see >> el2_setup). As Andre mentioned on the previous thread, U-boot is >> running >> at EL2 on various board (e.g pine64, juno). >> >> Modifying the firmware was the right way to go as there is no >> solution >> go boot at EL2 from EL1. >> >> >> >> Yes, correct, from general point of view :) >> >> My question to Iurii is more focused to this concrete board, if >> there everything works fine, too. You know, sometimes the >> implementation on a board might have bugs while it should work well >> in theory ;) >> >> So I'm just interested if everything works fine for him switching >> ATF to exit in EL2, or if additional fixes/patches are needed for >> this board. >> >> >> Looks like all basic functions working normally - I have successfully >> load linux & rootfs without any additional patches for linux kernel. >> > > > Ok, thanks for this info :) > > > As you ok with this - I will create Salvator-X board related page on Xen >> wiki. >> But first of all, I will update yocto layer mentioned by Andrii with >> minimal setup, based on the latest Renesas & Xen releases. >> This should be helpful for easier out of box board setup. >> > > > Ack > > Best regards > > Dirk > > > -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Error regarding filesystem in Dom0 in lager board
Hi, Try to use attached files as DTS. I didn't tested, but looks like there are few missed nodes: - hypervisor - psci I'm not sure, that Linux & Xen will correctly inter-works without them. With the best regards, Iurii Mykhalskyi On Wed, Nov 16, 2016 at 7:23 PM, George John wrote: > Hi, > I just bumped in to some errors related to filesystem . The following is > the log. I am using xen 4.7.1 along with linux kernel 3.19.8 as Dom0 > > Starting kernel ... > > - UART enabled - > - CPU booting - > - Xen starting in Hyp mode - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 4000 - 7fff > (XEN) RAM: 00014000 - 0001 > (XEN) > (XEN) MODULE[0]: 40ef2000 - 40efe000 Device Tree > (XEN) MODULE[1]: 7200 - 722a0660 Kernel > (XEN) MODULE[2]: 7400 - 7400284f XSM > (XEN) RESVD[0]: 7ff9a000 - 7ff9a120 > (XEN) RESVD[1]: 40ef2000 - 40efe000 > (XEN) > (XEN) Command line: console=dtuart dom0_mem=1G > (XEN) Placing Xen at 0x7fc0-0x7fe0 > (XEN) Update BOOTMOD_XEN from 9000-90105781 => > 7fc0-7fd05781 > (XEN) Xen heap: 0001f800-0002 (32768 pages) > (XEN) Dom heap: 1015808 pages > (XEN) Domain heap initialised > (XEN) Platform: Renesas R-Car Gen2 > (XEN) Taking dtuart configuration from /chosen/stdout-path > (XEN) Looking for dtuart at "serial0", options "38400n8" > (XEN) WARNING: UART configuration is not supported > Xen 4.7.1 > (XEN) Xen version 4.7.1 (tel...@tvm.telxsi.com) (arm-linux-gnueabihf-gcc > (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4) debug=y Mon Nov 7 11:44:45 > IST 2016 > (XEN) Latest ChangeSet: > (XEN) Processor: 413fc0f2: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x2 > (XEN) 32-bit Execution: > (XEN) Processor Features: 1131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 02010555 > (XEN) Auxiliary Features: > (XEN) Memory Model Features: 10201105 4000 0124 02102211 > (XEN) ISA Features: 02101110 13112111 21232041 2131 10011142 > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1 KHz > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000 > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=f1001000 > (XEN) gic_cpu_addr=f1002000 > (XEN) gic_hyp_addr=f1004000 > (XEN) gic_vcpu_addr=f1006000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 416 lines, 8 cpus, secure (IID 0200043b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Allocated console ring of 64 KiB. > (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 > (XEN) Bringing up CPU1 > - CPU 0001 booting - > - Xen starting in Hyp mode - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 1 booted. > (XEN) Bringing up CPU2 > - CPU 0002 booting - > - Xen starting in Hyp mode - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 2 booted. > (XEN) Bringing up CPU3 > - CPU 0003 booting - > - Xen starting in Hyp mode - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 3 booted. > (XEN) Bringing up CPU4 > (XEN) CPU4 never came online > (XEN) Failed to bring up CPU 4 (error -5) > (XEN) Bringing up CPU5 > (XEN) CPU5 never came online > (XEN) Failed to bring up CPU 5 (error -5) > (XEN) Bringing up CPU6 > (XEN) CPU6 never came online > (XEN) Failed to bring up CPU 6 (error -5) > (XEN) Bringing up CPU7 > (XEN) CPU7 never came online > (XEN) Failed to bring up CPU 7 (error -5) > (XEN) Brought up 4 CPUs > (XEN) P2M: 40-bit IPA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 > (XEN) I/O virtualisation disabled > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 7200 > (XEN) Allocating 1:1 mappings totalling 1024MB for dom0: > (XEN) BANK[0] 0x004800-0x007000 (640MB) > (XEN) BANK[1] 0x01d800-0x01f000 (384MB) > (XEN) Grant table range: 0x007fc0-0x007fc64000 > (XEN) Loading zImage from 7200 to 4fc0- > 4fe79fb8 > (XEN) Allocating PPI 16 for event channel interrupt > (XEN) Loading dom0 DTB to 0x5000-0x5000ab70 > (XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs > (XEN) ...
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Hello Dirk, On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme wrote: > On 09.11.2016 13:14, Julien Grall wrote: > >> Hello, >> >> On 09/11/16 07:14, Dirk Behme wrote: >> >>> On 08.11.2016 16:41, Iurii Mykhalskyi wrote: >>> >>>> Hello Dirk, >>>> >>>> I have made only single change - I recompile ATF to leave CPU in EL2 >>>> mode and reflash it. >>>> >>> >>> >>> Yes, this is what I meant with 'modifying firmware' ;) >>> >>> You are loading Xen with U-Boot running in EL2, then? >>> >>> With this modification, do all other use cases still work? E.g. load and >>> boot U-Boot and native Linux kernel without Xen? >>> >> >> Yes, when Linux is booting from EL2, it will drop to EL1 (see >> el2_setup). As Andre mentioned on the previous thread, U-boot is running >> at EL2 on various board (e.g pine64, juno). >> >> Modifying the firmware was the right way to go as there is no solution >> go boot at EL2 from EL1. >> > > > Yes, correct, from general point of view :) > > My question to Iurii is more focused to this concrete board, if there > everything works fine, too. You know, sometimes the implementation on a > board might have bugs while it should work well in theory ;) > > So I'm just interested if everything works fine for him switching ATF to > exit in EL2, or if additional fixes/patches are needed for this board. Looks like all basic functions working normally - I have successfully load linux & rootfs without any additional patches for linux kernel. > Best regards > > Dirk > As you ok with this - I will create Salvator-X board related page on Xen wiki. But first of all, I will update yocto layer mentioned by Andrii with minimal setup, based on the latest Renesas & Xen releases. This should be helpful for easier out of box board setup. Thank you. With the best regards, Iurii Mykhalskyi -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen ARM community call
Hello Julien, I and Iurii Konovalenko are interesting in attending. We are in GMT+2 timezone. With the best regards, Iurii Mykhalskyi On Tue, Nov 8, 2016 at 6:17 PM, Stewart Hildebrand < stewart.hildebr...@dornerworks.com> wrote: > Hello Julien, > > Yes, myself and a couple of others from DornerWorks are interested in > attending. We are in EST (GMT-5). > > Stewart Hildebrand > Embedded Software Engineer > DornerWorks, Ltd > stewart.hildebr...@dornerworks.com > > > -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: Tuesday, November 8, 2016 7:20 AM > To: xen-devel@lists.xen.org > Cc: Stefano Stabellini ; Edgar Iglesias ( > edgar.igles...@xilinx.com) ; > alistair.fran...@xilinx.com; Shanker Donthineni ; > Goel, Sameer ; Stewart Hildebrand < > stewart.hildebr...@dornerworks.com>; Steve Capper ; > andrii.ani...@gmail.com; Lars Kurth > Subject: Xen ARM community call > > Hi all, > > I would like to start organizing a recurring community call to discuss and > sync-up on upcoming features for Xen ARM. > > Example of features that could be discussed: > - Sharing co-processor between guests > - PCI passthrough > > I would suggest to start with a 1 hour meeting on the Wednesday 23rd > November. I know that people are spread across different timezones, so I > would like to gather thought before choosing a time. > > Your sincerely, > > -- > Julien Grall > _______ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel > -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
Hello Dirk, I have made only single change - I recompile ATF to leave CPU in EL2 mode and reflash it. Looks like this way are the mostly "correct" approach for this board. All changes are made in publicly available sources, based on official Renesas H3 yocto layer - https://github.com/renesas-rcar/meta-renesas If you don't mind - I can create & handle documentation page about board setup and take ownership about further board support. With the best regards, Iurii Mykhalskyi On Tue, Nov 8, 2016 at 5:22 PM, Dirk Behme wrote: > On 08.11.2016 15:30, Julien Grall wrote: > >> Hello Iurii, >> >> Dirk (in CC) sent a similar patch few months ago to add support for >> this board (see [1]). >> >> I didn't ack the patch back then because I wanted to see documentation >> on the wiki to bring up Xen on this board (see [2] for the >> requirements). I didn't see any follow-up since then for this board. >> >> Can one of you write a documentation for this board >> > > > Yes, that would be nice. > > As mentioned, I couldn't find an 'easy' way to load Xen without modifying > the firmware (U-Boot or ATF) or using a JTAG debugger. Therefore I > hesitated to write that documentation. > > Maybe Iurii found an easier, more user compatible way? > > Best regards > > Dirk > > > > and take > >> "ownership" on this board? >> >> Regards, >> >> [1] >> https://lists.xenproject.org/archives/html/xen-devel/2016-07 >> /msg00315.html >> >> [2] >> https://lists.xenproject.org/archives/html/xen-devel/2016-07 >> /msg00130.html >> >> >> On 08/11/2016 14:20, Iurii Mykhalskyi wrote: >> >>> From: Iurii Konovalenko >>> >>> Add support for the "Salvator-X" development board based on R-Car H3 >>> SoC >>> which has SCIF compatible UART. >>> >>> Signed-off-by: Iurii Konovalenko >>> Signed-off-by: Iurii Mykhalskyi >>> --- >>> xen/arch/arm/Rules.mk | 1 + >>> xen/arch/arm/arm64/debug-scif.inc | 51 >>> +++ >>> 2 files changed, 52 insertions(+) >>> create mode 100644 xen/arch/arm/arm64/debug-scif.inc >>> >>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk >>> index 569a0ba..7989634 100644 >>> --- a/xen/arch/arm/Rules.mk >>> +++ b/xen/arch/arm/Rules.mk >>> @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel := >>> pl011,0x1c09,115200 >>> EARLY_PRINTK_exynos5250 := exynos4210,0x12c2 >>> EARLY_PRINTK_juno := pl011,0x7ff8 >>> EARLY_PRINTK_lager := scif,0xe6e6 >>> +EARLY_PRINTK_salvator := scif,0xe6e88000 >>> EARLY_PRINTK_midway := pl011,0xfff36000 >>> EARLY_PRINTK_omap5432 := 8250,0x4802,2 >>> EARLY_PRINTK_seattle:= pl011,0xe101 >>> diff --git a/xen/arch/arm/arm64/debug-scif.inc >>> b/xen/arch/arm/arm64/debug-scif.inc >>> new file mode 100644 >>> index 000..1f4d657 >>> --- /dev/null >>> +++ b/xen/arch/arm/arm64/debug-scif.inc >>> @@ -0,0 +1,51 @@ >>> +/* >>> + * xen/arch/arm/arm64/debug-scif.inc >>> + * >>> + * SCIF specific debug code >>> + * >>> + * Oleksandr Tyshchenko >>> + * Iurii Konovalenko >>> + * Iurii Mykhalskyi >>> + * Copyright (C) 2014-2016, Globallogic. >>> + * >>> + * This program is free software; you can redistribute it and/or >>> modify >>> + * it under the terms of the GNU General Public License as >>> published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +#include >>> + >>> +/* SCIF UART wait UART to be ready to transmit >>> + * rb: register which contains the UART base address >>> + * rc: scratch register >>> + */ >>> +.macro early_uart_ready xb c >>> +1: >>> +ldrh w\c, [\xb, #SCIF_SCFSR] /* <- SCFSR (status >>> register) */ >>> + tst w\c, #SCFSR_TDFE /* Check TDFE bit */ >>> +beq1b
[Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board
From: Iurii Konovalenko Add support for the "Salvator-X" development board based on R-Car H3 SoC which has SCIF compatible UART. Signed-off-by: Iurii Konovalenko Signed-off-by: Iurii Mykhalskyi --- xen/arch/arm/Rules.mk | 1 + xen/arch/arm/arm64/debug-scif.inc | 51 +++ 2 files changed, 52 insertions(+) create mode 100644 xen/arch/arm/arm64/debug-scif.inc diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 569a0ba..7989634 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel := pl011,0x1c09,115200 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2 EARLY_PRINTK_juno := pl011,0x7ff8 EARLY_PRINTK_lager := scif,0xe6e6 +EARLY_PRINTK_salvator := scif,0xe6e88000 EARLY_PRINTK_midway := pl011,0xfff36000 EARLY_PRINTK_omap5432 := 8250,0x4802,2 EARLY_PRINTK_seattle:= pl011,0xe101 diff --git a/xen/arch/arm/arm64/debug-scif.inc b/xen/arch/arm/arm64/debug-scif.inc new file mode 100644 index 000..1f4d657 --- /dev/null +++ b/xen/arch/arm/arm64/debug-scif.inc @@ -0,0 +1,51 @@ +/* + * xen/arch/arm/arm64/debug-scif.inc + * + * SCIF specific debug code + * + * Oleksandr Tyshchenko + * Iurii Konovalenko + * Iurii Mykhalskyi + * Copyright (C) 2014-2016, Globallogic. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +/* SCIF UART wait UART to be ready to transmit + * rb: register which contains the UART base address + * rc: scratch register + */ +.macro early_uart_ready xb c +1: +ldrh w\c, [\xb, #SCIF_SCFSR] /* <- SCFSR (status register) */ +tstw\c, #SCFSR_TDFE /* Check TDFE bit */ +beq1b/* Wait for the UART to be ready */ +.endm + +/* SCIF UART transmit character + * rb: register which contains the UART base address + * rt: register which contains the character to transmit + */ +.macro early_uart_transmit xb wt +strb \wt, [\xb, #SCIF_SCFTDR] /* -> SCFTDR (data register) */ +ldrh \wt, [\xb, #SCIF_SCFSR] /* <- SCFSR (status register) */ +and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE)) /* Clear TEND and TDFE bits */ +strh \wt, [\xb, #SCIF_SCFSR] /* -> SCFSR (status register) */ +.endm + +/* + * Local variables: + * mode: ASM + * indent-tabs-mode: nil + * End: + */ -- 2.10.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 5/6] libxl: implementation of PV DRM device interface
From: Pavlo Suikov
Signed-off-by: Pavlo Suikov
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 290 +++
tools/libxl/libxl.h | 18 +++
tools/libxl/libxl_create.c | 42 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 21 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 164 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 567 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b64815e..ccb0411 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,284 @@ exit:
/**/
+int libxl__device_vdrm_setdefault(libxl__gc *gc, libxl_device_vdrm *vdrm)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vdrm->backend_domname, &vdrm->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vdrm(libxl__gc *gc, uint32_t domid,
libxl_device_vdrm *vdrm, libxl__device *device)
+{
+ device->backend_devid = vdrm->devid;
+ device->backend_domid = vdrm->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VDRM;
+ device->devid = vdrm->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VDRM;
+
+ return 0;
+}
+
+static int libxl__device_vdrm_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vdrm *vdrm)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vdrm_init(vdrm);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vdrm->devid = atoi(tmp);
+else
+vdrm->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vdrm(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vdrm *vdrm)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vdrm_init(vdrm);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vdrm/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vdrm_from_xs_be(gc, path, vdrm);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vdrm_add(libxl__egc *egc, uint32_t domid, libxl_device_vdrm
*vdrm, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vdrm vdrm_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vdrm_init(&vdrm_saved);
+libxl_device_vdrm_copy(CTX, &vdrm_saved, vdrm);
+
+rc = libxl__device_vdrm_setdefault(gc, vdrm);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vdrm->devid = libxl__device_nextid(gc, domid, "vdrm")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vdrm(gc, domid, vdrm, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vdrm->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+flexarray_append(back, "mode0");
+flexarray_append(back, vdrm->mode0);
+flexarray_append(back, "mode1");
+flexarray_append(back, vdrm->mode1);
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+flexarray_append(front, "mode0");
+flexarray_append(front, vdrm->mode0);
+flexarray_append(fr
[Xen-devel] [PATCH RFC 0/6] Set of PV drivers used by production project
This patches introduce set of pv drivers interfaces. Drivers interfaces list: - PV RTC - real-time clock - PV TTY - interface for pv version for device controlled by via tty (e.g. GPS) - PV Audio - sound interface virtualization - PV DRM - direct rengering manager virtualization - PV RPMSG - remove procedure call interface, in our case used for playback codecs virtualization Iurii Mykhalskyi (2): libxl: implementation of PV rtc device interface libxl: implementation of PV tty device interface. Pavlo Suikov (4): libxl: implementation of PV audio device interface libxl: implementation of PV event device interface libxl: implementation of PV DRM device interface libxl: implementation of PV RPMSG device interface tools/libxl/libxl.c | 1781 +- tools/libxl/libxl.h | 102 ++ tools/libxl/libxl_create.c | 214 +++- tools/libxl/libxl_device.c | 12 + tools/libxl/libxl_internal.c |8 + tools/libxl/libxl_internal.h | 88 +- tools/libxl/libxl_types.idl | 131 +++ tools/libxl/libxl_types_internal.idl |6 + tools/libxl/libxl_utils.h| 19 + tools/libxl/xl.h | 18 + tools/libxl/xl_cmdimpl.c | 1035 +++- tools/libxl/xl_cmdtable.c| 95 ++ 12 files changed, 3499 insertions(+), 10 deletions(-) -- 2.8.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 1/6] libxl: implementation of PV rtc device interface
PV rtc device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 287 ++-
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 39 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 19 ++-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 161 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 558 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ac50bda..09c4bc7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2323,6 +2323,277 @@ int libxl_devid_to_device_vtpm(libxl_ctx *ctx,
return rc;
}
+/**/
+
+int libxl__device_vrtc_setdefault(libxl__gc *gc, libxl_device_vrtc *vrtc)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrtc->backend_domname, &vrtc->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrtc(libxl__gc *gc, uint32_t domid,
libxl_device_vrtc *vrtc, libxl__device *device)
+{
+ device->backend_devid = vrtc->devid;
+ device->backend_domid = vrtc->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VRTC;
+ device->devid = vrtc->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VRTC;
+
+ return 0;
+}
+
+static int libxl__device_vrtc_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrtc *vrtc)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrtc_init(vrtc);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrtc->devid = atoi(tmp);
+else
+vrtc->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrtc(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vrtc *vrtc)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrtc_init(vrtc);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vrtc/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrtc_from_xs_be(gc, path, vrtc);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrtc_add(libxl__egc *egc, uint32_t domid, libxl_device_vrtc
*vrtc, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrtc vrtc_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vrtc_init(&vrtc_saved);
+libxl_device_vrtc_copy(CTX, &vrtc_saved, vrtc);
+
+rc = libxl__device_vrtc_setdefault(gc, vrtc);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrtc->devid = libxl__device_nextid(gc, domid, "vrtc")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrtc(gc, domid, vrtc, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrtc->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+
[Xen-devel] [PATCH RFC 6/6] libxl: implementation of PV RPMSG device interface
From: Pavlo Suikov
Signed-off-by: Pavlo Suikov
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 282 +++
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 40 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 161 +++-
tools/libxl/xl_cmdtable.c| 21 ++-
11 files changed, 554 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ccb0411..871061d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2873,6 +2873,276 @@ exit:
/**/
+int libxl__device_vrpmsg_setdefault(libxl__gc *gc, libxl_device_vrpmsg *vrpmsg)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrpmsg->backend_domname,
&vrpmsg->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrpmsg(libxl__gc *gc, uint32_t domid,
libxl_device_vrpmsg *vrpmsg, libxl__device *device)
+{
+ device->backend_devid = vrpmsg->devid;
+ device->backend_domid = vrpmsg->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VRPMSG;
+ device->devid = vrpmsg->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VRPMSG;
+
+ return 0;
+}
+
+static int libxl__device_vrpmsg_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrpmsg *vrpmsg)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrpmsg_init(vrpmsg);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrpmsg->devid = atoi(tmp);
+else
+vrpmsg->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrpmsg(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vrpmsg *vrpmsg)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrpmsg_init(vrpmsg);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vrpmsg/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrpmsg_from_xs_be(gc, path, vrpmsg);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrpmsg_add(libxl__egc *egc, uint32_t domid,
libxl_device_vrpmsg *vrpmsg, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrpmsg vrpmsg_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vrpmsg_init(&vrpmsg_saved);
+libxl_device_vrpmsg_copy(CTX, &vrpmsg_saved, vrpmsg);
+
+rc = libxl__device_vrpmsg_setdefault(gc, vrpmsg);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrpmsg->devid = libxl__device_nextid(gc, domid, "vrpmsg")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrpmsg(gc, domid, vrpmsg, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrpmsg->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domi
[Xen-devel] [PATCH RFC 4/6] libxl: implementation of PV event device interface
From: Pavlo Suikov
Touchscreen events device configuration support. Can be further
extended to support any event device whatsoever.
Signed-off-by: Pavlo Suikov
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 289 ++-
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 39 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.c | 4 +
tools/libxl/libxl_internal.h | 20 ++-
tools/libxl/libxl_types.idl | 21 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 4 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 170 -
tools/libxl/xl_cmdtable.c| 15 ++
12 files changed, 580 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1426bf6..b64815e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5003,6 +5003,282 @@ out:
/**/
+int libxl__device_vevent_setdefault(libxl__gc *gc, libxl_device_vevent *vevent)
+{
+int rc;
+rc = libxl__resolve_domid(gc, vevent->backend_domname,
&vevent->backend_domid);
+return rc;
+}
+
+static int libxl__device_from_vevent(libxl__gc *gc, uint32_t domid,
+ libxl_device_vevent *vevent,
+ libxl__device *device)
+{
+device->backend_devid = vevent->devid;
+device->backend_domid = vevent->backend_domid;
+device->backend_kind = LIBXL__DEVICE_KIND_VEVENT;
+device->devid = vevent->devid;
+device->domid = domid;
+device->kind = LIBXL__DEVICE_KIND_VEVENT;
+
+return 0;
+}
+
+static int libxl__device_vevent_from_xs_be(libxl__gc *gc,
+ const char *be_path,
+ libxl_device_vevent *vevent)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vevent_init(vevent);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vevent->devid = atoi(tmp);
+else
+vevent->devid = 0;
+
+rc = 0;
+out:
+return rc;
+}
+
+int libxl_devid_to_device_vevent(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vevent *vevent)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vevent_init(vevent);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vevent/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vevent_from_xs_be(gc, path, vevent);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vevent_add(libxl__egc *egc, uint32_t domid,
+ libxl_device_vevent *vevent,
+ libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vevent vevent_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vevent_init(&vevent_saved);
+libxl_device_vevent_copy(CTX, &vevent_saved, vevent);
+
+rc = libxl__device_vevent_setdefault(gc, vevent);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 16, 1);
+if (vevent->devid == -1) {
+if ((vevent->devid = libxl__device_nextid(gc, domid, "vevent")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vevent(gc, &vevent_saved, vevent);
+
+GCNEW(device);
+rc = libxl__device_from_vevent(gc, domid, vevent, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "feature-abs-pointer");
+flexarray_append(back, libxl__sprintf(gc, "%d",
vevent->feature_abs_pointer));
+flexarray_append(back, "abs-width");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_width));
+flexarray_append(back, "abs-height");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_height));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, libxl__sprintf(gc, &q
[Xen-devel] [PATCH RFC 2/6] libxl: implementation of PV audio device interface
From: Pavlo Suikov
PV Audio device interface is implemented in libxl and xl with
full support for device control
Signed-off-by: Pavlo Suikov
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 351 ++-
tools/libxl/libxl.h | 16 ++
tools/libxl/libxl_create.c | 39 +++-
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.c | 4 +
tools/libxl/libxl_internal.h | 20 +-
tools/libxl/libxl_types.idl | 32
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 229 ++-
tools/libxl/xl_cmdtable.c| 20 ++
12 files changed, 715 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 09c4bc7..d96172d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2593,7 +2593,344 @@ exit:
return rc;
}
+/**/
+
+int libxl__device_vsnd_setdefault(libxl__gc *gc, libxl_device_vsnd *vsnd)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vsnd->backend_domname, &vsnd->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vsnd(libxl__gc *gc, uint32_t domid,
libxl_device_vsnd *vsnd, libxl__device *device)
+{
+ device->backend_devid = vsnd->devid;
+ device->backend_domid = vsnd->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VSND;
+ device->devid = vsnd->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VSND;
+
+ return 0;
+}
+
+static int libxl__device_vsnd_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vsnd *vsnd)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vsnd_init(vsnd);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vsnd->devid = atoi(tmp);
+else
+vsnd->devid = 0;
+
+vsnd->short_name = READ_BACKEND(gc, "short-name");
+vsnd->long_name = READ_BACKEND(gc, "long-name");
+vsnd->sample_formats = READ_BACKEND(gc, "sample-formats");
+vsnd->rates = READ_BACKEND(gc, "rates");
+
+tmp = READ_BACKEND(gc, "channels-min");
+if (tmp)
+vsnd->channels_min = atoi(tmp);
+else
+vsnd->channels_min = 0;
+
+tmp = READ_BACKEND(gc, "channels-max");
+if (tmp)
+vsnd->channels_max = atoi(tmp);
+else
+vsnd->channels_max = 0;
+
+tmp = READ_BACKEND(gc, "priority");
+if (tmp)
+vsnd->priority = atoi(tmp);
+else
+vsnd->priority = 0;
+
+vsnd->slave_device = READ_BACKEND(gc, "slave-device");
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vsnd(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vsnd *vsnd)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vsnd_init(vsnd);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vsnd/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vsnd_from_xs_be(gc, path, vsnd);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+
+void libxl__device_vsnd_add(libxl__egc *egc, uint32_t domid, libxl_device_vsnd
*vsnd, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vsnd vsnd_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vsnd_init(&vsnd_saved);
+libxl_device_vsnd_copy(CTX, &vsnd_saved, vsnd);
+
+rc = libxl__device_vsnd_setdefault(gc, vsnd);
+if (rc) goto out;
+
+front = flexarray_make(gc, 32, 1);
+back = flexarray_make(gc, 32, 1);
+if (vsnd->devid == -1) {
+if ((vsnd->devid = libxl__device_nextid(gc, domid, "vsnd")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vsnd(gc, &vsnd_saved, vsnd);
+
+GCNEW(device);
+rc = libxl__device_from_vsnd(gc, domid, vsnd, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "DomD");
+flexarray_append(back, "1");
+flexarray_append(back, "DomU");
+flexarray_append(back, "2");
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vsnd->devid));
+flexarray_append(back, "short-name");
+flexarray_append(back, vsnd->short_name);
+flexarray_append(back, "long
[Xen-devel] [PATCH RFC 3/6] libxl: implementation of PV tty device interface.
PV tty device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 282 +++
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 37 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 160 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 549 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d96172d..1426bf6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,276 @@ exit:
/**/
+int libxl__device_vtty_setdefault(libxl__gc *gc, libxl_device_vtty *vtty)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vtty->backend_domname, &vtty->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vtty(libxl__gc *gc, uint32_t domid,
libxl_device_vtty *vtty, libxl__device *device)
+{
+ device->backend_devid = vtty->devid;
+ device->backend_domid = vtty->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VTTY;
+ device->devid = vtty->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VTTY;
+
+ return 0;
+}
+
+static int libxl__device_vtty_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vtty *vtty)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vtty_init(vtty);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+ vtty->devid = atoi(tmp);
+else
+ vtty->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vtty(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vtty *vtty)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vtty_init(vtty);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vtty/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vtty_from_xs_be(gc, path, vtty);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vtty_add(libxl__egc *egc, uint32_t domid, libxl_device_vtty
*vtty, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vtty vtty_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vtty_init(&vtty_saved);
+libxl_device_vtty_copy(CTX, &vtty_saved, vtty);
+
+rc = libxl__device_vtty_setdefault(gc, vtty);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vtty->devid = libxl__device_nextid(gc, domid, "vtty")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vtty(gc, domid, vtty, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vtty->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vtty->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(g
Re: [Xen-devel] Hotplugged devices in Xen 4.5 and domain reboot
Thanks to all for a replays, please see my answers below: On 12/01/2015 05:29 PM, Wei Liu wrote: On Tue, Dec 01, 2015 at 04:58:55PM +0200, Iurii Mykhalskyi wrote: Our real usb mass-storage device are located at driver domain (DomD). So we setup second block-device backend there. To hotplug usb mass-storage from DomD we use follow command: xl block-attach domU_id phy:/bla-bla,xvda10,w,backend="DomD" What happens if you run this in Dom0? I guess DomD doesn't respond to the request? Yes, there is no responded from domD, because actual storage device are located there, and toolstack stuck on real device existence check. There was no support of attaching block-device in runtime from domain other to Domain-0, so we have made some hacks to allow call block-attach command from non-dom0 privileged domain. So this is a special use case. This is the first time I know people actually run xl block-attach in driver domain. Yes, this is special case and we this by our solution design. One of patches was - don't update /var/lib/xen/userdata-d.$DOMID-$UUID.libxl-json during execution of this command (because this log located on dom0 rootfs and we don't have any access to it from DomD). So, there is no different in configs before and after hotplug. The state of $DOMID is recorded in libxl-json file. No wonder you lose all state. But even if you write those states, they are going to be inside driver domain. There is no way at the moment to synthesise the state inside Dom0 and DomD into one. There is also difficulty in how you can split the synthesised and dispatch the states to multiple entities again when rebuilding a domain. So I think having multiple entities managing state of one single domain is bad. I think the proper way of making it work is to make hotplug device from domain other than Dom0 work. There is a daemon "xl devd" in driver domain. We might be able to teach it to response to Dom0 toostack request. I'm a bit surprised if it doesn't do that already. Did you forget to start that daemon? We can't run devd in driver domain, because it failed on connect to xenstored socket (/var/run/xenstored/socket - we have xenstored running only in dom0). Roger, Ian and Ian, any thought? Wei. On 12/01/2015 05:41 PM, Ian Campbell wrote: On Tue, 2015-12-01 at 15:29 +, Wei Liu wrote: On Tue, Dec 01, 2015 at 04:58:55PM +0200, Iurii Mykhalskyi wrote: Our real usb mass-storage device are located at driver domain (DomD). So we setup second block-device backend there. To hotplug usb mass-storage from DomD we use follow command: xl block-attach domU_id phy:/bla-bla,xvda10,w,backend="DomD" What happens if you run this in Dom0? I guess DomD doesn't respond to the request? There was no support of attaching block-device in runtime from domain other to Domain-0, so we have made some hacks to allow call block-attach command from non-dom0 privileged domain. So this is a special use case. This is the first time I know people actually run xl block-attach in driver domain. Toolstack commands (xl *) should be run in the toolstack domain, not in the driver domain. I don't think it should be expected that the latter work (at least not without a large amount of development work). In general a driver domain would not be expected to have sufficient privilege over e.g. a guest domain's /local/domain/domU/devices to create the f.e. dirs. In our solution we have to create 2 full privileged domains - Dom0 and DomD, so we need 2 toolstack domains. Any special privileges hack wasn't done - we need just to setup additional permissions for DomD. There is a daemon "xl devd" in driver domain. We might be able to teach it to response to Dom0 toostack request. I'm a bit surprised if it doesn't do that already. Did you forget to start that daemon? That's the entire purpose of that daemon, isn't it? I can't find any valuable documentation or examples of use for this daemon. Can you point me please to any documentation about it, please? Thank you. Roger, Ian and Ian, any thought? Wei. On 12/01/2015 05:56 PM, Roger Pau Monné wrote: Hello, El 01/12/15 a les 15.58, Iurii Mykhalskyi ha escrit: Our real usb mass-storage device are located at driver domain (DomD). So we setup second block-device backend there. To hotplug usb mass-storage from DomD we use follow command: xl block-attach domU_id phy:/bla-bla,xvda10,w,backend="DomD" This is not possible by design, you should only be able to execute `xl block-attach ...` from the control domain (Dom0). This is due to the fact that attaching a new device to a guest requires write permissions in the guest xenstore paths, which the driver domain should not have. As I mention earlier, we need this case by design of our solution. And DomD in our most of same privilegies as Dom0, so access to xenstore isn't point of the proble
Re: [Xen-devel] Hotplugged devices in Xen 4.5 and domain reboot
Our real usb mass-storage device are located at driver domain (DomD). So we setup second block-device backend there. To hotplug usb mass-storage from DomD we use follow command: xl block-attach domU_id phy:/bla-bla,xvda10,w,backend="DomD" There was no support of attaching block-device in runtime from domain other to Domain-0, so we have made some hacks to allow call block-attach command from non-dom0 privileged domain. One of patches was - don't update /var/lib/xen/userdata-d.$DOMID-$UUID.libxl-json during execution of this command (because this log located on dom0 rootfs and we don't have any access to it from DomD). So, there is no different in configs before and after hotplug. Did xen hot-plug mechanism relay on those config? On Tue, Dec 1, 2015 at 4:02 PM, Wei Liu wrote: > On Tue, Dec 01, 2015 at 03:24:13PM +0200, Pavlo Suikov wrote: > > Hi, > > > > got a question regarding hotplugged devices in Xen 4.5. What we currently > > have is Xen 4.5, Linux in Dom0 and DomD and Android in DomU. All the > > devices are configured via domain config, so they are initialized on > domain > > startup: libxl reads config, sets up xenstore branches and fills them for > > driver back ends and front ends; front ends monitor these branches and > fill > > in their specific data once connection is established. On DomU reboot, > > config is being re-read and all the devices are started again in the same > > manner. > > > > Problem is we don't really know what to do with hotplugged devices. When > > such a device appears in DomU during runtime, we set up all the xenstore > > insformation on the fly, but it doesn't go to persistent domain > > configuration; so when DomU reboot comes, they are not set up again as > they > > should. All the solutions we are considering look like dirty hacks (e.g. > > making separate branch in xenstore for hotplugged devices, reading it on > > domain start in the same way domain config is parsed, and copying data to > > corresponding xenstore domain branches). Are there any existing ways to > > handle these? > > > > Do you have the exact runes you use to do the hotplug? How do you reboot > your DomU? What does /var/lib/xen/userdata-d.$DOMID-$UUID.libxl-json > look like before and after hotplug? > > Wei. > > > Suikov Pavlo > > GlobalLogic > > P +x.xxx.xxx. M +38.066.667.1296 S psujkov > > www.globallogic.com > > <http://www.globallogic.com/> > > http://www.globallogic.com/email_disclaimer.txt > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > -- Iurii Mykhalskyi | Senior Software Engineer GlobalLogic P +38.044.492.9695x3664 M +38.096.311.5467 S mad-nemoi www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
