1. 11 6月, 2013 1 次提交
  2. 03 6月, 2013 3 次提交
  3. 02 6月, 2013 1 次提交
  4. 29 5月, 2013 1 次提交
  5. 13 5月, 2013 1 次提交
  6. 07 5月, 2013 1 次提交
  7. 01 5月, 2013 3 次提交
  8. 30 4月, 2013 4 次提交
  9. 29 4月, 2013 1 次提交
  10. 25 4月, 2013 3 次提交
    • M
      pc: Kill the "use flash device for BIOS unless KVM" misfeature · 9953f882
      Markus Armbruster 提交于
      Use of a flash memory device for the BIOS was added in series "[PATCH
      v10 0/8] PC system flash support", commit 4732dcaf..1b89fafe, v1.1.
      
      Flash vs. ROM is a guest-visible difference.  Thus, flash use had to
      be suppressed for machine types pc-1.0 and older.  This was
      accomplished by adding a dummy device "pc-sysfw" with property
      "rom_only":
      
      * Non-zero rom_only means "use ROM".  Default for pc-1.0 and older.
      * Zero rom_only means "maybe use flash".  Default for newer machines.
      
      Not only is the dummy device ugly, it was also retroactively added to
      the older machine types!  Fortunately, it's not guest-visible (thus no
      immediate guest ABI breakage), and has no vmstate (thus no immediate
      migration breakage).  Breakage occurs only if the user unwisely
      enables flash by setting rom_only to zero.  Patch review FAIL #1.
      
      Why "maybe use flash"?  Flash didn't (and still doesn't) work with
      KVM.  Therefore, rom_only=0 really means "use flash, except when KVM
      is enabled, use ROM".  This is a Bad Idea, because it makes enabling/
      disabling KVM guest-visible.  Patch review FAIL #2.
      
      Aside: it also precludes migrating between KVM on and off, but that's
      not possible for other reasons anyway.
      
      Fix as follows:
      
      1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts,
      or maybes" for pc-i440fx-1.5 and pc-q35-1.5.  Don't change anything
      for older machines (to remain bug-compatible).
      
      2. Change the default value from 0 to 1 for these machines.
      Necessary, because 0 doesn't work with KVM.  Once it does, we can flip
      the default back to 0.
      
      3. Don't revert the retroactive addition of device "pc-sysfw" to older
      machine types.  Seems not worth the trouble.
      
      4. Add a TODO comment asking for device "pc-sysfw" to be dropped once
      flash works with KVM.
      
      Net effect is that you get a BIOS ROM again even when KVM is disabled,
      just like for machines predating the introduction of flash.
      
      To get flash instead, use "--global pc-sysfw.rom_only=0".
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      9953f882
    • M
      pc: Split pc_init_pci_1_0() off pc_init_pci_1_2() · 6fd028f6
      Markus Armbruster 提交于
      Just to make the next commit easier to review.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1365780303-26398-3-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      6fd028f6
    • M
      pc: Inline pc_init_pci_1_3() into pc_init_pci_1_2() · 36afbc51
      Markus Armbruster 提交于
      Just to make the commit after next easier to review.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1365780303-26398-2-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      36afbc51
  11. 15 4月, 2013 1 次提交
  12. 09 4月, 2013 1 次提交
    • P
      hw: move headers to include/ · 0d09e41a
      Paolo Bonzini 提交于
      Many of these should be cleaned up with proper qdev-/QOM-ification.
      Right now there are many catch-all headers in include/hw/ARCH depending
      on cpu.h, and this makes it necessary to compile these files per-target.
      However, fixing this does not belong in these patches.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0d09e41a
  13. 12 3月, 2013 1 次提交
  14. 01 3月, 2013 2 次提交
  15. 27 2月, 2013 1 次提交
  16. 23 2月, 2013 1 次提交
  17. 02 2月, 2013 1 次提交
  18. 30 1月, 2013 1 次提交
    • A
      virtio-net: introduce a new macaddr control · c1943a3f
      Amos Kong 提交于
      In virtio-net guest driver, currently we write MAC address to
      pci config space byte by byte, this means that we have an
      intermediate step where mac is wrong. This patch introduced
      a new control command to set MAC address, it's atomic.
      
      VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility.
      
      "mac" field will be set to read-only when VIRTIO_NET_F_CTRL_MAC_ADDR
      is acked.
      Signed-off-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c1943a3f
  19. 27 1月, 2013 2 次提交
    • E
      pc: Generate APIC IDs according to CPU topology · 8932cfdf
      Eduardo Habkost 提交于
      This keeps compatibility on machine-types pc-1.2 and older, and prints a
      warning in case the requested configuration won't get the correct
      topology.
      
      I couldn't think of a better way to warn about broken topology when in
      compat mode other than using error_report(). The warning message will
      probably be buried in a log file somewhere, but it's better than
      nothing.
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      8932cfdf
    • E
      pc: Reverse pc_init_pci() compatibility logic · 29694758
      Eduardo Habkost 提交于
      Currently, the pc-1.4 machine init function enables PV EOI and then
      calls the pc-1.2 machine init function. The problem with this approach
      is that now we can't enable any additional compatibility code inside the
      pc-1.2 init function because it would end up enabling the compatibility
      behavior on pc-1.3 and pc-1.4 as well.
      
      This reverses the logic so that the pc-1.2 machine init function will
      disable PV EOI, and then call the pc-1.4 machine init function.
      
      This way we can change older machine-types to enable compatibility
      behavior, and the newer machine-types (pc-1.3, pc-q35-1.4 and
      pc-i440fx-1.4) would just use the default behavior.
      
      (This means that one nice side-effect of this change is that pc-q35-1.4
      will get PV EOI enabled by default, too)
      
      It would be interesting to eventually change pc_init_pci_no_kvmclock()
      and pc_init_isa() to reuse pc_init_pci_1_2() as well (so we don't need
      to duplicate compatibility code on those two functions). But this will
      be probably much easier to do after we create a PCInitArgs struct for
      the PC initialization arguments, and/or after we use global-properties
      to implement the compatibility modes present in pc_init_pci_1_2().
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      29694758
  20. 16 1月, 2013 1 次提交
  21. 11 1月, 2013 1 次提交
    • G
      pc: rename machine types · 94dec594
      Gerd Hoffmann 提交于
      Starting with release 1.4 we have a fully functional q35 machine type,
      i.e. "qemu -M q35" JustWorks[tm].  Update machine type names to reflect
      that:
      
        * pc-1.4 becomes pc-i440fx-1.4
        * q35-next becomes pc-q35-1.4
      
      The pc-1.3 (+older) names are maintained for compatibility reasons.
      For the same reason the "pc" and "q35" aliases are kept.  pc-piix-1.4
      continues to be the default machine type, again for compatibility
      reasons.
      
      Also updated the description (shown by "qemu -M ?") with host bridge
      name, south bridge name and chipset release year.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      94dec594
  22. 04 1月, 2013 1 次提交
  23. 19 12月, 2012 3 次提交
  24. 17 12月, 2012 1 次提交
  25. 04 12月, 2012 2 次提交
    • H
      usb-tablet: Allow connecting to ehci · 427e3aa1
      Hans de Goede 提交于
      Our ehci code has is capable of significantly lowering the wakeup rate
      for the hcd emulation while the device is idle. It is possible to add
      similar code ot the uhci emulation, but that simply is not there atm,
      and there is no reason why a (virtual) usb-tablet can not be a USB-2 device.
      
      Making usb-hid devices connect to the emulated ehci controller instead
      of the emulated uhci controller on vms which have both lowers the cpuload
      for a fully idle vm from 20% to 2-3% (on my laptop).
      
      An alternative implementation to using a property to select the tablet
      type, would be simply making it a new device type, ie usb-tablet2, but the
      downside of that is that this will require libvirt changes to be available
      through libvirt at all, and then management tools changes to become the
      default for new vms, where as using a property will automatically get
      any pc-1.3 type vms the lower cpuload.
      
      [ kraxel: adapt compat property for post-1.3 merge ]
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      
      tablet compat fixup
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      427e3aa1
    • G
      add pc-1.4 · f1ae2e38
      Gerd Hoffmann 提交于
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      f1ae2e38
  26. 26 11月, 2012 1 次提交