1. 24 Nov, 2014 2 commits
  2. 02 Nov, 2014 2 commits
    • Nikita Belov's avatar
      hw/i386/acpi-build.c: Fix memory leak in acpi_build_tables_cleanup() · ac369a77
      Nikita Belov authored
      There are three ACPI tables: 'linker_data', 'rsdp' and 'table_data'. They are
      used differently. Two of them are being copied before using and only the copy
      is used later. But the third is used directly. Because of that we need to free
      two tables completely and delete only wrapper for the third one.
      
      Valgrind output:
      ==23931== 131,072 bytes in 1 blocks are definitely lost in loss record 7,729 of 7,734
      ==23931==    at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==23931==    by 0x2EA920: realloc_and_trace (vl.c:2811)
      ==23931==    by 0x509E6AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
      ==23931==    by 0x506DB32: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
      ==23931==    by 0x506E463: g_array_set_size (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
      ==23931==    by 0x256A4F: acpi_align_size (acpi-build.c:487)
      ==23931==    by 0x259F92: acpi_build (acpi-build.c:1601)
      ==23931==    by 0x25A212: acpi_setup (acpi-build.c:1682)
      ==23931==    by 0x24F346: pc_guest_info_machine_done (pc.c:1110)
      ==23931==    by 0x55FAAB: notifier_list_notify (notify.c:39)
      ==23931==    by 0x2EA704: qemu_run_machine_init_done_notifiers (vl.c:2759)
      ==23931==    by 0x2EEC3C: main (vl.c:4504)
      Signed-off-by: default avatarNikita Belov <zodiac@ispras.ru>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      ac369a77
    • Stefan Berger's avatar
      acpi: create separate file for TCPA log · 42a5b308
      Stefan Berger authored
      Create the TCPA log in a separate file rather than allocating
      ACPI table memory for it.
      Signed-off-by: default avatarStefan Berger <stefanb@linux.vnet.ibm.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      42a5b308
  3. 14 Oct, 2014 1 commit
  4. 03 Sep, 2014 1 commit
    • zhanghailiang's avatar
      acpi-build: Set FORCE_APIC_CLUSTER_MODEL bit for FADT flags · 07b81ed9
      zhanghailiang authored
      If we start Windows 2008 R2 DataCenter with number of cpu less than 8,
      The system will use APIC Flat Logical destination mode as default configuration,
      Which has an upper limit of 8 CPUs.
      
      The fault is that VM can not show all processors within Task Manager if
      we hot-add cpus when the number of cpus in VM extends the limit of 8.
      
      If we use cluster destination model, the problem will be solved.
      
      Note:
      This flag was introduced later than ACPI v1.0 specification while QEMU
      generates v1.0 tables only, but...
      
      linux kernel ignores this flag, so patch has no influence on it.
      
      Tested with Win[XPsp3|Srv2003EE|Srv2008DC|Srv2008R2|Srv2012R2], there
      isn't BSODs and guests boot just fine. In cases guest doesn't support
      cpu-hotplug, cpu becomes visible after reboot and in case the guest
      supports cpu-hotplug, it works as expected with this patch.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarhuangzhichao <huangzhichao@huawei.com>
      Signed-off-by: default avatarzhanghailiang <zhang.zhanghailiang@huawei.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-By: default avatarIgor Mammedov <imammedo@redhat.com>
      07b81ed9
  5. 28 Aug, 2014 1 commit
  6. 24 Aug, 2014 1 commit
  7. 14 Aug, 2014 1 commit
  8. 29 Jul, 2014 4 commits
  9. 28 Jul, 2014 1 commit
    • Paolo Bonzini's avatar
      pc: hack for migration compatibility from QEMU 2.0 · 07fb6176
      Paolo Bonzini authored
      Changing the ACPI table size causes migration to break, and the memory
      hotplug work opened our eyes on how horribly we were breaking things in
      2.0 already.
      
      The ACPI table size is rounded to the next 4k, which one would think
      gives some headroom.  In practice this is not the case, because the user
      can control the ACPI table size (each CPU adds 97 bytes to the SSDT and
      8 to the MADT) and so some "-smp" values will break the 4k boundary and
      fail to migrate.  Similarly, PCI bridges add ~1870 bytes to the SSDT.
      
      This patch concerns itself with fixing migration from QEMU 2.0.  It
      computes the payload size of QEMU 2.0 and always uses that one.
      The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size
      should always be enough; non-AML tables can change depending on the
      configuration (especially MADT, SRAT, HPET) but they remain the same
      between QEMU 2.0 and 2.1, so we only compute our padding based on the
      sizes of the SSDT and DSDT.
      
      Migration from QEMU 1.7 should work for guests that have a number of CPUs
      other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140.  It was already
      broken from QEMU 1.7 to QEMU 2.0 in the same way, though.
      
      Even with this patch, QEMU 1.7 and 2.0 have two different ideas of
      "-M pc-i440fx-2.0" when there are PCI bridges.  Igor sent a patch to
      adopt the QEMU 1.7 definition.  I think distributions should apply
      it if they move directly from QEMU 1.7 to 2.1+ without ever packaging
      version 2.0.
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Tested-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      07fb6176
  10. 19 Jun, 2014 2 commits
  11. 18 Jun, 2014 1 commit
  12. 15 Jun, 2014 1 commit
  13. 07 May, 2014 2 commits
  14. 14 Apr, 2014 1 commit
  15. 28 Mar, 2014 1 commit
  16. 27 Mar, 2014 1 commit
  17. 26 Mar, 2014 1 commit
    • Michael S. Tsirkin's avatar
      acpi: make SSDT 1.0 spec compliant when possible · b4f4d548
      Michael S. Tsirkin authored
      The ACPI specification says:
      
      The ASL compiler can emit two different AML opcodes for a Package
      declaration, either PackageOp or VarPackageOp. For small, fixed-length
      packages, the PackageOp is used and this opcode is compatible with ACPI
      1.0. A VarPackageOp will be emitted if any of the following conditions
      are true:
      . The NumElements argument is a TermArg that can only be resolved at
      runtime.
      . At compile time, NumElements resolves to a constant that is larger than
      255.
      . The PackageList contains more than 255 initializer elements.
      Note: The ability to create variable-sized packages was first introduced
      in ACPI 2.0. ACPI 1.0 only allowed fixed-size packages with up to 255 elements.
      
      So the spec seems to say a fixed value up to 255 must always
      be used with PackageOp and not VarPackageOp, and some guests
      (windows up to win2k8) seem to interpret it like this.
      
      Let's do just this, choosing the encoding depending on
      the number of elements.
      
      Fixes 9bcc80cd
      (i386/acpi-build: allow more than 255 elements in CPON).
      
      https://bugs.launchpad.net/bugs/1297651Reported-by: default avatarRobert Hu <robert.hu@intel.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      b4f4d548
  18. 18 Mar, 2014 4 commits
    • Michael S. Tsirkin's avatar
      acpi: fix endian-ness for table ids · 821e3227
      Michael S. Tsirkin authored
      when using signature for table ID, we forgot to byte-swap it.
      signatures are really ASCII strings, let's treat them as such.
      While at it, get rid of most of _SIGNATURE macros.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      821e3227
    • Laszlo Ersek's avatar
      i386/acpi-build: support hotplug of VCPU with APIC ID 0xFF · 2fd71f1b
      Laszlo Ersek authored
      Building on the previous patch, raise the maximal count of processor
      objects / NTFY branches / CPON elements from 255 to 256. This allows the
      VCPU with APIC ID 0xFF to be hotplugged.
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      2fd71f1b
    • Laszlo Ersek's avatar
      i386/acpi-build: allow more than 255 elements in CPON · 9bcc80cd
      Laszlo Ersek authored
      The build_ssdt() function builds a number of AML objects that are related
      to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
      (APIC IDs are in fact discontiguous, but this is the traditional
      interface: build a contiguous sequence from zero up that covers all
      possible APIC IDs.) These objects are:
      
      - a Processor() object for each VCPU,
      - a NTFY method, with one branch for each VCPU,
      - a CPON package with one element (hotplug status byte) for each VCPU.
      
      The build_ssdt() function currently limits the *count* of processor
      objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
      to "acpi_cpus"). This allows for an inclusive APIC ID range of [0..254].
      This is incorrect, because the highest APIC ID that we otherwise allow a
      VCPU to take is 255.
      
      In order to extend the maximum count to 256, and the traversed APIC ID
      range correspondingly to [0..255]:
      - the Processor() objects need no change,
      - the NTFY method also needs no change,
      - the CPON package must be updated, because it is defined with a
        DefPackage, and the number of elements in such a package can be at most
        255. We pick a DefVarPackage instead.
      
      We replace the Op byte, and the encoding of the number of elements.
      Compare:
      
      DefPackage     := PackageOp    PkgLength NumElements    PackageElementList
      DefVarPackage  := VarPackageOp PkgLength VarNumElements PackageElementList
      
      PackageOp      := 0x12
      VarPackageOp   := 0x13
      
      NumElements    := ByteData
      VarNumElements := TermArg => Integer
      
      The build_append_int() function implements precisely the following TermArg
      encodings (a subset of what the ACPI spec describes):
      
        TermArg             := DataObject
        DataObject          := ComputationalData
        ComputationalData   := ConstObj | ByteConst | WordConst | DWordConst
      
        directly encoded in the function, with build_append_byte():
          ConstObj          := ZeroOp | OneOp
            ZeroOp          := 0x00
            OneOp           := 0x01
      
        call to build_append_value(..., 1):
          ByteConst         := BytePrefix ByteData
            BytePrefix      := 0x0A
            ByteData        := 0x00 - 0xFF
      
        call to build_append_value(..., 2):
          WordConst         := WordPrefix WordData
            WordPrefix      := 0x0B
            WordData        := ByteData[0:7] ByteData[8:15]
      
        call to build_append_value(..., 4):
          DWordConst        := DWordPrefix DWordData
            DWordPrefix     := 0x0C
            DWordData       := WordData[0:15] WordData[16:31]
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      9bcc80cd
    • Eduardo Habkost's avatar
      acpi: Don't use MAX_CPUMASK_BITS for APIC ID bitmap · 798325ed
      Eduardo Habkost authored
      MAX_CPUMASK_BITS is a limit for max_cpus and CPU indexes, not for APIC
      IDs.
      
      ACPI_CPU_HOTPLUG_ID_LIMIT is the right macro for the limit on APIC IDs
      on the ACPI and CPU hotplug code.
      
      There are no functional changes introduced by this patch, as
      MAX_CPUMASK_BITS + 1 == 255 + 1 == 256 == ACPI_CPU_HOTPLUG_ID_LIMIT.
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      798325ed
  19. 12 Mar, 2014 1 commit
  20. 11 Mar, 2014 1 commit
  21. 09 Mar, 2014 1 commit
    • Michael S. Tsirkin's avatar
      acpi-build: append description for non-hotplug · 8dcf525a
      Michael S. Tsirkin authored
      As reported in
      http://article.gmane.org/gmane.comp.emulators.qemu/253987
      Mac OSX actually requires describing all occupied slots
      in ACPI - even if hotplug isn't enabled.
      
      I didn't expect this so I dropped description of all
      non hotpluggable slots from ACPI.
      As a result: before
      commit 99fd437d (enable
      hotplug for pci bridges), PCI cards show up in the "device tree" of OS X
      (System Information). E.g., on MountainLion users have:
      
      Hardware -> PCI Cards:
      
        Card          Type                 Driver Installed  Slot
       *ethernet      Ethernet Controller  Yes               PCI Slot 2
        pci8086,2934  USB UHC              Yes               PCI Slot 29
      
        ethernet:
          Type:                 Ethernet Controller
          Driver Installed:     Yes
          MSI:                  No
          Bus:                  PCI
          Slot                  PCI Slot 2
          Vendor ID:            0x8086
          Device ID:            0x100e
          Subsystem Vendor ID:  0x1af4
          Subsystem ID:         0x1100
          Revision ID:          0x0003
      
      Hardware -> Ethernet Cards
      
        ethernet:
          Type:                 Ethernet Controller
          Bus:                  PCI
          Slot                  PCI Slot 2
          Vendor ID:            0x8086
          Device ID:            0x100e
          Subsystem Vendor ID:  0x1af4
          Subsystem ID:         0x1100
          Revision ID:          0x0003
          BSD name:             en0
          Kext name:            AppleIntel8254XEthernet.kext
          Location:             /System/Library/Extensions/...
          Version:              3.1.1b1
      
      After commit 99fd437d, users get:
      
      Hardware -> PCI Cards:
      
        This computer doesn't contain any PCI cards. If you installed PCI
        cards, make sure they're properly installed.
      
      Hardware -> Ethernet Cards
      
        ethernet:
          Type:                 Ethernet Controller
          Bus:                  PCI
          Vendor ID:            0x8086
          Device ID:            0x100e
          Subsystem Vendor ID:  0x1af4
          Subsystem ID:         0x1100
          Revision ID:          0x0003
          BSD name:             en0
          Kext name:            AppleIntel8254XEthernet.kext
          Location:             /System/Library/Extensions/...
          Version:              3.1.1b1
      
      Ethernet still works, but it's not showing up on the PCI bus, and it
      no longer thinks it's plugged in to slot #2, as it used to before the
      change.
      
      To fix, append description for all occupied non hotpluggable PCI slots.
      
      One need to be careful when doing this: VGA devices
      are now described in SSDT, so we need to drop description from DSDT.
      And ISA devices are used in DSDT so drop them from SSDT.
      Reported-by: default avatarGabriel L. Somlo <gsomlo@gmail.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      
      Also update generated dsdt and pcihp hex dump files.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      8dcf525a
  22. 10 Feb, 2014 1 commit
  23. 26 Jan, 2014 4 commits
  24. 10 Dec, 2013 1 commit
  25. 02 Dec, 2013 1 commit
    • Stefan Weil's avatar
      acpi-build: Fix compiler warning (missing gnu_printf format attribute) · 867d898c
      Stefan Weil authored
      gcc 4.8.2 reports this warning when extra warnings are enabled (-Wextra):
      
        CC    m68k-softmmu/hw/m68k/mcf5206.o
      hw/i386/acpi-build.c: In function ‘build_append_nameseg’:
      hw/i386/acpi-build.c:294:5: error:
       function might be possible candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
           g_string_vprintf(s, format, args);
           ^
      
      When this warning is fixed, there is a new compiler warning:
      
        CC    i386-softmmu/hw/i386/acpi-build.o
      hw/i386/acpi-build.c: In function ‘build_append_notify’:
      hw/i386/acpi-build.c:632:5: error:
       format not a string literal and no format arguments [-Werror=format-security]
           build_append_nameseg(method, name);
           ^
      
      This is fixed here, too.
      Signed-off-by: default avatarStefan Weil <sw@weilnetz.de>
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      867d898c
  26. 25 Nov, 2013 1 commit
  27. 21 Nov, 2013 1 commit