On 01/16/15 01:30, Leif Lindholm wrote: > On Thu, Jan 15, 2015 at 03:35:40PM -0800, James Bottomley wrote: >> The UEFI Security Sub team needs to do some prototyping across all >> supported architectures. We've been having some discussions about how a >> particular feature would work on different architectures and have >> decided that prototyping it with edk2 would help ... unfortunately none >> of us has any ARM systems (and anyway, virtual images are so much easier >> to handle for those of us on the move). I've heard that you two may >> have some experimental patches to make Ovmf work on ARM, so I was >> wondering if you could share them? I'm also going to have to run them >> under qemu-arm on an x86 system, so any information you could share >> about doing that (does it actually work) would be helpful. > > Patches, no. Well, I have some for making use of the IntelBds on ARM > more straigtforward. > > Ovmf, no (lacking PCI emulation, and although Laszlo looks to be > working hard to de-x86 Ovmf, I believe there are still some > arch/platform-specific bits in there).
The working idea I have about OvmfPkg and ArmPlatformPkg/ArmVirtualizationPkg is the following: - OvmfPkg is a standalone, complete package for qemu-system-x86_64 (which more or less covers Xen too, not just qemu and/or KVM). "Standalone" obviously means that it includes stuff from all over the edk2 tree :), but only from packages that are meant to be reused, per design. OvmfPkg includes arch-independent stuff and arch-dependent stuff. These are usually nicely separated already (different libraries, different drivers etc), but some of the arch-independent stuff needs to be factored out / modularized some more. This is progressing as new client code / new use cases emerge in ArmPlatformPkg/ArmVirtualizationPkg. - ArmPlatformPkg/ArmVirtualizationPkg (in particular the ArmVirtualizationQemu.dsc edk2 platform) fills the same role for qemu-system-aarch64 / qemu-system-arm. It similarly includes a bunch of modules from all over the tree, but it's a bit more liberal than OvmfPkg: it pulls in more "embedded" related stuff, and of course it pulls in modules from OvmfPkg too. (Which counts as "internal" for OvmfPkg but as "external" for ArmPlatformPkg/ArmVirtualizationPkg.) IOW I'm following a "pull" model from the ARM side: factor out & scavenge what's needed & possible from OVMF, without regressing OVMF. Search "ArmVirtualizationQemu.dsc" for mentions of "OvmfPkg". So, "OVMF on ARM" doesn't exist. "OVMF on x86" exists; so does "ArmVirtualizationQemu on ARM". (I like to shorten ArmVirtualizationQemu as "AAVMF".) They share code. PCI emulation for ArmPlatformPkg/ArmVirtualizationPkg should take a new PCI root bridge IO driver (the rest of the protocols like PciIo are mostly hw-independent). I think it should live under ArmPlatformPkg/ArmVirtualizationPkg. > But ArmVirtualizationQemu will probably give you what you want (and > is upstream). Agreed. > I can write some proper instructions up and send out tomorrow, with a > tag and some prebuilt images to go with it. > > It is worth keeping in mind though that qemu does not emulate Security > Extensions or Virtualization Extensions, so there may be limitations > to what you can test with it. I think at least some of the security extensions have been implemented by Ard. See "target-arm/crypto_helper.c". > (Oh, and I've tried to respond to Mantis 1225 on the usst list, but my > email there bounces.) I skimmed that ticket now; my brain is mush, sorry. (Uptime: 16:32.) Thanks, Laszlo ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
