qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: "Marc Marí" <markmb@redhat.com>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>,
	qemu-devel@nongnu.org, Kevin O'Connor <kevin@koconnor.net>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Laszlo <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] Add optionrom compatible with fw_cfg DMA version
Date: Mon, 18 Jan 2016 14:42:06 +0000	[thread overview]
Message-ID: <20160118144206.GA32286@stefanha-x1.localdomain> (raw)
In-Reply-To: <1453111140-15128-1-git-send-email-markmb@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4541 bytes --]

On Mon, Jan 18, 2016 at 10:59:00AM +0100, Marc Marí wrote:
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 459260b..00339fa 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1007,8 +1007,13 @@ static void load_linux(PCMachineState *pcms,
>      fw_cfg_add_i32(fw_cfg, FW_CFG_SETUP_SIZE, setup_size);
>      fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA, setup, setup_size);
>  
> -    option_rom[nb_option_roms].name = "linuxboot.bin";
> -    option_rom[nb_option_roms].bootindex = 0;
> +    if (fw_cfg_dma_enabled(fw_cfg)) {
> +        option_rom[nb_option_roms].name = "linuxboot_dma.bin";
> +        option_rom[nb_option_roms].bootindex = 0;
> +    } else {
> +        option_rom[nb_option_roms].name = "linuxboot.bin";
> +        option_rom[nb_option_roms].bootindex = 0;
> +    }

Live migration compatibility requires that guest-visible changes to the
machine are only introduced in a new -machine <machine-type>.

This ensures that migrating from an older QEMU version to a newer QEMU
version will not change the guest-visible memory layout or device
behavior.

The Option ROM should not change when migration between different QEMU
versions.

I've CCed Gerd and Juan, I think they know how changes to Option ROMs
affect live migration better than me.  What needs to be done to preserve
live migration compatibility?

> diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
> index ce4852a..076f351 100644
> --- a/pc-bios/optionrom/Makefile
> +++ b/pc-bios/optionrom/Makefile
> @@ -2,6 +2,7 @@ all: build-all
>  # Dummy command so that make thinks it has done something
>  	@true
>  
> +BULD_DIR=$(CURDIR)

Is this a typo (BUILD_DIR)?  Is it even needed?

>  include ../../config-host.mak
>  include $(SRC_PATH)/rules.mak
>  
> @@ -11,15 +12,20 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom)
>  
>  CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer -fno-builtin
>  CFLAGS += -I$(SRC_PATH)
> +CFLAGS += -I$(SRC_PATH)/include

Are you using any QEMU headers?  If not, then this change can be
dropped.

> +linuxboot_dma.img: linuxboot_dma.o
> +	$(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -m elf_i386 -static -Ttext 0 -e _start -s -o $@ $<,"  Building $(TARGET_DIR)$@")

Why is -static necessary?

> +#define BOOT_ROM_PRODUCT "Linux loader"

Please differentiate from linuxboot.S.  Maybe call it "Linux loader
DMA".

> +typedef struct FWCfgDmaAccess {
> +    uint32_t control;
> +    uint32_t length;
> +    uint64_t address;
> +} __attribute__((gcc_struct, packed)) FWCfgDmaAccess;

gcc_struct is for gcc vs Windows compiler compatibility when the struct
contains bitfields.  No bitfields are used and no Windows compiled code
is linked, so it seems unnecessary.

> +static void bios_cfg_read_entry(void *buf, uint16_t entry, uint32_t len)
> +{
> +    FWCfgDmaAccess access;
> +    uint32_t control = (entry << 16) | BIOS_CFG_DMA_CTL_SELECT
> +                        | BIOS_CFG_DMA_CTL_READ;
> +
> +    access.address = cpu_to_be64((uint64_t)(uint32_t)buf);
> +    access.length = cpu_to_be32(len);
> +    access.control = cpu_to_be32(control);
> +
> +    barrier();
> +
> +    outl(cpu_to_be32((uint32_t)&access), BIOS_CFG_DMA_ADDR_LOW);
> +
> +    while(be32_to_cpu(access.control) & ~BIOS_CFG_DMA_CTL_ERROR) {
> +        barrier();
> +    }
> +}

This function is the unique part of linuxboot_dma.c.  Everything else is
copied and translated from linuxboot.S.  The refactorer in me wonders
how hard it would be to extend linuxboot.S instead of introducing this
new boot ROM.

Was there a technical reason why linuxboot.S cannot be extended (e.g.  a
size limit)?

> +    /* As we are changing crytical registers, we cannot leave freedom to the

s/crytical/critical/

> diff --git a/pc-bios/optionrom/optionrom.h b/pc-bios/optionrom/optionrom.h
> index f1a9021..25c765f 100644
> --- a/pc-bios/optionrom/optionrom.h
> +++ b/pc-bios/optionrom/optionrom.h
> @@ -29,7 +29,8 @@
>  #define DEBUG_HERE \
>  	jmp		1f;				\
>  	1:
> -	
> +
> +#ifndef C_CODE
>  /*
>   * Read a variable from the fw_cfg device.
>   * Clobbers:	%edx
> @@ -49,6 +50,7 @@
>  	inb		(%dx), %al
>  	bswap		%eax
>  .endm
> +#endif

Why do you need optionrom.h?  You seem to have expanded its macros
anyway (OPTION_ROM_START, BOOT_ROM_START, OPTION_ROM_END, BOOT_ROM_END).

If you need optionrom.h, please actually use its macros instead of
expanding them.

Otherwise, please don't include it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2016-01-18 14:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18  9:59 [Qemu-devel] [PATCH v2] Add optionrom compatible with fw_cfg DMA version Marc Marí
2016-01-18 10:38 ` Paolo Bonzini
2016-01-18 14:42 ` Stefan Hajnoczi [this message]
2016-01-18 16:22   ` Marc Marí
2016-01-18 17:10     ` Kevin O'Connor
2016-01-19 12:11     ` Gerd Hoffmann
2016-01-21 10:02       ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160118144206.GA32286@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=kevin@koconnor.net \
    --cc=lersek@redhat.com \
    --cc=markmb@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=somlo@cmu.edu \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).