Current UEFI image size which is built for Gauss is 760KB and I don't think it will be exceed 2MB even more features included in the UEFI for Laplace.
So I assume that the UEFI image can be stored in the SPI and loaded by SCP upon request of Atlas BL1.
That's the only option for the UEFI storage.
Is there anything I missed?
Thank you
Derek Son
---원본 메시지---
발신인 : [email protected]
발신일자 : 2013/11/09 10:02 (GMT+09:00)
제목 : edk2-devel Digest, Vol 47, Issue 23
Send edk2-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/edk2-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of edk2-devel digest..."
Today's Topics:
1. Re: [PATCH v4 00/11] OvmfPkg: Introduce and use the new
VIRTIO_DEVICE_PROTOCOL protocol (Jordan Justen)
2. Re: [Xen-devel] [PATCH] OvmfPkg/PlatformPei: allow platform
to specify start of PCI MMIO region (Wei Liu)
3. Re: [PATCH v2 00/10] OVMF support for QEMU's PC System Flash
(Jordan Justen)
4. Re: [PATCH v2 00/10] OVMF support for QEMU's PC System Flash
(Andrew Fish)
5. Re: [PATCH v2 00/10] OVMF support for QEMU's PC System Flash
(Jordan Justen)
6. Re: [PATCH v2 00/10] OVMF support for QEMU's PC System Flash
(Laszlo Ersek)
----------------------------------------------------------------------
Message: 1
Date: Fri, 8 Nov 2013 10:48:01 -0800
From: Jordan Justen <[email protected]>
Subject: Re: [edk2] [PATCH v4 00/11] OvmfPkg: Introduce and use the
new VIRTIO_DEVICE_PROTOCOL protocol
To: Laszlo Ersek <[email protected]>
Cc: "[email protected]"
<[email protected]>, Olivier Martin
<[email protected]>
Message-ID:
<CAFe8ug-=5duJFb=D=egr94yhjxssffq+jropbfmq08afvnc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 30, 2013 at 5:51 PM, Laszlo Ersek <[email protected]> wrote:
> On 10/31/13 00:26, Jordan Justen wrote:
>
>>> Jordan, could you please explain the problem again?
>>
>> This protocol interface doesn't seem to follow the conventions of the
>> other io protocols. In addition, the alignment issue seems unresolved
>> to me.
>>
>> I just don't want any code outside of EDK II to pick this interface
>> up, and become dependent on it.
>>
>> Changing the width to be enum based, and omitting 64-bit accesses
>> seems to resolve my immediate concerns.
>
> I think that changing the width to be enum based would eliminate a
> safety feature of the (device specific) VIRTIO_CFG_READ() macros -- we
> could no longer check if the size of the pointer target, and the size of
> the device-specific field, are equal. The driver writer would have to
> specify the field width (the enum) each time. I think that's more
> brittle than what we have now.
It seems like a matter of preference. I'm not a huge fan of the enum
width in PciIo/CpuIo, but I'd rather just do things the 'UEFI way' for
consistency.
>> I would also accept adding a disclaimer comment in the protocol file, such as:
>> "This protocol is a work in progress, and should not be used outside
>> of the EDK II tree."
>> Unfortunately, I think it would be all to easy to miss such a disclaimer.
>
> This is positively how I've approached the new protocol. In my eyes it's
> nothing to standardize or advertise or whatever. It's only a protocol
> because that's how we implement virtual functions (a structure of
> function pointers) in UEFI, while remaining compatible with the driver
> model (automatic discovery etc). That's all.
>
> The protocol serves our direct needs. We have two implementations, and
> three clients. I don't believe in early generalization.
It seems like there is a fair amount of interest in virtio. Can we at
least make it clear that this protocol interface is only half-baked,
and therefore should not be widely relied upon?
By the way, I'm also not sure about the virtio protocol being required
at all here. Can't we also argue that the fundamental issue is that
UEFI doesn't have a suitable IO protocol layer for non-PCI devices?
(Which brings us, unfortunately, back to the UEFI spec...)
Tangentially, the deprecated (?) MdePkg/Include/Protocol/DeviceIo.h
confuses me. Did it make pci-cfg optional? Why was it deprecated? I'm
thinking Andrew or Mike could give me a history lesson here. :)
-Jordan
------------------------------
Message: 2
Date: Fri, 8 Nov 2013 18:51:02 +0000
From: Wei Liu <[email protected]>
Subject: Re: [edk2] [Xen-devel] [PATCH] OvmfPkg/PlatformPei: allow
platform to specify start of PCI MMIO region
To: Konrad Rzeszutek Wilk <[email protected]>
Cc: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Fri, Nov 08, 2013 at 01:25:34PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 08, 2013 at 05:49:39PM +0000, Wei Liu wrote:
> > The original code calculates the start of PCI MMIO region automatically,
> > which is not desirable when running under Xen, as Xen is responsible of
> > setting up respective regions.
>
> What if Xen (hvmloader) also moves the MMIO to a different place and
> size? (Basically make e820_host option work with HVM)?
>
Good point. We probably need to find a way to retrieve the actual
information during runtime.
Wei.
------------------------------
Message: 3
Date: Fri, 8 Nov 2013 11:10:49 -0800
From: Jordan Justen <[email protected]>
Subject: Re: [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System
Flash
To: Laszlo Ersek <[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID:
<cafe8ug-vyayar4ebjx1910bpho30gxstocswu28aamae-cd...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek <[email protected]> wrote:
> On 11/08/13 19:04, Jordan Justen wrote:
>> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek <[email protected]> wrote:
>>> I also wanted to test secure boot (see if the enrolled keys survive a
>>> cold reboot), but I noticed that this series doesn't disable the "load
>>> variables from the NvVars file" functionality.
>>>
>>> I added the attached patch on top of this series, and this way the
>>> enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my
>>> SVM host with it, even after a full VM shutdown. Do you think the patch
>>> has merit?
>>
>> I want to consider keeping this (NvVars loading) functionality.
>>
>> The reason being is that it was pointed out that some people like to
>> distribute QEMU disk images pre-loaded with an OS. Therefore, this
>> might be the only way that those disk images could also set the boot
>> variables to point at the boot loader.
>>
>> I'm not sure this is the best idea though, so feel free to discuss
>> further. An alternative idea would be for those disk images to simply
>> supply \EFI\BOOT\BOOTXXXX.efi loaders though which we could try to
>> load in the absence of boot vars.
>
> I realize that allowing Boot#### and BootOrder settings "in downloads"
> is useful. I think the \EFI\BOOT\BOOTXXXX.efi way won't work though,
> because these disk images are usually presented as fixed disks (not
> removable media), and IIRC UEFI only auto-loads these paths on removable
> media.
Looks like in the UEFI 2.3 spec, these paths are specifically allowed
as fall-back boot paths.
See "3.4.1.2 Non-removable Media Boot Behavior"
-Jordan
------------------------------
Message: 4
Date: Fri, 08 Nov 2013 11:23:17 -0800
From: Andrew Fish <[email protected]>
Subject: Re: [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System
Flash
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On Nov 8, 2013, at 11:10 AM, Jordan Justen <[email protected]> wrote:
> On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek <[email protected]> wrote:
>> On 11/08/13 19:04, Jordan Justen wrote:
>>> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek <[email protected]> wrote:
>>>> I also wanted to test secure boot (see if the enrolled keys survive a
>>>> cold reboot), but I noticed that this series doesn't disable the "load
>>>> variables from the NvVars file" functionality.
>>>>
>>>> I added the attached patch on top of this series, and this way the
>>>> enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my
>>>> SVM host with it, even after a full VM shutdown. Do you think the patch
>>>> has merit?
>>>
>>> I want to consider keeping this (NvVars loading) functionality.
>>>
>>> The reason being is that it was pointed out that some people like to
>>> distribute QEMU disk images pre-loaded with an OS. Therefore, this
>>> might be the only way that those disk images could also set the boot
>>> variables to point at the boot loader.
>>>
>>> I'm not sure this is the best idea though, so feel free to discuss
>>> further. An alternative idea would be for those disk images to simply
>>> supply \EFI\BOOT\BOOTXXXX.efi loaders though which we could try to
>>> load in the absence of boot vars.
>>
>> I realize that allowing Boot#### and BootOrder settings "in downloads"
>> is useful. I think the \EFI\BOOT\BOOTXXXX.efi way won't work though,
>> because these disk images are usually presented as fixed disks (not
>> removable media), and IIRC UEFI only auto-loads these paths on removable
>> media.
>
> Looks like in the UEFI 2.3 spec, these paths are specifically allowed
> as fall-back boot paths.
> See "3.4.1.2 Non-removable Media Boot Behavior?
>
So technically Platform Policy can do just about anything it wants after all the variables fail. So something like a Platform Design Guide for example can call out requirements on default behavior.
But the question I will ask is why do we need to do something custom? Is your case any different than walking up to machine with a driver that has been pre-imaged? How would that get solved on a real system? Is it automating the solution your are after? In that case falling back to the removable media case seems like a reasonable solution, if no other solution exists.
Thanks
Andrew Fish
> -Jordan
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------
Message: 5
Date: Fri, 8 Nov 2013 11:34:40 -0800
From: Jordan Justen <[email protected]>
Subject: Re: [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System
Flash
To: "[email protected]"
<[email protected]>
Message-ID:
<cafe8ug91gpggc3rqdzyct7jdpfxhdvc2iw1qz+eggqy4gx7...@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
On Fri, Nov 8, 2013 at 11:23 AM, Andrew Fish <[email protected]> wrote:
>
> On Nov 8, 2013, at 11:10 AM, Jordan Justen <[email protected]> wrote:
>
>> On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek <[email protected]> wrote:
>>> On 11/08/13 19:04, Jordan Justen wrote:
>>>> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek <[email protected]> wrote:
>>>>> I also wanted to test secure boot (see if the enrolled keys survive a
>>>>> cold reboot), but I noticed that this series doesn't disable the "load
>>>>> variables from the NvVars file" functionality.
>>>>>
>>>>> I added the attached patch on top of this series, and this way the
>>>>> enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my
>>>>> SVM host with it, even after a full VM shutdown. Do you think the patch
>>>>> has merit?
>>>>
>>>> I want to consider keeping this (NvVars loading) functionality.
>>>>
>>>> The reason being is that it was pointed out that some people like to
>>>> distribute QEMU disk images pre-loaded with an OS. Therefore, this
>>>> might be the only way that those disk images could also set the boot
>>>> variables to point at the boot loader.
>>>>
>>>> I'm not sure this is the best idea though, so feel free to discuss
>>>> further. An alternative idea would be for those disk images to simply
>>>> supply \EFI\BOOT\BOOTXXXX.efi loaders though which we could try to
>>>> load in the absence of boot vars.
>>>
>>> I realize that allowing Boot#### and BootOrder settings "in downloads"
>>> is useful. I think the \EFI\BOOT\BOOTXXXX.efi way won't work though,
>>> because these disk images are usually presented as fixed disks (not
>>> removable media), and IIRC UEFI only auto-loads these paths on removable
>>> media.
>>
>> Looks like in the UEFI 2.3 spec, these paths are specifically allowed
>> as fall-back boot paths.
>> See "3.4.1.2 Non-removable Media Boot Behavior?
>
> But the question I will ask is why do we need to do something custom?
If the UEFI spec mentions it as an option, then it doesn't seem all that custom.
> Is your case any different than walking up to machine with a driver that has been pre-imaged? How would that get solved on a real system? Is it automating the solution your are after? In that case falling back to the removable media case seems like a reasonable solution, if no other solution exists.
There is no removable media. This is like walking up to a machine, and
installing a hard disk with a pre-imaged OS, and wanting it to just
boot.
-Jordan
------------------------------
Message: 6
Date: Sat, 09 Nov 2013 02:05:24 +0100
From: Laszlo Ersek <[email protected]>
Subject: Re: [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System
Flash
To: Jordan Justen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 11/08/13 19:04, Jordan Justen wrote:
> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek <[email protected]> wrote:
>> I also wanted to test secure boot (see if the enrolled keys survive a
>> cold reboot), but I noticed that this series doesn't disable the "load
>> variables from the NvVars file" functionality.
>>
>> I added the attached patch on top of this series, and this way the
>> enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my
>> SVM host with it, even after a full VM shutdown. Do you think the patch
>> has merit?
>
> I want to consider keeping this (NvVars loading) functionality.
>
> The reason being is that it was pointed out that some people like to
> distribute QEMU disk images pre-loaded with an OS. Therefore, this
> might be the only way that those disk images could also set the boot
> variables to point at the boot loader.
>
> I'm not sure this is the best idea though, so feel free to discuss
> further. An alternative idea would be for those disk images to simply
> supply \EFI\BOOT\BOOTXXXX.efi loaders though which we could try to
> load in the absence of boot vars.
>
> Unfortunately, actual NV vars in OVMF raises lots of questions of
> corner cases like this, and I'm not sure where we will end up.
Sorry about the 2nd followup, should have thought of this first:
What about making it someone else's problem? :)
Let's introduce a build option, or an OVMF-specific PCD. I don't mind if
the default favors NvVars, as long as I can carry a patch (or a build
option) that flips it my way.
(Actually I'm not sure it could be done *without* a PCD; the build
option would influence the PCD and the C source would read the PCD. I
guess.)
The PCD could have three values:
- never read NvVars (not very useful, but hey it's cheap to implement)
- read NvVars only if flash is absent (PcdFlashNvStorageVariableBase64),
- always read NvVars.
Thanks!
Laszlo
------------------------------
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
End of edk2-devel Digest, Vol 47, Issue 23
******************************************
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
