Drop CSM support in OvmfPkg?

Drop CSM support in OvmfPkg?

[Ni, Ruiyu]

Hi OvmfPkg maintainers and reviewers,
I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The biggest dependency now I see is the CSM components that OVMF depends on.
So I'd like to know your opinion about how to handle this. I see two options here:

  1.  Drop CSM support in OvmfPkg.
  2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.

What's your opinion about this?

Thanks/Ray

Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek]

(Adding Kevin, Gerd, David)

On 12/17/18 03:23, Ni, Ruiyu wrote:
> Hi OvmfPkg maintainers and reviewers,
> I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The biggest dependency now I see is the CSM components that OVMF depends on.
> So I'd like to know your opinion about how to handle this. I see two options here:
> 
>   1.  Drop CSM support in OvmfPkg.
>   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> 
> What's your opinion about this?

(1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
and Fedora also don't enable the CSM (mainly because I had found
debugging & supporting the CSM *extremely* difficult). For
virtualization, we generally recommend "use SeaBIOS directly if you need
a traditional BIOS guest".

(2) I'd be definitely unhappy about having to maintain the
platform-independent CSM components under OvmfPkg (such as
LegacyBootManagerLib, LegacyBootMaintUiLib, LegacyBiosDxe, VideoDxe).

(3) However, David and Kevin had put a *lot* of work into enabling
SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
target is a dedicated / separate "build mode" of SeaBIOS.

(4) I also think an open source CSM implementation should exist, just so
people can study it and experiment with it. The CSM specification (from
Intel) is a public document, and the edk2 code is the reference
implementation for it. Killing the reference implementation makes the
spec mostly useless. Are Intel withdrawing the spec too? (Or has that
happened already?)

In short, I think the community would benefit if someone continued to
maintain the CSM infrastructure in edk2, but personally I won't
volunteer. I also understand if Intel has no more resources for it.
Removing CSM from edk2 altogether (including OVMF) might be the natural
(albeit regrettable) result.

Thanks
Laszlo

Re: Drop CSM support in OvmfPkg?

[Ni, Ruiyu]

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Monday, December 17, 2018 5:54 PM
> To: Ni, Ruiyu <ruiyu.ni@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>;
> Anthony Perard <anthony.perard@citrix.com>; Julien Grall
> <julien.grall@linaro.org>
> Cc: edk2-devel@lists.01.org; Kevin O'Connor <kevin@koconnor.net>; Gerd
> Hoffmann <kraxel@redhat.com>; David Woodhouse
> <dwmw2@infradead.org>
> Subject: Re: Drop CSM support in OvmfPkg?
> 
> (Adding Kevin, Gerd, David)
> 
> On 12/17/18 03:23, Ni, Ruiyu wrote:
> > Hi OvmfPkg maintainers and reviewers,
> > I am working on removing IntelFrameworkModulePkg and
> IntelFrameworkPkg. The biggest dependency now I see is the CSM
> components that OVMF depends on.
> > So I'd like to know your opinion about how to handle this. I see two options
> here:
> >
> >   1.  Drop CSM support in OvmfPkg.
> >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> >
> > What's your opinion about this?
> 
> (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL and
> Fedora also don't enable the CSM (mainly because I had found debugging &
> supporting the CSM *extremely* difficult). For virtualization, we generally
> recommend "use SeaBIOS directly if you need a traditional BIOS guest".
Yes that was my original thought.

> 
> (2) I'd be definitely unhappy about having to maintain the platform-
> independent CSM components under OvmfPkg (such as
> LegacyBootManagerLib, LegacyBootMaintUiLib, LegacyBiosDxe, VideoDxe).
You are very correct about the scope of CSM components.

> 
> (3) However, David and Kevin had put a *lot* of work into enabling SeaBIOS
> to function as a CSM in combination with OVMF. Today, the CSM target is a
> dedicated / separate "build mode" of SeaBIOS.
I will wait for David and Kevin's comments.

> 
> (4) I also think an open source CSM implementation should exist, just so
> people can study it and experiment with it. The CSM specification (from
> Intel) is a public document, and the edk2 code is the reference
> implementation for it. Killing the reference implementation makes the spec
> mostly useless. Are Intel withdrawing the spec too? (Or has that happened
> already?)
CSM implementation follows the CSM specification. I am not sure if there is
a public spec, an accordingly implementation should exist.
For example, there is a framework HII spec which defines
EFI_FORM_BROWSER_PROTOCOL. But there is no implementation of such
protocol now in edk2 repo, only implementation of
EFI_FORM_BROWSER2_PROTOCOL.

> 
> In short, I think the community would benefit if someone continued to
> maintain the CSM infrastructure in edk2, but personally I won't volunteer. I
> also understand if Intel has no more resources for it.
> Removing CSM from edk2 altogether (including OVMF) might be the natural
> (albeit regrettable) result.

I just see not much benefit of maintaining CSM in edk2 since now major OSVs
don't support CSM boot anymore. Correct me if I am wrong.



> 
> Thanks
> Laszlo

Re: Drop CSM support in OvmfPkg?

[Gerd Hoffmann]

On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> (Adding Kevin, Gerd, David)
> 
> On 12/17/18 03:23, Ni, Ruiyu wrote:
> > Hi OvmfPkg maintainers and reviewers,
> > I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The biggest dependency now I see is the CSM components that OVMF depends on.
> > So I'd like to know your opinion about how to handle this. I see two options here:
> > 
> >   1.  Drop CSM support in OvmfPkg.
> >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > 
> > What's your opinion about this?
> 
> (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
> and Fedora also don't enable the CSM (mainly because I had found
> debugging & supporting the CSM *extremely* difficult). For
> virtualization, we generally recommend "use SeaBIOS directly if you need
> a traditional BIOS guest".

On a virtual machine it is very simple to switch the firmware (unlike on
physical machines), which I think is the main reason ovmf+csm never
really took off.

> (3) However, David and Kevin had put a *lot* of work into enabling
> SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
> target is a dedicated / separate "build mode" of SeaBIOS.

IIRC there are still some corner cases which are not working and nobody
wants put any effort into fixing them.  S3 suspend comes to mind.

I'm not even sure it still works.  It builds, yes, my jenkins instance
does that.  But there is no testing beyond that, and I doubt that
someone else does regular ovmf+csm regression testing.  So the chances
that any runtime breakage goes unnoticed are pretty high ...

> (4) I also think an open source CSM implementation should exist, just so
> people can study it and experiment with it.

It'll not be deleted from git, so it'll be there even when removed from
master branch.

> In short, I think the community would benefit if someone continued to
> maintain the CSM infrastructure in edk2,

But what is the point in keeping the infrastructure if even physical
hardware starts to drop csm support?

So, I'd go with option (1).

cheers,
  Gerd

Re: Drop CSM support in OvmfPkg?

[David Woodhouse]

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

On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote:
> On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> > (Adding Kevin, Gerd, David)
> > 
> > On 12/17/18 03:23, Ni, Ruiyu wrote:
> > > Hi OvmfPkg maintainers and reviewers,
> > > I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The biggest dependency now I see is the CSM components that OVMF depends on.
> > > So I'd like to know your opinion about how to handle this. I see two options here:
> > > 
> > >   1.  Drop CSM support in OvmfPkg.
> > >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > > 
> > > What's your opinion about this?
> > 
> > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
> > and Fedora also don't enable the CSM (mainly because I had found
> > debugging & supporting the CSM *extremely* difficult). For
> > virtualization, we generally recommend "use SeaBIOS directly if you need
> > a traditional BIOS guest".
> 
> On a virtual machine it is very simple to switch the firmware (unlike on
> physical machines), which I think is the main reason ovmf+csm never
> really took off.

Hm, that's true for virtual machines where you own the host system too
and switching BIOS is just a matter of configuration. If you're running
VM hosting at scale, however, and the customers don't get that level of
control, then offering a single BIOS image which does UEFI and CSM in a
"one size fits all" does have some merit.

> > (3) However, David and Kevin had put a *lot* of work into enabling
> > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
> > target is a dedicated / separate "build mode" of SeaBIOS.
> 
> IIRC there are still some corner cases which are not working and nobody
> wants put any effort into fixing them.  S3 suspend comes to mind.

Don't think that should be hard to fix if anyone really cares...

> I'm not even sure it still works.  It builds, yes, my jenkins instance
> does that.  But there is no testing beyond that, and I doubt that
> someone else does regular ovmf+csm regression testing.  So the chances
> that any runtime breakage goes unnoticed are pretty high ...
> 
> > (4) I also think an open source CSM implementation should exist, just so
> > people can study it and experiment with it.
> 
> It'll not be deleted from git, so it'll be there even when removed from
> master branch.
> 
> > In short, I think the community would benefit if someone continued to
> > maintain the CSM infrastructure in edk2,

Ruiyu (and Jordan), what's actually happening here? You said you were
deprecating IntelFrameworkPkg... in the internal Intel builds, what
replaces the CSM part? We fought to get parts of CSM support published
to TianoCore from the internal tree, and I'm concerned that this is a
regression — we end up with CSM support only being internal again. Or
is it being dropped from the Intel tree entirely? 

I am very much against *increasing* the number of features which are
supported in private repositories and not the public one.

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

Re: Drop CSM support in OvmfPkg?

[Ni, Ruiyu]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Thursday, December 20, 2018 9:37 PM
> To: Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek <lersek@redhat.com>
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>;
> Anthony Perard <anthony.perard@citrix.com>; Julien Grall
> <julien.grall@linaro.org>; edk2-devel@lists.01.org; Kevin O'Connor
> <kevin@koconnor.net>
> Subject: Re: Drop CSM support in OvmfPkg?
> 
> On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote:
> > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> > > (Adding Kevin, Gerd, David)
> > >
> > > On 12/17/18 03:23, Ni, Ruiyu wrote:
> > > > Hi OvmfPkg maintainers and reviewers,
> > > > I am working on removing IntelFrameworkModulePkg and
> IntelFrameworkPkg. The biggest dependency now I see is the CSM components
> that OVMF depends on.
> > > > So I'd like to know your opinion about how to handle this. I see two
> options here:
> > > >
> > > >   1.  Drop CSM support in OvmfPkg.
> > > >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > > >
> > > > What's your opinion about this?
> > >
> > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
> > > and Fedora also don't enable the CSM (mainly because I had found
> > > debugging & supporting the CSM *extremely* difficult). For
> > > virtualization, we generally recommend "use SeaBIOS directly if you need
> > > a traditional BIOS guest".
> >
> > On a virtual machine it is very simple to switch the firmware (unlike on
> > physical machines), which I think is the main reason ovmf+csm never
> > really took off.
> 
> Hm, that's true for virtual machines where you own the host system too
> and switching BIOS is just a matter of configuration. If you're running
> VM hosting at scale, however, and the customers don't get that level of
> control, then offering a single BIOS image which does UEFI and CSM in a
> "one size fits all" does have some merit.
> 
> > > (3) However, David and Kevin had put a *lot* of work into enabling
> > > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
> > > target is a dedicated / separate "build mode" of SeaBIOS.
> >
> > IIRC there are still some corner cases which are not working and nobody
> > wants put any effort into fixing them.  S3 suspend comes to mind.
> 
> Don't think that should be hard to fix if anyone really cares...
> 
> > I'm not even sure it still works.  It builds, yes, my jenkins instance
> > does that.  But there is no testing beyond that, and I doubt that
> > someone else does regular ovmf+csm regression testing.  So the chances
> > that any runtime breakage goes unnoticed are pretty high ...
> >
> > > (4) I also think an open source CSM implementation should exist, just so
> > > people can study it and experiment with it.
> >
> > It'll not be deleted from git, so it'll be there even when removed from
> > master branch.
> >
> > > In short, I think the community would benefit if someone continued to
> > > maintain the CSM infrastructure in edk2,
> 
> Ruiyu (and Jordan), what's actually happening here? You said you were
> deprecating IntelFrameworkPkg... in the internal Intel builds, what
> replaces the CSM part? We fought to get parts of CSM support published
> to TianoCore from the internal tree, and I'm concerned that this is a
> regression — we end up with CSM support only being internal again. Or
> is it being dropped from the Intel tree entirely?

UEFI secure boot enabled firmware is the very recommended pre-OS
environment considering nowadays more and more hackers are interested
in this area.
CSM enabled UEFI environment just cannot provide a trust chain up to OS loader
and it will be (or may be) deprecated.
I believe this is the major reason that we want to remove CSM support.
@Brian, correct me if I am wrong.

Regarding to deprecating IntelFrameworkPkg, that's to remove old used
interfaces/codes to make developers easier to under EDKII project.

> 
> I am very much against *increasing* the number of features which are
> supported in private repositories and not the public one.

Re: Drop CSM support in OvmfPkg?

[Ni, Ray]

David,
I'd like to re-start the discussion.
Could you please kindly explain the background/reason of adding CSM support in OVMF?
Maybe knowing the reason can help to make further decisions of whether to
A. keep it outside OvmfPkg
B. keep it inside OvmfPkg
C. maybe have a chance to just remove the CSM support after revisiting

Thanks,
Ray

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ni,
> Ruiyu
> Sent: Thursday, December 20, 2018 10:55 PM
> To: David Woodhouse <dwmw2@infradead.org>; Gerd Hoffmann
> <kraxel@redhat.com>; Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
> <brian.richardson@intel.com>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: [edk2] Drop CSM support in OvmfPkg?
> 
> 
> 
> > -----Original Message-----
> > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > Sent: Thursday, December 20, 2018 9:37 PM
> > To: Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek
> > <lersek@redhat.com>
> > Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; Ard Biesheuvel
> > <ard.biesheuvel@linaro.org>; Anthony Perard
> > <anthony.perard@citrix.com>; Julien Grall <julien.grall@linaro.org>;
> > edk2-devel@lists.01.org; Kevin O'Connor <kevin@koconnor.net>
> > Subject: Re: Drop CSM support in OvmfPkg?
> >
> > On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote:
> > > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> > > > (Adding Kevin, Gerd, David)
> > > >
> > > > On 12/17/18 03:23, Ni, Ruiyu wrote:
> > > > > Hi OvmfPkg maintainers and reviewers, I am working on removing
> > > > > IntelFrameworkModulePkg and
> > IntelFrameworkPkg. The biggest dependency now I see is the CSM
> > components that OVMF depends on.
> > > > > So I'd like to know your opinion about how to handle this. I see
> > > > > two
> > options here:
> > > > >
> > > > >   1.  Drop CSM support in OvmfPkg.
> > > > >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > > > >
> > > > > What's your opinion about this?
> > > >
> > > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in
> > > > RHEL and Fedora also don't enable the CSM (mainly because I had
> > > > found debugging & supporting the CSM *extremely* difficult). For
> > > > virtualization, we generally recommend "use SeaBIOS directly if
> > > > you need a traditional BIOS guest".
> > >
> > > On a virtual machine it is very simple to switch the firmware
> > > (unlike on physical machines), which I think is the main reason
> > > ovmf+csm never really took off.
> >
> > Hm, that's true for virtual machines where you own the host system too
> > and switching BIOS is just a matter of configuration. If you're
> > running VM hosting at scale, however, and the customers don't get that
> > level of control, then offering a single BIOS image which does UEFI
> > and CSM in a "one size fits all" does have some merit.
> >
> > > > (3) However, David and Kevin had put a *lot* of work into enabling
> > > > SeaBIOS to function as a CSM in combination with OVMF. Today, the
> > > > CSM target is a dedicated / separate "build mode" of SeaBIOS.
> > >
> > > IIRC there are still some corner cases which are not working and
> > > nobody wants put any effort into fixing them.  S3 suspend comes to mind.
> >
> > Don't think that should be hard to fix if anyone really cares...
> >
> > > I'm not even sure it still works.  It builds, yes, my jenkins
> > > instance does that.  But there is no testing beyond that, and I
> > > doubt that someone else does regular ovmf+csm regression testing.
> > > So the chances that any runtime breakage goes unnoticed are pretty high ...
> > >
> > > > (4) I also think an open source CSM implementation should exist,
> > > > just so people can study it and experiment with it.
> > >
> > > It'll not be deleted from git, so it'll be there even when removed
> > > from master branch.
> > >
> > > > In short, I think the community would benefit if someone continued
> > > > to maintain the CSM infrastructure in edk2,
> >
> > Ruiyu (and Jordan), what's actually happening here? You said you were
> > deprecating IntelFrameworkPkg... in the internal Intel builds, what
> > replaces the CSM part? We fought to get parts of CSM support published
> > to TianoCore from the internal tree, and I'm concerned that this is a
> > regression — we end up with CSM support only being internal again. Or
> > is it being dropped from the Intel tree entirely?
> 
> UEFI secure boot enabled firmware is the very recommended pre-OS
> environment considering nowadays more and more hackers are interested in
> this area.
> CSM enabled UEFI environment just cannot provide a trust chain up to OS loader
> and it will be (or may be) deprecated.
> I believe this is the major reason that we want to remove CSM support.
> @Brian, correct me if I am wrong.
> 
> Regarding to deprecating IntelFrameworkPkg, that's to remove old used
> interfaces/codes to make developers easier to under EDKII project.
> 
> >
> > I am very much against *increasing* the number of features which are
> > supported in private repositories and not the public one.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: Drop CSM support in OvmfPkg?

[David Woodhouse]

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

On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
> David,
> I'd like to re-start the discussion.
> Could you please kindly explain the background/reason of adding CSM
> support in OVMF?
> Maybe knowing the reason can help to make further decisions of
> whether to
> A. keep it outside OvmfPkg
> B. keep it inside OvmfPkg
> C. maybe have a chance to just remove the CSM support after
> revisiting


The idea was to make it simple to have a single firmware image for
virtual machines which would support both UEFI and Legacy boot for
guests simultaneously.

In libvirt there has been an alternative approach, where the BIOS image
is switched between OVMF and SeaBIOS according to the configuration of
the guest VM.

That's fine for libvirt, but in situations where VM hosting is provided
as a service, it becomes quite painful to manage the 'UEFI' vs.
'Legacy' flags on guest images and then switch firmware images
accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
preferable.



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

Re: Drop CSM support in OvmfPkg?

[Ni, Ray]

> -----Original Message-----
> From: David Woodhouse <dwmw2@infradead.org>
> Sent: Wednesday, January 23, 2019 12:23 AM
> To: Ni, Ray <ray.ni@intel.com>; Gerd Hoffmann <kraxel@redhat.com>;
> Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
> <brian.richardson@intel.com>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: Drop CSM support in OvmfPkg?
> 
> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
> > David,
> > I'd like to re-start the discussion.
> > Could you please kindly explain the background/reason of adding CSM
> > support in OVMF?
> > Maybe knowing the reason can help to make further decisions of
> > whether to
> > A. keep it outside OvmfPkg
> > B. keep it inside OvmfPkg
> > C. maybe have a chance to just remove the CSM support after
> > revisiting
> 
> 
> The idea was to make it simple to have a single firmware image for
> virtual machines which would support both UEFI and Legacy boot for
> guests simultaneously.
> 
> In libvirt there has been an alternative approach, where the BIOS image
> is switched between OVMF and SeaBIOS according to the configuration of
> the guest VM.
> 
> That's fine for libvirt, but in situations where VM hosting is provided
> as a service, it becomes quite painful to manage the 'UEFI' vs.
> 'Legacy' flags on guest images and then switch firmware images
> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
> preferable.

David,
Thanks for sharing. I now understand that you do have a need of
CSM + UEFI OVMF image.
A very straightforward idea is to move all COM components you needed
into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
So maybe you could set up another (github) repo and clone all the CSM components
there.
EDKII build tool supports to build firmware from multiple repos.
That's how we can have edk2-platforms and to-be-created edk2-app.
In practical, you could create a new csm repo.
Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
You can build the OVMF image from edk2 and csm repo.

We can have a call if you are ok. I can explain how that can work in details.

Thanks,
Ray 

Re: Drop CSM support in OvmfPkg?

[Andrew Fish]

> On Jan 22, 2019, at 7:43 PM, Ni, Ray <ray.ni@intel.com> wrote:
> 
>> -----Original Message-----
>> From: David Woodhouse <dwmw2@infradead.org <mailto:dwmw2@infradead.org>>
>> Sent: Wednesday, January 23, 2019 12:23 AM
>> To: Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>; Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>>;
>> Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>; Richardson, Brian
>> <brian.richardson@intel.com <mailto:brian.richardson@intel.com>>
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>; edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>;
>> Kevin O'Connor <kevin@koconnor.net <mailto:kevin@koconnor.net>>; Anthony Perard
>> <anthony.perard@citrix.com <mailto:anthony.perard@citrix.com>>
>> Subject: Re: Drop CSM support in OvmfPkg?
>> 
>> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
>>> David,
>>> I'd like to re-start the discussion.
>>> Could you please kindly explain the background/reason of adding CSM
>>> support in OVMF?
>>> Maybe knowing the reason can help to make further decisions of
>>> whether to
>>> A. keep it outside OvmfPkg
>>> B. keep it inside OvmfPkg
>>> C. maybe have a chance to just remove the CSM support after
>>> revisiting
>> 
>> 
>> The idea was to make it simple to have a single firmware image for
>> virtual machines which would support both UEFI and Legacy boot for
>> guests simultaneously.
>> 
>> In libvirt there has been an alternative approach, where the BIOS image
>> is switched between OVMF and SeaBIOS according to the configuration of
>> the guest VM.
>> 
>> That's fine for libvirt, but in situations where VM hosting is provided
>> as a service, it becomes quite painful to manage the 'UEFI' vs.
>> 'Legacy' flags on guest images and then switch firmware images
>> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
>> preferable.
> 
> David,
> Thanks for sharing. I now understand that you do have a need of
> CSM + UEFI OVMF image.
> A very straightforward idea is to move all COM components you needed
> into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
> So maybe you could set up another (github) repo and clone all the CSM components
> there.
> EDKII build tool supports to build firmware from multiple repos.
> That's how we can have edk2-platforms and to-be-created edk2-app.
> In practical, you could create a new csm repo.
> Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
> You can build the OVMF image from edk2 and csm repo.
> 

Ray,

I kind or agree at this point CSM is really more interesting for virtual machines vs. real platforms. I guess the interesting question to ask is do we want to start making it more part of the virtual machines that happen to be checked into TianoCore, or should we keep it more generic? The thinking being the CSM is likely upstreamed in other more commercial VMs? Can we just add a readme to the current CSM package and explain it mostly exists to support VMs? 

Thanks,

Andrew Fish

> We can have a call if you are ok. I can explain how that can work in details.
> 
> Thanks,
> Ray 
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>

Re: Drop CSM support in OvmfPkg?

[Ni, Ray]

Andrew,
Do you have any specific concerns if we move csm out of edk2 repo, to a repo owned by David?

As David mentioned, VM can switch between firmware images. It 's just somehow difficult in certain environment. Maybe for the long term consideration, enhancing the VM to support easily switching firmware images makes a little more sense.

Thanks,
Ray

From: afish@apple.com <afish@apple.com>
Sent: Wednesday, January 23, 2019 12:01 PM
To: Ni, Ray <ray.ni@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek <lersek@redhat.com>; Richardson, Brian <brian.richardson@intel.com>; Anthony Perard <anthony.perard@citrix.com>; Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org; Kevin O'Connor <kevin@koconnor.net>
Subject: Re: [edk2] Drop CSM support in OvmfPkg?




On Jan 22, 2019, at 7:43 PM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:

-----Original Message-----
From: David Woodhouse <dwmw2@infradead.org<mailto:dwmw2@infradead.org>>
Sent: Wednesday, January 23, 2019 12:23 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>;
Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Richardson, Brian
<brian.richardson@intel.com<mailto:brian.richardson@intel.com>>
Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>;
Kevin O'Connor <kevin@koconnor.net<mailto:kevin@koconnor.net>>; Anthony Perard
<anthony.perard@citrix.com<mailto:anthony.perard@citrix.com>>
Subject: Re: Drop CSM support in OvmfPkg?

On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:

David,
I'd like to re-start the discussion.
Could you please kindly explain the background/reason of adding CSM
support in OVMF?
Maybe knowing the reason can help to make further decisions of
whether to
A. keep it outside OvmfPkg
B. keep it inside OvmfPkg
C. maybe have a chance to just remove the CSM support after
revisiting


The idea was to make it simple to have a single firmware image for
virtual machines which would support both UEFI and Legacy boot for
guests simultaneously.

In libvirt there has been an alternative approach, where the BIOS image
is switched between OVMF and SeaBIOS according to the configuration of
the guest VM.

That's fine for libvirt, but in situations where VM hosting is provided
as a service, it becomes quite painful to manage the 'UEFI' vs.
'Legacy' flags on guest images and then switch firmware images
accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
preferable.

David,
Thanks for sharing. I now understand that you do have a need of
CSM + UEFI OVMF image.
A very straightforward idea is to move all COM components you needed
into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
So maybe you could set up another (github) repo and clone all the CSM components
there.
EDKII build tool supports to build firmware from multiple repos.
That's how we can have edk2-platforms and to-be-created edk2-app.
In practical, you could create a new csm repo.
Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
You can build the OVMF image from edk2 and csm repo.


Ray,

I kind or agree at this point CSM is really more interesting for virtual machines vs. real platforms. I guess the interesting question to ask is do we want to start making it more part of the virtual machines that happen to be checked into TianoCore, or should we keep it more generic? The thinking being the CSM is likely upstreamed in other more commercial VMs? Can we just add a readme to the current CSM package and explain it mostly exists to support VMs?

Thanks,

Andrew Fish


We can have a call if you are ok. I can explain how that can work in details.

Thanks,
Ray

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: Drop CSM support in OvmfPkg?

[Gerd Hoffmann]

On Tue, Jan 22, 2019 at 04:23:06PM +0000, David Woodhouse wrote:
> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
> > David,
> > I'd like to re-start the discussion.
> > Could you please kindly explain the background/reason of adding CSM
> > support in OVMF?
> > Maybe knowing the reason can help to make further decisions of
> > whether to
> > A. keep it outside OvmfPkg
> > B. keep it inside OvmfPkg
> > C. maybe have a chance to just remove the CSM support after
> > revisiting
> 
> The idea was to make it simple to have a single firmware image for
> virtual machines which would support both UEFI and Legacy boot for
> guests simultaneously.

The idea never really took off though.

> In libvirt there has been an alternative approach, where the BIOS image
> is switched between OVMF and SeaBIOS according to the configuration of
> the guest VM.

It's not mandated by libvirt, you can easily create a VM configuration
which uses a OVMF build with CSM support.

But, yes, it is rarely seen in practice.

Microsoft is doing the same btw:  hyper-v has gen1 (bios) and gen2
(uefi) guest types.

> That's fine for libvirt, but in situations where VM hosting is provided
> as a service, it becomes quite painful to manage the 'UEFI' vs.
> 'Legacy' flags on guest images and then switch firmware images
> accordingly.

Seems people try to address this by building cloud images which support
both BIOS and UEFI.

> A one-size-fits-all BIOS using OVMF+CSM is very much
> preferable.

Building a one-size-fits-all BIOS is pretty much impossible due to CSM
being incompatible with secure boot.

cheers,
  Gerd

Re: Drop CSM support in OvmfPkg?

[David Woodhouse]

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

On Wed, 2019-01-23 at 07:12 +0100, Gerd Hoffmann wrote:
> > A one-size-fits-all BIOS using OVMF+CSM is very much
> > preferable.
> 
> Building a one-size-fits-all BIOS is pretty much impossible due to CSM
> being incompatible with secure boot.

Booting with CSM is incompatible with Secure Boot, of course.

But it doesn't prevent Secure Boot unless we actually use the CSM for
booting, surely?


I'm interested in what happened to generic CSM support. Has Intel
really ditched CSM completely from all other TianoCore builds? Nobody
else will ever be able to build a Tiano-based UEFI firmware again,
unless they also squirrel away a copy of the code before it disappears?
The code really is otherwise being deleted?

Or is this an "open source regression", with code that was in the
public repository now disappearing and only being maintained in
private?


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

Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek]

Hi All,

On 01/23/19 04:43, Ni, Ray wrote:
>> -----Original Message-----
>> From: David Woodhouse <dwmw2@infradead.org>
>> Sent: Wednesday, January 23, 2019 12:23 AM
>> To: Ni, Ray <ray.ni@intel.com>; Gerd Hoffmann <kraxel@redhat.com>;
>> Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
>> <brian.richardson@intel.com>
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
>> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
>> <anthony.perard@citrix.com>
>> Subject: Re: Drop CSM support in OvmfPkg?
>>
>> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
>>> David,
>>> I'd like to re-start the discussion.
>>> Could you please kindly explain the background/reason of adding CSM
>>> support in OVMF?
>>> Maybe knowing the reason can help to make further decisions of
>>> whether to
>>> A. keep it outside OvmfPkg
>>> B. keep it inside OvmfPkg
>>> C. maybe have a chance to just remove the CSM support after
>>> revisiting
>>
>>
>> The idea was to make it simple to have a single firmware image for
>> virtual machines which would support both UEFI and Legacy boot for
>> guests simultaneously.
>>
>> In libvirt there has been an alternative approach, where the BIOS image
>> is switched between OVMF and SeaBIOS according to the configuration of
>> the guest VM.
>>
>> That's fine for libvirt, but in situations where VM hosting is provided
>> as a service, it becomes quite painful to manage the 'UEFI' vs.
>> 'Legacy' flags on guest images and then switch firmware images
>> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
>> preferable.
> 
> David,
> Thanks for sharing. I now understand that you do have a need of
> CSM + UEFI OVMF image.
> A very straightforward idea is to move all COM components you needed
> into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
> So maybe you could set up another (github) repo and clone all the CSM components
> there.
> EDKII build tool supports to build firmware from multiple repos.
> That's how we can have edk2-platforms and to-be-created edk2-app.
> In practical, you could create a new csm repo.
> Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
> You can build the OVMF image from edk2 and csm repo.
> 
> We can have a call if you are ok. I can explain how that can work in details.

I'm fine if we move the generic CSM components into OvmfPkg, however I'm
going to ask David to assume reviewer responsibilities for them.

Given the current format of "Maintainers.txt", we couldn't spell out the
exact pathnames of the CSM components, so we'd add a line like

R: David Woodhouse <dwmw2@infradead.org>

under OvmfPkg. There is "prior art" for this pattern, see:

R: Anthony Perard <anthony.perard@citrix.com>
R: Julien Grall <julien.grall@linaro.org>

Because Anthony and Julien are the authority on Xen-related code under
OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers
to OvmfPkg", 2017-09-26.)


If we keep CSM support in OvmfPkg in any form at all, then I would
prefer holding all the related stuff in the core edk2 repository (with
the above Reviewership), over requiring people to deal with multiple
repositories. I agree (from experience) that PACKAGES_PATH / multiple
workspaces work fine, but in this case I think keeping one shared
history is an advantage.

Thanks,
Laszlo

Re: Drop CSM support in OvmfPkg?

[David Woodhouse]

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

On Wed, 2019-01-23 at 10:46 +0100, Laszlo Ersek wrote:
> I'm fine if we move the generic CSM components into OvmfPkg, however I'm
> going to ask David to assume reviewer responsibilities for them.
> 
> Given the current format of "Maintainers.txt", we couldn't spell out the
> exact pathnames of the CSM components, so we'd add a line like
> 
> R: David Woodhouse <dwmw2@infradead.org>
> 
> under OvmfPkg. There is "prior art" for this pattern, see:
> 
> R: Anthony Perard <anthony.perard@citrix.com>
> R: Julien Grall <julien.grall@linaro.org>
> 
> Because Anthony and Julien are the authority on Xen-related code under
> OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers
> to OvmfPkg", 2017-09-26.)
> 
> 
> If we keep CSM support in OvmfPkg in any form at all, then I would
> prefer holding all the related stuff in the core edk2 repository (with
> the above Reviewership), over requiring people to deal with multiple
> repositories. I agree (from experience) that PACKAGES_PATH / multiple
> workspaces work fine, but in this case I think keeping one shared
> history is an advantage.

This all makes sense to me.

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

Re: Drop CSM support in OvmfPkg?

[Ard Biesheuvel]

On Wed, 23 Jan 2019 at 10:55, Laszlo Er

> > That's going to be a hard thing to keep from happening over time, as
> > this is valid C :(sek <lersek@redhat.com> wrote:
>
> Hi All,
>
> On 01/23/19 04:43, Ni, Ray wrote:
> >> -----Original Message-----
> >> From: David Woodhouse <dwmw2@infradead.org>
> >> Sent: Wednesday, January 23, 2019 12:23 AM
> >> To: Ni, Ray <ray.ni@intel.com>; Gerd Hoffmann <kraxel@redhat.com>;
> >> Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
> >> <brian.richardson@intel.com>
> >> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> >> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
> >> <anthony.perard@citrix.com>
> >> Subject: Re: Drop CSM support in OvmfPkg?
> >>
> >> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
> >>> David,
> >>> I'd like to re-start the discussion.
> >>> Could you please kindly explain the background/reason of adding CSM
> >>> support in OVMF?
> >>> Maybe knowing the reason can help to make further decisions of
> >>> whether to
> >>> A. keep it outside OvmfPkg
> >>> B. keep it inside OvmfPkg
> >>> C. maybe have a chance to just remove the CSM support after
> >>> revisiting
> >>
> >>
> >> The idea was to make it simple to have a single firmware image for
> >> virtual machines which would support both UEFI and Legacy boot for
> >> guests simultaneously.
> >>
> >> In libvirt there has been an alternative approach, where the BIOS image
> >> is switched between OVMF and SeaBIOS according to the configuration of
> >> the guest VM.
> >>
> >> That's fine for libvirt, but in situations where VM hosting is provided
> >> as a service, it becomes quite painful to manage the 'UEFI' vs.
> >> 'Legacy' flags on guest images and then switch firmware images
> >> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
> >> preferable.
> >
> > David,
> > Thanks for sharing. I now understand that you do have a need of
> > CSM + UEFI OVMF image.
> > A very straightforward idea is to move all COM components you needed
> > into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
> > So maybe you could set up another (github) repo and clone all the CSM components
> > there.
> > EDKII build tool supports to build firmware from multiple repos.
> > That's how we can have edk2-platforms and to-be-created edk2-app.
> > In practical, you could create a new csm repo.
> > Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
> > You can build the OVMF image from edk2 and csm repo.
> >
> > We can have a call if you are ok. I can explain how that can work in details.
>
> I'm fine if we move the generic CSM components into OvmfPkg, however I'm
> going to ask David to assume reviewer responsibilities for them.
>
> Given the current format of "Maintainers.txt", we couldn't spell out the
> exact pathnames of the CSM components, so we'd add a line like
>
> R: David Woodhouse <dwmw2@infradead.org>
>
> under OvmfPkg. There is "prior art" for this pattern, see:
>
> R: Anthony Perard <anthony.perard@citrix.com>
> R: Julien Grall <julien.grall@linaro.org>
>
> Because Anthony and Julien are the authority on Xen-related code under
> OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers
> to OvmfPkg", 2017-09-26.)
>
>
> If we keep CSM support in OvmfPkg in any form at all, then I would
> prefer holding all the related stuff in the core edk2 repository (with
> the above Reviewership), over requiring people to deal with multiple
> repositories. I agree (from experience) that PACKAGES_PATH / multiple
> workspaces work fine, but in this case I think keeping one shared
> history is an advantage.
>

I don't have an opinion on whether we should keep CSM or not in
OvmfPkg. But if we do, I agree we should just move all the pieces we
rely on and that are getting dropped into OvmfPkg/ proper, rather than
keeping them on the side somewhere.

Re: Drop CSM support in OvmfPkg?

[Ni, Ray]

David,
I think we got an agreement here to move CSM components in OvmfPkg.
I prefer we firstly clone the required CSM components in OvmfPkg right no.
Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch.
(I say "finally" because OVMF CSM dependency is not the only case that prevent removing
the two framework packages.)

Would you like to do the clone? Or if you are busy, I can do that.

Thanks,
Ray

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Wednesday, January 23, 2019 5:49 PM
> To: Laszlo Ersek <lersek@redhat.com>; Ni, Ray <ray.ni@intel.com>; Gerd
> Hoffmann <kraxel@redhat.com>; Richardson, Brian
> <brian.richardson@intel.com>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: Drop CSM support in OvmfPkg?
> 
> On Wed, 2019-01-23 at 10:46 +0100, Laszlo Ersek wrote:
> > I'm fine if we move the generic CSM components into OvmfPkg, however I'm
> > going to ask David to assume reviewer responsibilities for them.
> >
> > Given the current format of "Maintainers.txt", we couldn't spell out the
> > exact pathnames of the CSM components, so we'd add a line like
> >
> > R: David Woodhouse <dwmw2@infradead.org>
> >
> > under OvmfPkg. There is "prior art" for this pattern, see:
> >
> > R: Anthony Perard <anthony.perard@citrix.com>
> > R: Julien Grall <julien.grall@linaro.org>
> >
> > Because Anthony and Julien are the authority on Xen-related code under
> > OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers
> > to OvmfPkg", 2017-09-26.)
> >
> >
> > If we keep CSM support in OvmfPkg in any form at all, then I would
> > prefer holding all the related stuff in the core edk2 repository (with
> > the above Reviewership), over requiring people to deal with multiple
> > repositories. I agree (from experience) that PACKAGES_PATH / multiple
> > workspaces work fine, but in this case I think keeping one shared
> > history is an advantage.
> 
> This all makes sense to me.

Re: Drop CSM support in OvmfPkg?

[David Woodhouse]

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

On Thu, 2019-01-24 at 01:48 +0000, Ni, Ray wrote:
> David,
> I think we got an agreement here to move CSM components in OvmfPkg.
> I prefer we firstly clone the required CSM components in OvmfPkg right no.
> Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch.
> (I say "finally" because OVMF CSM dependency is not the only case that prevent removing
> the two framework packages.)
> 
> Would you like to do the clone? Or if you are busy, I can do that.

I keep asking this question, I don't believe I've seen an
answer. Apologies if I've missed it.

Is this code genuinely not going to continue to exist anywhere else in
the Intel ecosystem, any more?

No TianoCore-based images from this point forth are ever going to even
have the option of supporting CSM?

Unless some third party also chooses to fork the CSM support code and
keep it on for themselves? 


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

Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek]

On 01/24/19 10:31, David Woodhouse wrote:
> On Thu, 2019-01-24 at 01:48 +0000, Ni, Ray wrote:
>> David,
>> I think we got an agreement here to move CSM components in OvmfPkg.
>> I prefer we firstly clone the required CSM components in OvmfPkg right no.
>> Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch.
>> (I say "finally" because OVMF CSM dependency is not the only case that prevent removing
>> the two framework packages.)
>>
>> Would you like to do the clone? Or if you are busy, I can do that.
> 
> I keep asking this question, I don't believe I've seen an
> answer. Apologies if I've missed it.

I think you haven't. And, I'm curious too. :)

Thanks
Laszlo

> Is this code genuinely not going to continue to exist anywhere else in
> the Intel ecosystem, any more?
> 
> No TianoCore-based images from this point forth are ever going to even
> have the option of supporting CSM?
> 
> Unless some third party also chooses to fork the CSM support code and
> keep it on for themselves? 
> 

Re: Drop CSM support in OvmfPkg?

[Brian J. Johnson]

On 1/24/19 5:30 AM, Laszlo Ersek wrote:
> On 01/24/19 10:31, David Woodhouse wrote:
>> On Thu, 2019-01-24 at 01:48 +0000, Ni, Ray wrote:
>>> David,
>>> I think we got an agreement here to move CSM components in OvmfPkg.
>>> I prefer we firstly clone the required CSM components in OvmfPkg right no.
>>> Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch.
>>> (I say "finally" because OVMF CSM dependency is not the only case that prevent removing
>>> the two framework packages.)
>>>
>>> Would you like to do the clone? Or if you are busy, I can do that.
>>
>> I keep asking this question, I don't believe I've seen an
>> answer. Apologies if I've missed it.
> 
> I think you haven't. And, I'm curious too. :)
> 
> Thanks
> Laszlo
> 
>> Is this code genuinely not going to continue to exist anywhere else in
>> the Intel ecosystem, any more?
>>
>> No TianoCore-based images from this point forth are ever going to even
>> have the option of supporting CSM?
>>
>> Unless some third party also chooses to fork the CSM support code and
>> keep it on for themselves?
>>

In fall of 2017, Intel declared their intention to end legacy BIOS 
support on their platforms by 2020.

http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf

I believe they have stuck to this story at subsequent UEFI plugfests.

-- 

                                                 Brian

--------------------------------------------------------------------

    "Occasionally get out of the office, the lab, the computer room,
     smell the flowers and take a look at the physical world around you."
                                            -- Rob Cook

Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek]

On 01/25/19 21:28, Brian J. Johnson wrote:
> On 1/24/19 5:30 AM, Laszlo Ersek wrote:
>> On 01/24/19 10:31, David Woodhouse wrote:
>>> On Thu, 2019-01-24 at 01:48 +0000, Ni, Ray wrote:
>>>> David,
>>>> I think we got an agreement here to move CSM components in OvmfPkg.
>>>> I prefer we firstly clone the required CSM components in OvmfPkg
>>>> right no.
>>>> Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg
>>>> in one patch.
>>>> (I say "finally" because OVMF CSM dependency is not the only case
>>>> that prevent removing
>>>> the two framework packages.)
>>>>
>>>> Would you like to do the clone? Or if you are busy, I can do that.
>>>
>>> I keep asking this question, I don't believe I've seen an
>>> answer. Apologies if I've missed it.
>>
>> I think you haven't. And, I'm curious too. :)
>>
>> Thanks
>> Laszlo
>>
>>> Is this code genuinely not going to continue to exist anywhere else in
>>> the Intel ecosystem, any more?
>>>
>>> No TianoCore-based images from this point forth are ever going to even
>>> have the option of supporting CSM?
>>>
>>> Unless some third party also chooses to fork the CSM support code and
>>> keep it on for themselves?
>>>
> 
> In fall of 2017, Intel declared their intention to end legacy BIOS
> support on their platforms by 2020.
> 
> http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf
> 
> 
> I believe they have stuck to this story at subsequent UEFI plugfests.

Thank you! For me that answers the question.

--*--

BTW, I'm glad slides 11, 17, 18 say "Remove user motivations to stick
with BIOS: Improve experience with UEFI Secure Boot". It's incredible
how many UEFI implementations do not offer any *real* BootOrder/Boot####
management even, not to mention the obscure hacks such as forcibly
re-setting the first boot option to Windows, if it is installed etc.
It's no surprise people rely on "shim" and "grub" (and other 3rd party
boot loaders) more than ever -- they want to get out of the crappy
platform firmware UI as soon as they can, and reach a UI they can
actually control.

Thanks,
Laszlo