Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2016-05-03 Thread David Woodhouse
On Tue, 2016-05-03 at 12:37 +0200, Laszlo Ersek wrote:
> 
> However, CSM is apparently generally borked at the moment (see
> ), and I don't think I can
> spend time on analyzing and fixing that.
> 
> I guess this is not good news, but I thought it better to report than to
> drop the item silently.

Thank you for the explicit prod. Once I've sorted out the new
regressions in building against newly-opaque structures in OpenSSL
HEAD, I'll do a 'git bisect' and see when this broke.

I just hope the history is preserved accurately enough to point the
finger correctly, and that there *is* a point in the (apparent) history
during which it actually worked... :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2016-05-03 Thread Laszlo Ersek
On 08/04/15 13:07, Laszlo Ersek wrote:
> On 08/04/15 12:42, David Woodhouse wrote:
>> On Tue, 2015-08-04 at 03:16 +, Ni, Ruiyu wrote:
>>> I forgot to emphasize that I only tested the QEMU boot timeout 
>>> feature after changing the QemuBootOrderLib. I don't know how to test 
>>> the boot order feature.
>>> For the SeaBIOS CSM, can you tell me how to test or test it for me if 
>>> it's very quick?
>>
>> It's been a quite since I've done it; Laszlo probably has more up-to
>> -date instructions and a prepackaged SeaBIOS .config file (perhaps in
>> the RPM packages).
>>
>> But basically you first build the SeaBIOS CSM image as described at
>> http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29
>> and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with 
>> -DCSM_ENABLE.
>>
>> Then (if the BDS gets it right) you should be able to boot legacy
>> targets as well as native UEFI targets.
> 
> Okay, if you don't have your guests any longer, I guess I can add this
> to the end of my queue too.

I'm de-queueing this item for myself:

Ray's BDS work (for ) is
nearing completion (his v5 series at
 is fully
reviewed, and the test results are good), so the next item for me would
be to try to look into this.

However, CSM is apparently generally borked at the moment (see
), and I don't think I can
spend time on analyzing and fixing that.

I guess this is not good news, but I thought it better to report than to
drop the item silently.

Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-11 Thread Laszlo Ersek
On 08/07/15 11:31, Ni, Ruiyu wrote:
 Laszlo,
 Lots of questions were raised. :)

 Q1. can you please tell me more about the new BDS and UiApp? What the
 motivation for it was, what it does? Do the GenericBdsLib functions
 continue to work?

 Q2. given that ArmVirtPkg is not being modified, it appears that
 GenericBdsLib is not planned (in the short/mid term at least) to be
 phased out

 The BDS in IntelFrameworkModulePkg mixed the UI part and the real BDS
 part together that makes platform impossible to integrate a simpler
 UI but still use the BDS part. That's the main reason we create the
 new BDS and also the core sample UiApp.

 Other reasons are more related to just the BDS part. The interaction
 between old BDS and platform is not very clear. The boot option
 management in old BDS is a mess. It checks whether a boot option is
 valid by connecting to it, which is unexpected from caller's
 perspective. I cannot remember all the reasons now. Overall the new
 BDS is much more cleaner than the old BDS.

 GenericBdsLib still works but I will not integrate new UEFI features
 to it. The goal is every platform uses new BDS and old BDS will be
 removed when no one cares about it.

 I didn't change ArmVirtPkg is because I don't know how to even bulid
 the package. So I just throw the OvmfPkg changes out and if someone
 can help we can co-work on that package to also use the new BDS.

 The reason I want to enable the new BDS is to prove that new BDS is
 feasible to not only Intel close sourced platforms but also open
 sourced platforms.

Understood.

Once we successfully move OvmfPkg over to the new BDS, we should do the
same with ArmVirtPkg. Hopefully I'll understand the new BDS enough by
then for assisting or writing patches.

 Q3. push the series to a public repo
 Sure. the URL is: https://github.com/niruiyu/edk2/commits/OVMF_NEWBDS

 There are three commits. Check it and tell me whether it fits the GIT
 working style:)

 I clone edk2 master in my local disk. Then I created a OVMF_NEWBDS
 branch in local and checked in the three patches locally.

 Then I forked a edk2 in my personal GIT repo in github. Then Then I
 configure my GIT to add a new remote name niruiyu pointing to my
 personal GIT repo in github. Then I push the OVMF_NEWBDS local branch
 to niruiyu.

 Did I do the whole thing correctly? Any unnecessary steps?

Looks okay to me. I fetched your repo and am looking at the branch.

 
 Q4: A build flag to use new/old BDS

 Standing on my point (my reason is just to prove the new BDS's
 design), I am ok to use a build flag and default to use old BDS. But
 I am afraid that the build flag will always point to old BDS and new
 features enabling will only be developed and tested with old BDS. In
 a very near future when someone change the build flag to point to new
 BDS, the OVMF even cannot build.

 My understanding is the change only impacts boot timeout and boot
 order override from QEMU, and the legacy boot. I've already tested
 the boot timeout override. If we can prove that boot order override
 from QEMU and legacy boot still works, we are safe to just use the
 new BDS.

 What do you think?

I started looking at the patch. I can't yet say how intrusive it is.
Perhaps I'll be okay without a build time flag, not sure yet.

Thanks
Laszlo

 
 
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Tuesday, August 4, 2015 7:10 PM
 To: Ni, Ruiyu ruiyu...@intel.com
 Cc: edk2-de...@ml01.01.org; David Woodhouse dw...@infradead.org
 Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
 
 On 08/04/15 12:53, Laszlo Ersek wrote:
 
 No matter how carefully
 we review and test the new code, something will inevitably break,
 
 This wasn't meant as lack of trust in your code; it's just that there
 are many cases and corner cases in the related OVMF code, and it's quite
 hard to test them all.
 
 Thanks
 Laszlo
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 https://lists.01.org/mailman/listinfo/edk2-devel
 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-07 Thread Ni, Ruiyu
Laszlo,
Lots of questions were raised. :)
Q1. can you please tell me more about the new BDS and UiApp? What the 
motivation for it was, what it does? Do the GenericBdsLib functions continue to 
work?
Q2. given that ArmVirtPkg is not being modified, it appears that GenericBdsLib 
is not planned (in the short/mid term at least) to be phased out
The BDS in IntelFrameworkModulePkg mixed the UI part and the real BDS part 
together that makes platform impossible to integrate a simpler UI but still use 
the BDS part. That's the main reason we create the new BDS and also the core 
sample UiApp.
Other reasons are more related to just the BDS part. The interaction between 
old BDS and platform is not very clear. The boot option management in old BDS 
is a mess. It checks whether a boot option is valid by connecting to it, which 
is unexpected from caller's perspective. I cannot remember all the reasons now. 
Overall the new BDS is much more cleaner than the old BDS.
GenericBdsLib still works but I will not integrate new UEFI features to it. The 
goal is every platform uses new BDS and old BDS will be removed when no one 
cares about it.
I didn't change ArmVirtPkg is because I don't know how to even bulid the 
package. So I just throw the OvmfPkg changes out and if someone can help we can 
co-work on that package to also use the new BDS.
The reason I want to enable the new BDS is to prove that new BDS is feasible to 
not only Intel close sourced platforms but also open sourced platforms.

Q3. push the series to a public repo
Sure. the URL is: https://github.com/niruiyu/edk2/commits/OVMF_NEWBDS
There are three commits. Check it and tell me whether it fits the GIT working 
style:)
I clone edk2 master in my local disk. Then I created a OVMF_NEWBDS branch in 
local and checked in the three patches locally.
Then I forked a edk2 in my personal GIT repo in github. Then Then I configure 
my GIT to add a new remote name niruiyu pointing to my personal GIT repo in 
github. Then I push the OVMF_NEWBDS local branch to niruiyu.
Did I do the whole thing correctly? Any unnecessary steps?

Q4: A build flag to use new/old BDS
Standing on my point (my reason is just to prove the new BDS's design), I am ok 
to use a build flag and default to use old BDS. But I am afraid that the build 
flag will always point to old BDS and new features enabling will only be 
developed and tested with old BDS. In a very near future when someone change 
the build flag to point to new BDS, the OVMF even cannot build.
My understanding is the change only impacts boot timeout and boot order 
override from QEMU, and the legacy boot. I've already tested the boot timeout 
override. If we can prove that boot order override from QEMU and legacy boot 
still works, we are safe to just use the new BDS.
What do you think?


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, August 4, 2015 7:10 PM
To: Ni, Ruiyu ruiyu...@intel.com
Cc: edk2-de...@ml01.01.org; David Woodhouse dw...@infradead.org
Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

On 08/04/15 12:53, Laszlo Ersek wrote:

 No matter how carefully
 we review and test the new code, something will inevitably break,

This wasn't meant as lack of trust in your code; it's just that there
are many cases and corner cases in the related OVMF code, and it's quite
hard to test them all.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-04 Thread Laszlo Ersek
On 08/04/15 05:16, Ni, Ruiyu wrote:
 No.
 
 I forgot to emphasize that I only tested the QEMU boot timeout feature after 
 changing the QemuBootOrderLib. I don't know how to test the boot order 
 feature.

This series, on the surface, seems intrusive and to have potential to
cause many regressions. So, as the first step, please push the series to
a public repo, so I can fetch it -- I tried to apply it manually and it
failed -- and review it locally. In particular I'd like to review the
series with rename and copy detection enabled in git. (So that the pure
code movement is filtered out of the patches.)

The boot order stuff is very hairy and also very important to us, so
I'll have to review that carefully.

A different question -- can you please tell me more about the new BDS
and UiApp? What the motivation for it was, what it does?

Do the GenericBdsLib functions continue to work? What we have in OvmfPkg
at the moment is pretty fine-tuned to GenericBdsLib, so if the new
library is just a rough match, it might not be feasible to quickly
rebase OvmfPkg.

Also, given that ArmVirtPkg is not being modified, it appears that
GenericBdsLib is not planned (in the short/mid term at least) to be
phased out. Is that correct?

Because if it is, then I wonder if it would be more prudent to implement
these changes in OVMF with a new build time flag. Namely, I don't want
to block the testing / development of the new BDS infrastructure -- OVMF
is a nice testbed for firmware development, so it should support such
use cases. (Also, in the long term we should probably move to the new
BDS permanently, as there must have been good reasons for implementing
the new BDS in the first place.)

However, this should not regress current users. No matter how carefully
we review and test the new code, something will inevitably break, and
users should not be exposed to that at once (and we shouldn't have to
scramble for fixes retroactively, in a mortal hurry).

Optimally, edk2 should support stable and development branches 
releases (not just for UDK but for everything else, OvmfPkg included).
Since we don't have that, I think it's prudent to implement intrusive
changes in two phases, with a new build time flag. And at some point we
can flip the default, if we want to. (For example, in ArmVirtPkg we
still have -D INTEL_BDS separately.)

 For the SeaBIOS CSM, can you tell me how to test or test it for me if it's 
 very quick?

It's pretty messy. I think David used to have the best set of legacy
guests for testing CSM, so I'd ask him to help with testing it this time
too (sorry David! :)) However, that will also require this series to be
available in a public branch somewhere.

Thanks!
Laszlo

 
 Thanks,
 Ray
 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
 Woodhouse
 Sent: Monday, August 3, 2015 6:31 PM
 To: Ni, Ruiyu ruiyu...@intel.com; edk2-de...@ml01.01.org
 Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
 
 On Mon, 2015-08-03 at 13:41 +0800, Ruiyu Ni wrote:
 A new BDS and UiApp was created in MdeModulePkg and are already
 used in Nt32Pkg.
 The patch changes the OvmfPkg to use the new BDS and UiApp as well.
 
 Hi Ruiyu, were these changes tested with the SeaBIOS CSM?
 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-04 Thread Laszlo Ersek
On 08/04/15 12:53, Laszlo Ersek wrote:

 No matter how carefully
 we review and test the new code, something will inevitably break,

This wasn't meant as lack of trust in your code; it's just that there
are many cases and corner cases in the related OVMF code, and it's quite
hard to test them all.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-04 Thread David Woodhouse
On Tue, 2015-08-04 at 03:16 +, Ni, Ruiyu wrote:
 I forgot to emphasize that I only tested the QEMU boot timeout 
 feature after changing the QemuBootOrderLib. I don't know how to test 
 the boot order feature.
 For the SeaBIOS CSM, can you tell me how to test or test it for me if 
 it's very quick?

It's been a quite since I've done it; Laszlo probably has more up-to
-date instructions and a prepackaged SeaBIOS .config file (perhaps in
the RPM packages).

But basically you first build the SeaBIOS CSM image as described at
http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29
and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with -DCSM_ENABLE.

Then (if the BDS gets it right) you should be able to boot legacy
targets as well as native UEFI targets.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-03 Thread David Woodhouse
On Mon, 2015-08-03 at 13:41 +0800, Ruiyu Ni wrote:
 A new BDS and UiApp was created in MdeModulePkg and are already
 used in Nt32Pkg.
 The patch changes the OvmfPkg to use the new BDS and UiApp as well.

Hi Ruiyu, were these changes tested with the SeaBIOS CSM?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-02 Thread Ruiyu Ni
A new BDS and UiApp was created in MdeModulePkg and are already
used in Nt32Pkg.
The patch changes the OvmfPkg to use the new BDS and UiApp as well.

Ruiyu Ni (3):
  ArmVirtPkg: Copy QemuBootOrderLib to ArmVirtPkg
  OvmfPkg: use new BDS and UiApp in MdeModulePkg
  OvmfPkg: Remove unused PlatformBdsLib after using new BDS.

 ArmVirtPkg/ArmVirtQemu.dsc |2 +-
 .../Library/QemuBootOrderLib/ExtraRootBusMap.c |  313 
 .../Library/QemuBootOrderLib/ExtraRootBusMap.h |   40 +
 .../Library/QemuBootOrderLib/QemuBootOrderLib.c| 1793 
 .../Library/QemuBootOrderLib/QemuBootOrderLib.inf  |   68 +
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c   | 1597 -
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h   |  292 
 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf  |   72 -
 OvmfPkg/Library/PlatformBdsLib/PlatformData.c  |   51 -
 OvmfPkg/Library/PlatformBdsLib/QemuKernel.c|  170 --
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1438 
 .../Library/PlatformBootManagerLib/BdsPlatform.h   |  246 +++
 .../Library/PlatformBootManagerLib/MemoryTest.c|  450 +
 .../PlatformBootManagerLib.inf |   80 +
 .../Library/PlatformBootManagerLib/PlatformData.c  |   35 +
 .../Library/PlatformBootManagerLib/QemuKernel.c|  170 ++
 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c |  673 
 OvmfPkg/Library/PlatformBootManagerLib/Strings.uni |  Bin 0 - 3658 bytes
 .../Library/QemuBootOrderLib/QemuBootOrderLib.c|  355 ++--
 .../Library/QemuBootOrderLib/QemuBootOrderLib.inf  |4 +-
 OvmfPkg/OvmfPkg.dec|5 +-
 OvmfPkg/OvmfPkgIa32.dsc|   28 +-
 OvmfPkg/OvmfPkgIa32.fdf|3 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |   30 +-
 OvmfPkg/OvmfPkgIa32X64.fdf |3 +-
 OvmfPkg/OvmfPkgX64.dsc |   28 +-
 OvmfPkg/OvmfPkgX64.fdf |3 +-
 27 files changed, 5604 insertions(+), 2345 deletions(-)
 create mode 100644 ArmVirtPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c
 create mode 100644 ArmVirtPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h
 create mode 100644 ArmVirtPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
 create mode 100644 ArmVirtPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
 delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
 delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
 delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformData.c
 delete mode 100644 OvmfPkg/Library/PlatformBdsLib/QemuKernel.c
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/MemoryTest.c
 create mode 100644 
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/Strings.uni

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel