From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBC1EC433ED for ; Tue, 18 May 2021 13:41:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9DB46610E9 for ; Tue, 18 May 2021 13:41:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DB46610E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56188 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lizy0-0004XL-1R for qemu-devel@archiver.kernel.org; Tue, 18 May 2021 09:41:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lixKr-0004Ql-Af for qemu-devel@nongnu.org; Tue, 18 May 2021 06:52:25 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:59221) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1lixKd-0008G4-EL for qemu-devel@nongnu.org; Tue, 18 May 2021 06:52:24 -0400 Received: from mail-lj1-f200.google.com ([209.85.208.200]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lixKY-0004K7-Kv for qemu-devel@nongnu.org; Tue, 18 May 2021 10:52:06 +0000 Received: by mail-lj1-f200.google.com with SMTP id v26-20020a2e481a0000b02900bf48f13296so4328782lja.1 for ; Tue, 18 May 2021 03:52:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DrbhKQqWOKZ0x68DWMp1pQVKCMcjjsnU6WhS8cwd/sc=; b=oOOT9l2gFtU58uvhQAP0WbjETgGI7yQdF7AwLnYkv+1qCWUsgV0zDTwP4jl0GH7OlQ 04IbIQrAkz0gg9/DOkeBD0PBP8OULYgJ8fz6dYvE5F6qFLU4ypqtlTnHygpAV5qfReCX jOgSC5kyHCqLkOGYWGbS2Mm32POahZhpL1cbrJiJPnIx8cl2obd4wNMxYOnq1jcwaK9r YAcBAT6x3yXdnTKflK4fupwVPK8M8usCioHolrICgUs3YzUTlzHwYvlm/UWIhVNr704X /RE1GtOETXSqjTEOpsZnZkVFWnXxc4NBG9uq/x6wBawBCDOl8p1wN2CWryjDCZw5AGOU c20w== X-Gm-Message-State: AOAM5321wVuXG0ijpjsRBoupaFzf21q4QTmrRgE5B6AMSPnpeVx+QyNB eC440lsFUSrMFjpEdaBa2zV90ZJoVS3yZbqmVhje3YzcuNz/JcBBJlYhjjYqggFYU68QiStDa4x j6f3P/j/eF5ljfCwEvcU0YR4BlQ0L+sH/Htz48x5Hkb+cLpuz X-Received: by 2002:ac2:42ca:: with SMTP id n10mr3692511lfl.330.1621335126155; Tue, 18 May 2021 03:52:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzoBd2kffFSRkg+7JQNeknhKqhi+y2XpG2P+eXtiy7cAwZ+rHxusty9fjBR7+yTf8p5s86vS5egRrTR4zmRZc= X-Received: by 2002:ac2:42ca:: with SMTP id n10mr3692493lfl.330.1621335125918; Tue, 18 May 2021 03:52:05 -0700 (PDT) MIME-Version: 1.0 From: Thomas Parrott Date: Tue, 18 May 2021 11:51:40 +0100 Message-ID: Subject: Adding devices via QMP's device_add don't have their bootindex setting respected To: qemu-devel@nongnu.org Content-Type: multipart/alternative; boundary="0000000000003e1ce005c2988010" Received-SPF: none client-ip=91.189.89.112; envelope-from=thomas.parrott@canonical.com; helo=youngberry.canonical.com X-Spam_score_int: -68 X-Spam_score: -6.9 X-Spam_bar: ------ X-Spam_report: (-6.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 18 May 2021 09:39:06 -0400 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcel@redhat.com, jusual@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000003e1ce005c2988010 Content-Type: text/plain; charset="UTF-8" Due to QEMU moving towards a QMP configuration mechanism and away from config file support, the LXD team are currently in the process of migrating to using QMP to add devices to VMs (so that we can support the use of QEMU 6.0). Currently we are using the `-S` flag to freeze CPU at startup, then using QMP to add NIC devices via the `device_add` command, and then using the `cont` command to start the VM guest. This is working mostly fine, but there is one issue; the provided "bootindex" property is not respected. E.g. device_add {"addr":"00.0","bootindex":"0","bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-lxd_eth0","mac":"00:16:3e:0c:69:e7","mq":"on","multifunction":"off","netdev":"lxd_eth0","vectors":"6"} The device is seen within the VM guest and the VM BIOS, but its boot order is last rather than first. We've also tried using a non-zero bootindex of 1 and that has the same effect. After discussions on #qemu IRC channel, we found that running `system_reset` after adding the devices allowed the `bootindex` property to be respected. So this looks like bug. Perhaps we can discuss it in one of the forthcoming community calls? Thanks Tom Parrott --0000000000003e1ce005c2988010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Due to QEMU moving towards a QMP configuration mechan= ism and away from config file support, the LXD team are currently in the pr= ocess of migrating to using QMP to add devices to VMs (so that we can suppo= rt the use of QEMU 6.0).

Currently we are using th= e `-S` flag to freeze CPU at startup, then using QMP to add NIC devices via= the `device_add` command, and then using the `cont` command to start the V= M guest.

This is working mostly fine, but ther= e is one issue; the provided "bootindex" property is not respecte= d.

E.g.

device_add {"= ;addr":"00.0","bootindex":"0","bus&= quot;:"qemu_pcie4","driver":"virtio-net-pci",= "id":"dev-lxd_eth0","mac":"00:16:3e:0c:6= 9:e7","mq":"on","multifunction":"of= f","netdev":"lxd_eth0","vectors":"6= "}

The device is seen within the VM guest and= the VM BIOS, but its boot order is last rather than first.
<= br>
We've also tried using a non-zero bootindex of 1 and that= has the same effect.

After discussions on #qemu I= RC channel, we found that running `system_reset` after adding the devices a= llowed the `bootindex` property to be respected.

S= o this looks like bug. Perhaps we can discuss it in one of the forthcoming = community calls?

Thanks
Tom Parrott<= br>
--0000000000003e1ce005c2988010--