riscv: Add basic riscv bindings

[TimePrinciple]

Updated arm64, x86_64, and added riscv kvm bindings according to v6.9 kernel source.

Summary of the PR

Generate riscv bindings, and regenerate arm64, x86-64 bindings from v6.9. I've noticed #92, but it has not seen changes for a while, so I decided to push the work. I'm currently working on adding support to kvm-ioctls on riscv.

And I wonder how to add cross-compilation test CIs in rust-vmm-ci, may be configure a x86_64 ubuntu and set the runner field to /usr/bin/qemu-riscv64 or something?

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[JonathanWoollett-Light]

We want to integrate testing for RISC-V before merging RISC-V specific code, ideally resolving rust-vmm/rust-vmm-container#96.

[TimePrinciple]

We want to integrate testing for RISC-V before merging RISC-V specific code, ideally resolving rust-vmm/rust-vmm-container#96.

I've proposed using x86_64 machine to cross-compile and qemu-riscv64-static to test compiled binary in rust-vmm-ci and rust-vmm-container, please have a look at your convenience.

[rbradford]

@TimePrinciple Can you please split the arm64 & x86-64 bindings regenerations into their own separate patches and put them into a new PR as I think it may be some time until the required RISC-V CI enabling is available.

[TimePrinciple]

@TimePrinciple Can you please split the arm64 & x86-64 bindings regenerations into their own separate patches and put them into a new PR as I think it may be some time until the required RISC-V CI enabling is available.

Sure thing. But am I going to do it with the latest kernel version or just stick to v6.9.

[rbradford]

@TimePrinciple Can you please split the arm64 & x86-64 bindings regenerations into their own separate patches and put them into a new PR as I think it may be some time until the required RISC-V CI enabling is available.

Sure thing. But am I going to do it with the latest kernel version or just stick to v6.9.

v6.9 only just came out - it will be a while for another so seems fine to stick with that.

[TimePrinciple]

@TimePrinciple Can you please split the arm64 & x86-64 bindings regenerations into their own separate patches and put them into a new PR as I think it may be some time until the required RISC-V CI enabling is available.

Sure thing. But am I going to do it with the latest kernel version or just stick to v6.9.

v6.9 only just came out - it will be a while for another so seems fine to stick with that.

I mean if I'm going to split the x86_64 and arm bindings into a new PR, what kernel version would be suitable for me to do the regeneration.

[rbradford]

@TimePrinciple Can you please split the arm64 & x86-64 bindings regenerations into their own separate patches and put them into a new PR as I think it may be some time until the required RISC-V CI enabling is available.

Sure thing. But am I going to do it with the latest kernel version or just stick to v6.9.

v6.9 only just came out - it will be a while for another so seems fine to stick with that.

I mean if I'm going to split the x86_64 and arm bindings into a new PR, what kernel version would be suitable for me to do the regeneration.

I would stick with v6.9 - just split your existing work into different commits - no need to change the content. :-)

[TimePrinciple]

It seems that net.ipv4.ip_forward is not enabled on runners, which causes the network problem inside QEMU.

I currently have no clue on what's going on inside the runners, I tried those CI commands locally, everything works fine.

I propose vendor all dependencies outside QEMU, which could address this problem, but a lot of modifications are to be made.

[stefano-garzarella]

It seems that net.ipv4.ip_forward is not enabled on runners, which causes the network problem inside QEMU.

I currently have no clue on what's going on inside the runners, I tried those CI commands locally, everything works fine.

I propose vendor all dependencies outside QEMU, which could address this problem, but a lot of modifications are to be made.

In the container we do echo 'nameserver 8.8.8.8' > $ROOTFS_DIR/etc/resolv.conf, I'm not sure if that IP is accessible, so maybe we should use the host as nameserver. In https://wiki.qemu.org/Documentation/Networking it looks like the default virtual DNS server is 10.0.2.3 or You can specify the guest-visible virtual DNS server address with -netdev user,id=n0,dns=addr

[stefano-garzarella]

It seems that net.ipv4.ip_forward is not enabled on runners, which causes the network problem inside QEMU.
I currently have no clue on what's going on inside the runners, I tried those CI commands locally, everything works fine.
I propose vendor all dependencies outside QEMU, which could address this problem, but a lot of modifications are to be made.

In the container we do echo 'nameserver 8.8.8.8' > $ROOTFS_DIR/etc/resolv.conf, I'm not sure if that IP is accessible, so maybe we should use the host as nameserver. In https://wiki.qemu.org/Documentation/Networking it looks like the default virtual DNS server is 10.0.2.3 or You can specify the guest-visible virtual DNS server address with -netdev user,id=n0,dns=addr

BTW I'm expecting that the DHCP implemented by the user netdev should also set the DNS, so why we need to set /etc/resolv.conf ?

[roypat]

GitHub's PR linking strikes again

[TimePrinciple]

I would like to know how do we fix this

[roypat]

I would like to know how do we fix this

You can just adjust the value in the json file, the toolchain update caused this in a few repositories for some reason

[TimePrinciple]

It's ready now, please take a look when convenient @stefano-garzarella @roypat @rbradford , many thanks 😊