On Fri, 2017-07-21 at 14:51 -0400, John Ferlan wrote:
> > Not your fault of course, but the way this is done at the
> > moment is *extremely* yucky.
> >
> > I just posted a patch[1] that makes it saner, and although I
> > realize that's a bit more work I'd ask you to wait for it to
> > land in mas
On 07/21/2017 06:52 AM, Andrea Bolognani wrote:
> On Thu, 2017-07-20 at 13:56 -0600, dann frazier wrote:
>> @@ -131,6 +131,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr
>> def)
>> #define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd"
>> #define VIR_QEMU_AAVMF_LOADE
On Thu, 2017-07-20 at 13:56 -0600, dann frazier wrote:
> @@ -131,6 +131,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def)
> #define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd"
> #define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd"
> #define VIR_QEMU_A
On 07/20/2017 03:56 PM, dann frazier wrote:
> Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using.
> libvirt is the de facto canonical location for defining where distros
> should place these firmware images, so let's define this path here to try
> and minimize distro fragm
Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using.
libvirt is the de facto canonical location for defining where distros
should place these firmware images, so let's define this path here to try
and minimize distro fragmentation.
---
src/qemu/qemu.conf
