On Sat, Aug 3, 2013 at 9:01 PM, Laine Stump <laine@xxxxxxxxx> wrote:
> Current seabios doesn't recognize any disk device that is attached
> anywhere behind an i82801b11-bridge, so it can't boot from them. (It's
> possible/probable that seabios simply doesn't recognize that bridge at
> all, so *no* devices behind it are available to the bios). In order to
> allow booting from any disk no matter where it is attached, this patch
> flouts the hardware specs (which say that only PCIe devices can be
> connected directly to a PCIe bus such as the q35 machine's "pcie.0"),
> taking advantage of the fact that qemu also ignores this rule, and
> installs a stnadard pci-bridge device anywhere the config requests a
> "dmi-to-pci-bridge (which had been setup to use i82801b11-bridge).
>
> Because this isn't really the way things should be, the original code
> is left in place, and the new code is put inside an #ifdef indicating
> why it is there.
> ---
> src/qemu/qemu_command.c | 16 ++++++++++++++++
> tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 2 +-
> tests/qemuxml2argvdata/qemuxml2argv-q35.args | 2 +-
> 3 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 3353c61..460144f 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -4571,7 +4571,23 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef,
> _("dmi-to-pci-bridge index should be > 0"));
> goto error;
> }
> +#define SEABIOS_NO_I82801B11_SUPPORT
> +#if defined SEABIOS_NO_I82801B11_SUPPORT
> + /* since seabios currently doesn't recognize boot devices
> + * that are anywhere behind an i82801b11-bridge, we take
> + * advantage of the fact that qemu erroneously
> + * (generously) allows us to plug a pci-bridge into a PCIe
> + * slot, and create a pci-bridge to take the place of the
> + * i82801b11-bridge. When seabios is fixed, we will figure
> + * out the best way to determine whether or not the fix is
> + * present, and switch to the more proper device when
> + * appropriate.
> + */
> + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=%d,id=pci.%d",
> + def->idx, def->idx);
> +#else
> virBufferAsprintf(&buf, "i82801b11-bridge,id=pci.%d", def->idx);
> +#endif
> break;
> case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
> case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
> index 84428f9..da970db 100644
> --- a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
> @@ -1,5 +1,5 @@
> LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/libexec/qemu-kvm \
> -S -M q35 -m 2048 -smp 2 -nographic -nodefaults \
> -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \
> --device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x2 \
> +-device pci-bridge,chassis_nr=1,id=pci.1,bus=pcie.0,addr=0x2 \
> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1
> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35.args b/tests/qemuxml2argvdata/qemuxml2argv-q35.args
> index 5ff4bc7..a0ec66e 100644
> --- a/tests/qemuxml2argvdata/qemuxml2argv-q35.args
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-q35.args
> @@ -1,6 +1,6 @@
> LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \
> /usr/libexec/qemu-kvm -S -M q35 -m 2048 -smp 2 -nographic -nodefaults \
> -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \
> --device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x2 \
> +-device pci-bridge,chassis_nr=1,id=pci.1,bus=pcie.0,addr=0x2 \
> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
> -vga qxl -global qxl.ram_size=67108864 -global qxl.vram_size=18874368
> --
> 1.7.11.7
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
While this certainly works, I'll wait until Eric or Dan weigh in on
migration concerns with this approach as well as correctness (QEMU
allowing you to attach PCI devices to PCIe buses and vis versa). If
this approach is the one that goes forward, then consider this an ACK
of this patch.
--
Doug Goldstein
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list