ivhsmem_uio driver update

[Nikhil Devshatwar]

Hi Henning,

As part of the TI SDK, we were integrating the ivhsmem_uio as external module
from https://github.com/henning-schild-work/ivshmem-guest-code

Since the ivshmem changes in the Jailhouse, that driver no more works (because of the vendor ID change)
Do you plan to host the updated version of the driver in this repo?

I know that the driver is already part of the siemens repo but it is much simpler to integrate an external module in yocto.

Thanks & Regards,
Nikhil D

[Jan Kiszka]

Actually, that new driver is a complete rewrite, not just an ID update.
It allows to securely pass access to unprivileged users and provides all
features of the new ivshmem interface. For that, it requires to patch
the kernel with [1]. But given that you have to patch your kernel anyway
for other Jailhouse details and given that this is trivial in yocto, I
don't get the point of having an external module package being easier.

Jan

[1]
http://git.kiszka.org/?p=linux.git;a=commitdiff;h=651db1cf858dd7afef7ef98c7db86223c1f73a59;hp=2c523b344dfa65a3738e7039832044aa133c75fb

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[Nikhil Devshatwar]

On 09/03/20 4:39 pm, Jan Kiszka wrote:

On 09.03.20 11:12, Nikhil Devshatwar wrote:

Hi Henning,

As part of the TI SDK, we were integrating the ivhsmem_uio as external module
from https://github.com/henning-schild-work/ivshmem-guest-code

Since the ivshmem changes in the Jailhouse, that driver no more works (because of the vendor ID change)
Do you plan to host the updated version of the driver in this repo?

I know that the driver is already part of the siemens repo but it is much simpler to integrate an external module in yocto.

Actually, that new driver is a complete rewrite, not just an ID update. It allows to securely pass access to unprivileged users and provides all features of the new ivshmem interface.

Got it

For that, it requires to patch the kernel with [1]. But given that you have to patch your kernel anyway for other Jailhouse details and given that this is trivial in yocto, I don't get the point of having an external module package being easier.

Sure, I wasn't aware of this dependency.

Regards,
Nikhil D

[Nikhil Devshatwar]

On 09/03/20 4:52 pm, 'Nikhil Devshatwar' via Jailhouse wrote:

On 09/03/20 4:39 pm, Jan Kiszka wrote:

On 09.03.20 11:12, Nikhil Devshatwar wrote:

Hi Henning,

As part of the TI SDK, we were integrating the ivhsmem_uio as external module
from https://github.com/henning-schild-work/ivshmem-guest-code

Since the ivshmem changes in the Jailhouse, that driver no more works (because of the vendor ID change)
Do you plan to host the updated version of the driver in this repo?

I know that the driver is already part of the siemens repo but it is much simpler to integrate an external module in yocto.

Actually, that new driver is a complete rewrite, not just an ID update. It allows to securely pass access to unprivileged users and provides all features of the new ivshmem interface.

With this driver, I can get the uio device registered but when I run the uio_send and uio_read apps,
I get mmap failure. Looking into more details, it seems that the new driver exposes specific input and output regions to UIO

Am I supposed to use a different app for testing the ivshmem?

Regards,
Nikhil D

Got it

For that, it requires to patch the kernel with [1]. But given that you have to patch your kernel anyway for other Jailhouse details and given that this is trivial in yocto, I don't get the point of having an external module package being easier.

Sure, I wasn't aware of this dependency.

Regards,
Nikhil D

Jan

[1] http://git.kiszka.org/?p=linux.git;a=commitdiff;h=651db1cf858dd7afef7ef98c7db86223c1f73a59;hp=2c523b344dfa65a3738e7039832044aa133c75fb

--
You received this message because you are subscribed to the Google Groups "Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/5e63fd55-8606-3046-a2cf-2ba8efc80203%40ti.com.

[Nikhil Devshatwar]

On 30/04/20 7:01 pm, 'Nikhil Devshatwar' via Jailhouse wrote:

On 09/03/20 4:52 pm, 'Nikhil Devshatwar' via Jailhouse wrote:

On 09/03/20 4:39 pm, Jan Kiszka wrote:

On 09.03.20 11:12, Nikhil Devshatwar wrote:

Hi Henning,

As part of the TI SDK, we were integrating the ivhsmem_uio as external module
from https://github.com/henning-schild-work/ivshmem-guest-code

Since the ivshmem changes in the Jailhouse, that driver no more works (because of the vendor ID change)
Do you plan to host the updated version of the driver in this repo?

I know that the driver is already part of the siemens repo but it is much simpler to integrate an external module in yocto.

Actually, that new driver is a complete rewrite, not just an ID update. It allows to securely pass access to unprivileged users and provides all features of the new ivshmem interface.

With this driver, I can get the uio device registered but when I run the uio_send and uio_read apps,

Using the uio_send and uio_read apps from https://github.com/henning-schild-work/ivshmem-guest-code/tree/master/uio/tests/Interrupts/VM

I get mmap failure. Looking into more details, it seems that the new driver exposes specific input and output regions to UIO

Am I supposed to use a different app for testing the ivshmem?

Regards,
Nikhil D

Got it

For that, it requires to patch the kernel with [1]. But given that you have to patch your kernel anyway for other Jailhouse details and given that this is trivial in yocto, I don't get the point of having an external module package being easier.

Sure, I wasn't aware of this dependency.

Regards,
Nikhil D

Jan

[1] http://git.kiszka.org/?p=linux.git;a=commitdiff;h=651db1cf858dd7afef7ef98c7db86223c1f73a59;hp=2c523b344dfa65a3738e7039832044aa133c75fb

--
You received this message because you are subscribed to the Google Groups "Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/5e63fd55-8606-3046-a2cf-2ba8efc80203%40ti.com.

--
You received this message because you are subscribed to the Google Groups "Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/92c2a027-7a70-5d0b-d12a-45c54272afd8%40ti.com.

[Jan Kiszka]

On 30.04.20 15:32, 'Nikhil Devshatwar' via Jailhouse wrote:
>
>
> On 30/04/20 7:01 pm, 'Nikhil Devshatwar' via Jailhouse wrote:
>>
>>
>> On 09/03/20 4:52 pm, 'Nikhil Devshatwar' via Jailhouse wrote:
>>>
>>>
>>> On 09/03/20 4:39 pm, Jan Kiszka wrote:
>>>> On 09.03.20 11:12, Nikhil Devshatwar wrote:
>>>>> Hi Henning,
>>>>>
>>>>> As part of the TI SDK, we were integrating the ivhsmem_uio as
>>>>> external module
>>>>> from https://github.com/henning-schild-work/ivshmem-guest-code
>>>>>
>>>>> Since the ivshmem changes in the Jailhouse, that driver no more
>>>>> works (because of the vendor ID change)
>>>>> Do you plan to host the updated version of the driver in this repo?
>>>>>
>>>>> I know that the driver is already part of the siemens repo but it
>>>>> is much simpler to integrate an external module in yocto.
>>>>
>>>> Actually, that new driver is a complete rewrite, not just an ID
>>>> update. It allows to securely pass access to unprivileged users and
>>>> provides all features of the new ivshmem interface.
>>
>> With this driver, I can get the uio device registered but when I run
>> the uio_send and uio_read apps,
> Using the uio_send and uio_read apps from
> https://github.com/henning-schild-work/ivshmem-guest-code/tree/master/uio/tests/Interrupts/VM
>

Yeah, Henning already suggested to shut that repo down as people are
still finding it...

Please follow the *updated* description in
Documentation/inter-cell-communication.md regarding demos.

Jan

[Nikhil Devshatwar]

Hi Jan,

Please follow the *updated* description in
Documentation/inter-cell-communication.md regarding demos.

I am now running the tools/ivshmem-demo.c application.
I am getting failure to mmap the registers region because the default sizes for most of the ivshmem regions are multiple of 4096
When runnning a 64 bit kernel, mapping a 4k memory chunk in userspace fails with EINVAL error [1]
How can this be fixed?

[1] https://elixir.bootlin.com/linux/v5.4.38/source/drivers/uio/uio.c#L737

Regards,
Nikhil D

Jan

[Jan Kiszka]

Are you using a kernel configuration with PAGE_SIZE > 4K? Not
recommended, for a number of reasons.

BTW, you can test that this works in principle via jailhouse-images,
qemu-arm64 target. Eventually, there will be a TI target as well ;).

Jan