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.129.124]) by mx.groups.io with SMTP id smtpd.web08.6280.1653373490621283581 for ; Mon, 23 May 2022 23:24:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dq/c0Hdy; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653373489; 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=IV6RdL9lM/rVg7V7jRIaQszKh1BNRRiFyeuM0XFjXuU=; b=dq/c0HdyOzCsmS+2cjea1Dm0l2PZCuNkNM0DggbAx1ULFLe8xlYDdnH+xjjz4DnTDRXJwA 2zdOcHFe1P96hqjc6UyLh6jO7pieeM8AvuoRQ8oemCBlLBgcVb/Gqg+gAYN8dWqaz9Wx+a yHLQdZws0j4Nw7N9ax/B97Noqlwhl9U= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-97-62ZAxvURMMmFZfUwwEcVHQ-1; Tue, 24 May 2022 02:24:48 -0400 X-MC-Unique: 62ZAxvURMMmFZfUwwEcVHQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DA2401C0513C; Tue, 24 May 2022 06:24:47 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE03C40F9D41; Tue, 24 May 2022 06:24:47 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3895E1800393; Tue, 24 May 2022 08:24:46 +0200 (CEST) Date: Tue, 24 May 2022 08:24:46 +0200 From: "Gerd Hoffmann" To: "Albecki, Mateusz" Cc: devel@edk2.groups.io Subject: Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory Message-ID: <20220524062446.x4gpibum74zwi4zu@sirius.home.kraxel.org> References: <20220502104854.zq633gergmwlcs26@sirius.home.kraxel.org> <2650.1653306485291202681@groups.io> MIME-Version: 1.0 In-Reply-To: <2650.1653306485291202681@groups.io> X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 23, 2022 at 04:48:05AM -0700, Albecki, Mateusz wrote: > @Ni, Ray > > I think EDK2 needs to provide a way for root port to operate without IO space assigned in a platform-independent way. I can think of the following cases when root port didn't get IO space: > > 1. We have run out of IO space but it's fine since the device under the root port doesn't use IO or has only non-critical functionalities under IO > 2. We have run out of IO space and it's really not fine since device needs IO > 3. We are running on a CPU which doesn't support IO > > For 1. the question is whether the device driver in EDK2 understands that IO bar for that device is optional and will bother to check if it has been assigned and either fail gracefully or continue operation in limited capacity. For 2. the question is whether the driver will fail gracefully. 3 is for completeness at this point I think since the only other architecture that uses EDK2 is ARM which has to deal with it in some way right now which I think maps IO region into MMIO so in a way it supports IO. Well, the case I'm trying to handle here is qemu microvm. It's x86, but io address space support for pcie devices is not wired up. So the pcie host bridge doesn't support io, which is rather close to case (3). > I've checked the device driver behavior in EDK2 for devices which use IO bar here is the rundown: > 1. IDE - Doesn't check if IO has been assigned, not giving IO results in undefined behavior > 2. SerialIo -> Doesn't check, will assert the system when IO is not assigned (although the logic there is really strange as it can use 3 different access methods) > 3. UHCI -> Checks but too late, will most likely result in undefined behavior Current edk2 behavior is that the initialization of the pcie host bridge fails in case no io space is present (and all devices connected to it are not initialized either of course). With this patch applied pcie host bridge initialization works. PCIe devices without io bars are enumerated and initialized sucessfully. PCIe devices with io bar fail to initialize. That isn't much of a problem tough as a qemu microvm typically has no pcie devices with io bars. > Even with those bad device drivers I would agree that taking this > change presents low risk given that those devices are pretty old and > should be mostly unused on new systems(SerialIo being an exception but > that one is usually an RCIEP). Also note that for pcie root bridges which do support io address space this patch changes nothing. > That said I think we are missing a larger issue here - why are we > running out of IO when we have 16 root ports? I don't think so. I see the *linux kernel* hand out io address space to pcie root ports (until it runs out). edk2 doesn't. take care, Gerd