Re: arm/cadence_gem driver support
On Wed, Sep 25, 2019 at 12:46:40PM -0400, Kent Dorfman wrote: > Thanks for the input! > > Could you post your complete startup command sequence for the VM? I'm > trying to get a handle on whether I would need to create DTB files for > the image. Also I've noted that qemu can be picky about command > option ordering. As far as I understand, for recent boards Xilinx defines the board HW via device tree. Btw, to be clear, the device tree code only exists in the Xilinx fork and not upstream. If you do go the Xilinx fork road, then what I'm doing is essentially their instructions for ZCU102. Machine type is 'arm-generic-fdt', with a different DTB for each board. The DTBs are in a Xilinx qemu-devicetrees repo on github, iirc; if your board is similar to any of the existing ones there, the DT will be largedly the same. Ours is a custom board, similar to Xilinx ZCU102, we wrote a custom DT for it. This is probably not too helpful, but invocation for us is: qemu-system-aarch64 -machine arm-generic-fdt -hw-dtb custom-qemu.dtb -serial pty -net nic -net tap,br0,helper=/usr/local/bin/qemu-bridge-helper -monitor stdio -device loader,file=/path/to/elf,cpu-num=0
Re: arm/cadence_gem driver support
Thanks for the input! Could you post your complete startup command sequence for the VM? I'm trying to get a handle on whether I would need to create DTB files for the image. Also I've noted that qemu can be picky about command option ordering. Thanks On 9/25/19, Alexei Colin wrote: > On Wed, Sep 25, 2019 at 11:24:12AM -0400, Kent Dorfman wrote: >> yes. fully bridged access via a tap is what I was looking for...but I >> don't see anything on your command line identifying the guest network >> as cadence_gem: no model=cadence_gem. Is it implicit? > > Instantiation of the device is happening via Xilinx Qemu device tree > node, which has a 'compatible' string identifying the model. The command > line args are implicitly referring to the device in the device tree, by > order, I believe (so, '-net nic' will refer to first ethernet device in > DT, '-net nic -net nic' will refer to first and second etc). > > I have not tried tap mode in upstream Qemu. >
Re: arm/cadence_gem driver support
On Wed, Sep 25, 2019 at 11:24:12AM -0400, Kent Dorfman wrote: > yes. fully bridged access via a tap is what I was looking for...but I > don't see anything on your command line identifying the guest network > as cadence_gem: no model=cadence_gem. Is it implicit? Instantiation of the device is happening via Xilinx Qemu device tree node, which has a 'compatible' string identifying the model. The command line args are implicitly referring to the device in the device tree, by order, I believe (so, '-net nic' will refer to first ethernet device in DT, '-net nic -net nic' will refer to first and second etc). I have not tried tap mode in upstream Qemu.
Re: arm/cadence_gem driver support
Also noticed that you are using a xilinx fork of the qemu package. Would prefer to NOT use their fork, as I'm very much opposed to having to register on corporate websites to acquire and use OS tools. Have any xilinx specific enhancements made it back into the main repository? does version 4.x contain a superset of the required functionality? On 9/25/19, Kent Dorfman wrote: > yes. fully bridged access via a tap is what I was looking for...but I > don't see anything on your command line identifying the guest network > as cadence_gem: no model=cadence_gem. Is it implicit? > > I prefer to run all guests under bridged-tap so that they can be seen > by the host network...I guess this requires the main host nic also be > in promiscuous mode before assigning it to the bridge interface. > > > > On 9/25/19, Alexei Colin wrote: >> On Wed, Sep 25, 2019 at 08:52:45AM -0400, Kent Dorfman wrote: >>> This seems to negate the ability to >>> set up the guest in a fully bridged network configuration where it is >>> seen as a generic station on the host network. I need a fully bridged >>> network connection. >> >> FWIW, on Xilinx's fork of Qemu (~v2.11.1) I had Cadence Ethernet working >> in tap mode (with Linux guest), where the Qemu guest is recheable via a >> first class tap interface on the host; not sure if that's what you refer >> to as fully bridged or not. >> >> Create a bridge device on the host and assign it an IP: >> # ip link add br0 type bridge >> # ip link set up dev br0 >> # ip addr add 10.0.2.1/24 dev br0 >> >> Install helper with setuid: >> # install -o root -g root -m 4775 qemu/qemu-bridge-helper >> /usr/local/bin/qemu-bridge-helper >> Grant permission to non-root users: >> # echo "allow br0" > /usr/local/bin/etc/qemu/bridge.conf >> ^ prefix set when ./configure was run >> >> Run qemu (as non-root user should work, given the above setup) with: >> -net nic,vlan=0 -net >> tap,vlan=0,br=br0,helper=/usr/local/bin/qemu-bridge-helper >> >> Within guest, assign IP address and host should become reacheable: >> # ip addr add 10.0.2.10/24 dev eth0 >> # ping 10.0.2.1 >> >> Multiple guests all connected to the same bridge worked too. >> >
Re: arm/cadence_gem driver support
On Wed, Sep 25, 2019 at 08:52:45AM -0400, Kent Dorfman wrote: > This seems to negate the ability to > set up the guest in a fully bridged network configuration where it is > seen as a generic station on the host network. I need a fully bridged > network connection. FWIW, on Xilinx's fork of Qemu (~v2.11.1) I had Cadence Ethernet working in tap mode (with Linux guest), where the Qemu guest is recheable via a first class tap interface on the host; not sure if that's what you refer to as fully bridged or not. Create a bridge device on the host and assign it an IP: # ip link add br0 type bridge # ip link set up dev br0 # ip addr add 10.0.2.1/24 dev br0 Install helper with setuid: # install -o root -g root -m 4775 qemu/qemu-bridge-helper /usr/local/bin/qemu-bridge-helper Grant permission to non-root users: # echo "allow br0" > /usr/local/bin/etc/qemu/bridge.conf ^ prefix set when ./configure was run Run qemu (as non-root user should work, given the above setup) with: -net nic,vlan=0 -net tap,vlan=0,br=br0,helper=/usr/local/bin/qemu-bridge-helper Within guest, assign IP address and host should become reacheable: # ip addr add 10.0.2.10/24 dev eth0 # ping 10.0.2.1 Multiple guests all connected to the same bridge worked too.
Re: arm/cadence_gem driver support
yes. fully bridged access via a tap is what I was looking for...but I don't see anything on your command line identifying the guest network as cadence_gem: no model=cadence_gem. Is it implicit? I prefer to run all guests under bridged-tap so that they can be seen by the host network...I guess this requires the main host nic also be in promiscuous mode before assigning it to the bridge interface. On 9/25/19, Alexei Colin wrote: > On Wed, Sep 25, 2019 at 08:52:45AM -0400, Kent Dorfman wrote: >> This seems to negate the ability to >> set up the guest in a fully bridged network configuration where it is >> seen as a generic station on the host network. I need a fully bridged >> network connection. > > FWIW, on Xilinx's fork of Qemu (~v2.11.1) I had Cadence Ethernet working > in tap mode (with Linux guest), where the Qemu guest is recheable via a > first class tap interface on the host; not sure if that's what you refer > to as fully bridged or not. > > Create a bridge device on the host and assign it an IP: > # ip link add br0 type bridge > # ip link set up dev br0 > # ip addr add 10.0.2.1/24 dev br0 > > Install helper with setuid: > # install -o root -g root -m 4775 qemu/qemu-bridge-helper > /usr/local/bin/qemu-bridge-helper > Grant permission to non-root users: > # echo "allow br0" > /usr/local/bin/etc/qemu/bridge.conf > ^ prefix set when ./configure was run > > Run qemu (as non-root user should work, given the above setup) with: > -net nic,vlan=0 -net > tap,vlan=0,br=br0,helper=/usr/local/bin/qemu-bridge-helper > > Within guest, assign IP address and host should become reacheable: > # ip addr add 10.0.2.10/24 dev eth0 > # ping 10.0.2.1 > > Multiple guests all connected to the same bridge worked too. >
