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 1653B5A0082 for ; Fri, 24 Feb 2023 20:05:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677265504; 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=GvjIsOm2UjLpLwa4BTLPpHGLpl115rs7UDOykqa9V6k=; b=UC8QaECtrpdElLjQey/vWFAEuQBWECqWiIeXbidwEHJSB0V+fOzTXfVeIEdum+D4J1kuNt UxaMFcuj23+MzrvzQ7Zv5FvjyMcAK86FfwbOhxbkKLpb5O4BtAI/GjiaG4TH1OQ2uelMdj LXNerdadPVDXacMzlsUxkJ87/2KQ6xc= Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-468-6hAgSv-lMAelFDg3nZGBTA-1; Fri, 24 Feb 2023 14:05:02 -0500 X-MC-Unique: 6hAgSv-lMAelFDg3nZGBTA-1 Received: by mail-pg1-f197.google.com with SMTP id s9-20020a634509000000b004fc1c14c9daso40404pga.23 for ; Fri, 24 Feb 2023 11:05:02 -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=GvjIsOm2UjLpLwa4BTLPpHGLpl115rs7UDOykqa9V6k=; b=0IOUL6xZfLFJ6xsHh4PX5YCtxzR111tl9VTM+asS+ObXwIU7wflUDPAFbqObDuwS+w gWovCwRXVrQtmcNfNtHr7t3GTfgwZjpOj5zk5+w28ygtxpVxBcBbWyWqt1ELkWQdp1H9 NMdvKwhFFKpLmVC9Glep0Lmu98lqqIMW2AlIuFhlqVmhCn+rXeMcYSYbH6n5ndouw9xl Sf4ZygnuqXogsze1AIQj7UqWVc4nx654Af19ZaGigLhWOb1I3cjXaWSyjqE2L6COrvfU HZC2ACVxJzdY/PNy0W9SUMG/uuQkacWGrCUVzXB9k1L3b0qF2OpumcqklVzaQvYuQI9m 2d+w== X-Gm-Message-State: AO0yUKW2mVo+afQKfmB/ZRf8s9y2tTriIqkhqQpd+mZ3Y5pUGcSj73ur AHdzPUhELwquBQbifKIkbQWLMJZcSkvqrnTau/aZJpAlR68xnVvn6xkcSad97BjS7V0LDEx70CS dduuE8qDUBWnr5PsXeNZR5qM+W7Iz X-Received: by 2002:a63:6d43:0:b0:502:fd12:c086 with SMTP id i64-20020a636d43000000b00502fd12c086mr1792279pgc.3.1677265501843; Fri, 24 Feb 2023 11:05:01 -0800 (PST) X-Google-Smtp-Source: AK7set+NC9RhLqkzOUWuh2gxfaIIVjE7fwhhNTu7Jq+IH+eh92SmP52QbYrQG/UL0estfV3LMIt5P9plQ5hfe6A5+MA= X-Received: by 2002:a63:6d43:0:b0:502:fd12:c086 with SMTP id i64-20020a636d43000000b00502fd12c086mr1792274pgc.3.1677265501518; Fri, 24 Feb 2023 11:05:01 -0800 (PST) Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Feb 2023 11:05:00 -0800 From: Andrea Bolognani References: <20230221192425.3745394-1-sbrivio@redhat.com> <20230224081416.47b85d01@elisabeth> MIME-Version: 1.0 In-Reply-To: <20230224081416.47b85d01@elisabeth> Date: Fri, 24 Feb 2023 11:05:00 -0800 Message-ID: Subject: Re: [PATCH] qrap: Pass PCI device numbers to qemu in base 10, not in base 16 To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: XBGJGPRNJASYCN5APA4SEDMJHHDR7UVC X-Message-ID-Hash: XBGJGPRNJASYCN5APA4SEDMJHHDR7UVC 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: David Gibson , 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 Fri, Feb 24, 2023 at 08:14:16AM +0100, Stefano Brivio wrote: > On Thu, 23 Feb 2023 06:06:17 -0800 Andrea Bolognani wrote: > > 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, allow me to do this: I would push this patch meanwhile, along > with the changes for the DNS issue you reported, because that one might > impact many users, and I think it makes sense to have a fix out soon. > > I start thinking it's also part of the issue Paul reported for Podman > with pasta here: > https://github.com/containers/podman/issues/17074 > > This patch itself can't hurt, and it changes exactly two letters. I strongly disagree with this assessment. This patch merely trades one set of issues for another one. In particular, for pc machine types we'd end up producing bus=pci.0,addr=0x10 for slot 10 instead of bus=pci.0,addr=0xa, because the addr=0x part is baked into the template. So the QEMU logic David mentioned above wouldn't kick in at all. More importantly, for q35 machines we'd start producing decimal bus numbers while still parsing the ones present in the original command line as hexadecimal, so things would stop lining up as soon as enough devices are present, meaning that the issue reported by Alona would still exist. > As soon as you have something less qrappy we'll go with that (you don't > even need to rebase, I'll revert this one on the tree first). Patches fixing this issue, as well as a few additional ones, are now on the list. I'll follow up on that thread with some considerations related to testing the changes. -- Andrea Bolognani / Red Hat / Virtualization