Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

2018-02-01 Thread Saumya Rajesh 
On Wed, Jan 31, 2018 at 8:36 PM, Andrii Anisov <andrii_ani...@epam.com> wrote:
> Hello Saumya,
>
>
> On 18.01.18 09:50, Saumya Rajesh wrote:
>>
>> Actually I am planning to set up Android as guest in Xen.
>
> I see.
>
>> In order to enable sound in the Android guest, I need to passthrough the
>> audio codec device which communicates through the I2C bus. For BE/FE scheme,
>> I think sharing the internal DMA and clock would pose problems. So I'm going
>> to go ahead with the device passthrough way.
>
> Passing through I2C bus to guest domain would not be enough to get sound in
> Android. You would face more dependencies, and they may appear not solvable.
>
>> Any thoughts or inputs you can possibly give regarding this use case will
>> be very helpful and valuable.
>
> We are using PV Audio solution for such a task:
>
> https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg02428.html
> https://lkml.org/lkml/2017/8/7/115
>
> --
>
> *Andrii Anisov*
>
>

Hi Andrii

I guess you are right. I am already facing issues in doing I2C bus
passthrough. If you find time, please look into [1][2].

I was able to successfully build and execute the PV Audio solution on
R-Car H3, with xen-front[3] as frontend and snd_be[4] as backend. The
only issue I encountered was that Dom0 could not use the sound card as
long as the backend application ran. It is the only working solution
that I have found till now.

I think I am back to square one but I can't help but ask if you are
familiar with any work which is going on in Xen which makes it
possible for the guest domain(Linux based) to interact with all kinds
of I2C devices such as audio SoCs or sensors?

Regards
Saumya

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02711.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02618.html
[3] https://lists.xen.org/archives/html/xen-devel/2017-08/msg00626.html
[4] https://github.com/xen-troops/snd_be

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

[Xen-devel] Issue with booting with xen,passthrough DTB

2018-01-30 Thread Saumya Rajesh 
Hi

I am trying to passthrough the I2C bus[channel 2 group A] to DomU in
Xen. I am implementing this on R-Car H3.

I added xen,passthrough = "1" to the i2c2 node in r8a7795.dtsi and
rebuilt the dtb for Domain 0. The dtb works when I boot into Dom0, but
the kernel crashes when I try to boot again using the same dtb.
Assuming that the integrated device using i2c2 somehow gets corrupted
for the second run, I tried to passthrough the entire rcar sound
system, which is associated with i2c2. But I get the same result i.e.
Kernel boots for the first run but fails when I reboot using the same
dtb.

Following is the modification in Dom 0 dtb :

i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,i2c-r8a7795";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 929>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
dmas = < 0x95>, < 0x94>;
dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
xen,passthrough = "1";
};

***
rcar_sound: sound@ec50 {
***
power-domains = < R8A7795_PD_ALWAYS_ON>;
status = "disabled";
xen,passthrough = "1";
***
Please see the attachment for the kernel log.

Any support or suggestion regarding the cause of this issue will be
much appreciated.

I have also posted another issue regarding passthrough [1]. Please
have a look into it also.

Regards
Saumya

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02618.html

*
*   Booting using passthrough DTB for the first time
*

NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9
NOTICE:  BL2: PRR is R-Car H3 ES1.1
NOTICE:  BL2: Boot device is HyperFlash(80MHz)
NOTICE:  BL2: LCM state is CM
NOTICE:  BL2: AVS setting succeeded. DVFS_SetVID=0x52
NOTICE:  BL2: DDR2400(rev.0.15)
NOTICE:  BL2: DRAM Split is 4ch
NOTICE:  BL2: QoS is default setting(rev.0.32)
NOTICE:  BL2: v1.1(release):3ad02ac
NOTICE:  BL2: Built : 15:16:01, Feb 15 2017
NOTICE:  BL2: Normal boot
NOTICE:  BL2: dst=0xe631a208 src=0x818 len=512(0x200)
NOTICE:  BL2: dst=0x43f0 src=0x8180400 len=6144(0x1800)
NOTICE:  BL2: dst=0x4400 src=0x81c len=65536(0x1)
NOTICE:  BL2: dst=0x4410 src=0x820 len=524288(0x8)
NOTICE:  BL2: dst=0x4900 src=0x864 len=1048576(0x10)


U-Boot 2015.04 (Feb 15 2017 - 15:16:02)

CPU: Renesas Electronics R8A7795 rev 1.1
Board: Salvator-X
I2C:   ready
DRAM:  3.9 GiB
MMC:   sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2
In:serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot:  0 
819584 bytes read in 100 ms (7.8 MiB/s)
65776 bytes read in 36 ms (1.7 MiB/s)
15067648 bytes read in 1305 ms (11 MiB/s)
10319 bytes read in 24 ms (418.9 KiB/s)
## Booting kernel from Legacy Image at 4808 ...
   Image Name:   XEN
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:819520 Bytes = 800.3 KiB
   Load Address: 7808
   Entry Point:  7808
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4800
   Booting using the fdt blob at 0x4800
   Loading Kernel Image ... OK
   Using Device Tree in place at 4800, end 480130ef

Starting kernel ...

 Xen 4.8.0
(XEN) Xen version 4.8.0 (aarch64-poky-linux-gcc (Linaro GCC 5.2-2015.11-2) 
5.2.1 20151005) debug=n  Wed Feb 15 14:56:12 IST 2017
(XEN) Latest ChangeSet: Wed Jun 22 17:28:18 2016 +0300 git:3fa5d2a-dirty
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1124 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using PSCI-1.0 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) XSM Framework v1.0.0 initialized
(XEN) xsm: Policy len = 0x0001 start at 0x7c00
(XEN) Flask: 128 avtab hash slots, 280 rules.
(XEN)

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

2018-01-29 Thread Saumya Rajesh 
On Thu, Jan 18, 2018 at 1:20 PM, Saumya Rajesh <saumyarajes...@gmail.com> wrote:
> On Wed, Jan 17, 2018 at 9:06 PM, Andrii Anisov <andrii_ani...@epam.com>
> wrote:
>>
>> Rajesh,
>>
>> On 17.01.18 16:03, Saumya Rajesh wrote:
>>>
>>> Just out of curiosity, is it possible to split the Driver for the Renesas
>>> RCar I2C unit [1] into frontend and backend to use the i2c bus from guest?
>>> Or to do something similar to PCI passthrough? Please forgive me if I sound
>>> illogical. I'm just curious.
>>
>> I guess you could implement PV I2C using FE/BE scheme. With enormous
>> efforts and unpredictable results.
>> But I'm sure it is not what you really need.
>>
>> --
>>
>> *Andrii Anisov*
>>
>>
>
> Hi Andrii
>
> Actually I am planning to set up Android as guest in Xen. In order to enable
> sound in the Android guest, I need to passthrough the audio codec device
> which communicates through the I2C bus. For BE/FE scheme, I think sharing
> the internal DMA and clock would pose problems. So I'm going to go ahead
> with the device passthrough way.
>
> Any thoughts or inputs you can possibly give regarding this use case will be
> very helpful and valuable.
>
> Regards
> Saumya
>

Hi

I am trying to passthrough I2C bus to guest domain in Xen. I am
referring [1][2][3] to implement this on Renesas R-Car H3. Following
is the list of all I2C buses available when not passed through :

root@salvator-x-xen-dom0:~# i2cdetect -l
i2c-2 i2ce651.i2cI2C adapter
i2c-4 i2ce66d8000.i2cI2C adapter
i2c-7 i2ce60b.i2cI2C adapter
i2c-8 i2cDesignWare HDMI  I2C adapter
i2c-9 i2cDesignWare HDMI  I2C adapter

I added " xen,passthrough = "1"; " and built the Dom0 device tree to
enable I2C bus passthrough :

r8a7795.dtsi:

i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,i2c-r8a7795";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 929>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
dmas = < 0x95>, < 0x94>;
dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
xen,passthrough = "1";
};

After booting using the modified dtb, i2c-2 disappears, meaning it was
not taken by Dom0 :

root@salvator-x-xen-dom0:~# i2cdetect -l
i2c-4 i2ce66d8000.i2cI2C adapter
i2c-7 i2ce60b.i2cI2C adapter
i2c-8 i2cDesignWare HDMI  I2C adapter
i2c-9 i2cDesignWare HDMI  I2C adapter

I built a partial device tree guest_dtb_test.dtb using the following content :

guest_dtb_test.dts:
/dts-v1/;

/ {
/* #*cells are here to keep DTC happy */
#address-cells = <2>;
#size-cells = <2>;

aliases {
i2c0 = 
};
passthrough {
compatible = "simple-bus";
ranges;
#address-cells = <2>;
#size-cells = <2>;
i2c0: i2c@1000 {
compatible = "renesas,i2c-r8a7795";
reg = <0 0x1000 0 0x40>;
interrupts = <0 286 4>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
};
};
};

I also added the following lines to DomU configuration file :

device_tree = "/root/guest_test_dtb.dtb"
dtdev = [ "/soc/i2c@e651" ]
irqs = [ 318 ]
iomem = [ "0xe6510,1" ]

But when I start DomU, the booting fails. Log of starting DomU :

root@salvator-x-xen-dom0:~# xl create -c Domu.cfg
Parsing config from Domu.cfg
[ 2160.083551] rcar_gen3_thermal e61a8000.thermal: Can't register thermal zone
(XEN) avc:  denied  { use } for domid=0 irq=318
scontext=system_u:system_r:domU_t tcontext=system_u:object_r:irq_t
tclass=resource
libxl: error: libxl_create.c:1284:domcreate_launch_dm: failed give
dom2 access to irq 318: Permission denied
libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 2
libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy
guest with domid 2

libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 2 failed

Seeing the log, I guess the irq could not be given to DomU. It is
actually 286 + 32, as it was mentioned in [1].

Is there a workaround to this issue? Any solution or suggestion
related to this will be much appreciated.

Regards
Saumya

[1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
[2] https://events.static.linuxfound.org/sites/events/files/slides/talk_5.pdf
[3] https://lists.xenproject.org/archives/html/xen-users/2017-10/msg00031.html

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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

2018-01-17 Thread Saumya Rajesh 
On Wed, Jan 17, 2018 at 9:06 PM, Andrii Anisov <andrii_ani...@epam.com>
wrote:

> Rajesh,
>
> On 17.01.18 16:03, Saumya Rajesh wrote:
>
>> Just out of curiosity, is it possible to split the Driver for the Renesas
>> RCar I2C unit [1] into frontend and backend to use the i2c bus from guest?
>> Or to do something similar to PCI passthrough? Please forgive me if I sound
>> illogical. I'm just curious.
>>
> I guess you could implement PV I2C using FE/BE scheme. With enormous
> efforts and unpredictable results.
> But I'm sure it is not what you really need.
>
> --
>
> *Andrii Anisov*
>
>
>
​Hi Andrii

Actually I am planning to set up Android as guest in Xen. In order to
enable sound in the Android guest, I need to passthrough the audio codec
device which communicates through the I2C bus. For BE/FE scheme, I think
sharing the internal DMA and clock would pose problems. So I'm going to go
ahead with the device passthrough way.

Any thoughts or inputs you can possibly give regarding this use case will
be very helpful and valuable.

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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

2018-01-17 Thread Saumya Rajesh 
On Tue, Jan 16, 2018 at 9:22 PM, Andrii Anisov 
wrote:

> Dear Rajesh,
>
>
> You can try to get an I2C bus controller in DomU in PIO mode following
> [1], keeping in mind [2].
>
> If you want it DMA capable you need Renesas IPMMU support in XEN [3], [4]
> to be incorporated.
>
>
> [1] - https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
>
> [2] - https://lists.xenproject.org/archives/html/xen-users/2017-10
> /msg00031.html
>
> [3] - https://lists.xenproject.org/archives/html/xen-devel/2017-07
> /msg02545.html
>
> [4] - https://lists.xenproject.org/archives/html/xen-devel/2017-07
> /msg02679.html
>
>
> --
>
> *Andrii Anisov*
>
>
>
Thank you Andrii for replying. I will try the device passthrough way of
using I2C bus from guest and post the updates.

Just out of curiosity, is it possible to split the Driver for the Renesas
RCar I2C unit [1] into frontend and backend to use the i2c bus from guest?
Or to do something similar to PCI passthrough? Please forgive me if I sound
illogical. I'm just curious.

Regards
Saumya

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/i2c/busses/i2c-rcar.c?h=v4.14.13
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Access I2C bus from guest/DomU on ARM board

2018-01-16 Thread Saumya Rajesh 
Hi Xen community


I have built and brought up Xen 4.8 on Renesas RCar H3. For a specific
requirement, I need to use the I2C bus of the board from Domain U. Is there
a way to use the I2C bus from the guest?
I have looked into para-virtualization and passthrough [1][2] but there
isn't enough support or resources related to I2C bus sharing on ARM. Any
possible idea would be appreciated.

Regards
Saumya

[1]
https://lists.xenproject.org/archives/html/xen-users/2017-10/msg00019.html
[2] https://wiki.xenproject.org/wiki/File:DriverDomainonARM01.pdf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel