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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 50AB5C433E0 for ; Tue, 12 Jan 2021 17:18:42 +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 CFEEB23120 for ; Tue, 12 Jan 2021 17:18:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFEEB23120 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=0bits.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzNJY-0006wR-UE for qemu-devel@archiver.kernel.org; Tue, 12 Jan 2021 12:18:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzN6O-00005w-Ep for qemu-devel@nongnu.org; Tue, 12 Jan 2021 12:05:04 -0500 Received: from uk.hasbox.com ([2a01:7e00::f03c:91ff:fe91:5fdc]:38847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzN6M-0000fT-JB for qemu-devel@nongnu.org; Tue, 12 Jan 2021 12:05:04 -0500 Received: from [192.168.86.42] (dev.hasbox.com [151.236.217.240]) (authenticated bits=0) by uk.hasbox.com (8.15.2/8.15.2) with ESMTPSA id 10CH4vDx012543 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 12 Jan 2021 17:04:58 GMT Subject: Re: absolute firmware path made relocatable in qemu 5.2.0 To: Paolo Bonzini References: <428592f1-a5fd-7e6a-f181-28f31343518a@0bits.com> From: Dave Message-ID: <3ab19db3-7339-79d5-9f4f-aee7165b531a@0bits.com> Date: Tue, 12 Jan 2021 21:04:57 +0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=2a01:7e00::f03c:91ff:fe91:5fdc; envelope-from=dave@0bits.com; helo=uk.hasbox.com X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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: qemu-devel Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Thanks Paola, We are still in testing and that's the only thing we've uncovered so far with the new 5.2.0. I will post if the ops guys find anything else. Dave On 12/01/2021 20:53, Paolo Bonzini wrote: > > > Il mar 12 gen 2021, 17:48 Dave > > ha scritto: > > Hi Paolo, > > While this (option 2) partially works, it will still search for > /nonexistent/libexec/qemu-bridge-helper for example so seems that some > paths are still absolute and some relative. > > > Ok, that's a bug that can be fixed in 5.2.1. Are there other instances? > > > To explain, what we are expecting that we compile one binary with the > relevant options, test that and then it goes into production. If we > compile with --prefix=/usr (it's final resting place will be /usr/bin) > then everything works as expected once it is in production (since > /usr/share/qemu, /usr/libexec, /etc/qemu exists as expected).  However > when we are testing the binary in a directory /root/qemu/5.2.0 with > --prefix=/usr it breaks since it converts the firmware and bios > paths to > /root/qemu/5.2.0/../share/qemu. This means we need to recompile twice > with relevant prefixes since if i use --prefix=/nonexistent then we > can't find the qemu-bridge-helper when the binary goes into production. > > It would be nicer with the relocatable binary took some fixed paths > from > /etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down. > > thanks > Dave > > > On 12/01/2021 18:48, Paolo Bonzini wrote: > > On 12/01/21 15:05, Dave wrote: > >> Is seem that absolute firmwarepath compilation option is > converted  to > >> relocatable in 5.2.0 qemu. > >> > >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021 > >> # Configured with: '../configure' '--prefix=/usr' > >> '--sysconfdir=/etc/qemu' '--disable-bochs' > >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*' > >> # > > > > Yes, all paths within the prefix are relocated.  The workaround is > > simply to configure the intended prefix with configure: > > > > ./configure --prefix=/root/qemu ... > > > > or if you don't know the prefix: > > > > ./configure --prefix=/nonexistent ... > > > > Because /usr/share/qemu and /usr/share/qemu-firmware are outside > /usr, > > they will be treated as absolute just like /etc/qemu. > > > > Thanks, > > > > Paolo > > > >> And trying to run the executable > >> > >>     bash-5.1# ./qemu-system-x86_64 > >>     qemu: could not load PC BIOS 'bios-256k.bin' > >> > >> If i print out the resultant binary paths > >> > >>     bash-5.1# ./qemu-system-x86_64 -L help > >>     /root/qemu/../share/qemu > >>     /root/qemu/../share/qemu-firmware > >> > >> So there is no way to have a absolute path for firmware /bios > and all > >> qemu's that we test need to be at the right directory nesting to > find > >> firmware, bios etc or else they all need their own duplicate > firmware > >> files. Firmware path needs to honor the absolute paths i believe. > >> > > >