From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 2039F5A0268 for ; Thu, 23 Feb 2023 15:06:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677161181; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZvW1/4zWun19Tu4gKklrafL4C8BbMLTuFT0f/JsZrwk=; b=UGxRxs0kZ/THL/eT21/fS6qcogO9Rt+hXlSmGv3+QThyava9ylf1XamAg94oVNyAAbALMO wXNSC+HJ4MPiAj6GIj2CvzXsy0i+ym5Ya4QQeE234eG8iWCyYSxiIWkfiyNnU012FjLurj NelcFIR5p+aM5jEiQVuOq8fQlGm/geE= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-270-qtHD--KvPfiC4WJRC6V6nA-1; Thu, 23 Feb 2023 09:06:19 -0500 X-MC-Unique: qtHD--KvPfiC4WJRC6V6nA-1 Received: by mail-pl1-f197.google.com with SMTP id c9-20020a170902d48900b0019ab46166a3so5467041plg.5 for ; Thu, 23 Feb 2023 06:06:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:in-reply-to:mime-version:references :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZvW1/4zWun19Tu4gKklrafL4C8BbMLTuFT0f/JsZrwk=; b=IGZyiG4eGOsrLfMyPJHxklm9SWMAeiv6m520M3JFu4mu97pW0wV142cvlcrChf9BBo sjuTifaEqnx3Na6Mn8kVTXDSFh1zlGaibuRHELcxA+gSlsTcFRkP8BYpd1JxwR1EC/FK +F0iebhCq7uC5Sl26PUT91lbJdqPdKV2Atkk0H14S2Zp4TIF5DrBh1pDspvv73Dbg6S/ 9Qh61jQBShXWwldjt4MOFPxROJTKf6zaYy8iO9TjG6t0PW3PkDQbrF2nA4lPwhf1SqrH DjZLFqXs5zNEeA+xI4DtCfQTyzeo8Qn6HCGEEC50LMv0lJJUht0bVBl8//tr74UK1Zlx oRxA== X-Gm-Message-State: AO0yUKVVrPuL0vHY3vCauOu9pn0+hkhSkQAqT/WR4Y83OLRq55TyaD7q r1SpWee/nRFtplX5SYUv2/+o4nWReOZaPmuiNWIOuCA3lhu5DeVD4S0gUmjRkqg54S9XBC+3I+k 72VkW7IPYBhArt4F1tFYhFvA7RsdM X-Received: by 2002:a17:90b:390d:b0:237:7761:37f9 with SMTP id ob13-20020a17090b390d00b00237776137f9mr128221pjb.91.1677161178667; Thu, 23 Feb 2023 06:06:18 -0800 (PST) X-Google-Smtp-Source: AK7set8RFuI0RvO0fY6DHy47JTPl+24qbTr4u7r9lzYDDMipkzKmUBvsIRdBMw5Fup4km6kIhyvCkvjr8azTbLdR1ZQ= X-Received: by 2002:a17:90b:390d:b0:237:7761:37f9 with SMTP id ob13-20020a17090b390d00b00237776137f9mr128216pjb.91.1677161178377; Thu, 23 Feb 2023 06:06:18 -0800 (PST) Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Thu, 23 Feb 2023 06:06:17 -0800 From: Andrea Bolognani References: <20230221192425.3745394-1-sbrivio@redhat.com> MIME-Version: 1.0 In-Reply-To: Date: Thu, 23 Feb 2023 06:06:17 -0800 Message-ID: Subject: Re: [PATCH] qrap: Pass PCI device numbers to qemu in base 10, not in base 16 To: David Gibson X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 2TU3DOJCVNHHQYVE4ESB33N7JDQQHMWA X-Message-ID-Hash: 2TU3DOJCVNHHQYVE4ESB33N7JDQQHMWA X-MailFrom: abologna@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Stefano Brivio , passt-dev@passt.top, Alona Paz X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Feb 23, 2023 at 09:27:14AM +1100, David Gibson wrote: > On Wed, Feb 22, 2023 at 02:40:32AM -0800, Andrea Bolognani wrote: > > I don't think this is going to work. > > > > The problem is that, while PCI buses are indeed named with increasing > > numbers in integer format (pci.9, pci.10 and so on), PCI slots are > > addressed using hexadecimal format (0x9, 0xa and so on). libvirt uses > > this naming convention because it matches QEMU's. > > Actually, I think we're ok. PCI slots are addressed in hex by > convention, but AFAICT if you *just* give a slot number, it will > accept either decimal or hex (so addr=10 and addr=0xa are equivalent). > That's *not* true if you use SS.F format to include the function > number - then it expects hex only. But we're not doing that, so so > always using decimal should be ok here. > > Source: set_pci_devfn() in the qemu source > > Obviously that's a pretty fragile hack, but that's 'qrap' for you. Yeah, even if that happens to work I'd rather not rely on it, especially since a proper solution doesn't look like it would be a lot of additional effort. I've managed to reproduce the original issue in the context of KubeVirt. I'll hopefully have a patch ready soon. -- Andrea Bolognani / Red Hat / Virtualization