1. 05 6月, 2015 1 次提交
  2. 04 6月, 2015 1 次提交
  3. 03 6月, 2015 2 次提交
  4. 01 6月, 2015 2 次提交
    • L
      i386/pc: '-drive if=floppy' should imply a board-default FDC · 936a7c1c
      Laszlo Ersek 提交于
      Even if board code decides not to request the creation of the FDC (keyed
      off board-level factors, to be determined later), we should create the FDC
      nevertheless if the user passes '-drive if=floppy' on the command line.
      
      Otherwise '-drive if=floppy' would break without explicit '-device
      isa-fdc' on such boards.
      
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Cc: "Gabriel L. Somlo" <gsomlo@gmail.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: qemu-block@nongnu.org
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      936a7c1c
    • L
      i386/pc: pc_basic_device_init(): delegate FDC creation request · fd53c87c
      Laszlo Ersek 提交于
      This patch introduces no observable change, but it allows the callers of
      pc_basic_device_init(), ie. pc_init1() and pc_q35_init(), to request (or
      not request) the creation of the FDC explicitly.
      
      At the moment both callers pass constant create_fdctrl=true (hence no
      observable change).
      
      Assuming a board passes create_fdctrl=false, "floppy" will be NULL on
      output, and (beyond the FDC not being created) that NULL will be passed on
      to pc_cmos_init(). Luckily, pc_cmos_init() already handles that case.
      
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Cc: "Gabriel L. Somlo" <gsomlo@gmail.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: qemu-block@nongnu.org
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      fd53c87c
  5. 31 5月, 2015 1 次提交
  6. 28 4月, 2015 2 次提交
  7. 25 3月, 2015 1 次提交
    • G
      fw_cfg: factor out initialization of FW_CFG_ID (rev. number) · 3a5c76ba
      Gabriel L. Somlo 提交于
      The fw_cfg documentation says this of the revision key (0x0001, FW_CFG_ID):
      
      > A 32-bit little-endian unsigned int, this item is used as an interface
      > revision number, and is currently set to 1 by all QEMU architectures
      > which expose a fw_cfg device.
      
      arm/virt doesn't.  It could be argued that that's an error in
      "hw/arm/virt.c"; on the other hand, all of the other fw_cfg providing
      boards set the interface version to 1 manually, despite the device
      coming from the same, shared implementation. Therefore, instead of
      adding
      
          fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
      
      to arm/virt, consolidate all such existing calls in the fw_cfg
      initialization code.
      Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
      Message-Id: <1426789244-26318-1-git-send-email-somlo@cmu.edu>
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3a5c76ba
  8. 20 3月, 2015 1 次提交
    • I
      pc: fix default VCPU to NUMA node mapping · fb43b73b
      Igor Mammedov 提交于
      Since commit
         dd0247e0 pc: acpi: mark all possible CPUs as enabled in SRAT
      Linux kernel actually tries to use CPU to Node mapping from
      QEMU provided SRAT table instead of discarding it, and that
      in some cases breaks build_sched_domains() which expects
      sane mapping where cores/threads belonging to the same socket
      are on the same NUMA node.
      
      With current default round-robin mapping of VCPUs to nodes
      guest ends-up with cores/threads belonging to the same socket
      being on different NUMA nodes.
      
      For example with following CLI:
      
         qemu-system-x86_64 -m 4G \
               -cpu Opteron_G3,vendor=AuthenticAMD \
               -smp 5,sockets=1,cores=4,threads=1,maxcpus=8 \
               -numa node,nodeid=0 -numa node,nodeid=1
      
      2.6.32 based kernels will hang on boot due to incorrectly built
      sched_group-s list in update_sd_lb_stats()
      
      Replacing default mapping with a manual, where VCPUs belonging to
      the same socket are on the same NUMA node, fixes the issue for
      guests which can't handle nonsense topology i.e. changing CLI to:
        -numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7
      
      So instead of simply scattering VCPUs around nodes, provide
      callback to map the same socket VCPUs to the same NUMA node,
      which is what guests would expect from a sane hardware/BIOS.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NAndreas Färber <afaerber@suse.de>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      fb43b73b
  9. 17 3月, 2015 2 次提交
  10. 10 3月, 2015 1 次提交
  11. 03 3月, 2015 1 次提交
  12. 26 2月, 2015 5 次提交
  13. 24 2月, 2015 3 次提交
  14. 18 2月, 2015 1 次提交
  15. 27 1月, 2015 3 次提交
  16. 23 12月, 2014 2 次提交
  17. 22 12月, 2014 1 次提交
  18. 15 12月, 2014 1 次提交
  19. 26 11月, 2014 1 次提交
  20. 25 11月, 2014 2 次提交
  21. 23 11月, 2014 4 次提交
  22. 04 11月, 2014 1 次提交
  23. 02 11月, 2014 1 次提交