Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

[Alex Williamson]

On Fri, 11 Aug 2017 02:34:26 +0200
Laszlo Ersek <ler...@redhat.com> wrote:
> Cc: Alex Williamson <alex.william...@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Yonghong Zhu <yonghong@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 1fa3ca3ceae9..2ef495540e5f 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -5335,10 +5335,10 @@ RELEASE_GCC5_IA32_DLINK_FLAGS= 
> DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Os -Wl,
>  *_GCC5_X64_OBJCOPY_FLAGS =
>  *_GCC5_X64_NASM_FLAGS= -f elf64
>  
> -  DEBUG_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO 
> -Os
> +  DEBUG_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -fno-pie 
> -mcmodel=large -flto -DUSING_LTO -Os
>DEBUG_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  
> -RELEASE_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO 
> -Os -Wno-unused-but-set-variable
> +RELEASE_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -fno-pie 
> -mcmodel=large -flto -DUSING_LTO -Os -Wno-unused-but-set-variable
>  RELEASE_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  
>NOOPT_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -O0

VM boots again, Thanks Laszlo!

Tested-by: Alex Williamson <alex.william...@redhat.com>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PCIe hotplug into downstream port

[Alex Williamson]

On Thu, 30 Jun 2016 15:07:27 +0200
Laszlo Ersek  wrote:
> - What could be the difference between root ports and downstream ports?
>   (Hotplug into root ports seems to work fine.) Are OSes entitled to
>   allocate any unused address space (MMIO and IO) right when a device is
>   hot-plugged into a root port?

A possible difference is simply the depth of the hierarchy, the
apertures on a root port come directly from the host bridge and there's
no affect to other devices to disable and resize the root port
apertures.  In order to resize a switch downstream port aperture, the
OS would need to touch multiple levels, which could affect peer devices
already in operation.  Does hotplug to a downstream switch port work if
the hot added device is the only endpoint within that sub-hierarchy?  I
wouldn't necessarily be surprised either way, it seems like a
complicated resource runtime reallocation issue that probably isn't
very prevalent on real hardware.  Thanks,

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

Re: [edk2] PcdSrIovSupport

[Alex Williamson]

On Mon, 20 Jun 2016 16:02:59 +0200
Laszlo Ersek  wrote:

> Hi,
> 
> I posted a related question in
> 
>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/13381
> 
> but I thought I'd approach it from another angle, more succinctly.
> 
> If I set PcdSrIovSupport to FALSE, what functionality exactly will
> become unavailable in the firmware? I tried to grep the source for it,
> but since I'm not familiar with virtual functions at all, I couldn't
> learn much from the code.
> 
> From
> ,
> 
>   The SR-IOV allows different virtual machines (VMs) in a virtual
>   environment to share a single PCI Express hardware interface.
> 
> Furthermore, the following edk2 commit:
> 
>   https://github.com/tianocore/edk2/commit/d40483911c83
> 
> says
> 
>   Change type of PcdSrIovSupport, PcdAriSupport, PcdMrIovSupport from
>   FeatureFlag to [FixAtBuild, PcdDynamics], which allows
>   SR-IOV/MR-IOV/ARI feature can be turn on/off dynamically, typically
>   via a setup option.
> 
> Thus it seems to me that PcdSrIovSupport only makes sense in firmware
> for physical hosts, not virtual machines (unless we talk nested virt of
> course, but I believe nested virt with QEMU/KVM/VFIO isn't that far
> advanced yet). I believe PcdSrIovSupport controls, in the host UEFI
> firmware, whether the SR-IOV capability will be available to the
> *hypervisor* that runs on the host machine.
> 
> Is that correct? If it is, then I'm going to submit a patch that
> disables PcdSrIovSupport for OVMF.

As I noted in the bz that spawned this discussion, there are folks that
seem to think that enabling SR-IOV from a guest owned PF is not a
completely insane thing to do:

http://www.spinics.net/lists/kvm/msg134370.html

They would probably be sad to see such a change and re-introducing OVMF
SR-IOV support in the cases where it's needed seems painful.  As I
mentioned last week, I'm open to vfio fixes for this as well, whether
it's in QEMU or the kernel.  The more I think about it, the more I
suspect we're asking something unreasonable of OVMF to detect fixed
VFBARs, no matter how convenient or robust we might think it would be
to do so.  Now I'm wondering if we should a) hide the capability from
the VM in QEMU (or host kernel?) or b) enable virtualization of the
VFBARs for proper sizing while leaving the rest of the capability
read-only.  I'm not sure the latter has much value, it may just lead to
further issues.  Thanks,

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