OVMF package : Question about Qemu/Xen support

OVMF package : Question about Qemu/Xen support

[Tiger Liu(BJ-RD)]

Hi, experts:
I have a question about Ovmf.

Must Ovmf be run with qemu tool?
Or It could be run with Xen without needed qemu software.

It seems Xen began to support uefi boot from 4.4 version.

Thanks


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

Re: OVMF package : Question about Qemu/Xen support

[Laszlo Ersek]

On 03/05/18 06:49, Tiger Liu(BJ-RD) wrote:
> Hi, experts:
> I have a question about Ovmf.
> 
> Must Ovmf be run with qemu tool?
> Or It could be run with Xen without needed qemu software.
> 
> It seems Xen began to support uefi boot from 4.4 version.

- From the Xen wiki:

https://wiki.xenproject.org/wiki/OVMF

> One thing to have in mind is Xen supports both its own QEMU fork
> called qemu-traditional and upstream QEMU called qemu-xen. OVMF only
> supports the latter. Xen 4.4 has upstream QEMU configured for all HVM
> guests by default, so it is fine to not specify which QEMU to use in
> guest config file. But if you have already configured qemu-traditional
> for your guest you would need to delete / comment out that line.

See also

https://wiki.xenproject.org/wiki/Xen_Project_Release_Features#Device_Models_and_Virtual_Firmware

- I'm also CC'ing the OVMF reviewers for Xen (from the "Maintainers.txt"
file).

Thanks
Laszlo

答复: OVMF package : Question about Qemu/Xen support

[Tiger Liu(BJ-RD)]

Hi, Laszlo:
Got it!

Thanks a lot!

Best wishes,
-----邮件原件-----
发件人: Laszlo Ersek [mailto:lersek@redhat.com]
发送时间: 2018年3月5日 17:15
收件人: Tiger Liu(BJ-RD) <TigerLiu@zhaoxin.com>
抄送: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>; Anthony Perard <anthony.perard@citrix.com>; Julien Grall <julien.grall@linaro.org>
主题: Re: [edk2] OVMF package : Question about Qemu/Xen support

On 03/05/18 06:49, Tiger Liu(BJ-RD) wrote:
> Hi, experts:
> I have a question about Ovmf.
>
> Must Ovmf be run with qemu tool?
> Or It could be run with Xen without needed qemu software.
>
> It seems Xen began to support uefi boot from 4.4 version.

- From the Xen wiki:

https://wiki.xenproject.org/wiki/OVMF

> One thing to have in mind is Xen supports both its own QEMU fork
> called qemu-traditional and upstream QEMU called qemu-xen. OVMF only
> supports the latter. Xen 4.4 has upstream QEMU configured for all HVM
> guests by default, so it is fine to not specify which QEMU to use in
> guest config file. But if you have already configured qemu-traditional
> for your guest you would need to delete / comment out that line.

See also

https://wiki.xenproject.org/wiki/Xen_Project_Release_Features#Device_Models_and_Virtual_Firmware

- I'm also CC'ing the OVMF reviewers for Xen (from the "Maintainers.txt"
file).

Thanks
Laszlo


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

Re: OVMF package : Question about Qemu/Xen support

[Tiger Liu(BJ-RD)]

Hi, Laszlo:
I have a question you would like to ask you.
Could I study pcie native hot plug feature with ovmf?

It seems qemu emulates Q35 chipset.
And ovmf provides PciHotPlugInitDxe driver.

Thanks

Best wishes,
-----邮件原件-----
发件人: Laszlo Ersek [mailto:lersek@redhat.com]
发送时间: 2018年3月5日 17:15
收件人: Tiger Liu(BJ-RD) <TigerLiu@zhaoxin.com>
抄送: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>; Anthony Perard <anthony.perard@citrix.com>; Julien Grall <julien.grall@linaro.org>
主题: Re: [edk2] OVMF package : Question about Qemu/Xen support

On 03/05/18 06:49, Tiger Liu(BJ-RD) wrote:
> Hi, experts:
> I have a question about Ovmf.
>
> Must Ovmf be run with qemu tool?
> Or It could be run with Xen without needed qemu software.
>
> It seems Xen began to support uefi boot from 4.4 version.

- From the Xen wiki:

https://wiki.xenproject.org/wiki/OVMF

> One thing to have in mind is Xen supports both its own QEMU fork
> called qemu-traditional and upstream QEMU called qemu-xen. OVMF only
> supports the latter. Xen 4.4 has upstream QEMU configured for all HVM
> guests by default, so it is fine to not specify which QEMU to use in
> guest config file. But if you have already configured qemu-traditional
> for your guest you would need to delete / comment out that line.

See also

https://wiki.xenproject.org/wiki/Xen_Project_Release_Features#Device_Models_and_Virtual_Firmware

- I'm also CC'ing the OVMF reviewers for Xen (from the "Maintainers.txt"
file).

Thanks
Laszlo


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

Re: OVMF package : Question about Qemu/Xen support

[Laszlo Ersek]

Hi,

(CC Marcel)

On 04/02/18 08:55, Tiger Liu(BJ-RD) wrote:
> Hi, Laszlo:
> I have a question you would like to ask you.
> Could I study pcie native hot plug feature with ovmf?
> 
> It seems qemu emulates Q35 chipset.
> And ovmf provides PciHotPlugInitDxe driver.

Sure. Here's some tips I can give you:

* The first PCI Express -- not traditional PCI -- hotplug feature
request for OVMF arrived in
<https://github.com/tianocore/edk2/issues/32>. That link is dead now,
because we abandoned the GitHub issue tracker. Instead, the report was
migrated to <https://bugzilla.tianocore.org/show_bug.cgi?id=75>.

This issue got solved by adding MMCONFIG (ECAM) config space access to
OVMF. Without MMCONFIG, PCIe hotplug in the guest OS would not work.
Please see Marcel's analysis in the TianoCore BZ linked above. The edk2
commit range is noted in comment 32.

* Once config space access works like that, you need the PCIe
enumeration / resource assignment (which occurs in the firmware) to
account for PCI resources *in advance* that hotplugged endpoints *might*
require. This means reserving various kinds of apertures. On the QEMU
side, this is documented in the following two text files (in the QEMU tree):

- docs/pcie.txt
- docs/pcie_pci_bridge.txt

In particular there is a "resource reservation hint" PCIe capability
(for PCIe root ports) that QEMU can populate and OVMF can parse. Then
OVMF informs PciBusDxe to reserve the appropriate resources.

* PCI_HOT_PLUG_INIT_PROTOCOL (implemented in OVMF by
OvmfPkg/PciHotPlugInitDxe) is defined by the PI spec. Roughly, it has
two purposes: it can (a) report+initialize non-enumerable [*] hotplug
controllers (of which QEMU has none) to PciBusDxe, (b) it can convey
reservation hints ("resource paddings") to PciBusDxe. OVMF stubs out the
two interfaces related to purpose (a), and implements the
GetResourcePadding() member function (purpose (b)) by translating QEMU's
PCIe capability to the format expected by the PI spec and PciBusDxe.

[*] The PI spec calls this kind of hotplug controller "root" HPC, but
that has nothing to do with "root" in the PCIe sense. In this
terminology, "root HPC" simply means "non-enumerable", and "non-root
HPC" means "enumerable" through the normal PCI(e) traversal.


Hope this helps,
Laszlo

Re: OVMF package : Question about Qemu/Xen support

[Tiger Liu(BJ-RD)]

Hi, Laszlo:
Got it!

Thank you very much!

Best wishes,

-----邮件原件-----
发件人: Laszlo Ersek [mailto:lersek@redhat.com]
发送时间: 2018年4月3日 18:36
收件人: Tiger Liu(BJ-RD) <TigerLiu@zhaoxin.com>
抄送: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>; Anthony Perard <anthony.perard@citrix.com>; Julien Grall <julien.grall@linaro.org>; Marcel Apfelbaum <marcel@redhat.com>
主题: Re: [edk2] OVMF package : Question about Qemu/Xen support

Hi,

(CC Marcel)

On 04/02/18 08:55, Tiger Liu(BJ-RD) wrote:
> Hi, Laszlo:
> I have a question you would like to ask you.
> Could I study pcie native hot plug feature with ovmf?
>
> It seems qemu emulates Q35 chipset.
> And ovmf provides PciHotPlugInitDxe driver.

Sure. Here's some tips I can give you:

* The first PCI Express -- not traditional PCI -- hotplug feature request for OVMF arrived in <https://github.com/tianocore/edk2/issues/32>. That link is dead now, because we abandoned the GitHub issue tracker. Instead, the report was migrated to <https://bugzilla.tianocore.org/show_bug.cgi?id=75>.

This issue got solved by adding MMCONFIG (ECAM) config space access to OVMF. Without MMCONFIG, PCIe hotplug in the guest OS would not work.
Please see Marcel's analysis in the TianoCore BZ linked above. The edk2 commit range is noted in comment 32.

* Once config space access works like that, you need the PCIe enumeration / resource assignment (which occurs in the firmware) to account for PCI resources *in advance* that hotplugged endpoints *might* require. This means reserving various kinds of apertures. On the QEMU side, this is documented in the following two text files (in the QEMU tree):

- docs/pcie.txt
- docs/pcie_pci_bridge.txt

In particular there is a "resource reservation hint" PCIe capability (for PCIe root ports) that QEMU can populate and OVMF can parse. Then OVMF informs PciBusDxe to reserve the appropriate resources.

* PCI_HOT_PLUG_INIT_PROTOCOL (implemented in OVMF by
OvmfPkg/PciHotPlugInitDxe) is defined by the PI spec. Roughly, it has two purposes: it can (a) report+initialize non-enumerable [*] hotplug controllers (of which QEMU has none) to PciBusDxe, (b) it can convey reservation hints ("resource paddings") to PciBusDxe. OVMF stubs out the two interfaces related to purpose (a), and implements the
GetResourcePadding() member function (purpose (b)) by translating QEMU's PCIe capability to the format expected by the PI spec and PciBusDxe.

[*] The PI spec calls this kind of hotplug controller "root" HPC, but that has nothing to do with "root" in the PCIe sense. In this terminology, "root HPC" simply means "non-enumerable", and "non-root HPC" means "enumerable" through the normal PCI(e) traversal.


Hope this helps,
Laszlo


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.