Re: Virtio on Xen with Rust

[Oleksandr <olekstysh@gmail.com>]

On 29.04.22 06:48, Viresh Kumar wrote:


Hello Viresh

> On 28-04-22, 16:52, Oleksandr Tyshchenko wrote:
>> Great work!
> Thanks Oleksandr.
>
>> I skimmed through your toolstack patches, awesome, you created a completely
>> new virtual device "I2C".
> I have also created GPIO now :)

Awesome!


>
> What should I do about these patches ? Send them to xen list ? I can at least
> send the stuff which doesn't depend on your series ?

Below my understanding, which might be wrong)


I think, the best case scenario - is to try to get these features 
upstreamed. I expect a possible interest to virtulized I2C/GPIO devices 
on Xen,
especially in embedded environment where the passthrough of dedicated 
I2C/GPIO controller to the guest is not possible for some reason 
(clocks, pins, power domains, etc).
But I do understand it most likely takes some time. If upsteaming this 
stuff is not your primary target, then I think, such patch series 
deserves to be sent to the Xen mailing list anyway for someone who is 
interested in the topic to give it a try. For example, you can send RFC 
version saying in cover letter that it depends on non-upsteamed yet 
stuff to start discussion.



>
>> FYI, I have updated "Virtio support for toolstack on Arm" [1] since (to
>> make it more generic), now V7 is available and I have a plan to push V8
>> soon.
> I will surely have a look, thanks.
>
>> FYI, currently we are working on one feature to restrict memory access
>> using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1].
>> And there is a working PoC on Arm based on an updated virtio-disk. As for
>> libraries, there is a new dependency on "xengnttab" library. In comparison
>> with Xen foreign mappings model (xenforeignmemory),
>> the Xen grant mappings model is a good fit into the Xen security model,
>> this is a safe mechanism to share pages between guests.
> Right, I was aware of this work but didn't dive into it yet. We will surely need
> to do that eventually, lets see when I will be able to get to that. The current
> focus is the get the solution a bit more robust (so it can be used with any
> device) and upstream it to rust-vmm space on github.

ok, I see. I understand your point, your primary target is 
hypervisor-agnostic Rust based backend(s) to be applicable for any device.



>
>> With Xen grant mappings, if I am not mistaken, it is going to be almost the
>> same: mmap() then ioctl(). But the file will be "/dev/xen/gntdev".
> Okay, the problem (for us) still exists then :)

It seems, yes.


>   
>> FYI, new branch "virtio_grant" besides supporting Xen grant mappings also
>> supports virtio-mmio modern transport.
> Somehow the timing of your emails have been spot on.
>
> Last time, when you told me about the "dev" branch, I have already started to
> reinvent the wheel and your branch really helped.
>
> Now, it was just yesterday that I started looking into MMIO modern stuff as the
> GPIO device needs it and you sent me working code to look how to do it as well.
> You saved at least 1-2 days of my time :)

Great, I'm glad to hear it.


>
> Thanks Oleksandr.
>
-- 
Regards,

Oleksandr Tyshchenko