* [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support @ 2015-07-17 14:37 Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 1/7] ipxe: update from 35c53797 to 24112d9 (upstream/master) Gerd Hoffmann ` (7 more replies) 0 siblings, 8 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann Hi, This pull finally fixes the efi boot support. ipxe is updated to the latest master, two non-upstream commits needed to make efi work are added on top, and the build process is tweaked a bit. The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git before merging this pull request. please pull, Gerd The following changes since commit 2d5ee9e7a7dd495d233cf9613a865f63f88e3375: Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150716' into staging (2015-07-16 10:40:23 +0100) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-ipxe-20150717-1 for you to fetch changes up to 4f0c601b71e53a7d225a1913b784242400788991: ipxe: update binaries (2015-07-16 17:39:12 +0200) ---------------------------------------------------------------- update ipxe roms, fix efi support ---------------------------------------------------------------- Gerd Hoffmann (7): ipxe: update from 35c53797 to 24112d9 (upstream/master) ipxe: update to 87981bb (qemu) ipxe: rm local config in cleanup ipxe: disable load file protocol ipxe: add qemu branding ipxe: don't override GITVERSION ipxe: update binaries pc-bios/efi-e1000.rom | Bin 197120 -> 192512 bytes pc-bios/efi-eepro100.rom | Bin 197632 -> 192512 bytes pc-bios/efi-ne2k_pci.rom | Bin 195584 -> 190976 bytes pc-bios/efi-pcnet.rom | Bin 195584 -> 190976 bytes pc-bios/efi-rtl8139.rom | Bin 200192 -> 194560 bytes pc-bios/efi-virtio.rom | Bin 194048 -> 188928 bytes roms/Makefile | 9 +++++---- roms/config.ipxe.branding.h | 2 ++ roms/config.ipxe.general.h | 1 + roms/ipxe | 2 +- 10 files changed, 9 insertions(+), 5 deletions(-) create mode 100644 roms/config.ipxe.branding.h ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 1/7] ipxe: update from 35c53797 to 24112d9 (upstream/master) 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 2/7] ipxe: update to 87981bb (qemu) Gerd Hoffmann ` (6 subsequent siblings) 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann git shortlog ============ Alex Williamson (1): [dhcp] Extract timing parameters out to config/dhcp.h Bernd Wiebelt (1): [tg3] Add support for BCM57766 Christian Hesse (3): [intel] Add PCI device IDs for Intel I218-LM and I218-V [build] Add missing "const" qualifiers [ath9k] Remove confusing logic inversion in an ANI variable Ed Swierk (1): [intel] Update PCI device IDs for Intel 82599 and X540 10G NICs Laszlo Ersek (1): [virtio] Downgrade per-iobuf debug messages to DBGC2 Michael Brown (228): [device] Provide a driver-private data field for root devices [iobuf] Add iob_split() to split an I/O buffer into portions [rndis] Add generic RNDIS device abstraction [hyperv] Add support for Hyper-V hypervisor [hyperv] Add support for VMBus devices [hyperv] Add support for NetVSC paravirtual network devices [rndis] Send RNDIS_INITIALISE_MSG [rndis] Send RNDIS_HALT_MSG [hyperv] Tear down NetVSC RX buffer GPADL after closing VMBus device [rndis] Clear receive filter when closing the device [hyperv] Receive all VMBus messages in a poll [hyperv] Increase TX ring size [hyperv] Assume that VMBus xfer page ranges correspond to RNDIS messages [rndis] Ignore start-of-day RNDIS_INDICATE_STATUS_MSG with status 0x40020006 [hyperv] Tidy up debug output [hyperv] Require support for VMBus version 3.0 or newer [build] Include Hyper-V driver in the all-drivers build [pci] Allow drivers to specify a PCI class [romprefix] Ensure UNDI loader can be included by all ROM types [usb] Add basic support for USB devices [usb] Add basic support for USB hubs [usb] Add support for xHCI host controllers [ncm] Add support for CDC-NCM USB Ethernet devices [usb] Report xHCI host controller events [ncm] Use large multi-packet buffers by default [tftp] Explicitly abort connection whenever parent interface is closed [uri] Allow tftp_uri() to construct a URI with a custom port [pxe] Use tftp_uri() to construct PXE TFTP URIs [pxe] Maintain a queue for received PXE UDP packets [ncm] Reserve headroom in received packets [usb] Try multiple USB device configurations [usb] Handle CDC union functional descriptors [usb] Parse endpoint descriptor bInterval field [usb] Allow usb_stream() to enforce a terminating short packet [ecm] Add support for CDC-ECM USB Ethernet devices [xhci] Delay after (possibly) forcing port link state to RxDetect [build] Move branding information to config/branding.h [build] Use PRODUCT_SHORT_NAME for end-user visible strings [build] Allow product URI to be customised via config/branding.h [build] Allow error message URI to be customised via config/branding.h [build] Allow command help text URI to be customised via config/branding.h [build] Allow setting help text URI to be customised via config/branding.h [build] Allow product tag line to be customised via config/branding.h [rndis] Add rndis_rx_err() [usb] Handle port status changes received after failing to find a driver [efi] Disallow R_X86_64_32 relocations [build] Apply the "-fno-PIE -nopie" workaround only to i386 builds [usb] Provide generic framework for refilling receive endpoints [usb] Use generic refill framework for USB hub interrupt endpoints [ecm] Use generic refill framework for bulk IN and interrupt endpoints [ncm] Use generic refill framework for bulk IN and interrupt endpoints [libc] Remove unused string functions [libc] Rewrite string functions [test] Add self-tests for more string functions [test] Add constant-length memset() self-tests [libc] Reduce size of memset() [usb] Add generic USB network device framework [ecm] Use generic USB network device framework [ncm] Use generic USB network device framework [timer] Rewrite the 8254 Programmable Interval Timer support [xhci] Leak memory if controller fails to disable slot [xhci] Abort commands on timeout [test] Add IPv4 self-tests [legal] Add missing copyright header to net/ipv4.c [ipv4] Rewrite inet_aton() [libc] Rewrite strtoul() [hyperv] Check for required features [prefix] Use .bss16 as temporary stack space for calls to install_block [zbin] Use LZMA compression [zbin] Perform extra normalisation after completing decompression [prefix] Call decompressor in flat real mode when DEBUG=libprefix is enabled [zbin] Allow decompressor to generate debug output via BIOS console [zbin] Fix check for existence of most recent output byte [zbin] Remove now-unused unnrv2b.S decompressor [legal] Update GPLv2 licence text [legal] Include full licence text for all GPL2_OR_LATER files [mucurses] Add missing FILE_LICENCE declarations [legal] Add support for the Unmodified Binary Distribution Licence [legal] Add UBDL relicensing tool [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [libc] Rewrite unrelicensable portions of stddef.h [libc] Rewrite unrelicensable portions of ctype.h [libc] Rewrite setjmp() and longjmp() [libc] Rewrite byte-swapping code [elf] Rewrite ELF header [list] Relicense list.h [iscsi] Rewrite unrelicensable portions of iscsi.c [pci] Remove outdated and mostly-unused pci_ids.h file [pci] Rewrite unrelicensable portions of pci.h [settings] Use list_first_entry() when unregistering child settings [settings] Rewrite unrelicensable portions of settings.c [menu] Abstract out the generic concept of a jump scroller [settings] Use generic jump scrolling abstraction [malloc] Move valgrind headers out of arch/x86 [malloc] Rewrite unrelicensable portions of malloc.c [build] Remove unused IMPORT_SYMBOL() and EXPORT_SYMBOL() macros [build] Remove unused __keepme macro [pxe] Remove obsolete references to pxeparent_dhcp [build] Remove obsolete and unused portions of config.c [build] Use REQUIRE_OBJECT() to drag in per-object configuration [build] Fix the REQUIRE_SYMBOL mechanism [i386] Move real_to_user() to realmode.h [linux] Rewrite headers included in all builds [retry] Rewrite unrelicensable portions of retry.c [retry] Colourise debug output [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [xhci] Enable USB3 ports on Intel PCH8/PCH9 controllers [xhci] Undo PCH-specific quirk fixes when removing device [xen] Set the "feature-rx-notify" flag for netfront devices [http] Abstract out HTTP Digest hash algorithm operations [http] Support MD5-sess Digest authentication [dm96xx] Add driver for Davicom DM96xx USB Ethernet NICs [legal] Relicense Davicom DM96xx drivers [mii] Add generic mii_check_link() function [smsc75xx] Add driver for SMSC/Microchip LAN75xx USB Ethernet NICs [legal] Relicense files under GPL2_OR_LATER_OR_UBDL [tcp] Implement support for TCP Selective Acknowledgements (SACK) [smsc75xx] Move RX FIFO overflow message to DBGLVL_EXTRA [tcpip] Fix dubious calculation of min_port [libc] Add ffs(), ffsl(), and ffsll() [usb] Add the concept of a USB bus maximum transfer size [ncm] Respect maximum transfer size of the bus [usb] Add functions for manual device address assignment [xhci] Forcibly disable SMIs if BIOS fails to release ownership [autoboot] Match against parent devices when matching by bus type and location [usb] Add config/usb.h for USB configuration options [xhci] Do not release ownership back to BIOS when booting an OS [ehci] Add support for EHCI host controllers [netdevice] Add missing bus types to netdev_fetch_bustype() [usb] Fix USB timeouts to match specification [libprefix] Fix building on 64-bit FreeBSD 8.4 [xhci] Ring doorbell as part of endpoint reset [usb] Reset endpoints without waiting for a new transfer to be enqueued [usb] Add clear_tt() hub method to clear transaction translator buffer [usb] Clear transaction translator buffers when applicable [ehci] Support USB1 devices attached via transaction translators [usb] Improve debug messages for failed control transactions [xhci] Support USB1 devices attached via transaction translators [libc] Fix typo in longjmp() [libc] Add x86_64 versions of setjmp() and longjmp() [test] Add setjmp()/longjmp() self-tests [test] Simplify digest algorithm self-tests [crypto] Add SHA-224 algorithm [crypto] Add SHA-512 algorithm [crypto] Add SHA-384 algorithm [crypto] Add SHA-512/256 algorithm [crypto] Add SHA-512/224 algorithm [efi] Ensure drivers are disconnected when ExitBootServices() is called [peerdist] Add support for decoding PeerDist Content Information [xhci] Always reset root hub ports [romprefix] Allow autoboot device filter to be disabled [util] Add ability to dump PCI device ID list [efi] Add EFI entropy source [efi] Add EFI time source [efi] Provide a dummy data block in nii_initialise() [efi] Poll media status only if advertised as supported [efi] Poll for TX completions only when there is an outstanding TX buffer [efi] Use the EFI_RNG_PROTOCOL as an entropy source if available [eepro100] Remove duplicate PCI_ROM() line [prism2] Remove duplicate PCI_ROM() lines [build] Allow building PCI ROMs with device ID lists [build] Fix compiler warning on OpenBSD 5.7 [build] Work around binutils quirk on OpenBSD 5.7 [build] Use a single call to parserom.pl to speed up building [intel] Report any unexpected interrupt causes [intel] Force RX polling on VMware emulated 82545em [realtek] Do not attempt to access EEPROM on RTL8169 chips [rtl818x] Obviate RTL_ROM() hack [build] Construct all-drivers list based on driver class [test] Include IPv6 support when performing settings self-tests [base16] Add buffer size parameter to base16_encode() and base16_decode() [base64] Add buffer size parameter to base64_encode() and base64_decode() [settings] Add "base64" setting type [vram] Add "vram" built-in setting to dump video RAM [usb] Include setup packet within I/O buffer for message transfers [pci] Provide PCI_CLASS() to calculate a scalar PCI class value [usb] Detect missed disconnections [usb] Maintain a list of all USB buses [usb] Maintain single lists of halted endpoints and changed ports [ehci] Poll child companion controllers after disowning port [usb] Add find_usb_bus_by_location() helper function [ehci] Allow UHCI/OHCI controllers to locate the EHCI companion controller [uhci] Add support for UHCI host controllers [usb] Provide usb_endpoint_name() for use by host controller drivers [xhci] Use meaningful device names in debug messages [ehci] Use meaningful device names in debug messages [uhci] Use meaningful device names in debug messages [ipv6] Disambiguate received ICMPv6 errors [usb] Add USB_INTERRUPT_OUT internal type [usb] Add generic USB human interface device (HID) framework [usb] Add basic support for USB keyboards [usb] Do not call usb_hotplug() when registering a new hub [usb] Always clear recorded disconnections after performing hotplug actions [intel] Expose intel_diag() for use by other Intel NIC drivers [intel] Allow for the use of advanced TX descriptors [intel] Add support for mailbox used by virtual functions [intel] Add intelxvf driver for Intel 10 GigE virtual function NICs [int13con] Add basic ability to log to a local disk via INT 13 [intel] Add intelxvf_stats() to dump packet statistics registers [intel] Fix operation when physical function has jumbo frames enabled [neighbour] Return success when deferring a packet [xhci] Fix length of allocated slot array [build] Fix .ids.o creation for drivers not in the all-drivers build [xhci] Fix comparison of signed and unsigned integers [ipoib] Fix REMAC cache discarder [xhci] Record device-specific quirks in xHCI device structure [xhci] Ignore invalid protocol speed ID values on Intel Skylake platforms [pci] Use flat real mode to call INT 1a,b101 [tcp] Do not shrink window when discarding received packets [mromprefix] Report a dummy size at offset 0x02 of .mrom payload [ethernet] Add minimal support for receiving LLC frames [netdevice] Add a generic concept of a "blocked link" [stp] Add support for detecting Spanning Tree Protocol non-forwarding ports [stp] Fix interpretaton of hello time [dhcp] Defer discovery if link is blocked [pxe] Always reconstruct packet for PXENV_GET_CACHED_INFO [serial] Add general abstraction of a 16550-compatible UART [gdb] Use new UART abstraction in GDB serial transport [serial] Use new UART abstraction in serial console driver [ipoib] Mark REMAC cache as expensive [ipoib] Attempt to generate ARPs as needed to repopulate REMAC cache [gdb] Allow gdbstub to be started on an arbitrary serial port [xen] Wait for and clear XenStore event before receiving data [tcp] Gracefully close connections during shutdown [ipoib] Transmit multicast packets as broadcasts Olaf Hering (1): [build] Sort objects in blib.a Robin Smidsrød (2): [vbox] Enable some more features now that we have LZMA compression [build] Rewrite parserom.pl to support multiple source files Thomas Miletich (1): [intel] Add PCI ID for I218-LM Wissam Shoukair (1): [comboot] Implement INT22,0x000c Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> --- roms/ipxe | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/roms/ipxe b/roms/ipxe index 35c5379..24112d9 160000 --- a/roms/ipxe +++ b/roms/ipxe @@ -1 +1 @@ -Subproject commit 35c5379760aa1fea5e38f7a78b090f92bb7813ee +Subproject commit 24112d91a0ab4c29794bc7750cbfc4166bc9026a -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 2/7] ipxe: update to 87981bb (qemu) 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 1/7] ipxe: update from 35c53797 to 24112d9 (upstream/master) Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 3/7] ipxe: rm local config in cleanup Gerd Hoffmann ` (5 subsequent siblings) 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann Add two patches we've been struggling to get upstream. They are available from "git://git.qemu.org/ipxe.git qemu" git shortlog ------------ Gerd Hoffmann (1): [efi] make load file protocol optional Laszlo Ersek (1): efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> --- roms/ipxe | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/roms/ipxe b/roms/ipxe index 24112d9..87981bb 160000 --- a/roms/ipxe +++ b/roms/ipxe @@ -1 +1 @@ -Subproject commit 24112d91a0ab4c29794bc7750cbfc4166bc9026a +Subproject commit 87981bb66f5f496f124469fb6c13aa13ee00061e -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 3/7] ipxe: rm local config in cleanup 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 1/7] ipxe: update from 35c53797 to 24112d9 (upstream/master) Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 2/7] ipxe: update to 87981bb (qemu) Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 4/7] ipxe: disable load file protocol Gerd Hoffmann ` (4 subsequent siblings) 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann ipxe build now generates empty local header files in case they are not present. Let's remove them on cleanup to make sure we store a fresh copy on the next build. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> --- roms/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/roms/Makefile b/roms/Makefile index 7b3f156..c0153c7 100644 --- a/roms/Makefile +++ b/roms/Makefile @@ -153,5 +153,6 @@ clean: $(MAKE) -C sgabios clean rm -f sgabios/.depend $(MAKE) -C ipxe/src veryclean + (cd ipxe; rm -f src/config/local/*.h) $(MAKE) -C SLOF clean rm -rf u-boot/build.e500 -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 4/7] ipxe: disable load file protocol 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann ` (2 preceding siblings ...) 2015-07-17 14:37 ` [Qemu-devel] [PULL 3/7] ipxe: rm local config in cleanup Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 5/7] ipxe: add qemu branding Gerd Hoffmann ` (3 subsequent siblings) 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann Activate the opt-out added by one not-upstream ipxe patch: [efi] make load file protocol optional Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> --- roms/config.ipxe.general.h | 1 + 1 file changed, 1 insertion(+) diff --git a/roms/config.ipxe.general.h b/roms/config.ipxe.general.h index 619ee4c..2df042a 100644 --- a/roms/config.ipxe.general.h +++ b/roms/config.ipxe.general.h @@ -2,3 +2,4 @@ #define BANNER_TIMEOUT 30 #undef ROM_BANNER_TIMEOUT #define ROM_BANNER_TIMEOUT 0 +#undef EFI_PROTO_LOAD_FILE -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 5/7] ipxe: add qemu branding 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann ` (3 preceding siblings ...) 2015-07-17 14:37 ` [Qemu-devel] [PULL 4/7] ipxe: disable load file protocol Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 6/7] ipxe: don't override GITVERSION Gerd Hoffmann ` (2 subsequent siblings) 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann Apply qemu-project.org branding, so the official builds can easily be identified in the banner. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> --- roms/Makefile | 4 ++-- roms/config.ipxe.branding.h | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) create mode 100644 roms/config.ipxe.branding.h diff --git a/roms/Makefile b/roms/Makefile index c0153c7..4971f6b 100644 --- a/roms/Makefile +++ b/roms/Makefile @@ -120,12 +120,12 @@ efi-rom-%: build-pxe-roms build-efi-roms -ec ipxe/src/bin-x86_64-efi/$(VID)$(DID).efidrv \ -o ../pc-bios/efi-$*.rom -build-pxe-roms: ipxe/src/config/local/general.h +build-pxe-roms: ipxe/src/config/local/general.h ipxe/src/config/local/branding.h $(MAKE) -C ipxe/src GITVERSION="" \ CROSS_COMPILE=$(x86_64_cross_prefix) \ $(patsubst %,bin/%.rom,$(pxerom_targets)) -build-efi-roms: build-pxe-roms ipxe/src/config/local/general.h +build-efi-roms: build-pxe-roms ipxe/src/config/local/general.h ipxe/src/config/local/branding.h $(MAKE) -C ipxe/src GITVERSION="" \ CROSS_COMPILE=$(x86_64_cross_prefix) \ $(patsubst %,bin-i386-efi/%.efidrv,$(pxerom_targets)) \ diff --git a/roms/config.ipxe.branding.h b/roms/config.ipxe.branding.h new file mode 100644 index 0000000..324995e --- /dev/null +++ b/roms/config.ipxe.branding.h @@ -0,0 +1,2 @@ +#undef PRODUCT_NAME +#define PRODUCT_NAME "iPXE for qemu-project.org" -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 6/7] ipxe: don't override GITVERSION 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann ` (4 preceding siblings ...) 2015-07-17 14:37 ` [Qemu-devel] [PULL 5/7] ipxe: add qemu branding Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 7/7] ipxe: update binaries Gerd Hoffmann 2015-07-20 10:04 ` [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Peter Maydell 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann We had build problems due to the git version checking in the ipxe build system in the past. Don't remember the details, but the problem seems to be gone now, so lets remove the workaround. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> [ most likely ipxe commit 6153c09c41034250408f3596555fcaae715da46c: [build] Set GITVERSION only if there is a git repository ] Reviewed-by: Laszlo Ersek <lersek@redhat.com> --- roms/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/roms/Makefile b/roms/Makefile index 4971f6b..55fc45b 100644 --- a/roms/Makefile +++ b/roms/Makefile @@ -121,12 +121,12 @@ efi-rom-%: build-pxe-roms build-efi-roms -o ../pc-bios/efi-$*.rom build-pxe-roms: ipxe/src/config/local/general.h ipxe/src/config/local/branding.h - $(MAKE) -C ipxe/src GITVERSION="" \ + $(MAKE) -C ipxe/src \ CROSS_COMPILE=$(x86_64_cross_prefix) \ $(patsubst %,bin/%.rom,$(pxerom_targets)) build-efi-roms: build-pxe-roms ipxe/src/config/local/general.h ipxe/src/config/local/branding.h - $(MAKE) -C ipxe/src GITVERSION="" \ + $(MAKE) -C ipxe/src \ CROSS_COMPILE=$(x86_64_cross_prefix) \ $(patsubst %,bin-i386-efi/%.efidrv,$(pxerom_targets)) \ $(patsubst %,bin-x86_64-efi/%.efidrv,$(pxerom_targets)) -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Qemu-devel] [PULL 7/7] ipxe: update binaries 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann ` (5 preceding siblings ...) 2015-07-17 14:37 ` [Qemu-devel] [PULL 6/7] ipxe: don't override GITVERSION Gerd Hoffmann @ 2015-07-17 14:37 ` Gerd Hoffmann 2015-07-20 10:04 ` [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Peter Maydell 7 siblings, 0 replies; 29+ messages in thread From: Gerd Hoffmann @ 2015-07-17 14:37 UTC (permalink / raw) To: qemu-devel; +Cc: Gerd Hoffmann Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> --- pc-bios/efi-e1000.rom | Bin 197120 -> 192512 bytes pc-bios/efi-eepro100.rom | Bin 197632 -> 192512 bytes pc-bios/efi-ne2k_pci.rom | Bin 195584 -> 190976 bytes pc-bios/efi-pcnet.rom | Bin 195584 -> 190976 bytes pc-bios/efi-rtl8139.rom | Bin 200192 -> 194560 bytes pc-bios/efi-virtio.rom | Bin 194048 -> 188928 bytes 6 files changed, 0 insertions(+), 0 deletions(-) diff --git a/pc-bios/efi-e1000.rom b/pc-bios/efi-e1000.rom index 4e29d9d..203bbaf 100644 Binary files a/pc-bios/efi-e1000.rom and b/pc-bios/efi-e1000.rom differ diff --git a/pc-bios/efi-eepro100.rom b/pc-bios/efi-eepro100.rom index 2a92d6f..0df3135 100644 Binary files a/pc-bios/efi-eepro100.rom and b/pc-bios/efi-eepro100.rom differ diff --git a/pc-bios/efi-ne2k_pci.rom b/pc-bios/efi-ne2k_pci.rom index 6366017..91c0ebb 100644 Binary files a/pc-bios/efi-ne2k_pci.rom and b/pc-bios/efi-ne2k_pci.rom differ diff --git a/pc-bios/efi-pcnet.rom b/pc-bios/efi-pcnet.rom index a61f586..4d79e37 100644 Binary files a/pc-bios/efi-pcnet.rom and b/pc-bios/efi-pcnet.rom differ diff --git a/pc-bios/efi-rtl8139.rom b/pc-bios/efi-rtl8139.rom index c9c77ea..0d3287b 100644 Binary files a/pc-bios/efi-rtl8139.rom and b/pc-bios/efi-rtl8139.rom differ diff --git a/pc-bios/efi-virtio.rom b/pc-bios/efi-virtio.rom index eec2790..8f9a9b4 100644 Binary files a/pc-bios/efi-virtio.rom and b/pc-bios/efi-virtio.rom differ -- 1.8.3.1 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann ` (6 preceding siblings ...) 2015-07-17 14:37 ` [Qemu-devel] [PULL 7/7] ipxe: update binaries Gerd Hoffmann @ 2015-07-20 10:04 ` Peter Maydell 2015-07-21 8:21 ` Peter Maydell 7 siblings, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-20 10:04 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: QEMU Developers, Stefan Hajnoczi On 17 July 2015 at 15:37, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > This pull finally fixes the efi boot support. ipxe is updated to the > latest master, two non-upstream commits needed to make efi work are > added on top, and the build process is tweaked a bit. > > The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, > tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git > before merging this pull request. Is this supposed to happen automatically, or does somebody need to manually do something for that to happen? thanks -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-20 10:04 ` [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Peter Maydell @ 2015-07-21 8:21 ` Peter Maydell 2015-07-21 8:51 ` Paolo Bonzini 0 siblings, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-21 8:21 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: QEMU Developers, Stefan Hajnoczi On 20 July 2015 at 11:04, Peter Maydell <peter.maydell@linaro.org> wrote: > On 17 July 2015 at 15:37, Gerd Hoffmann <kraxel@redhat.com> wrote: >> Hi, >> >> This pull finally fixes the efi boot support. ipxe is updated to the >> latest master, two non-upstream commits needed to make efi work are >> added on top, and the build process is tweaked a bit. >> >> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >> before merging this pull request. > > Is this supposed to happen automatically, or does somebody > need to manually do something for that to happen? I need an answer to this question or this pull will miss rc2 :-( -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 8:21 ` Peter Maydell @ 2015-07-21 8:51 ` Paolo Bonzini 2015-07-21 13:27 ` Peter Maydell 0 siblings, 1 reply; 29+ messages in thread From: Paolo Bonzini @ 2015-07-21 8:51 UTC (permalink / raw) To: Peter Maydell, Gerd Hoffmann; +Cc: QEMU Developers, Stefan Hajnoczi On 21/07/2015 10:21, Peter Maydell wrote: >>> >> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >>> >> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >>> >> before merging this pull request. >> > >> > Is this supposed to happen automatically, or does somebody >> > need to manually do something for that to happen? > I need an answer to this question or this pull will miss rc2 :-( Looks like it needs to be done manually. Paolo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 8:51 ` Paolo Bonzini @ 2015-07-21 13:27 ` Peter Maydell 2015-07-21 13:47 ` Paolo Bonzini 0 siblings, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-21 13:27 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21 July 2015 at 09:51, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 21/07/2015 10:21, Peter Maydell wrote: >>>> >> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >>>> >> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >>>> >> before merging this pull request. >>> > >>> > Is this supposed to happen automatically, or does somebody >>> > need to manually do something for that to happen? >> I need an answer to this question or this pull will miss rc2 :-( > > Looks like it needs to be done manually. I think we're mirroring git://git.ipxe.org/ipxe.git, so the ipxe changes need to be merged into that repo first. Gerd, have you submitted those to the ipxe upstream? thanks -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 13:27 ` Peter Maydell @ 2015-07-21 13:47 ` Paolo Bonzini 2015-07-21 13:57 ` Peter Maydell 0 siblings, 1 reply; 29+ messages in thread From: Paolo Bonzini @ 2015-07-21 13:47 UTC (permalink / raw) To: Peter Maydell; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21/07/2015 15:27, Peter Maydell wrote: >> > On 21/07/2015 10:21, Peter Maydell wrote: >>>>>>> >>>> >> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >>>>>>> >>>> >> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >>>>>>> >>>> >> before merging this pull request. >>>>> >>> > >>>>> >>> > Is this supposed to happen automatically, or does somebody >>>>> >>> > need to manually do something for that to happen? >>> >> I need an answer to this question or this pull will miss rc2 :-( >> > >> > Looks like it needs to be done manually. > I think we're mirroring git://git.ipxe.org/ipxe.git, so the ipxe > changes need to be merged into that repo first. > > Gerd, have you submitted those to the ipxe upstream? Multiple times in the last six months. Paolo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 13:47 ` Paolo Bonzini @ 2015-07-21 13:57 ` Peter Maydell 2015-07-21 14:09 ` Paolo Bonzini 0 siblings, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-21 13:57 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21 July 2015 at 14:47, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 21/07/2015 15:27, Peter Maydell wrote: >>> > On 21/07/2015 10:21, Peter Maydell wrote: >>>>>>>> >>>> >> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >>>>>>>> >>>> >> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >>>>>>>> >>>> >> before merging this pull request. >>>>>> >>> > >>>>>> >>> > Is this supposed to happen automatically, or does somebody >>>>>> >>> > need to manually do something for that to happen? >>>> >> I need an answer to this question or this pull will miss rc2 :-( >>> > >>> > Looks like it needs to be done manually. >> I think we're mirroring git://git.ipxe.org/ipxe.git, so the ipxe >> changes need to be merged into that repo first. >> >> Gerd, have you submitted those to the ipxe upstream? > > Multiple times in the last six months. So is the proposal here that we ship a non-upstream IPXE? That was less than entirely clear from the pull request... -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 13:57 ` Peter Maydell @ 2015-07-21 14:09 ` Paolo Bonzini 2015-07-21 14:25 ` Peter Maydell 0 siblings, 1 reply; 29+ messages in thread From: Paolo Bonzini @ 2015-07-21 14:09 UTC (permalink / raw) To: Peter Maydell; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21/07/2015 15:57, Peter Maydell wrote: > On 21 July 2015 at 14:47, Paolo Bonzini <pbonzini@redhat.com> wrote: >> On 21/07/2015 15:27, Peter Maydell wrote: >>>>> On 21/07/2015 10:21, Peter Maydell wrote: >>>>>>>>>>>>>>> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu, >>>>>>>>>>>>>>> tag qemu-2.4). They should be mirrored to git://git.qemu.org/ipxe.git >>>>>>>>>>>>>>> before merging this pull request. >>>>>>>>>>> >>>>>>>>>>> Is this supposed to happen automatically, or does somebody >>>>>>>>>>> need to manually do something for that to happen? >>>>>>> I need an answer to this question or this pull will miss rc2 :-( >>>>> >>>>> Looks like it needs to be done manually. >>> I think we're mirroring git://git.ipxe.org/ipxe.git, so the ipxe >>> changes need to be merged into that repo first. >>> >>> Gerd, have you submitted those to the ipxe upstream? >> >> Multiple times in the last six months. > > So is the proposal here that we ship a non-upstream IPXE? > That was less than entirely clear from the pull request... Well, it did say "This pull finally fixes the efi boot support. ipxe is updated to the latest master, two non-upstream commits needed to make efi work are added on top, and the build process is tweaked a bit". Paolo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 14:09 ` Paolo Bonzini @ 2015-07-21 14:25 ` Peter Maydell 2015-07-21 14:28 ` Paolo Bonzini 0 siblings, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-21 14:25 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21 July 2015 at 15:09, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 21/07/2015 15:57, Peter Maydell wrote: >> On 21 July 2015 at 14:47, Paolo Bonzini <pbonzini@redhat.com> wrote: >> So is the proposal here that we ship a non-upstream IPXE? >> That was less than entirely clear from the pull request... > > Well, it did say "This pull finally fixes the efi boot support. ipxe is > updated to the latest master, two non-upstream commits needed to make > efi work are added on top, and the build process is tweaked a bit". Right, but if you want us to switch from "we just mirror upstream ipxe" to "we have our own ipxe" then it's probably better to start with that, rather than by submitting a pullreq that can't be applied until we switch our ipxe workflow. Do we really need this for 2.4, or can we wait and sort this out afterwards? It feels a bit late in the release cycle to start doing this kind of thing to me. -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 14:25 ` Peter Maydell @ 2015-07-21 14:28 ` Paolo Bonzini 2015-07-21 16:10 ` Stefan Hajnoczi 0 siblings, 1 reply; 29+ messages in thread From: Paolo Bonzini @ 2015-07-21 14:28 UTC (permalink / raw) To: Peter Maydell; +Cc: Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21/07/2015 16:25, Peter Maydell wrote: >> > >> > Well, it did say "This pull finally fixes the efi boot support. ipxe is >> > updated to the latest master, two non-upstream commits needed to make >> > efi work are added on top, and the build process is tweaked a bit". > Right, but if you want us to switch from "we just mirror > upstream ipxe" to "we have our own ipxe" then it's probably > better to start with that, rather than by submitting a pullreq > that can't be applied until we switch our ipxe workflow. > > Do we really need this for 2.4, or can we wait and sort > this out afterwards? It feels a bit late in the release > cycle to start doing this kind of thing to me. Well, it is a bugfix. shim.efi doesn't work with upstream iPXE, and hence doesn't work with the ROMs currently distributed by QEMU (Fedora applies the patches already). The patches have missed 2.3 and 2.4 because Gerd has been sending them again upstream every month. That said, I see your point. It's probably not of utmost importance as long as OVMF remains non-free and hence not shipped by most distributions. Paolo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 14:28 ` Paolo Bonzini @ 2015-07-21 16:10 ` Stefan Hajnoczi 2015-07-21 16:18 ` Peter Maydell 2015-07-21 22:58 ` Laszlo Ersek 0 siblings, 2 replies; 29+ messages in thread From: Stefan Hajnoczi @ 2015-07-21 16:10 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, Hannes Reinecke, Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 21/07/2015 16:25, Peter Maydell wrote: >>> > >>> > Well, it did say "This pull finally fixes the efi boot support. ipxe is >>> > updated to the latest master, two non-upstream commits needed to make >>> > efi work are added on top, and the build process is tweaked a bit". >> Right, but if you want us to switch from "we just mirror >> upstream ipxe" to "we have our own ipxe" then it's probably >> better to start with that, rather than by submitting a pullreq >> that can't be applied until we switch our ipxe workflow. >> >> Do we really need this for 2.4, or can we wait and sort >> this out afterwards? It feels a bit late in the release >> cycle to start doing this kind of thing to me. > > Well, it is a bugfix. shim.efi doesn't work with upstream iPXE, and > hence doesn't work with the ROMs currently distributed by QEMU (Fedora > applies the patches already). > > The patches have missed 2.3 and 2.4 because Gerd has been sending them > again upstream every month. > > That said, I see your point. It's probably not of utmost importance as > long as OVMF remains non-free and hence not shipped by most distributions. With regards to git.qemu.org mirroring: I could update the ipxe.git mirror URL on git.qemu.org to Gerd's public repo and change the description to indicate that this includes out-of-tree patches. Please let me know if you'd like to go ahead. I'd prefer it if we don't ship a patched ipxe since Paolo mentions Fedora already has a fix in place. Instead of propagating that fix into QEMU, let's focus on ipxe upstream to solve the problem. I've reviewed the ipxe-devel archives and see that patches have been on the list for weeks/months without replies. I didn't see ping emails though so maybe it just requires a bit of poking via email or IRC. We either need to figure out how to get attention upstream or work with others to add upstream maintainers. I see that Hannes Reinecke also has patches on ipxe-devel that look ignored, so Gred and Laszlo are not the only ones struggling to get patches upstream into ipxe. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 16:10 ` Stefan Hajnoczi @ 2015-07-21 16:18 ` Peter Maydell 2015-07-21 23:00 ` Laszlo Ersek 2015-07-21 22:58 ` Laszlo Ersek 1 sibling, 1 reply; 29+ messages in thread From: Peter Maydell @ 2015-07-21 16:18 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Paolo Bonzini, Hannes Reinecke, Gerd Hoffmann, Stefan Hajnoczi, QEMU Developers On 21 July 2015 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote: > With regards to git.qemu.org mirroring: > I could update the ipxe.git mirror URL on git.qemu.org to Gerd's > public repo and change the description to indicate that this includes > out-of-tree patches. Please let me know if you'd like to go ahead. > > I'd prefer it if we don't ship a patched ipxe since Paolo mentions > Fedora already has a fix in place. Instead of propagating that fix > into QEMU, let's focus on ipxe upstream to solve the problem. I think this would be my preference too. I wouldn't absolutely rule out shipping a patched ipxe, but I think it should be a last resort and not something we do at this point in our release cycle. thanks -- PMM ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 16:18 ` Peter Maydell @ 2015-07-21 23:00 ` Laszlo Ersek 0 siblings, 0 replies; 29+ messages in thread From: Laszlo Ersek @ 2015-07-21 23:00 UTC (permalink / raw) To: Peter Maydell, Stefan Hajnoczi Cc: QEMU Developers, Paolo Bonzini, Hannes Reinecke, Stefan Hajnoczi, Gerd Hoffmann On 07/21/15 18:18, Peter Maydell wrote: > On 21 July 2015 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote: >> With regards to git.qemu.org mirroring: >> I could update the ipxe.git mirror URL on git.qemu.org to Gerd's >> public repo and change the description to indicate that this includes >> out-of-tree patches. Please let me know if you'd like to go ahead. >> >> I'd prefer it if we don't ship a patched ipxe since Paolo mentions >> Fedora already has a fix in place. Instead of propagating that fix >> into QEMU, let's focus on ipxe upstream to solve the problem. > > I think this would be my preference too. I wouldn't absolutely > rule out shipping a patched ipxe, but I think it should be a > last resort Yes, it should be. And, we're already there. > and not something we do at this point in our > release cycle. Not contesting that. Laszlo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 16:10 ` Stefan Hajnoczi 2015-07-21 16:18 ` Peter Maydell @ 2015-07-21 22:58 ` Laszlo Ersek 2015-07-21 23:22 ` Laszlo Ersek ` (2 more replies) 1 sibling, 3 replies; 29+ messages in thread From: Laszlo Ersek @ 2015-07-21 22:58 UTC (permalink / raw) To: Stefan Hajnoczi, Paolo Bonzini Cc: QEMU Developers, Peter Maydell, Hannes Reinecke, Stefan Hajnoczi, Gerd Hoffmann On 07/21/15 18:10, Stefan Hajnoczi wrote: > On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> On 21/07/2015 16:25, Peter Maydell wrote: >>>>> >>>>> Well, it did say "This pull finally fixes the efi boot support. ipxe is >>>>> updated to the latest master, two non-upstream commits needed to make >>>>> efi work are added on top, and the build process is tweaked a bit". >>> Right, but if you want us to switch from "we just mirror >>> upstream ipxe" to "we have our own ipxe" then it's probably >>> better to start with that, rather than by submitting a pullreq >>> that can't be applied until we switch our ipxe workflow. >>> >>> Do we really need this for 2.4, or can we wait and sort >>> this out afterwards? It feels a bit late in the release >>> cycle to start doing this kind of thing to me. >> >> Well, it is a bugfix. shim.efi doesn't work with upstream iPXE, and >> hence doesn't work with the ROMs currently distributed by QEMU (Fedora >> applies the patches already). >> >> The patches have missed 2.3 and 2.4 because Gerd has been sending them >> again upstream every month. >> >> That said, I see your point. It's probably not of utmost importance as >> long as OVMF remains non-free and hence not shipped by most distributions. > > With regards to git.qemu.org mirroring: > I could update the ipxe.git mirror URL on git.qemu.org to Gerd's > public repo and change the description to indicate that this includes > out-of-tree patches. Please let me know if you'd like to go ahead. > > I'd prefer it if we don't ship a patched ipxe since Paolo mentions > Fedora already has a fix in place. RHEL doesn't (yet). In fact these QEMU patches are the result of a long (and mostly fruitless) effort to get the ipxe patches upstream -- for RHEL we prefer *something* to point at as "upstream". > Instead of propagating that fix > into QEMU, let's focus on ipxe upstream to solve the problem. How's this for focus: (1) [PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec http://thread.gmane.org/gmane.network.ipxe.devel/3799 Date: 2015-Jan-27 feedback: none (2) [PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec http://thread.gmane.org/gmane.network.ipxe.devel/3955 Date: 2015-Feb-10 feedback: zero (3) [PATCH] [efi] make load file protocol optional http://thread.gmane.org/gmane.network.ipxe.devel/3815 Date: 2015-Feb-11 feedback: the patch destroys the user's ability to use most features of iPXE our point: we don't care about most features of iPXE, we just need it for EFI drivers (Simple Network Protocol instances) result: nothing (4) [RESENT PATCH 0/2] efi boot fixes. http://thread.gmane.org/gmane.network.ipxe.devel/3854 Date: 2015-Mar-10 feedback: zilch (5) [RESEND PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec http://thread.gmane.org/gmane.network.ipxe.devel/3934 Date: 2015-Apr-14 feedback: nada (6) [PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec http://thread.gmane.org/gmane.network.ipxe.devel/4096 Date: 2015-Jun-10 feedback: null So, let us *not* focus on getting these into upstream ipxe. The mailing list is a black hole. The upstream maintainer behaves completely unpredictably. For example, look at this one example: [PATCH 0/2] virtio-net shutdown fix for ExitBootServices() http://thread.gmane.org/gmane.network.ipxe.devel/3918 Date: 2015-Apr-10 For this submission, the maintainer provided good feedback, then decided to rewrite the patches (which was a good call, no doubt about it), then went ahead and committed that patch, and even gave credit: commit 755d2b8f6be681a2e620534b237471b75f28ed8c Author: Michael Brown <mcb30@ipxe.org> Date: Mon Apr 13 12:06:59 2015 +0100 [efi] Ensure drivers are disconnected when ExitBootServices() is called [...] Originally-fixed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org> (Therefore this patch is actually covered by the upstream rebase in [PULL 1/7] here.) And then, *just one day* after this commit, Gerd submits (5) -- and complete silence. > I've reviewed the ipxe-devel archives and see that patches have been > on the list for weeks/months without replies. I didn't see ping > emails though so maybe it just requires a bit of poking via email or > IRC. Rather than pings, Gerd kept resending the actual patches. That's a strictly stronger kind of "reminder". So no, pings are useless. Regarding IRC, let me quote the following from freenode | #ipxe, date 2015-Jan-23 (ie. four days before posting (1)). The first quote is about the patch in (3) -- the implementation looked differently at that point, but the behavior was identical: <mcb30> Patches to modify our LOAD_FILE_PROTOCOL to support loading arbitrary files would be fine <lersek> mcb30, thanks. :) <mcb30> but there's no way I'm turning UEFI iPXE back into being a dumb SNP driver with the appalling UEFI UX <mcb30> Consider what happens when a user attempts normal network boot and something goes wrong (e.g. the file doesn't exist) <mcb30> iPXE displays a UI with a meaningful error message and a shell allowing you to troubleshoot <lersek> the UEFI boot option fails and the boot option processing continues. <mcb30> UEFI simply displays a dot on an otherwise blank screen and then returns to the boot menu <lersek> yes <lersek> if there are no more UEFI boot options to try <lersek> I understand your point fully <mcb30> A dot on a blank screen is not a meaningful error message <lersek> we have different goals here <mcb30> Understood <lersek> the dot is not meant as an error message, it's progress info AFAIR <mcb30> In which case, a total absence of an error message is not a meaningful error message <lersek> correct <lersek> but it's consistent with the handling of other (not necessarily network related) boot options when they fail <lersek> your main goal is to provide a nice iPXE experience, while we need some UEFI NIC drivers (for OVMF) in qemu-kvm guests <lersek> so I thought I'd try to check with upstream developers before keeping these patches downstream only <lersek> thanks! <mcb30> I would suggest adding code to support downloading arbitrary files via LOAD_FILE_PROTOCOL <mcb30> which would avoid a UX downgrade when network-booting a qemu-kvm guest <mcb30> (i.e. when not going through grub) So, this is consistent with the feedback we'd actually get later for (3). It makes no sense to struggle more with this patch. Then, regarding the other patch (the one in (1)): <lersek> mcb30, what about the second patch? <mcb30> lersek: sorry; I mssed the second patch <mcb30> Looking... <lersek> mcb30, thanks -- my first msg in this channel was quite long & crowded <mcb30> lersek: looks okish. I need to check the code again; it's been a long time since I looked at that. In particular, is there any functional difference between the existing tx_count_interrupts (used I think to determine how many TX completions to return) and the producer/consumer counters that you have added? If tx_count_interrupts is now redundant because the producer/consumer already include that information then it should probably be <mcb30> removed <lersek> mcb30, that's a good question. The UEFI spec emphasizes that clearing / retrieving a recycled txbuf does not clear interrupt status if the caller doesn't ask for that too, and vice versa -- if the caller only asks about interrupt status, then no recycled txbuf is returned <lersek> so they should remain independent <lersek> but how exactly you calculate the interrupt status when the caller *does* ask for it, that's anyone's best guess <lersek> the spec is unclear about it <lersek> in OVMF's builtin virtio-net driver I think I just check if there are any pending outgoing & incoming packets, and set the corresponding bits <lersek> I don't use a counter <lersek> but it's very obscure indeed and no caller I know of seems to care about interrupt status <lersek> which is why I didn't touch that part of the code <lersek> I just kept those two things independent, because their independence *is* specified <mcb30> ok <mcb30> That makes sense <lersek> (more precisely, re OVMF's builtin virtio-net driver, the RX intr bit is reported when more stuff is available for reception, and the TX intr bit is reported if we have transmitted at least one buffer that the caller queued with Transmit) <lersek> mcb30, so can you pick up the 2nd patch from bugzilla, or should I send it to the list? (Actually if you deem the patch appropriate I can only send it to the list, because current master iPXE looks a bit different from our fork in RHEL, and the 2nd patch takes different forms accordingly.) I got no further replies here. Based on the apparently positive feedback on IRC, four days later I posted (1). No feedback. > We either need to figure out how to get attention upstream Good luck with that. In my educated experience: completely unpredictable maintainer behavior, not a real community project. > or work > with others to add upstream maintainers. When we can't get the maintainer's attention for our patches, and when the maintainer tends to rewrite even those patches he more or less likes, how do you propose we convince him to give *push access* to random people? > I see that Hannes Reinecke > also has patches on ipxe-devel that look ignored, so Gred and Laszlo > are not the only ones struggling to get patches upstream into ipxe. I've said it several times (on other lists too), and I'll say it again: ipxe is not an "open process" community project at this point. The last half year, as Paolo indicated, and as I proved above, has been ample experience. --*-- On the technical level, let me summarize: we needed three patches in total to get UEFI boot working: #1 efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec #2 [efi] make load file protocol optional #3 [efi] Ensure drivers are disconnected when ExitBootServices() is called Wrt. #1, the maintainer expressed agreement on IRC, but never replied to patch emails. Wrt. #2, the maintainer expressed strong disagreement (due to "user interface" concerns) on both IRC and later on the mailing list. Therefore the idea of upstreaming this patch is dead in the water. The maintainer would accept an alternative that would take a huge development effort, and would be useless for virtualization purposes (ie. PXE-booting with OVMF in QEMU). Wrt. #3, the maintainer decided to look at the patch, rewrite it, and commit it. For some unfathomable reason. Maybe because he was Cc'd directly on the patch email. I don't know. (The ipxe-devel list has absolutely minimal traffic, why wouldn't he read it without explicit Cc?!) This PULL is about getting #3 via rebase, and #1 and #2 as downstream patches. Thanks Laszlo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 22:58 ` Laszlo Ersek @ 2015-07-21 23:22 ` Laszlo Ersek 2015-07-22 9:05 ` Stefan Hajnoczi 2015-07-22 20:06 ` Michael Brown 2 siblings, 0 replies; 29+ messages in thread From: Laszlo Ersek @ 2015-07-21 23:22 UTC (permalink / raw) To: Stefan Hajnoczi, Paolo Bonzini Cc: QEMU Developers, Peter Maydell, Hannes Reinecke, Stefan Hajnoczi, Gerd Hoffmann Oops, I got carried away a little bit, and forgot about a crucial detail: On 07/22/15 00:58, Laszlo Ersek wrote: [snip] > (1) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3799 > Date: 2015-Jan-27 > feedback: none > > (2) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3955 > Date: 2015-Feb-10 > feedback: zero > > (3) [PATCH] [efi] make load file protocol optional > http://thread.gmane.org/gmane.network.ipxe.devel/3815 > Date: 2015-Feb-11 > feedback: the patch destroys the user's ability to use > most features of iPXE > our point: we don't care about most features of iPXE, we just need > it for EFI drivers (Simple Network Protocol instances) > result: nothing Mark this ^^^ > > (4) [RESENT PATCH 0/2] efi boot fixes. > http://thread.gmane.org/gmane.network.ipxe.devel/3854 > Date: 2015-Mar-10 > feedback: zilch > > (5) [RESEND PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3934 > Date: 2015-Apr-14 > feedback: nada > > (6) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/4096 > Date: 2015-Jun-10 > feedback: null [snip] > On the technical level, let me summarize: we needed three patches in > total to get UEFI boot working: > > #1 efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec > #2 [efi] make load file protocol optional > #3 [efi] Ensure drivers are disconnected when ExitBootServices() is > called > > Wrt. #1, the maintainer expressed agreement on IRC, but never replied to > patch emails. > > Wrt. #2, the maintainer expressed strong disagreement (due to "user > interface" concerns) on both IRC and later on the mailing list. > Therefore the idea of upstreaming this patch is dead in the water. The > maintainer would accept an alternative that would take a huge > development effort, and would be useless for virtualization purposes > (ie. PXE-booting with OVMF in QEMU). So, the important detail that I forgot is that Gerd's patch, listed as #2 here, and as (3) above in the list of earlier submissions, actually does not change the behavior of ipxe *at all*. It just introduces a config option, a knob if you like, that allows downstreams to rebuild ipxe *that specific way* easily. Therefore, absolutely no user interface concerns are valid in this case -- those concerns may have been correct for my very first patch, but Gerd reworked the patch to depend on a new config option (with unchanged default behavior), and the maintainer refused to take even that. (Despite the fact that upstream iPXE users would see no change in behavior.) Laszlo > > Wrt. #3, the maintainer decided to look at the patch, rewrite it, and > commit it. For some unfathomable reason. Maybe because he was Cc'd > directly on the patch email. I don't know. (The ipxe-devel list has > absolutely minimal traffic, why wouldn't he read it without explicit Cc?!) > > This PULL is about getting #3 via rebase, and #1 and #2 as downstream > patches. > > Thanks > Laszlo > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 22:58 ` Laszlo Ersek 2015-07-21 23:22 ` Laszlo Ersek @ 2015-07-22 9:05 ` Stefan Hajnoczi 2015-07-22 10:05 ` Laszlo Ersek 2015-07-22 20:06 ` Michael Brown 2 siblings, 1 reply; 29+ messages in thread From: Stefan Hajnoczi @ 2015-07-22 9:05 UTC (permalink / raw) To: Laszlo Ersek Cc: Peter Maydell, Stefan Hajnoczi, QEMU Developers, Gerd Hoffmann, Paolo Bonzini, Hannes Reinecke [-- Attachment #1: Type: text/plain, Size: 1588 bytes --] On Wed, Jul 22, 2015 at 12:58:59AM +0200, Laszlo Ersek wrote: > On 07/21/15 18:10, Stefan Hajnoczi wrote: > > On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > >> On 21/07/2015 16:25, Peter Maydell wrote: > > or work > > with others to add upstream maintainers. > > When we can't get the maintainer's attention for our patches, and when > the maintainer tends to rewrite even those patches he more or less > likes, how do you propose we convince him to give *push access* to > random people? > > > I see that Hannes Reinecke > > also has patches on ipxe-devel that look ignored, so Gred and Laszlo > > are not the only ones struggling to get patches upstream into ipxe. > > I've said it several times (on other lists too), and I'll say it again: > ipxe is not an "open process" community project at this point. The last > half year, as Paolo indicated, and as I proved above, has been ample > experience. I understand the frustration with upstream. Thanks for posting a summary of stranded patch series, it helped explain that. The reason I'm suggesting reaching out to Michael Brown is that the downstream repo will only be an "open process" for us virtualization developers. It won't have a user community, support, or help improve the situation for non-virtualization developers - all things which matter for a healthy long-term open source project. It may be simplest if Gerd maintains a QEMU downstream repository. I'm not against that. But let's notify Michael Brown so he has a chance to consider the problem. [-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-22 9:05 ` Stefan Hajnoczi @ 2015-07-22 10:05 ` Laszlo Ersek 2015-07-22 11:42 ` Stefan Hajnoczi 0 siblings, 1 reply; 29+ messages in thread From: Laszlo Ersek @ 2015-07-22 10:05 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Peter Maydell, Stefan Hajnoczi, QEMU Developers, Gerd Hoffmann, Paolo Bonzini, Hannes Reinecke On 07/22/15 11:05, Stefan Hajnoczi wrote: > On Wed, Jul 22, 2015 at 12:58:59AM +0200, Laszlo Ersek wrote: >> On 07/21/15 18:10, Stefan Hajnoczi wrote: >>> On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>> On 21/07/2015 16:25, Peter Maydell wrote: >>> or work >>> with others to add upstream maintainers. >> >> When we can't get the maintainer's attention for our patches, and when >> the maintainer tends to rewrite even those patches he more or less >> likes, how do you propose we convince him to give *push access* to >> random people? >> >>> I see that Hannes Reinecke >>> also has patches on ipxe-devel that look ignored, so Gred and Laszlo >>> are not the only ones struggling to get patches upstream into ipxe. >> >> I've said it several times (on other lists too), and I'll say it again: >> ipxe is not an "open process" community project at this point. The last >> half year, as Paolo indicated, and as I proved above, has been ample >> experience. > > I understand the frustration with upstream. Thanks for posting a > summary of stranded patch series, it helped explain that. > > The reason I'm suggesting reaching out to Michael Brown is that the > downstream repo will only be an "open process" for us virtualization > developers. It won't have a user community, support, or help improve > the situation for non-virtualization developers - all things which > matter for a healthy long-term open source project. All the things upstream ipxe has been lacking for at least half a year now, without much indication that it could improve. > It may be simplest if Gerd maintains a QEMU downstream repository. I'm > not against that. But let's notify Michael Brown so he has a chance to > consider the problem. If you can reach out to Michael Brown, that would be highly appreciated. Personally I lost all hope. Thanks Laszlo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-22 10:05 ` Laszlo Ersek @ 2015-07-22 11:42 ` Stefan Hajnoczi 2015-07-22 20:08 ` Laszlo Ersek 0 siblings, 1 reply; 29+ messages in thread From: Stefan Hajnoczi @ 2015-07-22 11:42 UTC (permalink / raw) To: Laszlo Ersek Cc: Peter Maydell, QEMU Developers, Gerd Hoffmann, Stefan Hajnoczi, Paolo Bonzini, Hannes Reinecke On Wed, Jul 22, 2015 at 11:05 AM, Laszlo Ersek <lersek@redhat.com> wrote: > On 07/22/15 11:05, Stefan Hajnoczi wrote: >> On Wed, Jul 22, 2015 at 12:58:59AM +0200, Laszlo Ersek wrote: >>> On 07/21/15 18:10, Stefan Hajnoczi wrote: >>>> On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>>> On 21/07/2015 16:25, Peter Maydell wrote: >>>> or work >>>> with others to add upstream maintainers. >>> >>> When we can't get the maintainer's attention for our patches, and when >>> the maintainer tends to rewrite even those patches he more or less >>> likes, how do you propose we convince him to give *push access* to >>> random people? >>> >>>> I see that Hannes Reinecke >>>> also has patches on ipxe-devel that look ignored, so Gred and Laszlo >>>> are not the only ones struggling to get patches upstream into ipxe. >>> >>> I've said it several times (on other lists too), and I'll say it again: >>> ipxe is not an "open process" community project at this point. The last >>> half year, as Paolo indicated, and as I proved above, has been ample >>> experience. >> >> I understand the frustration with upstream. Thanks for posting a >> summary of stranded patch series, it helped explain that. >> >> The reason I'm suggesting reaching out to Michael Brown is that the >> downstream repo will only be an "open process" for us virtualization >> developers. It won't have a user community, support, or help improve >> the situation for non-virtualization developers - all things which >> matter for a healthy long-term open source project. > > All the things upstream ipxe has been lacking for at least half a year > now, without much indication that it could improve. > >> It may be simplest if Gerd maintains a QEMU downstream repository. I'm >> not against that. But let's notify Michael Brown so he has a chance to >> consider the problem. > > If you can reach out to Michael Brown, that would be highly appreciated. > Personally I lost all hope. Done. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-22 11:42 ` Stefan Hajnoczi @ 2015-07-22 20:08 ` Laszlo Ersek 2015-07-23 8:26 ` Stefan Hajnoczi 0 siblings, 1 reply; 29+ messages in thread From: Laszlo Ersek @ 2015-07-22 20:08 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Peter Maydell, QEMU Developers, Hannes Reinecke, Stefan Hajnoczi, Paolo Bonzini, Gerd Hoffmann On 07/22/15 13:42, Stefan Hajnoczi wrote: > On Wed, Jul 22, 2015 at 11:05 AM, Laszlo Ersek <lersek@redhat.com> wrote: >> On 07/22/15 11:05, Stefan Hajnoczi wrote: >>> On Wed, Jul 22, 2015 at 12:58:59AM +0200, Laszlo Ersek wrote: >>>> On 07/21/15 18:10, Stefan Hajnoczi wrote: >>>>> On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>>>> On 21/07/2015 16:25, Peter Maydell wrote: >>>>> or work >>>>> with others to add upstream maintainers. >>>> >>>> When we can't get the maintainer's attention for our patches, and when >>>> the maintainer tends to rewrite even those patches he more or less >>>> likes, how do you propose we convince him to give *push access* to >>>> random people? >>>> >>>>> I see that Hannes Reinecke >>>>> also has patches on ipxe-devel that look ignored, so Gred and Laszlo >>>>> are not the only ones struggling to get patches upstream into ipxe. >>>> >>>> I've said it several times (on other lists too), and I'll say it again: >>>> ipxe is not an "open process" community project at this point. The last >>>> half year, as Paolo indicated, and as I proved above, has been ample >>>> experience. >>> >>> I understand the frustration with upstream. Thanks for posting a >>> summary of stranded patch series, it helped explain that. >>> >>> The reason I'm suggesting reaching out to Michael Brown is that the >>> downstream repo will only be an "open process" for us virtualization >>> developers. It won't have a user community, support, or help improve >>> the situation for non-virtualization developers - all things which >>> matter for a healthy long-term open source project. >> >> All the things upstream ipxe has been lacking for at least half a year >> now, without much indication that it could improve. >> >>> It may be simplest if Gerd maintains a QEMU downstream repository. I'm >>> not against that. But let's notify Michael Brown so he has a chance to >>> consider the problem. >> >> If you can reach out to Michael Brown, that would be highly appreciated. >> Personally I lost all hope. > > Done. Thanks. Looks like you got through. Obviously, that cannot be ascribed to anything else than blind luck, or a personal relationship from the past. Ie. things that should not matter in open source. In any case, I asked Michael Brown what we should do differently next time. Laszlo ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-22 20:08 ` Laszlo Ersek @ 2015-07-23 8:26 ` Stefan Hajnoczi 0 siblings, 0 replies; 29+ messages in thread From: Stefan Hajnoczi @ 2015-07-23 8:26 UTC (permalink / raw) To: Laszlo Ersek Cc: Peter Maydell, QEMU Developers, Hannes Reinecke, Stefan Hajnoczi, Paolo Bonzini, Gerd Hoffmann On Wed, Jul 22, 2015 at 9:08 PM, Laszlo Ersek <lersek@redhat.com> wrote: > On 07/22/15 13:42, Stefan Hajnoczi wrote: >> On Wed, Jul 22, 2015 at 11:05 AM, Laszlo Ersek <lersek@redhat.com> wrote: >>> On 07/22/15 11:05, Stefan Hajnoczi wrote: >>>> On Wed, Jul 22, 2015 at 12:58:59AM +0200, Laszlo Ersek wrote: >>>>> On 07/21/15 18:10, Stefan Hajnoczi wrote: >>>>>> On Tue, Jul 21, 2015 at 3:28 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>>>>> On 21/07/2015 16:25, Peter Maydell wrote: >>>>>> or work >>>>>> with others to add upstream maintainers. >>>>> >>>>> When we can't get the maintainer's attention for our patches, and when >>>>> the maintainer tends to rewrite even those patches he more or less >>>>> likes, how do you propose we convince him to give *push access* to >>>>> random people? >>>>> >>>>>> I see that Hannes Reinecke >>>>>> also has patches on ipxe-devel that look ignored, so Gred and Laszlo >>>>>> are not the only ones struggling to get patches upstream into ipxe. >>>>> >>>>> I've said it several times (on other lists too), and I'll say it again: >>>>> ipxe is not an "open process" community project at this point. The last >>>>> half year, as Paolo indicated, and as I proved above, has been ample >>>>> experience. >>>> >>>> I understand the frustration with upstream. Thanks for posting a >>>> summary of stranded patch series, it helped explain that. >>>> >>>> The reason I'm suggesting reaching out to Michael Brown is that the >>>> downstream repo will only be an "open process" for us virtualization >>>> developers. It won't have a user community, support, or help improve >>>> the situation for non-virtualization developers - all things which >>>> matter for a healthy long-term open source project. >>> >>> All the things upstream ipxe has been lacking for at least half a year >>> now, without much indication that it could improve. >>> >>>> It may be simplest if Gerd maintains a QEMU downstream repository. I'm >>>> not against that. But let's notify Michael Brown so he has a chance to >>>> consider the problem. >>> >>> If you can reach out to Michael Brown, that would be highly appreciated. >>> Personally I lost all hope. >> >> Done. > > Thanks. Looks like you got through. Obviously, that cannot be ascribed > to anything else than blind luck, or a personal relationship from the > past. Ie. things that should not matter in open source. Maybe a bit of both. I sent a link to the email thread via IRC. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-21 22:58 ` Laszlo Ersek 2015-07-21 23:22 ` Laszlo Ersek 2015-07-22 9:05 ` Stefan Hajnoczi @ 2015-07-22 20:06 ` Michael Brown 2015-07-22 20:10 ` Laszlo Ersek 2 siblings, 1 reply; 29+ messages in thread From: Michael Brown @ 2015-07-22 20:06 UTC (permalink / raw) To: Laszlo Ersek, Stefan Hajnoczi, Paolo Bonzini Cc: QEMU Developers, Peter Maydell, Hannes Reinecke, Stefan Hajnoczi, Gerd Hoffmann On 21/07/15 23:58, Laszlo Ersek wrote: >> Instead of propagating that fix >> into QEMU, let's focus on ipxe upstream to solve the problem. > > How's this for focus: > > (1) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3799 > > (2) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3955 > > (3) [PATCH] [efi] make load file protocol optional > http://thread.gmane.org/gmane.network.ipxe.devel/3815 > > (4) [RESENT PATCH 0/2] efi boot fixes. > http://thread.gmane.org/gmane.network.ipxe.devel/3854 > > (5) [RESEND PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3934 > > (6) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/4096 Both (sic) of these patches now have upstream implementations: http://git.ipxe.org/ipxe.git/commitdiff/88a5f56 http://git.ipxe.org/ipxe.git/commitdiff/a15c0d7 Unless I'm missing something, there are only two patches involved here. I've also upstreamed a named configuration for qemu which incorporates your existing config changes (based on roms/config.ipxe.general.h) and adds the option to disable the EFI_LOAD_FILE_PROTOCOL installation: http://git.ipxe.org/ipxe.git/commitdiff/a200ad4 To build with this named configuration, just add "CONFIG=qemu" to the make command line when building iPXE. Michael ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support 2015-07-22 20:06 ` Michael Brown @ 2015-07-22 20:10 ` Laszlo Ersek 0 siblings, 0 replies; 29+ messages in thread From: Laszlo Ersek @ 2015-07-22 20:10 UTC (permalink / raw) To: Michael Brown, Stefan Hajnoczi, Paolo Bonzini Cc: QEMU Developers, Peter Maydell, Hannes Reinecke, Stefan Hajnoczi, Gerd Hoffmann On 07/22/15 22:06, Michael Brown wrote: > On 21/07/15 23:58, Laszlo Ersek wrote: >>> Instead of propagating that fix >>> into QEMU, let's focus on ipxe upstream to solve the problem. >> >> How's this for focus: >> >> (1) [PATCH] efi_snp: improve compliance with the >> EFI_SIMPLE_NETWORK_PROTOCOL spec >> http://thread.gmane.org/gmane.network.ipxe.devel/3799 >> >> (2) [PATCH] efi_snp: improve compliance with the >> EFI_SIMPLE_NETWORK_PROTOCOL spec >> http://thread.gmane.org/gmane.network.ipxe.devel/3955 >> >> (3) [PATCH] [efi] make load file protocol optional >> http://thread.gmane.org/gmane.network.ipxe.devel/3815 >> >> (4) [RESENT PATCH 0/2] efi boot fixes. >> http://thread.gmane.org/gmane.network.ipxe.devel/3854 >> >> (5) [RESEND PATCH] efi_snp: improve compliance with the >> EFI_SIMPLE_NETWORK_PROTOCOL spec >> http://thread.gmane.org/gmane.network.ipxe.devel/3934 >> >> (6) [PATCH] efi_snp: improve compliance with the >> EFI_SIMPLE_NETWORK_PROTOCOL spec >> http://thread.gmane.org/gmane.network.ipxe.devel/4096 > > Both (sic) of these patches now have upstream implementations: > > http://git.ipxe.org/ipxe.git/commitdiff/88a5f56 > http://git.ipxe.org/ipxe.git/commitdiff/a15c0d7 Thank you. > Unless I'm missing something, there are only two patches involved here. No, you are right, it's about two patches. > I've also upstreamed a named configuration for qemu which incorporates > your existing config changes (based on roms/config.ipxe.general.h) and > adds the option to disable the EFI_LOAD_FILE_PROTOCOL installation: > > http://git.ipxe.org/ipxe.git/commitdiff/a200ad4 > > To build with this named configuration, just add "CONFIG=qemu" to the > make command line when building iPXE. Much appreciated. Hopefully Gerd can cover this when he returns from his vacation. Laszlo ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2015-07-23 8:26 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-17 14:37 [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 1/7] ipxe: update from 35c53797 to 24112d9 (upstream/master) Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 2/7] ipxe: update to 87981bb (qemu) Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 3/7] ipxe: rm local config in cleanup Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 4/7] ipxe: disable load file protocol Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 5/7] ipxe: add qemu branding Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 6/7] ipxe: don't override GITVERSION Gerd Hoffmann 2015-07-17 14:37 ` [Qemu-devel] [PULL 7/7] ipxe: update binaries Gerd Hoffmann 2015-07-20 10:04 ` [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support Peter Maydell 2015-07-21 8:21 ` Peter Maydell 2015-07-21 8:51 ` Paolo Bonzini 2015-07-21 13:27 ` Peter Maydell 2015-07-21 13:47 ` Paolo Bonzini 2015-07-21 13:57 ` Peter Maydell 2015-07-21 14:09 ` Paolo Bonzini 2015-07-21 14:25 ` Peter Maydell 2015-07-21 14:28 ` Paolo Bonzini 2015-07-21 16:10 ` Stefan Hajnoczi 2015-07-21 16:18 ` Peter Maydell 2015-07-21 23:00 ` Laszlo Ersek 2015-07-21 22:58 ` Laszlo Ersek 2015-07-21 23:22 ` Laszlo Ersek 2015-07-22 9:05 ` Stefan Hajnoczi 2015-07-22 10:05 ` Laszlo Ersek 2015-07-22 11:42 ` Stefan Hajnoczi 2015-07-22 20:08 ` Laszlo Ersek 2015-07-23 8:26 ` Stefan Hajnoczi 2015-07-22 20:06 ` Michael Brown 2015-07-22 20:10 ` Laszlo Ersek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.