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
