public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "David Woodhouse" <dwmw2@infradead.org>
To: Laszlo Ersek <lersek@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	jljusten@gmail.com, afish@apple.com, pbonzini@redhat.com
Subject: Re: [PATCH 2/2] LegacyBbs: add boot entries for virtio-blk devices
Date: Tue, 18 Jun 2019 10:13:12 +0100	[thread overview]
Message-ID: <9c9d53f5da9c3dec56cff0ff07c399e3034444a1.camel@infradead.org> (raw)
In-Reply-To: <1359147866-15605-3-git-send-email-lersek@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6327 bytes --]

On Fri, 2013-01-25 at 22:04 +0100, Laszlo Ersek wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>


Hm. This no longer works as-is because...

> ---
>  .../Csm/LegacyBiosDxe/LegacyBbs.c                  |  134 +++++++++++++++++++-
>  1 files changed, 133 insertions(+), 1 deletions(-)
> 
> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBbs.c b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBbs.c
> index 6ee43ad..964d7d2 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBbs.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBbs.c
> @@ -259,8 +259,140 @@ LegacyBiosBuildBbs (
>      }
>    }
>  
> -  return EFI_SUCCESS;
> +  //
> +  // add virtio-blk devices
> +  //
> +  {
> +    EFI_STATUS Status;
> +    UINTN      NumPciIoHandles;
> +    EFI_HANDLE *PciIoHandles;
> +
> +    BbsIndex = HddIndex * 2 + 1;
> +
> +    //
> +    // scan all handles supporting the PCI IO protocol
> +    //
> +    Status = gBS->LocateHandleBuffer (
> +                    ByProtocol,
> +                    &gEfiPciIoProtocolGuid,
> +                    NULL,
> +                    &NumPciIoHandles,
> +                    &PciIoHandles
> +                    );
> +
> +    if (Status == EFI_SUCCESS) {
> +      UINTN CurPciIo;
> +
> +      for (CurPciIo = 0; CurPciIo < NumPciIoHandles; ++CurPciIo) {
> +        EFI_OPEN_PROTOCOL_INFORMATION_ENTRY *References;
> +        UINTN                               NumReferences;
> +        UINTN                               CurRef;
> +
> +        //
> +        // on each handle supporting the PCI IO protocol, see which drivers
> +        // (agents) have a PCI IO protocol interface actually opened
> +        //
> +        Status = gBS->OpenProtocolInformation (
> +                        PciIoHandles[CurPciIo],
> +                        &gEfiPciIoProtocolGuid,
> +                        &References,
> +                        &NumReferences
> +                        );
> +        if (EFI_ERROR (Status)) {
> +          continue;
> +        }
> +
> +        for (CurRef = 0; CurRef < NumReferences; ++CurRef) {
> +          if (References[CurRef].Attributes & EFI_OPEN_PROTOCOL_BY_DRIVER) {
> +            EFI_COMPONENT_NAME2_PROTOCOL *ComponentName;
> +            CHAR16                       *DriverName;
> +
> +            //
> +            // OpenProtocol() enforced non-NULL AgentHandle for this case
> +            //
> +            ASSERT (References[CurRef].AgentHandle != NULL);
> +
> +            //
> +            // Check if the agent owning the open protocol interface can
> +            // provide its name, and if so, whether it's VirtioBlkDxe. For this
> +            // check we don't want a persistent reference to the agent's
> +            // EFI_COMPONENT_NAME2_PROTOCOL instance, therefore we use
> +            // HandleProtocol() instead of OpenProtocol().
> +            //
> +            Status = gBS->HandleProtocol (
> +                            References[CurRef].AgentHandle,
> +                            &gEfiComponentName2ProtocolGuid,
> +                            (VOID **) &ComponentName
> +                            );
> +            if (EFI_ERROR (Status)) {
> +              continue;
> +            }
> +
> +            Status = ComponentName->GetDriverName (
> +                                      ComponentName,
> +                                      "en",
> +                                      &DriverName
> +                                      );
>  
> +            if (Status == EFI_SUCCESS &&
> +                StrCmp (DriverName, L"Virtio Block Driver") == 0) {
> +              break;



... this would need to match on 'Virtio PCI Driver' instead. Obviously
that's a trivial fix but it raises the question of whether this is the
right thing to be matching on at all.

It also doesn't catch NVMe drives. 

Should we just be iterating over all block devices or something like
that instead?

> +            }
> +          }
> +        }
> +
> +        if (CurRef < NumReferences) {
> +          EFI_PCI_IO_PROTOCOL *PciIo;
> +          UINTN               Segment;
> +          UINTN               Bus;
> +          UINTN               Device;
> +          UINTN               Function;
> +
> +          //
> +          // reference by VirtioBlkDxe found, produce boot entry for device
> +          //
> +          Status = gBS->HandleProtocol (
> +                          PciIoHandles[CurPciIo],
> +                          &gEfiPciIoProtocolGuid,
> +                          (VOID **) &PciIo
> +                          );
> +          ASSERT (Status == EFI_SUCCESS);
> +
> +          Status = PciIo->GetLocation (
> +                            PciIo,
> +                            &Segment,
> +                            &Bus,
> +                            &Device,
> +                            &Function
> +                            );
> +          ASSERT (Status == EFI_SUCCESS);
> +
> +          if (Segment == 0) {
> +            BbsTable[BbsIndex].Bus                      = (UINT32) Bus;
> +            BbsTable[BbsIndex].Device                   = (UINT32) Device;
> +            BbsTable[BbsIndex].Function                 = (UINT32) Function;
> +            BbsTable[BbsIndex].Class                    = 1;
> +            BbsTable[BbsIndex].SubClass                 = 0x80;
> +            BbsTable[BbsIndex].StatusFlags.OldPosition  = 0;
> +            BbsTable[BbsIndex].StatusFlags.Reserved1    = 0;
> +            BbsTable[BbsIndex].StatusFlags.Enabled      = 0;
> +            BbsTable[BbsIndex].StatusFlags.Failed       = 0;
> +            BbsTable[BbsIndex].StatusFlags.MediaPresent = 0;
> +            BbsTable[BbsIndex].StatusFlags.Reserved2    = 0;
> +            BbsTable[BbsIndex].DeviceType               = BBS_HARDDISK;
> +            BbsTable[BbsIndex].BootPriority             = BBS_UNPRIORITIZED_ENTRY;
> +            ++BbsIndex;
> +          }
> +        }
> +
> +        FreePool (References);
> +      }
> +
> +      FreePool (PciIoHandles);
> +    }
> +  }
> +
> +  return EFI_SUCCESS;
>  }
>  
>  


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

       reply	other threads:[~2019-06-18  9:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1359122038.24865.19.camel@shinybook.infradead.org>
     [not found] ` <1359147866-15605-3-git-send-email-lersek@redhat.com>
2019-06-18  9:13   ` David Woodhouse [this message]
2019-06-19 12:44     ` [PATCH 1/2] LegacyBios: set NumberBbsEntries to the size of BbsTable David Woodhouse
2019-06-20 16:12       ` [edk2-devel] " Laszlo Ersek
2019-06-20 17:32         ` David Woodhouse
2019-06-20 20:35           ` Laszlo Ersek
2019-06-21 10:59             ` David Woodhouse
2019-06-24 22:08               ` Laszlo Ersek
2019-06-24 22:22                 ` Laszlo Ersek
     [not found]                   ` <F95F0A95-4638-4B08-BDAF-53A797A6B877@infradead.org>
2019-06-25  7:06                     ` Ni, Ray
2019-06-25 10:34                       ` Laszlo Ersek
2019-06-25  7:29                 ` David Woodhouse
2019-06-24 11:48             ` David Woodhouse
2019-06-24 21:49               ` Laszlo Ersek
2019-06-19 12:44     ` [PATCH 2/2] LegacyBbs: Add boot entries for VirtIO and NVME devices David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c9d53f5da9c3dec56cff0ff07c399e3034444a1.camel@infradead.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox