firmware selection for SEV-ES

firmware selection for SEV-ES

[Laszlo Ersek]

Hi Brijesh, Tom,

in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
has a constant called @amd-sev. We should introduce an @amd-sev-es
constant as well, minimally for the following reason:

AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
Standardization") revision 1.40 says in "4.6 System Management Mode
(SMM)" that "SMM will not be supported in this version of the
specification". This is reflected in OVMF, so an OVMF binary that's
supposed to run in a SEV-ES guest must be built without "-D
SMM_REQUIRE". (As a consequence, such a binary should be built also
without "-D SECURE_BOOT_ENABLE".)

At the level of "docs/interop/firmware.json", this means that management
applications should be enabled to look for the @amd-sev-es feature (and
it also means, for OS distributors, that any firmware descriptor
exposing @amd-sev-es will currently have to lack all three of:
@requires-smm, @secure-boot, @enrolled-keys).

I have three questions:


(1) According to
<https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
explicitly requested in the domain XML via setting bit#2 in the "policy"
element.

Can this setting be used by libvirt to look for such a firmware
descriptor that exposes @amd-sev-es?


(2) "docs/interop/firmware.json" documents @amd-sev as follows:

# @amd-sev: The firmware supports running under AMD Secure Encrypted
#           Virtualization, as specified in the AMD64 Architecture
#           Programmer's Manual. QEMU command line options related to
#           this feature are documented in
#           "docs/amd-memory-encryption.txt".

Documenting the new @amd-sev-es enum constant with very slight
customizations for the same text should be possible, I reckon. However,
"docs/amd-memory-encryption.txt" (nor
"docs/confidential-guest-support.txt") seem to mention SEV-ES.

Can you guys propose a patch for "docs/amd-memory-encryption.txt"?

I guess that would be next to this snippet:

> # ${QEMU} \
>    sev-guest,id=sev0,policy=0x1...\


(3) Is the "AMD64 Architecture Programmer's Manual" the specification
that we should reference under @amd-sev-es as well (i.e., same as with
@amd-sev), or is there a more specific document?

Thanks,
Laszlo

Re: firmware selection for SEV-ES

[Pavel Hrdina]

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

On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
> Hi Brijesh, Tom,
> 
> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
> has a constant called @amd-sev. We should introduce an @amd-sev-es
> constant as well, minimally for the following reason:
> 
> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
> Standardization") revision 1.40 says in "4.6 System Management Mode
> (SMM)" that "SMM will not be supported in this version of the
> specification". This is reflected in OVMF, so an OVMF binary that's
> supposed to run in a SEV-ES guest must be built without "-D
> SMM_REQUIRE". (As a consequence, such a binary should be built also
> without "-D SECURE_BOOT_ENABLE".)
> 
> At the level of "docs/interop/firmware.json", this means that management
> applications should be enabled to look for the @amd-sev-es feature (and
> it also means, for OS distributors, that any firmware descriptor
> exposing @amd-sev-es will currently have to lack all three of:
> @requires-smm, @secure-boot, @enrolled-keys).
> 
> I have three questions:
> 
> 
> (1) According to
> <https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
> explicitly requested in the domain XML via setting bit#2 in the "policy"
> element.
> 
> Can this setting be used by libvirt to look for such a firmware
> descriptor that exposes @amd-sev-es?

Hi Laszlo and all,

Currently we use only <launchSecurity type='sev'> when selecting
firmware to make sure that it supports @amd-sev. Since we already have a
place in the VM XML where users can configure amd-sev-as we can use that
information when selecting correct firmware that should be used for the
VM.

Pavel

> (2) "docs/interop/firmware.json" documents @amd-sev as follows:
> 
> # @amd-sev: The firmware supports running under AMD Secure Encrypted
> #           Virtualization, as specified in the AMD64 Architecture
> #           Programmer's Manual. QEMU command line options related to
> #           this feature are documented in
> #           "docs/amd-memory-encryption.txt".
> 
> Documenting the new @amd-sev-es enum constant with very slight
> customizations for the same text should be possible, I reckon. However,
> "docs/amd-memory-encryption.txt" (nor
> "docs/confidential-guest-support.txt") seem to mention SEV-ES.
> 
> Can you guys propose a patch for "docs/amd-memory-encryption.txt"?
> 
> I guess that would be next to this snippet:
> 
> > # ${QEMU} \
> >    sev-guest,id=sev0,policy=0x1...\
> 
> 
> (3) Is the "AMD64 Architecture Programmer's Manual" the specification
> that we should reference under @amd-sev-es as well (i.e., same as with
> @amd-sev), or is there a more specific document?
> 
> Thanks,
> Laszlo
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: firmware selection for SEV-ES

[Tom Lendacky]

On 4/21/21 4:54 AM, Laszlo Ersek wrote:
> Hi Brijesh, Tom,

Hi Laszlo,

> 
> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
> has a constant called @amd-sev. We should introduce an @amd-sev-es
> constant as well, minimally for the following reason:
> 
> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
> Standardization") revision 1.40 says in "4.6 System Management Mode
> (SMM)" that "SMM will not be supported in this version of the
> specification". This is reflected in OVMF, so an OVMF binary that's
> supposed to run in a SEV-ES guest must be built without "-D
> SMM_REQUIRE". (As a consequence, such a binary should be built also
> without "-D SECURE_BOOT_ENABLE".)
> 
> At the level of "docs/interop/firmware.json", this means that management
> applications should be enabled to look for the @amd-sev-es feature (and
> it also means, for OS distributors, that any firmware descriptor
> exposing @amd-sev-es will currently have to lack all three of:
> @requires-smm, @secure-boot, @enrolled-keys).
> 
> I have three questions:
> 
> 
> (1) According to
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibvirt.org%2Fformatdomain.html%23launch-security&amp;data=04%7C01%7Cthomas.lendacky%40amd.com%7Ca80df30ddbc54479df1008d904ab7ab8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637545956815983695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=aQ1yttPryxCjO%2B7cIPfxathftEPEKb0QYhdHI7WkWLU%3D&amp;reserved=0>, SEV-ES is
> explicitly requested in the domain XML via setting bit#2 in the "policy"
> element.
> 
> Can this setting be used by libvirt to look for such a firmware
> descriptor that exposes @amd-sev-es?
> 
> 
> (2) "docs/interop/firmware.json" documents @amd-sev as follows:
> 
> # @amd-sev: The firmware supports running under AMD Secure Encrypted
> #           Virtualization, as specified in the AMD64 Architecture
> #           Programmer's Manual. QEMU command line options related to
> #           this feature are documented in
> #           "docs/amd-memory-encryption.txt".
> 
> Documenting the new @amd-sev-es enum constant with very slight
> customizations for the same text should be possible, I reckon. However,
> "docs/amd-memory-encryption.txt" (nor
> "docs/confidential-guest-support.txt") seem to mention SEV-ES.
> 
> Can you guys propose a patch for "docs/amd-memory-encryption.txt"?

Yes, I can submit a patch to update the documentation.

> 
> I guess that would be next to this snippet:
> 
>> # ${QEMU} \
>>    sev-guest,id=sev0,policy=0x1...\
> 
> 
> (3) Is the "AMD64 Architecture Programmer's Manual" the specification
> that we should reference under @amd-sev-es as well (i.e., same as with
> @amd-sev), or is there a more specific document?

Yes, the same specification applies to SEV-ES.

Thanks,
Tom

> 
> Thanks,
> Laszlo
> 

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/21/21 13:51, Pavel Hrdina wrote:
> On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
>> Hi Brijesh, Tom,
>>
>> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
>> has a constant called @amd-sev. We should introduce an @amd-sev-es
>> constant as well, minimally for the following reason:
>>
>> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
>> Standardization") revision 1.40 says in "4.6 System Management Mode
>> (SMM)" that "SMM will not be supported in this version of the
>> specification". This is reflected in OVMF, so an OVMF binary that's
>> supposed to run in a SEV-ES guest must be built without "-D
>> SMM_REQUIRE". (As a consequence, such a binary should be built also
>> without "-D SECURE_BOOT_ENABLE".)
>>
>> At the level of "docs/interop/firmware.json", this means that management
>> applications should be enabled to look for the @amd-sev-es feature (and
>> it also means, for OS distributors, that any firmware descriptor
>> exposing @amd-sev-es will currently have to lack all three of:
>> @requires-smm, @secure-boot, @enrolled-keys).
>>
>> I have three questions:
>>
>>
>> (1) According to
>> <https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
>> explicitly requested in the domain XML via setting bit#2 in the "policy"
>> element.
>>
>> Can this setting be used by libvirt to look for such a firmware
>> descriptor that exposes @amd-sev-es?
> 
> Hi Laszlo and all,
> 
> Currently we use only <launchSecurity type='sev'> when selecting
> firmware to make sure that it supports @amd-sev. Since we already have a
> place in the VM XML where users can configure amd-sev-as we can use that
> information when selecting correct firmware that should be used for the
> VM.

Thanks!

Should we file a libvirtd Feature Request (where?) for recognizing the
@amd-sev-es feature flag?

Cheers
Laszlo

> 
> Pavel
> 
>> (2) "docs/interop/firmware.json" documents @amd-sev as follows:
>>
>> # @amd-sev: The firmware supports running under AMD Secure Encrypted
>> #           Virtualization, as specified in the AMD64 Architecture
>> #           Programmer's Manual. QEMU command line options related to
>> #           this feature are documented in
>> #           "docs/amd-memory-encryption.txt".
>>
>> Documenting the new @amd-sev-es enum constant with very slight
>> customizations for the same text should be possible, I reckon. However,
>> "docs/amd-memory-encryption.txt" (nor
>> "docs/confidential-guest-support.txt") seem to mention SEV-ES.
>>
>> Can you guys propose a patch for "docs/amd-memory-encryption.txt"?
>>
>> I guess that would be next to this snippet:
>>
>>> # ${QEMU} \
>>>    sev-guest,id=sev0,policy=0x1...\
>>
>>
>> (3) Is the "AMD64 Architecture Programmer's Manual" the specification
>> that we should reference under @amd-sev-es as well (i.e., same as with
>> @amd-sev), or is there a more specific document?
>>
>> Thanks,
>> Laszlo
>>

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/21/21 17:25, Tom Lendacky wrote:
> On 4/21/21 4:54 AM, Laszlo Ersek wrote:
>> Hi Brijesh, Tom,
> 
> Hi Laszlo,
> 
>>
>> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
>> has a constant called @amd-sev. We should introduce an @amd-sev-es
>> constant as well, minimally for the following reason:
>>
>> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
>> Standardization") revision 1.40 says in "4.6 System Management Mode
>> (SMM)" that "SMM will not be supported in this version of the
>> specification". This is reflected in OVMF, so an OVMF binary that's
>> supposed to run in a SEV-ES guest must be built without "-D
>> SMM_REQUIRE". (As a consequence, such a binary should be built also
>> without "-D SECURE_BOOT_ENABLE".)
>>
>> At the level of "docs/interop/firmware.json", this means that management
>> applications should be enabled to look for the @amd-sev-es feature (and
>> it also means, for OS distributors, that any firmware descriptor
>> exposing @amd-sev-es will currently have to lack all three of:
>> @requires-smm, @secure-boot, @enrolled-keys).
>>
>> I have three questions:
>>
>>
>> (1) According to
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibvirt.org%2Fformatdomain.html%23launch-security&amp;data=04%7C01%7Cthomas.lendacky%40amd.com%7Ca80df30ddbc54479df1008d904ab7ab8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637545956815983695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=aQ1yttPryxCjO%2B7cIPfxathftEPEKb0QYhdHI7WkWLU%3D&amp;reserved=0>, SEV-ES is
>> explicitly requested in the domain XML via setting bit#2 in the "policy"
>> element.
>>
>> Can this setting be used by libvirt to look for such a firmware
>> descriptor that exposes @amd-sev-es?
>>
>>
>> (2) "docs/interop/firmware.json" documents @amd-sev as follows:
>>
>> # @amd-sev: The firmware supports running under AMD Secure Encrypted
>> #           Virtualization, as specified in the AMD64 Architecture
>> #           Programmer's Manual. QEMU command line options related to
>> #           this feature are documented in
>> #           "docs/amd-memory-encryption.txt".
>>
>> Documenting the new @amd-sev-es enum constant with very slight
>> customizations for the same text should be possible, I reckon. However,
>> "docs/amd-memory-encryption.txt" (nor
>> "docs/confidential-guest-support.txt") seem to mention SEV-ES.
>>
>> Can you guys propose a patch for "docs/amd-memory-encryption.txt"?
> 
> Yes, I can submit a patch to update the documentation.

Thank you, I've made some comments there.

Laszlo

> 
>>
>> I guess that would be next to this snippet:
>>
>>> # ${QEMU} \
>>>    sev-guest,id=sev0,policy=0x1...\
>>
>>
>> (3) Is the "AMD64 Architecture Programmer's Manual" the specification
>> that we should reference under @amd-sev-es as well (i.e., same as with
>> @amd-sev), or is there a more specific document?
> 
> Yes, the same specification applies to SEV-ES.
> 
> Thanks,
> Tom
> 
>>
>> Thanks,
>> Laszlo
>>
> 

Re: firmware selection for SEV-ES

[Michal Privoznik]

On 4/22/21 4:13 PM, Laszlo Ersek wrote:
> On 04/21/21 13:51, Pavel Hrdina wrote:
>> On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
>>> Hi Brijesh, Tom,
>>>
>>> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
>>> has a constant called @amd-sev. We should introduce an @amd-sev-es
>>> constant as well, minimally for the following reason:
>>>
>>> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
>>> Standardization") revision 1.40 says in "4.6 System Management Mode
>>> (SMM)" that "SMM will not be supported in this version of the
>>> specification". This is reflected in OVMF, so an OVMF binary that's
>>> supposed to run in a SEV-ES guest must be built without "-D
>>> SMM_REQUIRE". (As a consequence, such a binary should be built also
>>> without "-D SECURE_BOOT_ENABLE".)
>>>
>>> At the level of "docs/interop/firmware.json", this means that management
>>> applications should be enabled to look for the @amd-sev-es feature (and
>>> it also means, for OS distributors, that any firmware descriptor
>>> exposing @amd-sev-es will currently have to lack all three of:
>>> @requires-smm, @secure-boot, @enrolled-keys).
>>>
>>> I have three questions:
>>>
>>>
>>> (1) According to
>>> <https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
>>> explicitly requested in the domain XML via setting bit#2 in the "policy"
>>> element.
>>>
>>> Can this setting be used by libvirt to look for such a firmware
>>> descriptor that exposes @amd-sev-es?
>>
>> Hi Laszlo and all,
>>
>> Currently we use only <launchSecurity type='sev'> when selecting
>> firmware to make sure that it supports @amd-sev. Since we already have a
>> place in the VM XML where users can configure amd-sev-as we can use that
>> information when selecting correct firmware that should be used for the
>> VM.
> 
> Thanks!
> 
> Should we file a libvirtd Feature Request (where?) for recognizing the
> @amd-sev-es feature flag?

Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you 
want to do it yourself or shall I help you with that?

Michal

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/23/21 10:16, Michal Privoznik wrote:
> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
>> On 04/21/21 13:51, Pavel Hrdina wrote:
>>> On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
>>>> Hi Brijesh, Tom,
>>>>
>>>> in QEMU's "docs/interop/firmware.json", the @FirmwareFeature
>>>> enumeration
>>>> has a constant called @amd-sev. We should introduce an @amd-sev-es
>>>> constant as well, minimally for the following reason:
>>>>
>>>> AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
>>>> Standardization") revision 1.40 says in "4.6 System Management Mode
>>>> (SMM)" that "SMM will not be supported in this version of the
>>>> specification". This is reflected in OVMF, so an OVMF binary that's
>>>> supposed to run in a SEV-ES guest must be built without "-D
>>>> SMM_REQUIRE". (As a consequence, such a binary should be built also
>>>> without "-D SECURE_BOOT_ENABLE".)
>>>>
>>>> At the level of "docs/interop/firmware.json", this means that
>>>> management
>>>> applications should be enabled to look for the @amd-sev-es feature (and
>>>> it also means, for OS distributors, that any firmware descriptor
>>>> exposing @amd-sev-es will currently have to lack all three of:
>>>> @requires-smm, @secure-boot, @enrolled-keys).
>>>>
>>>> I have three questions:
>>>>
>>>>
>>>> (1) According to
>>>> <https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
>>>> explicitly requested in the domain XML via setting bit#2 in the
>>>> "policy"
>>>> element.
>>>>
>>>> Can this setting be used by libvirt to look for such a firmware
>>>> descriptor that exposes @amd-sev-es?
>>>
>>> Hi Laszlo and all,
>>>
>>> Currently we use only <launchSecurity type='sev'> when selecting
>>> firmware to make sure that it supports @amd-sev. Since we already have a
>>> place in the VM XML where users can configure amd-sev-as we can use that
>>> information when selecting correct firmware that should be used for the
>>> VM.
>>
>> Thanks!
>>
>> Should we file a libvirtd Feature Request (where?) for recognizing the
>> @amd-sev-es feature flag?
> 
> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you
> want to do it yourself or shall I help you with that?

Please go ahead, I appreciate your help! :)

Thanks!
Laszlo

Re: firmware selection for SEV-ES

[Pavel Hrdina]

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

On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
> > On 04/21/21 13:51, Pavel Hrdina wrote:
> > > On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
> > > > Hi Brijesh, Tom,
> > > > 
> > > > in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
> > > > has a constant called @amd-sev. We should introduce an @amd-sev-es
> > > > constant as well, minimally for the following reason:
> > > > 
> > > > AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
> > > > Standardization") revision 1.40 says in "4.6 System Management Mode
> > > > (SMM)" that "SMM will not be supported in this version of the
> > > > specification". This is reflected in OVMF, so an OVMF binary that's
> > > > supposed to run in a SEV-ES guest must be built without "-D
> > > > SMM_REQUIRE". (As a consequence, such a binary should be built also
> > > > without "-D SECURE_BOOT_ENABLE".)
> > > > 
> > > > At the level of "docs/interop/firmware.json", this means that management
> > > > applications should be enabled to look for the @amd-sev-es feature (and
> > > > it also means, for OS distributors, that any firmware descriptor
> > > > exposing @amd-sev-es will currently have to lack all three of:
> > > > @requires-smm, @secure-boot, @enrolled-keys).
> > > > 
> > > > I have three questions:
> > > > 
> > > > 
> > > > (1) According to
> > > > <https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
> > > > explicitly requested in the domain XML via setting bit#2 in the "policy"
> > > > element.
> > > > 
> > > > Can this setting be used by libvirt to look for such a firmware
> > > > descriptor that exposes @amd-sev-es?
> > > 
> > > Hi Laszlo and all,
> > > 
> > > Currently we use only <launchSecurity type='sev'> when selecting
> > > firmware to make sure that it supports @amd-sev. Since we already have a
> > > place in the VM XML where users can configure amd-sev-as we can use that
> > > information when selecting correct firmware that should be used for the
> > > VM.
> > 
> > Thanks!
> > 
> > Should we file a libvirtd Feature Request (where?) for recognizing the
> > @amd-sev-es feature flag?
> 
> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
> do it yourself or shall I help you with that?

This BZ looks like it's already tracking support for amd-sev-es [1].

Pavel.

[1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/23/21 12:31, Pavel Hrdina wrote:
> On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
>> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
>>> On 04/21/21 13:51, Pavel Hrdina wrote:

>>> Should we file a libvirtd Feature Request (where?) for recognizing the
>>> @amd-sev-es feature flag?
>>
>> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
>> do it yourself or shall I help you with that?
> 
> This BZ looks like it's already tracking support for amd-sev-es [1].
> 
> Pavel.
> 
> [1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>

That's a private RHBZ that tracks SEV-ES for a product that is different
from "libvirt upstream".

Thanks
Laszlo

Re: firmware selection for SEV-ES

[Pavel Hrdina]

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

On Fri, Apr 23, 2021 at 02:34:02PM +0200, Laszlo Ersek wrote:
> On 04/23/21 12:31, Pavel Hrdina wrote:
> > On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
> >> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
> >>> On 04/21/21 13:51, Pavel Hrdina wrote:
> 
> >>> Should we file a libvirtd Feature Request (where?) for recognizing the
> >>> @amd-sev-es feature flag?
> >>
> >> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
> >> do it yourself or shall I help you with that?
> > 
> > This BZ looks like it's already tracking support for amd-sev-es [1].
> > 
> > Pavel.
> > 
> > [1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>
> 
> That's a private RHBZ that tracks SEV-ES for a product that is different
> from "libvirt upstream".

I didn't notice that's a private RHBZ, thanks for pointing it out.

For upstream libvirt we no longer use RHBZ to track RFEs/BZs, we use
gitlab issues so if we want to track the work in upstream as well I can
create a new issue.

Pavel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/23/21 15:01, Pavel Hrdina wrote:
> On Fri, Apr 23, 2021 at 02:34:02PM +0200, Laszlo Ersek wrote:
>> On 04/23/21 12:31, Pavel Hrdina wrote:
>>> On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
>>>> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
>>>>> On 04/21/21 13:51, Pavel Hrdina wrote:
>>
>>>>> Should we file a libvirtd Feature Request (where?) for recognizing the
>>>>> @amd-sev-es feature flag?
>>>>
>>>> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
>>>> do it yourself or shall I help you with that?
>>>
>>> This BZ looks like it's already tracking support for amd-sev-es [1].
>>>
>>> Pavel.
>>>
>>> [1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>
>>
>> That's a private RHBZ that tracks SEV-ES for a product that is different
>> from "libvirt upstream".
> 
> I didn't notice that's a private RHBZ, thanks for pointing it out.
> 
> For upstream libvirt we no longer use RHBZ to track RFEs/BZs, we use
> gitlab issues so if we want to track the work in upstream as well I can
> create a new issue.

Heh, I suspected I was missing something there :) Yes, please, if you or
Michal could create a new issue in gitlab, that would be great.

Thanks
Laszlo

Re: firmware selection for SEV-ES

[Pavel Hrdina]

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

On Fri, Apr 23, 2021 at 03:06:49PM +0200, Laszlo Ersek wrote:
> On 04/23/21 15:01, Pavel Hrdina wrote:
> > On Fri, Apr 23, 2021 at 02:34:02PM +0200, Laszlo Ersek wrote:
> >> On 04/23/21 12:31, Pavel Hrdina wrote:
> >>> On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
> >>>> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
> >>>>> On 04/21/21 13:51, Pavel Hrdina wrote:
> >>
> >>>>> Should we file a libvirtd Feature Request (where?) for recognizing the
> >>>>> @amd-sev-es feature flag?
> >>>>
> >>>> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
> >>>> do it yourself or shall I help you with that?
> >>>
> >>> This BZ looks like it's already tracking support for amd-sev-es [1].
> >>>
> >>> Pavel.
> >>>
> >>> [1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>
> >>
> >> That's a private RHBZ that tracks SEV-ES for a product that is different
> >> from "libvirt upstream".
> > 
> > I didn't notice that's a private RHBZ, thanks for pointing it out.
> > 
> > For upstream libvirt we no longer use RHBZ to track RFEs/BZs, we use
> > gitlab issues so if we want to track the work in upstream as well I can
> > create a new issue.
> 
> Heh, I suspected I was missing something there :) Yes, please, if you or
> Michal could create a new issue in gitlab, that would be great.

I've created a new libvirt issue [1], hopefully the description makes
sense. :)

Pavel

[1] <https://gitlab.com/libvirt/libvirt/-/issues/156>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: firmware selection for SEV-ES

[Laszlo Ersek]

On 04/23/21 19:36, Pavel Hrdina wrote:
> On Fri, Apr 23, 2021 at 03:06:49PM +0200, Laszlo Ersek wrote:
>> On 04/23/21 15:01, Pavel Hrdina wrote:
>>> On Fri, Apr 23, 2021 at 02:34:02PM +0200, Laszlo Ersek wrote:
>>>> On 04/23/21 12:31, Pavel Hrdina wrote:
>>>>> On Fri, Apr 23, 2021 at 10:16:24AM +0200, Michal Privoznik wrote:
>>>>>> On 4/22/21 4:13 PM, Laszlo Ersek wrote:
>>>>>>> On 04/21/21 13:51, Pavel Hrdina wrote:
>>>>
>>>>>>> Should we file a libvirtd Feature Request (where?) for recognizing the
>>>>>>> @amd-sev-es feature flag?
>>>>>>
>>>>>> Yes, we should. We can use RedHat bugzilla for that. Laszlo - do you want to
>>>>>> do it yourself or shall I help you with that?
>>>>>
>>>>> This BZ looks like it's already tracking support for amd-sev-es [1].
>>>>>
>>>>> Pavel.
>>>>>
>>>>> [1] <https://bugzilla.redhat.com/show_bug.cgi?id=1895035>
>>>>
>>>> That's a private RHBZ that tracks SEV-ES for a product that is different
>>>> from "libvirt upstream".
>>>
>>> I didn't notice that's a private RHBZ, thanks for pointing it out.
>>>
>>> For upstream libvirt we no longer use RHBZ to track RFEs/BZs, we use
>>> gitlab issues so if we want to track the work in upstream as well I can
>>> create a new issue.
>>
>> Heh, I suspected I was missing something there :) Yes, please, if you or
>> Michal could create a new issue in gitlab, that would be great.
> 
> I've created a new libvirt issue [1], hopefully the description makes
> sense. :)
> 
> Pavel
> 
> [1] <https://gitlab.com/libvirt/libvirt/-/issues/156>

Looks good to me, thank you!
Laszlo