AGL in the Cloud: Progress on AMI Builds - Jan-Simon Möller, The Linux Foundation

### Overview Jan-Simon Möller, the Automotive Grade Linux (AGL) release manager and CI infrastructure lead, presents progress on running AGL virtual machine instances on Amazon Web Services (AWS). Echoing goals introduced by Jerry to develop in the cloud and deploy to edge devices, the talk demonstrates how cloud-hosted Amazon Machine Images (AMIs) can accelerate development and scale automated testing beyond the constraints of limited physical test boards on developers' desks. While previous efforts relied on costly bare-metal hardware instances, this work focuses on a more cost-effective intermediate approach: running AGL on virtualized AWS Nitro hypervisor instances.

### Key Topics - **Cloud-First Development and Testing:** Replacing scarce desktop test hardware with scalable virtualized instances to streamline CI test pipelines and parallel validation. - **Cost vs. Capability Trade-Offs:** Moving from expensive bare-metal AWS instances to cheaper virtualized Nitro instances, which do not expose bare-metal graphics hardware. - **Meta-AWS Layer Integration:** Using the AWS IoT group's standardized `meta-aws` Yocto layer to build unified x86_64 and arm64 (AWS Graviton) images that boot via UEFI (aligning with Arm SystemReady standards). - **Image Creation and Cloud Deployment:** Packaging AGL builds (such as `ivi-demo-flutter`) using the `create-ec2` script to automate uploading to Amazon S3 and importing as usable AMIs. - **Remote Graphical Access:** Bypassing the lack of direct DRM graphics hardware on virtualized Nitro instances by deploying an RDP backend for Wayland/Weston with llvmpipe software rendering.

### Technical Details The build pipeline relies on the `meta-aws` layer, embedded into the AGL tree, supporting both x86_64 and arm64 EC2 machine definitions. Standard configurations supply UEFI boot support, network drivers, and an SSH server. For arm64, builds target Graviton instance types (such as `t4g`), while x86 builds target standard types (such as `t3.xlarge`).

To bridge local builds to AWS, developers execute `create-ec2`, which requires the AWS CLI tool, appropriate IAM roles, an 8 GB image specification, target machine architecture, and an S3 bucket. After automated AMI importation, instances require key pair assignment and security group setup (at minimum opening SSH).

Möller highlights critical implementation and security details: - **User Account Nuance:** The AWS web console UI suggests connecting via SSH as `root`, but `meta-aws` replaces this by injecting a standard account named `user`. - **Remote Graphics with Weston RDP:** Because non-bare-metal Nitro hypervisor instances do not expose a Direct Rendering Manager (DRM) device, Weston's standard DRM compositor cannot start. AGL integrates an RDP transport feature (`agl-rdp`) into the build. Remote desktop protocol support requires mandatory TLS configuration (keys and certificates). Pre-configured canned certificates are provided for initial testing convenience, though Möller cautions that these canned certificates are insecure. - **Software Rendering Performance:** To accelerate non-GPU graphical rendering over RDP, `llvmpipe` is enabled on x86_64, providing workable performance for verifying UI changes without pure CPU software rasterization. Getting `llvmpipe` functional on arm64 remains an ongoing effort, with full GPU virtualization across hypervisors planned via parallel VirtIO development by Michele from Virtual Open Systems. - **Public Testing Image:** A pre-built snapshot AMI is made available in the `us-west-2` (Oregon) region, allowing developers to run on a `t3.xlarge` instance, establish an SSH tunnel forwarding the RDP port, and connect via a local RDP client.

### Takeaways Running AGL on virtualized AWS instances offers a practical, scalable, and economical method for developers to test builds and UI changes without physical hardware. While graphics performance over Weston RDP backed by llvmpipe is acceptable for interface validation rather than full framerate testing, it provides functional remote access. Future developments will focus on resolving arm64 llvmpipe rendering and integrating VirtIO-based GPU acceleration.