1. 20 6月, 2013 9 次提交
    • P
      memory: move private types to exec.c · 1db8abb1
      Paolo Bonzini 提交于
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1db8abb1
    • J
      memory: Introduce address_space_lookup_region · 9f029603
      Jan Kiszka 提交于
      This introduces a wrapper for phys_page_find (before we complicate
      address_space_translate with IOMMU translation).  This function will
      also encapsulate locking and reference counting when we introduce
      BQL-free dispatching.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9f029603
    • P
      exec.c: address_space_translate: handle access to addr 0 of 2^64 sized region · 3752a036
      Peter Maydell 提交于
      The memory API allows a MemoryRegion's size to be 2^64, as a special
      case (otherwise the size always fits in a 64 bit integer). This meant
      that attempts to access address zero in a 2^64 sized region would
      assert in address_space_translate():
      
        #3  0x00007ffff3e4d192 in __GI___assert_fail#(assertion=0x555555a43f32
          "!a.hi", file=0x555555a43ef0 "include/qemu/int128.h", line=18,
          function=0x555555a4439f "int128_get64") at assert.c:103
        #4  0x0000555555877642 in int128_get64 (a=...)
          at include/qemu/int128.h:18
        #5  0x00005555558782f2 in address_space_translate (as=0x55555668d140,
         /addr=0, xlat=0x7fffafac9918, plen=0x7fffafac9920, is_write=false)
          at exec.c:221
      
      Fix this by doing the 'min' operation in 128 bit arithmetic
      rather than 64 bit arithmetic (we know the result of the 'min'
      definitely fits in 64 bits because one of the inputs did).
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3752a036
    • M
      doc: Drop ref to Bochs from -no-fd-bootchk documentation · 4eda32f5
      Markus Armbruster 提交于
      Manual page and qemu-doc on talk about "Bochs BIOS".  We use SeaBIOS,
      and it implements the feature.  Replace by just "BIOS", and drop the
      TODO line wondering about the Bochs reference.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-7-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4eda32f5
    • M
      pc: Make -no-fd-bootchk stick across boot order changes · e1123015
      Markus Armbruster 提交于
      Option -no-fd-bootchk asks the BIOS to attempt booting from a floppy
      even when the boot sector signature isn't there, by setting a bit in
      RTC CMOS.  It was added back in 2006 (commit 52ca8d6a).
      
      Two years later, commit 0ecdffbb added monitor command boot_set.
      Implemented by new function pc_boot_set().  It unconditionally clears
      the floppy signature bit in CMOS.
      
      Commit e0f084bf added -boot option once to automatically change the
      boot order on first reset.  Reuses pc_boot_set(), thus also clears the
      floppy signature bit.  Commit d9346e81 took care to preserve this
      behavior.
      
      Thus, -no-fd-bootchk applies to any number of boots.  Except it
      applies just to the first boot with -boot once, and never after
      boot_set.  Weird.  Make it stick instead: set the bit according to
      -no-fd-bootchk in pc_boot_set().
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-6-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      e1123015
    • M
      vl: Rename *boot_devices to *boot_order, for consistency · 083b79c9
      Markus Armbruster 提交于
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-5-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      083b79c9
    • M
      vl: Fix -boot order and once regressions, and related bugs · 8281abd5
      Markus Armbruster 提交于
      Option "once" sets up a different boot order just for the initial
      boot.  Boot order reverts back to normal on reset.  Option "order"
      changes the normal boot order.
      
      The reversal is implemented by reset handler restore_boot_devices(),
      which takes the boot order to revert to as argument.
      restore_boot_devices() does nothing on its first call, because that
      must be the initial machine reset.  On its second call, it changes the
      boot order back, and unregisters itself.
      
      Because we register the handler right when -boot gets parsed, we can
      revert to an incorrect normal boot order, and multiple -boot can
      interact in funny ways.
      
      Here's how things work without -boot once or order:
      
      * boot_devices is "".
      
      * main() passes machine->boot_order to to machine->init(), because
        boot_devices is "".  machine->init() configures firmware
        accordingly.  For PC machines, machine->boot_order is "cad", and
        pc_cmos_init() writes it to RTC CMOS, where SeaBIOS picks it up.
      
      Now consider -boot order=:
      
      * boot_devices is "".
      
      * -boot order= sets boot_devices to "" (no change).
      
      * main() passes machine->boot_order to to machine->init(), because
        boot_devices is "", as above.
      
        Bug: -boot order= has no effect.  Broken in commit e4ada29e.
      
      Next, consider -boot once=a:
      
      * boot_devices is "".
      
      * -boot once=a registers restore_boot_devices() with argument "", and
        sets boot_devices to "a".
      
      * main() passes boot_devices "a" to machine->init(), which configures
        firmware accordingly.  For PC machines, pc_cmos_init() writes the
        boot order to RTC CMOS.
      
      * main() calls qemu_system_reset().  This runs reset handlers.
      
        - restore_boot_devices() gets called with argument "".  Does
          nothing, because it's the first call.
      
      * Machine boots, boot order is "a".
      
      * Machine resets (e.g. monitor command).  Reset handlers run.
      
        - restore_boot_devices() gets called with argument "".  Calls
          qemu_boot_set("") to reconfigure firmware.  For PC machines,
          pc_boot_set() writes it into RTC CMOS.  Reset handler
          unregistered.
      
          Bug: boot order reverts to "" instead of machine->boot_order.  The
          actual boot order depends on how firmware interprets "".  Broken
          in commit e4ada29e.
      
      Next, consider -boot once=a -boot order=c:
      
      * boot_devices is "".
      
      * -boot once=a registers restore_boot_devices() with argument "", and
        sets boot_devices to "a".
      
      * -boot order=c sets boot_devices to "c".
      
      * main() passes boot_devices "c" to machine->init(), which configures
        firmware accordingly.  For PC machines, pc_cmos_init() writes the
        boot order to RTC CMOS.
      
      * main() calls qemu_system_reset().  This runs reset handlers.
      
        - restore_boot_devices() gets called with argument "".  Does
          nothing, because it's the first call.
      
      * Machine boots, boot order is "c".
      
        Bug: it should be "a".  I figure this has always been broken.
      
      * Machine resets (e.g. monitor command).  Reset handlers run.
      
        - restore_boot_devices() gets called with argument "".  Calls
          qemu_boot_set("") to reconfigure firmware.  For PC machines,
          pc_boot_set() writes it into RTC CMOS.  Reset handler
          unregistered.
      
          Bug: boot order reverts to "" instead of "c".  I figure this has
          always been broken, just differently broken before commit
          e4ada29e.
      
      Next, consider -boot once=a -boot once=b -boot once=c:
      
      * boot_devices is "".
      
      * -boot once=a registers restore_boot_devices() with argument "", and
        sets boot_devices to "a".
      
      * -boot once=b registers restore_boot_devices() with argument "a", and
        sets boot_devices to "b".
      
      * -boot once=c registers restore_boot_devices() with argument "b", and
        sets boot_devices to "c".
      
      * main() passes boot_devices "c" to machine->init(), which configures
        firmware accordingly.  For PC machines, pc_cmos_init() writes the
        boot order to RTC CMOS.
      
      * main() calls qemu_system_reset().  This runs reset handlers.
      
        - restore_boot_devices() gets called with argument "".  Does
          nothing, because it's the first call.
      
        - restore_boot_devices() gets called with argument "a".  Calls
          qemu_boot_set("a") to reconfigure firmware.  For PC machines,
          pc_boot_set() writes it into RTC CMOS.  Reset handler
          unregistered.
      
        - restore_boot_devices() gets called with argument "b".  Calls
          qemu_boot_set("b") to reconfigure firmware.  For PC machines,
          pc_boot_set() writes it into RTC CMOS.  Reset handler
          unregistered.
      
      * Machine boots, boot order is "b".
      
        Bug: should really be "c", because that came last, and for all other
        -boot options, the last one wins.  I figure this was broken some
        time before commit 37905d6a, and fixed there only for a single
        occurence of "once".
      
      * Machine resets (e.g. monitor command).  Reset handlers run.
      
        - restore_boot_devices() gets called with argument "".  Calls
          qemu_boot_set("") to reconfigure firmware.  For PC machines,
          pc_boot_set() writes it into RTC CMOS.  Reset handler
          unregistered.
      
          Same bug as above: boot order reverts to "" instead of
          machine->boot_order.
      
      Fix by acting upon -boot options order, once and menu only after
      option parsing is complete, and the machine is known.  This is how the
      other -boot options work already.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-4-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      8281abd5
    • M
      qemu-option: check_params() is now unused, drop it · a86b35f9
      Markus Armbruster 提交于
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-3-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      a86b35f9
    • M
      vl: Clean up parsing of -boot option argument · 6ef4716c
      Markus Armbruster 提交于
      Commit 3d3b8303 threw in some QemuOpts parsing without replacing the
      existing ad hoc parser, resulting in a confusing mess.  Clean it up.
      
      Two user-visible changes:
      
      1. Invalid options are reported more nicely.  Before:
      
              qemu: unknown boot parameter 'x' in 'x=y'
      
         After:
      
              qemu-system-x86_64: -boot x=y: Invalid parameter 'x'
      
      2. If -boot is given multiple times, options accumulate, just like for
         -machine.  Before, only options order, once and menu accumulated.
         For the other ones, all but the first -boot in non-legacy syntax
         got simply ignored.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1371208516-7857-2-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      6ef4716c
  2. 19 6月, 2013 1 次提交
  3. 18 6月, 2013 24 次提交
  4. 17 6月, 2013 6 次提交