Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1442846imw; Tue, 5 Jul 2022 09:31:20 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sCsSizVLiqjnKq8QOaxu9kk+fs7H/QHzzTKleDA4vn+9CSHV+N/z6pQzyUdRk+uYMPVV3M X-Received: by 2002:a17:902:9301:b0:16a:1c68:f8d6 with SMTP id bc1-20020a170902930100b0016a1c68f8d6mr41804357plb.72.1657038679868; Tue, 05 Jul 2022 09:31:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657038679; cv=none; d=google.com; s=arc-20160816; b=YzwqDtx0qNvdLCG/2WrQVsjGZAV7um/isjsBww1BbsJUuH5KGlpsRkF1SgDVwzj+K2 uwcHtGeAR+j/DDIS2Tktq9F4p0sdBh3R5JC/4mT5wG8XIpmpc81A3OEGtdMPIAes993M grD11x2i2FsvT5CJ5QG9dp4MZ+xSir0IhM0+Y9CObTuI+T5YP/02iDFb6oRw1+gbqDRv niv8rBliTzU2f9Bnh932XYHwNIcJQYTO27d/kIBcCwI33cNddxCx9BrHC9+G5EY6dADP kScksx/uVRdNbfpbr/tmja3WypD4LzbDVTEJUfvu0Y3ysrfGbvofni7Nx+hGBR1ge0rI /u9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=g4Q/2dqWDjkZY0WPpT8x7ipzlESmHSOD8ijO+/Hy+KY=; b=rDbBF0rlEQ5ev8Yx9LErXqxpLYGQIpEmqvR9n2t53cUw5N4Few+mpZ2ItvacMQs7zt TMpP8uhJbrOS7vuInQ1+Zp3we8yhe2xP4Fs3F/uMkVKv1bwkHZELNRLXm4jZWx7nd0Oq HK+EVP5QkCV+nFukwUWe2G4dIn6ZENXxI2vZBVYSwzJcY60ABN6BpyDNMrbBolue2pBC 2XBhBuhjNEo2n1fXf8H60Zgwu6R8hEwIz5gVKLBtylTn1KXINhEhOuNluRQHTOMhTePa F47fkPXkA+40uH/uFvC2WDH3MvHOGdfjIhJVS2o6ngAx/kynro/wSzVBWceh9MtoEiEe CYUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XkMroAVa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q6-20020a056a0002a600b005289cc7d546si1107178pfs.186.2022.07.05.09.31.06; Tue, 05 Jul 2022 09:31:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XkMroAVa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232446AbiGEQPs (ORCPT + 99 others); Tue, 5 Jul 2022 12:15:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232838AbiGEQPr (ORCPT ); Tue, 5 Jul 2022 12:15:47 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7841A1D0FB for ; Tue, 5 Jul 2022 09:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657037745; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g4Q/2dqWDjkZY0WPpT8x7ipzlESmHSOD8ijO+/Hy+KY=; b=XkMroAVaYNE/lDNjoWdbfxG/mTtvwYGUrqQryXeyhhnDxh8Mi+p4DIJOQFgdfzNqsXw/1L tNC5RNRfHpGDhZcfaZD99ttbePZPRqoDcRA4NwE1kqxt7b2vPw73RbWt7Xfj6qol7Ll9Q0 3ORLXtyzzLsVwjQLpAp/NGaiUU4N6KM= Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-132-wmBcBjWXM1KLTbn0sYFECQ-1; Tue, 05 Jul 2022 12:15:38 -0400 X-MC-Unique: wmBcBjWXM1KLTbn0sYFECQ-1 Received: by mail-il1-f197.google.com with SMTP id i2-20020a056e021d0200b002d8ff49e7c4so5991442ila.8 for ; Tue, 05 Jul 2022 09:15:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=g4Q/2dqWDjkZY0WPpT8x7ipzlESmHSOD8ijO+/Hy+KY=; b=79iHPpLUxJGrEGzQ3yrJNMRbVFnwNG6vCY+Ne/rv30KSzJXfsUdsJloe6YGYDNC1CJ i1s275B+gU3y9kaCzCsZEcUmrdntxCjY0jTc2D6KjuRcV6MVy4ZPEg+TGU+AGYrc8e9l OUYT10U24zSgmubJ17t21LY10G7szc5e2MtxgSK6jVUADXGdZKnMhbeCwZ7gKpnw7qv9 YOI+dxbF7GJB3SlHzKGk53a9X1mnBjs0NVH0lCZijie6Z4PD/OMiGv0eRwCHuTwuh+Iz sH8k8GmYREwld5NztBt3SMuHbVbQsYEyfoIm1sPgMr962LlurzHtdkv8+fnaKLMFm0vx Ef0w== X-Gm-Message-State: AJIora9+BhP/xFfZX4JeYY/JHUSKDYNum6F+2QdJGtAU5Hv+b78LCbYJ wbEggA2TqTm5pSvMAWU7xHukK+UlqN1LKlpdXnKq23RWiJ1pqMqt8p1KH/swrQHt4xR8rKfQdkW PufqxtqK8gmwSXDYu5I9i4DaR X-Received: by 2002:a05:6e02:1c0d:b0:2da:8116:a568 with SMTP id l13-20020a056e021c0d00b002da8116a568mr20607899ilh.98.1657037737498; Tue, 05 Jul 2022 09:15:37 -0700 (PDT) X-Received: by 2002:a05:6e02:1c0d:b0:2da:8116:a568 with SMTP id l13-20020a056e021c0d00b002da8116a568mr20607880ilh.98.1657037737230; Tue, 05 Jul 2022 09:15:37 -0700 (PDT) Received: from redhat.com ([38.15.36.239]) by smtp.gmail.com with ESMTPSA id co14-20020a0566383e0e00b0033efe711a37sm224071jab.35.2022.07.05.09.15.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Jul 2022 09:15:36 -0700 (PDT) Date: Tue, 5 Jul 2022 10:15:35 -0600 From: Alex Williamson To: Bjorn Helgaas Cc: Cal Peake , Randy Dunlap , Kernel Mailing List , Bjorn Helgaas , Huacai Chen , linux-pci@vger.kernel.org, Cornelia Huck , kvm@vger.kernel.org Subject: Re: [PATCHv2] vgaarb: Add module param to allow for choosing the boot VGA device Message-ID: <20220705101535.569f5cac.alex.williamson@redhat.com> In-Reply-To: <20220704213829.GA16883@bhelgaas> References: <8498ea9f-2ba9-b5da-7dc4-1588363f1b62@absolutedigital.net> <20220704213829.GA16883@bhelgaas> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Jul 2022 16:38:29 -0500 Bjorn Helgaas wrote: > [+cc Alex, Cornelia, kvm] > > On Mon, Jul 04, 2022 at 05:12:44PM -0400, Cal Peake wrote: > > Add module parameter 'bootdev' to the VGA arbiter to allow the user > > to choose which PCI device should be selected over any others as the > > boot VGA device. > > > > When using a multi-GPU system with one or more GPUs being used in > > conjunction with VFIO for passthrough to a virtual machine, if the > > VGA arbiter settles on a passthrough GPU as the boot VGA device, > > once the VFIO PCI driver claims that GPU, all display output is lost > > and the result is blank screens and no VT access. > > I cc'd KVM folks in case they have anything to add here because I'm > not a VFIO passthrough expert. > > It sounds like the problem occurs when the VFIO driver claims the GPU. > I assume that happens after boot, when setting up for the virtual > machine? If so, is there a way to avoid the problem at run-time so > the admin doesn't have to decide at boot-time which GPU will be passed > through to a VM? Is it possible or desirable to pass through GPU A to > VM A, then after VM A exits, pass through GPU B to VM B? > > > Signed-off-by: Cal Peake > > --- > > .../admin-guide/kernel-parameters.txt | 7 ++++ > > drivers/pci/vgaarb.c | 40 +++++++++++++++++++ > > 2 files changed, 47 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > > index 2522b11e593f..21ac87f4a8a9 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -6518,6 +6518,13 @@ > > This is actually a boot loader parameter; the value is > > passed to the kernel using a special protocol. > > > > + vgaarb.bootdev= [PCI] Specify the PCI ID (e.g. 0e:00.0) of the > > + device to use as the boot VGA device, overriding > > + the heuristic used to normally determine which > > + of the eligible VGA devices to use. If the device > > + specified is not valid or not eligible, then we > > + fallback to the heuristic. > > + > > vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y. > > May slow down system boot speed, especially when > > enabled on systems with a large amount of memory. > > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c > > index f80b6ec88dc3..d3689b7dc63d 100644 > > --- a/drivers/pci/vgaarb.c > > +++ b/drivers/pci/vgaarb.c > > @@ -35,6 +35,34 @@ > > > > #include > > > > +static char *bootdev __initdata; > > +module_param(bootdev, charp, 0); > > +MODULE_PARM_DESC(bootdev, "Force boot device to the specified PCI ID"); > > + > > +/* > > + * Initialize to the last possible ID to have things work as normal > > + * when no 'bootdev' option is supplied. We especially do not want > > + * this to be zero (0) since that is a valid PCI ID (00:00.0). > > + */ > > +static u16 bootdev_id = 0xffff; > > + > > +static void __init parse_bootdev(char *input) > > +{ > > + unsigned int bus, dev, func; > > + int ret; > > + > > + if (input == NULL) > > + return; > > + > > + ret = sscanf(input, "%x:%x.%x", &bus, &dev, &func); > > + if (ret != 3) { > > + pr_warn("Improperly formatted PCI ID: %s\n", input); > > + return; > > + } See pci_dev_str_match() > > + > > + bootdev_id = PCI_DEVID(bus, PCI_DEVFN(dev, func)); > > +} > > + > > static void vga_arbiter_notify_clients(void); > > /* > > * We keep a list of all vga devices in the system to speed > > @@ -53,6 +81,7 @@ struct vga_device { > > bool bridge_has_one_vga; > > bool is_firmware_default; /* device selected by firmware */ > > unsigned int (*set_decode)(struct pci_dev *pdev, bool decode); > > + bool is_chosen_one; /* device specified on command line */ > > }; > > > > static LIST_HEAD(vga_list); > > @@ -605,6 +634,7 @@ static bool vga_is_boot_device(struct vga_device *vgadev) > > > > /* > > * We select the default VGA device in this order: > > + * User specified device (see module param bootdev=) > > * Firmware framebuffer (see vga_arb_select_default_device()) > > * Legacy VGA device (owns VGA_RSRC_LEGACY_MASK) > > * Non-legacy integrated device (see vga_arb_select_default_device()) > > @@ -612,6 +642,14 @@ static bool vga_is_boot_device(struct vga_device *vgadev) > > * Other device (see vga_arb_select_default_device()) > > */ > > > > + if (boot_vga && boot_vga->is_chosen_one) > > + return false; > > + > > + if (bootdev_id == PCI_DEVID(pdev->bus->number, pdev->devfn)) { > > + vgadev->is_chosen_one = true; > > + return true; > > + } This seems too simplistic, for example PCI code determines whether the ROM is a shadow ROM at 0xc0000 based on whether it's the vga_default_device() where that default device is set in vga_arbiter_add_pci_device() based on the value returned by this vga_is_boot_device() function. A user wishing to specify the boot VGA device doesn't magically make that device's ROM shadowed into this location. I also don't see how this actually enables VGA routing to the user selected device, where we generally expect the boot device already has this enabled. Furthermore, what's the initialization state of the selected device, if it has not had its option ROM executed, is it necessarily in a state to accept VGA commands? If we're changing the default VGA device, are we fully uncoupling from any firmware notions of the console device? Thanks, Alex > > + > > /* > > * We always prefer a firmware default device, so if we've already > > * found one, there's no need to consider vgadev. > > @@ -1544,6 +1582,8 @@ static int __init vga_arb_device_init(void) > > int rc; > > struct pci_dev *pdev; > > > > + parse_bootdev(bootdev); > > + > > rc = misc_register(&vga_arb_device); > > if (rc < 0) > > pr_err("error %d registering device\n", rc); > > -- > > 2.35.3 > > >