On Sat, 29 Sep 2018 at 06:14, chao yang <yangchao.free@gmail.com> wrote:
Thank you for your detailed answer.
It means that in the typical lava LXC environment, no such arm device(DUT)emulator exists.

In a typical LXC test job, there is just the LXC and the DUT, yes. No emulation is used. LAVA does support emulation, by using the QEMU device-type, as a separate type of test job.
The LXC does not run the arm emulator and it exists  is for convenient management, and the LXC is connected to real DUT.

The LXC runs on the worker.
The DUT is connected to the worker, typically over USB.
The Device Dictionary is configured to add the USB device to the LXC so that programs inside the container can access the DUT through that interface. e.g. fastboot through /dev/bus/usb/

If you want an ARM emulator, you can run a QEMU device on the worker passing in an ARM kernel and rootfs.
Is this understood?

Mostly. What are you actually trying to achieve? Do you need to run QEMU to emulate an ARM device instead of or as well as a DUT?


On Fri, Sep 28, 2018 at 8:31 PM Neil Williams <neil.williams@linaro.org> wrote:
On Fri, 28 Sep 2018 at 12:11, chao yang <yangchao.free@gmail.com> wrote:
It say that LXC devices can run lava tests within a container without disturbing the dispatcher host. 
Does LXC support the arm device?

We routinely use LXC with an ARM DUT on x86 and arm64 workers.

 Although LXC may supports to run the arm virtual machine in PC server,

LXC does not emulate anything - this is a container, not a virtual machine. The architecture of the container matches the architecture of the worker. The LXC runs on the worker to isolate certain programs (like fastboot and adb) from the worker. This means that those programs only see specific devices in /dev/bus/usb and do not have access to the full list of USB devices on that worker.
but how does it support the completed arm device(Including various peripheral interfaces eg ethernet,usb.. ) ? Because the test job  often test various peripheral interfaces,Is  LXC emulating these interfaces?

Peripheral support depends on how the peripheral is connected. We routinely test with an energy probe which has a USB A connection to the worker and power measurement soldered connections onto the DUT. The probe therefore shows up on the worker in /dev/bus/usb/ - to have that visible inside the LXC, the device dictionary simply defines the serial number of the device in /dev/bus/usb. The probe does not show up on the DUT at all.

There are two methods:

Devices like energy probes remain connected to the worker (and therefore visible in /dev/bus/usb on the worker) whether the DUT is powered on or off - these are static devices and the details go into static_info - these devices will be added every LXC used with the DUT whether the test job needs them or not, before the DUT is powered on. There is no udev ADD event because that only happens when the cable is unplugged or the worker rebooted.

Often, devices with a static device will also have their own USB connection to the worker, so the device dictionary lists a static_info for the peripheral and device_info for the DUT.

Peripherals which are connected to the worker but which lose power when the DUT loses power need to be defined in exactly the same way as the DUT itself - device_info. These will be added to the LXC when udev detects an ADD event on the worker.
Only devices which show up in /dev/bus/usb on the worker can be added to the LXC.

Anything else can only be managed solely on the DUT - if there is a USB ethernet dongle, it is up to the kernel on the DUT to raise an interface using that device, this has nothing at all to do with the LXC.
Lava-users mailing list



Neil Williams