Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 17 12月, 2015 1 次提交
  3. 15 12月, 2015 1 次提交
    • G
      fw_cfg: remove offset argument from callback prototype · 3f8752b4
      由 Gabriel L. Somlo 提交于 
      Read callbacks are now only invoked at item selection, before any
data is read. As such, the value of the offset argument passed to
the callback will always be 0. Also, the two callback instances
currently in use both leave their offset argument unused.

This patch removes the offset argument from the fw_cfg read callback
prototype, and from the currently available instances. The unused
(write) callback prototype is also removed (write support was removed
earlier, in commit 023e3148).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Marc Marí <markmb@redhat.com>
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1446733972-1602-4-git-send-email-somlo@cmu.edu
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      3f8752b4
  5. 13 8月, 2015 1 次提交
  7. 28 7月, 2015 1 次提交
  9. 04 7月, 2015 1 次提交
  11. 23 6月, 2015 1 次提交
  13. 11 6月, 2015 2 次提交
    • L
      i386/acpi-build: fix PXB workarounds for unsupported BIOSes · 4ebc736e
      由 Laszlo Ersek 提交于 
      The patch

  apci: fix PXB behaviour if used with unsupported BIOS

uses the following condition to see if a "PXB mem/IO chunk" has *not* been
configured by the BIOS:

  (!range_base || range_base > range_limit)

When this condition evaluates to true, said patch *omits* the
corresponding entry from the _CRS.

Later on the patch checks for the opposite condition (with the intent of
*adding* entries to the _CRS if the "PXB mem/IO chunks" *have* been
configured). Unfortunately, the condition was negated incorrectly: only
the first ! operator was removed, which led to the nonsensical expression

  (range_base || range_base > range_limit)

leading to bogus entries in the _CRS, and causing BSOD in Windows Server
2012 R2 when it runs on OVMF.

The correct negative of the condition seen at the top is

  (range_base && range_base <= range_limit)

Fix the expressions.

Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      4ebc736e
    • L
      i386/acpi-build: more traditional _UID and _HID for PXB root buses · c96d9286
      由 Laszlo Ersek 提交于 
      The ACPI specification permits the _HID and _UID objects to evaluate to
strings. (See "6.1.5 _HID (Hardware ID)" and "6.1.12 _UID (Unique ID)" in
the ACPI v6.0 spec.)

With regard to related standards, the UEFI specification can also express
a device address composed from string _HID and _UID identifiers, inside
the Expanded ACPI Device Path Node. (See "9.3.3 ACPI Device Path", Table
49, in the UEFI v2.5 spec.)

However, numeric (integer) contents for both _HID and _UID are more
traditional. They are recommended by the UEFI spec for size reasons:

  [...] the ACPI Device Path node is smaller and should be used if
  possible to reduce the size of device paths that may potentially be
  stored in nonvolatile storage [...]

External tools support them better (for example the --acpi_hid and
--acpi_uid options of "efibootmgr" only take numeric identifiers).
Finally, numeric _HID and _UID contents are existing practice in the QEMU
source.

This patch was tested with a Fedora 20 LiveCD and a preexistent Windows
Server 2012 R2 guest. Using "acpidump" and "iasl" in the Fedora guest, we
get, in the SSDT:

> Scope (\_SB)
> {
>   Device (PC04)
>   {
>     Name (_UID, 0x04)  // _UID: Unique ID
>     Name (_HID, EisaId ("PNP0A03") /* PCI Bus */)  // _HID: Hardware ID

Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c96d9286
  15. 04 6月, 2015 7 次提交
  17. 03 6月, 2015 1 次提交
    • S
      hw/i386/acpi-build: decref after use · d370dfa9
      由 Shannon Zhao 提交于 
      valgrind complains about:
==16447== 48 bytes in 2 blocks are definitely lost in loss record 2,033 of 3,310
==16447==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==    by 0x2E4FD7: malloc_and_trace (vl.c:2546)
==16447==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16447==    by 0x53EC3F: qint_from_int (qint.c:33)
==16447==    by 0x53B426: qmp_output_type_int (qmp-output-visitor.c:162)
==16447==    by 0x539257: visit_type_uint32 (qapi-visit-core.c:147)
==16447==    by 0x471D07: property_get_uint32_ptr (object.c:1651)
==16447==    by 0x47000C: object_property_get (object.c:822)
==16447==    by 0x472428: object_property_get_qobject (qom-qobject.c:37)
==16447==    by 0x25701A: build_append_pci_bus_devices (acpi-build.c:520)
==16447==    by 0x25902E: build_ssdt (acpi-build.c:1004)
==16447==    by 0x25A0A8: acpi_build (acpi-build.c:1420)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      d370dfa9
  19. 01 6月, 2015 1 次提交
  21. 31 5月, 2015 1 次提交
    • R
      pc: acpi: fix pvpanic for buggy guests · 2332333c
      由 Radim Krčmář 提交于 
      In the old times, we always had pvpanic in ACPI and a _STA method told
the guest not to use it.  Automatic generation dropped the _STA method
as the specification says that missing _STA means enabled and working.
Some guests (Linux) had buggy drivers and this change made them unable
to utilize pvpanic.

A Linux patch is posted as well, but I think it's worth to make pvpanic
useable on old guests at the price of three lines and few bytes of SSDT.

The old _STA method was
  Method (_STA, 0, NotSerialized) {
      Store (PEST, Local0)
      If (LEqual (Local0, Zero)) {
          Return (Zero) }
      Else {
          Return (0x0F) }}

Igor pointed out that we don't need to use a method to return a constant
and that 0xB (don't show in UI) is the common definition now.

Also, the device used to be PEVT.  (PEVT as in "panic event"?)
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      2332333c
  23. 29 5月, 2015 2 次提交
  25. 30 4月, 2015 1 次提交
  27. 28 4月, 2015 8 次提交
  29. 01 4月, 2015 1 次提交
  31. 08 3月, 2015 2 次提交
  33. 01 3月, 2015 8 次提交