From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory To: Gerd Hoffmann ,devel@edk2.groups.io From: "Albecki, Mateusz" X-Originating-Location: Munich, Bavaria, DE (134.191.220.85) X-Originating-Platform: Windows Chrome 101 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 23 May 2022 04:48:05 -0700 References: <20220502104854.zq633gergmwlcs26@sirius.home.kraxel.org> In-Reply-To: <20220502104854.zq633gergmwlcs26@sirius.home.kraxel.org> Message-ID: <2650.1653306485291202681@groups.io> Content-Type: multipart/alternative; boundary="C0201rNOt8ZKzsFgCp45" --C0201rNOt8ZKzsFgCp45 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable @Ni, Ray I think EDK2 needs to provide a way for root port to operate without IO spa= ce assigned in a platform-independent way. I can think of the following cas= es 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 roo= t 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 I= O bar for that device is optional and will bother to check if it has been a= ssigned and either fail gracefully or continue operation in limited capacit= y. 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 th= ink maps IO region into MMIO so in a way it supports IO. I've checked the device driver behavior in EDK2 for devices which use IO ba= r here is the rundown: 1. IDE - Doesn't check if IO has been assigned, not giving IO results in un= defined behavior 2. SerialIo -> Doesn't check, will assert the system when IO is not assigne= d (although the logic there is really strange as it can use 3 different acc= ess methods) 3. UHCI -> Checks but too late, will most likely result in undefined behavi= or Even with those bad device drivers I would agree that taking this change pr= esents low risk given that those devices are pretty old and should be mostl= y unused on new systems(SerialIo being an exception but that one is usually= an RCIEP). That said I think we are missing a larger issue here - why are = we running out of IO when we have 16 root ports? Surely we don't have a dev= ice with IO requirement behind each of those root ports so is the BIOS blin= dly assigning IO to root ports which have no requirement? I see on my syste= m that when we don't have IO requirement behind the root port BIOS sets IOB= ASE to 0xF0 and IOLIMIT to 0x0 which means no IO decode will be performed. Thanks, Mateusz --C0201rNOt8ZKzsFgCp45 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable @Ni, Ray

I think EDK2 needs to provide a way for root port to op= erate 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 por= t 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<= br />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 f= or 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 comple= teness at this point I think since the only other architecture that uses ED= K2 is ARM which has to deal with it in some way right now which I think map= s IO region into MMIO so in a way it supports IO.

I've checked t= he 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 a= ssert the system when IO is not assigned (although the logic there is reall= y strange as it can use 3 different access methods)
3. UHCI -> Chec= ks but too late, will most likely result in undefined behavior

E= ven with those bad device drivers I would agree that taking this change pre= sents 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). That said I think we are missing a larger issue here - why are w= e running out of IO when we have 16 root ports? Surely we don't have a devi= ce with IO requirement behind each of those root ports so is the BIOS blind= ly assigning IO to root ports which have no requirement? I see on my system= that when we don't have IO requirement behind the root port BIOS sets IOBA= SE to 0xF0 and IOLIMIT to 0x0 which means no IO decode will be performed.
Thanks,
Mateusz --C0201rNOt8ZKzsFgCp45--