From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web11.6871.1626546862692095355 for ; Sat, 17 Jul 2021 11:34:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=HIGkQ6op; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 16HITFGa037692; Sat, 17 Jul 2021 11:34:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=e8KX+zN4ZyZgB1dtNB/d2R7wOChMTRKJ1QVTRUkqO6g=; b=HIGkQ6opDZAldisI2BiI7WVgqPD1NU8WZoVXrva5+lddqgzq0bKvwkgZatIfr3vpBbZ5 4VX4z8vUED6XuCqWgM1Up8wBxVZm6L+bEALVaKts25jAQJmfHHvZdanqeuJa9ZrrirqF ug90SN4imDxiz3Iou0Y+DLVl1n3wfeaehBdKRS2QvIyy1damXj0Ld/VCXsANx4zC34Ex lhmf2aT35sYpD5GvUsGbLto+0MDfbuPjxUgimgAYZPtf20osQ30li/hy3VZUYAJR8G6Q EHXNRSTt/h2W0kCrK9KocrCeZKsRMC9yyqq///djVKis4X0y3BPowqiLx2vcrCySs++L vw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 39ux6ud0u0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 17 Jul 2021 11:34:21 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QWE00C3OJL89000@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 17 Jul 2021 11:34:20 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QWE00S00J7DE400@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Jul 2021 11:34:20 -0700 (PDT) X-Va-A: X-Va-T-CD: 7b14d6a7a32af921a367ac8b06702e34 X-Va-E-CD: 086b2cc192df006f59d7facad959a6fe X-Va-R-CD: a7a5a53aae481dccc3f624a5487f0eef X-Va-CD: 0 X-Va-ID: 3d6a645f-c4ab-41ab-b506-987752664c6b X-V-A: X-V-T-CD: 7b14d6a7a32af921a367ac8b06702e34 X-V-E-CD: 086b2cc192df006f59d7facad959a6fe X-V-R-CD: a7a5a53aae481dccc3f624a5487f0eef X-V-CD: 0 X-V-ID: e1499a3c-09d5-4200-be2a-772b76766090 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-17_07:2021-07-16,2021-07-17 signatures=0 Received: from [17.235.34.166] (unknown [17.235.34.166]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QWE00Y62JL69G00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Jul 2021 11:34:20 -0700 (PDT) From: "Andrew Fish" Message-id: <200C48C1-A7E4-4076-9042-CB62EE3F997A@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER Date: Sat, 17 Jul 2021 11:34:18 -0700 In-reply-to: Cc: "Leif Lindholm (Nuvia address)" , Ray Ni To: edk2-devel-groups-io , harlydavidsen@gmail.com References: <88AE4AB4-12BA-433C-9EA4-EDC01B30DAD1@apple.com> <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-17_07:2021-07-16,2021-07-17 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_62D8F766-DF93-4D3D-8B15-0B3EF68F46B6" --Apple-Mail=_62D8F766-DF93-4D3D-8B15-0B3EF68F46B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I `OvmfPkg/builds.sh qemu -usb -device usb-audio -device qemu-xhci` I se= e 2 USB handle? When you open EXCLUSIVE you are kicking other people off the handles. I=E2= = =80=99m not sure that is a good idea for you to do that to every USB handl= e in the system. If there was a handle that represented a USB to USB bridge= seems like you could kick all the children off=E2=80=A6. So when you are probing try using GET_PROTOCOL, and only use EXCLUSIVE aft= er you find the device you want to manage.=20 Thanks, Andrew Fish > On Jul 17, 2021, at 11:10 AM, Ethin Probst wro= te: >=20 > Thanks, Andrew. So it appears as though only a single handle exists > ("AF: DevicePath(..)/Pci(0x1D,0x0)/USB(0x0,0x0)) USBIO") but my app is > getting two handles, one of which doesn't actually exist. I still am > unsure why though. Getting verbose info about handle AF yields an > interface with class 0x01, subclass 0x01, and protocol 0x04, so this > appears to match the USB audio control interface. However, no audio > streaming device is available, as I would expect. Attempting to set > the interface to `1` also fails on the UAC device (though the USB > specification does note that this is not necessarily an error and may > just indicate that that interface setting is not supported so my app > currently just continues on regardless). I am running with qemu args > `-usb -device usb-audio,... -audiodev ...`. I've tried with `-device > qemu-xhci ...` but I get the same result. >=20 > On 7/17/21, Andrew Fish > wrote= : >>=20 >>=20 >>> On Jul 17, 2021, at 10:06 AM, Ethin Probst >>> wrote: >>>=20 >>> Okay, so I just tried dh -v 7EDE4C18 (that was the handle that I'm >>> getting from `HandleBuffer()`) and it says "dh: Handle - '7EDE4C18' >>> not found". So I'm definitely confused because that's what >>> `HandleBuffer()` is getting me. Should I pre-allocate the buffer? >>>=20 >>=20 >> Ethin, >>=20 >> The UEFI Shell `dh` command UI uses handle numbers from 0 - N as hex >> digits. You have use these abstract values with the `dh` command. For >> example: use `dh -v A1` to see the actual handle value for A1 (7EBA959= 8). >> You can search handles that contain a specific protocol... >>=20 >> Shell> dh -p PciIo >> Handle dump by protocol 'PCIIO' >> A1: PCIIO DevicePath(PciRoot(0x0)/Pci(0x0,0x0)) >> A2: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1,0x0)) >> A3: PCIIO DevicePath(PciRoot(0x0)/Pci(0x2,0x0)) >> A4: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x0,0x0)) >> A5: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0)) >> A6: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x2,0x0)) >> A7: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x3,0x0)) >> A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x4,0x0)) >> A9: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x5,0x0)) >> AA: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1E,0x0)) >> AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO >> DevicePath(..)/Pci(0x1E,0x0)/Pci(0x0,0x0)) >> AC: ISAACPI PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x0)) >> AD: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x3)) >> Shell> dh -v A1 >> A1: 7EBA9598 >> PCIIO(7EBA8AA8) >> Segment #.....: 00 >> Bus #.........: 00 >> Device #......: 00 >> Function #....: 00 >> ROM Size......: 0 >> ROM Location..: 00000000 >> Vendor ID.....: 8086 >> Device ID.....: 29C0 >> Class Code....: 00 00 06 >> Configuration Header : >> 8680C029070000000000000600000000 >> 00000000000000000000000000000000 >> 000000000000000000000000F41A0011 >> 000000000000000000000000FF000000 >> DevicePath(7EBA9E18) >> PciRoot(0x0)/Pci(0x0,0x0) >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> On 7/17/21, Ethin Probst wrote: >>>> I mean, possible... The code I'm using to initialize the handle buffe= r >>>> is >>>> this: >>>>=20 >>>> ```C >>>> EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN >>>> EFI_SYSTEM_TABLE* >>>> st) { >>>> Print(L"Attempting to find USB IO protocol\n"); >>>> UINTN numHandles =3D 0; >>>> UINTN i =3D 0; >>>> UINT32 UsbStatus =3D 0; >>>> EFI_HANDLE* handles =3D NULL; >>>> EFI_USB_IO_PROTOCOL* UsbIo =3D NULL; >>>> EFI_STATUS status =3D st->BootServices->LocateHandleBuffer(ByProtocol= , >>>> &gEfiUsbIoProtocolGuid, NULL, &numHandles, &handles); >>>> if (EFI_ERROR(status)) { >>>> Print(L"Cannot find any handles for USB devices, reason: %r\n", >>>> status); >>>> return EFI_ABORTED; >>>> } >>>> Print(L"Found %d USB devices; enumerating\n", numHandles); >>>> for (; i < numHandles; ++i) { >>>> Print(L"Trying to open handle %d (%x)... ", i, handles[i]); >>>> status =3D st->BootServices->OpenProtocol(handles[i], >>>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>>> if (EFI_ERROR(status)) { >>>> Print(L"%r, skipping\n", status); >>>> continue; >>>> } >>>> // ... >>>> ``` >>>> I've done my best to follow SEI secure C coding standards, like >>>> initializing all variables, regardless of type -- e.g. initializing >>>> pointers to 0/NULL. But I will definitely try that idea. >>>>=20 >>>> On 7/17/21, Andrew Fish wrote: >>>>>=20 >>>>>=20 >>>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst >>>>>> wrote: >>>>>>=20 >>>>>> Hey all, >>>>>>=20 >>>>>> So my UsbAudio.efi app has hit a bit of a roadblock. This code: >>>>>>=20 >>>>>> ```C >>>>>> status =3D st->BootServices->OpenProtocol(handles[i], >>>>>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>>>>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>>>>> if (EFI_ERROR(status)) { >>>>>> Print(L"%r, skipping\n", status); >>>>>> continue; >>>>>> } >>>>>> ``` >>>>>=20 >>>>> How are you constructing handle[]? Could it have gotten stale? You >>>>> could >>>>> print out the value of handle[I] on the failure. >>>>>=20 >>>>> The contents of a handle are not defined, but the current >>>>> implementation >>>>> is >>>>> a pointer to an IHANDLE internal data structure in the DXE Core. If = you >>>>> are >>>>> at the UEFI Shell and you `dh -v it will show the >>>>> >>>>> and the value. >>>>>=20 >>>>> Shell> dh -v 98 >>>>> 98: 6d5CF18 >>>>> =E2=80=A6. >>>>>=20 >>>>> I think you can `dh -p UsbIo=E2=80=99 to get the list of the UsbIo h= andles. >>>>>=20 >>>>> So you can poke around and see what is happening on that handle. >>>>>=20 >>>>> I guess the handle[] array could be getting corrupted? So you could >>>>> check >>>>> for that? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Andrew Fish >>>>>=20 >>>>>> Is giving me EFI_INVALID_PARAMETER and I don=E2=80=99t know why. I = don't think >>>>>> I'm violating any of its constraints, according to the specificatio= n, >>>>>> and I haven't touched this code since it was written. It also happe= ns >>>>>> irregularly: sometimes it happens on the USB audio streaming device= , >>>>>> or if I have a device plugged in it might happen on that device, yo= u >>>>>> get the idea. But it doesn't consistently fail. Does anybody have a= ny >>>>>> idea what's going on? >>>>>>=20 >>>>>> -- >>>>>> Signed, >>>>>> Ethin D. Probst >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>>=20 >>>=20 >>>=20 >>> -- >>> Signed, >>> Ethin D. Probst >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst >=20 >=20 >=20 --Apple-Mail=_62D8F766-DF93-4D3D-8B15-0B3EF68F46B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If I `OvmfPkg/builds.sh q= emu -usb -device usb-audio -device qemu-xhci` I see 2 USB handle?

When you open EXCLUSIVE you are= kicking other people off the handles. I=E2=80=99m not sure that is a good = idea for you to do that to every USB handle in the system. If there was a h= andle that represented a USB to USB bridge seems like you could kick all th= e children off=E2=80=A6.

So when you are probing try using GET_PROTOCOL, and only use EXCLUS= IVE after you find the device you want to manage. 

Thanks,

Andrew Fish

On Jul 17, 2021, at 1= 1:10 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:

T= hanks, Andrew. So it appears as though only a single handle exists("AF: DevicePath(..)/Pci(0x1D,0= x0)/USB(0x0,0x0)) USBIO") but my app is
getting two handles, one of which doesn't actually exist. = I still am
unsure why t= hough. Getting verbose info about handle AF yields an
interface with class 0x01, subclass 0x01, an= d protocol 0x04, so this
appears to match the USB audio control interface. However, no audio
streaming device is availabl= e, as I would expect. Attempting to set
the interface to `1` also fails on the UAC device (though = the USB
specification d= oes note that this is not necessarily an error and may
just indicate that that interface setting i= s not supported so my app
currently just continues on regardless). I am running with qemu args
`-usb -device usb-audio,..= . -audiodev ...`. I've tried with `-device
qemu-xhci ...` but I get the same result.

On 7/17/21, Andrew Fish <afish@apple.com>= ; wrote:
<= br class=3D"">
On Jul 17= , 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Okay, so I just tried dh -v 7EDE4C18 (that was the = handle that I'm
getting from `HandleBuffer()`) and it says "d= h: Handle - '7EDE4C18'
not found". So I'm definitely confused= because that's what
`HandleBuffer()` is getting me. Should I= pre-allocate the buffer?


Ethin,

The UEFI Shell `dh` command &nb= sp;UI uses handle numbers from 0 - N as hex
digits. You have = use these abstract values with the `dh` command. For
example:=  use `dh -v A1` to see the actual handle value for A1 (7EBA9598).
You can search handles that contain a specific protocol...

Shell> dh -p PciIo
Handle dump by = protocol 'PCIIO'
A1: PCIIO DevicePath(PciRoot(0x0)/Pci(0x0,0x= 0))
A2: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1,0x0))
A3: PCIIO DevicePath(PciRoot(0x0)/Pci(0x2,0x0))
A4: PC= IIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x0,0x0))
A5: PCIIO Devi= cePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0))
A6: PCIIO DevicePath(.= .0)/Pci(0x2,0x0)/Pci(0x2,0x0))
A7: PCIIO DevicePath(..0)/Pci(= 0x2,0x0)/Pci(0x3,0x0))
A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)= /Pci(0x4,0x0))
A9: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x5= ,0x0))
AA: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1E,0x0))
AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO
DevicePath(..)/Pci(0x1E,0x0)/Pci(0x0,0x0))
AC: ISAA= CPI PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x0))
AD: PCIIO De= vicePath(PciRoot(0x0)/Pci(0x1F,0x3))
Shell> dh -v A1
A1: 7EBA9598
PCIIO(7EBA8AA8)
 Seg= ment #.....: 00
 Bus #.........: 00
 = Device #......: 00
 Function #....: 00
&nb= sp;ROM Size......: 0
 ROM Location..: 00000000
 Vendor ID.....: 8086
 Device ID.....: 29C0<= br class=3D""> Class Code....: 00 00 06
 Configurat= ion Header :
      8680C0290700= 00000000000600000000
      0000= 0000000000000000000000000000
     &n= bsp;000000000000000000000000F41A0011
    =   000000000000000000000000FF000000
DevicePath(7EBA9= E18)
 PciRoot(0x0)/Pci(0x0,0x0)

Thanks,

Andrew Fish

On 7/17/21, Ethin Probst <= ;harlydavidsen@gmail.= com> wrote:
I mea= n, possible... The code I'm using to initialize the handle buffer
is
this:

```C
EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN
E= FI_SYSTEM_TABLE*
st) {
Print(L"Attempting to fi= nd USB IO protocol\n");
UINTN numHandles =3D 0;
UINTN i =3D 0;
UINT32 UsbStatus =3D 0;
EFI_HAN= DLE* handles =3D NULL;
EFI_USB_IO_PROTOCOL* UsbIo =3D NULL;EFI_STATUS status =3D st->BootServices->LocateHandleBuff= er(ByProtocol,
&gEfiUsbIoProtocolGuid, NULL, &numHand= les, &handles);
if (EFI_ERROR(status)) {
&n= bsp; Print(L"Cannot find any handles for USB devices, reason: %r\n",status);
  return EFI_ABORTED;
}
Print(L"Found %d USB devices; enumerating\n", numHan= dles);
for (; i < numHandles; ++i) {
 &= nbsp;Print(L"Trying to open handle %d (%x)... ", i, handles[i]);
  status =3D st->BootServices->OpenProtocol(handles[= i],
&gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHand= le, NULL,
EFI_OPEN_PROTOCOL_EXCLUSIVE);
 &= nbsp;if (EFI_ERROR(status)) {
    Print(L= "%r, skipping\n", status);
    continue;<= br class=3D"">  }
  // ...
= ```
I've done my best to follow SEI secure C coding standards= , like
initializing all variables, regardless of type -- e.g.= initializing
pointers to 0/NULL. But I will definitely try t= hat idea.

On 7/17/21, Andrew Fish <afish@apple.com> wrote:


On Jul 17, 2021, at 9:41 AM, Ethin P= robst <harlydavids= en@gmail.com>
wrote:

Hey = all,

So my UsbAudio.efi app has hit a bit of a= roadblock. This code:

```C
&nbs= p;status =3D st->BootServices->OpenProtocol(handles[i],
&gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL,
EFI_OPEN_PROTOCOL_EXCLUSIVE);
 if (EFI_ERROR(stat= us)) {
   Print(L"%r, skipping\n", status);   continue;
 }
```

How are you constructing han= dle[]? Could it have gotten stale? You
could
pr= int out the value of handle[I] on the failure.

The contents of a handle are not defined, but the current
im= plementation
is
a pointer to an IHANDLE interna= l data structure in the DXE Core. If you
are
at= the UEFI Shell and you `dh -v <handleNum> it will show the
<handleNum>
and the value.

Shell> dh -v 98
98: 6d5CF18
=E2=80= =A6.

I think you can `dh -p UsbIo=E2=80=99 to= get the list of the UsbIo handles.

So you can= poke around and see what is happening on that handle.

I guess the handle[] array could be getting corrupted? So you coul= d
check
for that?

= Thanks,

Andrew Fish

Is giving me EFI_INVALID_PARAMETER = and I don=E2=80=99t know why. I don't think
I'm violating any= of its constraints, according to the specification,
and I ha= ven't touched this code since it was written. It also happens
irregularly: sometimes it happens on the USB audio streaming device,
or if I have a device plugged in it might happen on that device, y= ou
get the idea. But it doesn't consistently fail. Does anybo= dy have any
idea what's going on?

--
Signed,
Ethin D. Probst




--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst








<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">-- 
Signed,
Ethin D. Probs= t



--Apple-Mail=_62D8F766-DF93-4D3D-8B15-0B3EF68F46B6--