qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] f40422: q35: implement 128K SMRAM at default


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] f40422: q35: implement 128K SMRAM at default SMBASE address
Date: Thu, 23 Jan 2020 06:30:12 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: f404220e279cec435dae3ea6c4093b43b984c76a
      
https://github.com/qemu/qemu/commit/f404220e279cec435dae3ea6c4093b43b984c76a
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/i386/pc.c
    M hw/pci-host/q35.c
    M include/hw/pci-host/q35.h

  Log Message:
  -----------
  q35: implement 128K SMRAM at default SMBASE address

It's not what real HW does, implementing which would be overkill [**]
and would require complex cross stack changes (QEMU+firmware) to make
it work.
So considering that SMRAM is owned by MCH, for simplicity (ab)use
reserved Q35 register, which allows QEMU and firmware easily init
and make RAM at SMBASE available only from SMM context.

Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes)
for inspiration and uses reserved register in config space at 0x9c
offset [*] to extend q35 pci-host with ability to use 128K at
0x30000 as SMRAM and hide it (like TSEG) from non-SMM context.

Usage:
  1: write 0xff in the register
  2: if the feature is supported, follow up read from the register
     should return 0x01. At this point RAM at 0x30000 is still
     available for SMI handler configuration from non-SMM context
  3: writing 0x02 in the register, locks SMBASE area, making its contents
     available only from SMM context. In non-SMM context, reads return
     0xff and writes are ignored. Further writes into the register are
     ignored until the system reset.

*) https://www.mail-archive.com/address@hidden/msg455991.html
**) https://www.mail-archive.com/address@hidden/msg646965.html

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Tested-by: Laszlo Ersek <address@hidden>


  Commit: 0cdd3eae15964ab589977a09a9765d5a5ca5b9cd
      
https://github.com/qemu/qemu/commit/0cdd3eae15964ab589977a09a9765d5a5ca5b9cd
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M tests/qtest/q35-test.c

  Log Message:
  -----------
  tests: q35: MCH: add default SMBASE SMRAM lock test

test lockable SMRAM at default SMBASE feature, introduced by
patch "q35: implement 128K SMRAM at default SMBASE address"

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 1d7a52835dc6bf5d641a0d29ad35c881b8d0ba5a
      
https://github.com/qemu/qemu/commit/1d7a52835dc6bf5d641a0d29ad35c881b8d0ba5a
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt

  Log Message:
  -----------
  acpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness

* Move reserved registers to the top of the section, so reader would be
  aware of effects when reading registers description.
* State registers endianness explicitly at the beginning of the section
* Describe registers behavior in case of 'CPU selector' register contains
  value that doesn't point to a possible CPU.

Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 1c1d43bf015df2768bf832ea76752dd95286fc8f
      
https://github.com/qemu/qemu/commit/1c1d43bf015df2768bf832ea76752dd95286fc8f
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt

  Log Message:
  -----------
  acpi: cpuhp: spec: fix 'Command data' description

Correct returned value description in case 'Command field' == 0x0,
it's not PXM but CPU selector value with pending event

In addition describe 0 blanket value in case of not supported
'Command field' value.

Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 5b8e5363faa19f6f5064df7f3830c7b56d80f28d
      
https://github.com/qemu/qemu/commit/5b8e5363faa19f6f5064df7f3830c7b56d80f28d
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt

  Log Message:
  -----------
  acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0

Write section of 'Command data' register should describe what happens
when it's written into. Correct description in case the last stored
'Command field' value is equal to 0, to reflect that currently it's not
supported.

Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: e6d0c3ce689585ad8f38c826e69ee04fb2c2257c
      
https://github.com/qemu/qemu/commit/e6d0c3ce689585ad8f38c826e69ee04fb2c2257c
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt
    M hw/acpi/cpu.c
    M hw/acpi/trace-events

  Log Message:
  -----------
  acpi: cpuhp: introduce 'Command data 2' field

No functional change in practice, patch only aims to properly
document (in spec and code) intended usage of the reserved space.

The new field is to be used for 2 purposes:
  - detection of modern CPU hotplug interface using
    CPHP_GET_NEXT_CPU_WITH_EVENT_CMD command.
    procedure will be described in follow up patch:
      "acpi: cpuhp: spec: add typical usecases"
  - for returning upper 32 bits of architecture specific CPU ID,
    for new CPHP_GET_CPU_ID_CMD command added by follow up patch:
      "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command"

Change is backward compatible with 4.2 and older machines, as field was
unconditionally reserved and always returned 0x0 if modern CPU hotplug
interface was enabled.

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>


  Commit: ae340aa3d2567694c48737939496c1e699cad7e2
      
https://github.com/qemu/qemu/commit/ae340aa3d2567694c48737939496c1e699cad7e2
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt

  Log Message:
  -----------
  acpi: cpuhp: spec: add typical usecases

Document work-flows for
  * enabling/detecting modern CPU hotplug interface
  * finding a CPU with pending 'insert/remove' event
  * enumerating present and possible CPUs

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>


  Commit: 3a61c8db9d25ff8ed08c5f96acecd63707187904
      
https://github.com/qemu/qemu/commit/3a61c8db9d25ff8ed08c5f96acecd63707187904
  Author: Igor Mammedov <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt
    M hw/acpi/cpu.c

  Log Message:
  -----------
  acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command

Firmware can enumerate present at boot APs by broadcasting wakeup IPI,
so that woken up secondary CPUs could register them-selves.
However in CPU hotplug case, it would need to know architecture
specific CPU IDs for possible and hotplugged CPUs so it could
prepare environment for and wake hotplugged AP.

Reuse and extend existing CPU hotplug interface to return architecture
specific ID for currently selected CPU in 2 registers:
 - lower 32 bits in ACPI_CPU_CMD_DATA_OFFSET_RW
 - upper 32 bits in ACPI_CPU_CMD_DATA2_OFFSET_R

On x86, firmware will use CPHP_GET_CPU_ID_CMD for fetching the APIC ID
when handling hotplug SMI.

Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR,
which serves the similar to APIC ID purpose.

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>


  Commit: 3c2ab5593bd3b75e0a13f6e9826606a640b46fe0
      
https://github.com/qemu/qemu/commit/3c2ab5593bd3b75e0a13f6e9826606a640b46fe0
  Author: Michael S. Tsirkin <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M tests/qtest/bios-tables-test.c

  Log Message:
  -----------
  bios-tables-test: document expected file update

Document the flow for the case where contributor
updates the expected files.

Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 9580d60e66d1543a0d79265c0085ee09b8782987
      
https://github.com/qemu/qemu/commit/9580d60e66d1543a0d79265c0085ee09b8782987
  Author: Pan Nengyuan <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/9pfs/virtio-9p-device.c

  Log Message:
  -----------
  virtio-9p-device: fix memleak in virtio_9p_device_unrealize

v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak
stack is as follow:

Direct leak of 14336 byte(s) in 2 object(s) allocated from:
  #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624)  
/mnt/sdb/qemu/hw/virtio/virtio.c:2327
  #3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7)  
/mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209
  #4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6)  
/mnt/sdb/qemu/hw/virtio/virtio.c:3504
  #5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37)  
/mnt/sdb/qemu/hw/core/qdev.c:876

Reported-by: Euler Robot <address@hidden>
Signed-off-by: Pan Nengyuan <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Christian Schoenebeck <address@hidden>
Acked-by: Greg Kurz <address@hidden>


  Commit: ad30a9e9043ac6ca386d5baca71e6c3d33bfcb9c
      
https://github.com/qemu/qemu/commit/ad30a9e9043ac6ca386d5baca71e6c3d33bfcb9c
  Author: Pan Nengyuan <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/9pfs/virtio-9p-device.c

  Log Message:
  -----------
  virtio-9p-device: convert to new virtio_delete_queue

Use virtio_delete_queue to make it more clear.

Signed-off-by: Pan Nengyuan <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Acked-by: Christian Schoenebeck <address@hidden>


  Commit: dd958f9ef44e2639a384fb9f764ff0bc8181abcd
      
https://github.com/qemu/qemu/commit/dd958f9ef44e2639a384fb9f764ff0bc8181abcd
  Author: Pan Nengyuan <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/scsi/virtio-scsi.c

  Log Message:
  -----------
  virtio-scsi: delete vqs in unrealize to avoid memleaks

This patch fix memleaks when attaching/detaching virtio-scsi device, the
memory leak stack is as follow:

Direct leak of 21504 byte(s) in 3 object(s) allocated from:
  #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa)  
/mnt/sdb/qemu/hw/virtio/virtio.c:2333
  #3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55)  
/mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912
  #4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b)  
/mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924
  #5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47)  
/mnt/sdb/qemu/hw/virtio/virtio.c:3531
  #6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224)  
/mnt/sdb/qemu/hw/core/qdev.c:865

Reported-by: Euler Robot <address@hidden>
Signed-off-by: Pan Nengyuan <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>


  Commit: 2feff67c4e10823604ca2ce8ae933868b558d255
      
https://github.com/qemu/qemu/commit/2feff67c4e10823604ca2ce8ae933868b558d255
  Author: Pan Nengyuan <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/scsi/virtio-scsi.c

  Log Message:
  -----------
  virtio-scsi: convert to new virtio_delete_queue

Use virtio_delete_queue to make it more clear.

Signed-off-by: Pan Nengyuan <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>


  Commit: e1932cf9144a008d85b28c6ff348495cf26e771d
      
https://github.com/qemu/qemu/commit/e1932cf9144a008d85b28c6ff348495cf26e771d
  Author: Pan Nengyuan <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/virtio/vhost-vsock.c
    M include/hw/virtio/vhost-vsock.h

  Log Message:
  -----------
  vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
patch save receive/transmit vq pointer in realize() and cleanup vqs
through those vq pointers in unrealize(). The leak stack is as follow:

Direct leak of 21504 byte(s) in 3 object(s) allocated from:
  #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  
/mnt/sdb/qemu/hw/virtio/virtio.c:2333
  #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  
/mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
  #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  
/mnt/sdb/qemu/hw/virtio/virtio.c:3531
  #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  
/mnt/sdb/qemu/hw/core/qdev.c:865
  #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  
/mnt/sdb/qemu/qom/object.c:2102

Reported-by: Euler Robot <address@hidden>
Signed-off-by: Pan Nengyuan <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefano Garzarella <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: ff4776147e960b128ee68f94c728659f662f4378
      
https://github.com/qemu/qemu/commit/ff4776147e960b128ee68f94c728659f662f4378
  Author: Dr. David Alan Gilbert <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: Add names to section rounded warning

Add the memory region names to section rounding/alignment
warnings.

Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 76525114736e8f669766e69b715fa59ce8648aae
      
https://github.com/qemu/qemu/commit/76525114736e8f669766e69b715fa59ce8648aae
  Author: Dr. David Alan Gilbert <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: Only align sections for vhost-user

I added hugepage alignment code in c1ece84e7c9 to deal with
vhost-user + postcopy which needs aligned pages when using userfault.
However, on x86 the lower 2MB of address space tends to be shotgun'd
with small fragments around the 512-640k range - e.g. video RAM, and
with HyperV synic pages tend to sit around there - again splitting
it up.  The alignment code complains with a 'Section rounded to ...'
error and gives up.

Since vhost-user already filters out devices without an fd
(see vhost-user.c vhost_user_mem_section_filter) it shouldn't be
affected by those overlaps.

Turn the alignment off on vhost-kernel so that it doesn't try
and align, and thus won't hit the rounding issues.

Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>


  Commit: aefcaf9d1b3ebb30981627bd08f595211a648a62
      
https://github.com/qemu/qemu/commit/aefcaf9d1b3ebb30981627bd08f595211a648a62
  Author: Corey Minyard <address@hidden>
  Date:   2020-01-22 (Wed, 22 Jan 2020)

  Changed paths:
    M hw/i386/acpi-build.c
    M tests/data/acpi/q35/DSDT
    M tests/data/acpi/q35/DSDT.acpihmat
    M tests/data/acpi/q35/DSDT.bridge
    M tests/data/acpi/q35/DSDT.cphp
    M tests/data/acpi/q35/DSDT.dimmpxm
    M tests/data/acpi/q35/DSDT.ipmibt
    M tests/data/acpi/q35/DSDT.memhp
    M tests/data/acpi/q35/DSDT.mmio64
    M tests/data/acpi/q35/DSDT.numamem

  Log Message:
  -----------
  i386:acpi: Remove _HID from the SMBus ACPI entry

Per the ACPI spec (version 6.1, section 6.1.5 _HID) it is not required
on enumerated buses (like PCI in this case), _ADR is required (and is
already there).  And the _HID value is wrong.  Linux appears to ignore
the _HID entry, but Windows 10 detects it as 'Unknown Device' and there
is no driver available.  See https://bugs.launchpad.net/qemu/+bug/1856724

Signed-off-by: Corey Minyard <address@hidden>
Cc: Michael S. Tsirkin <address@hidden>
Cc: Igor Mammedov <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 8347505640238d3b80f9bb7510fdc1bb574bad19
      
https://github.com/qemu/qemu/commit/8347505640238d3b80f9bb7510fdc1bb574bad19
  Author: Michael S. Tsirkin <address@hidden>
  Date:   2020-01-23 (Thu, 23 Jan 2020)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: coding style fix

Drop a trailing whitespace. Make line shorter.

Fixes: 76525114736e8 ("vhost: Only align sections for vhost-user")
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 7cea426c1d2e12777a2e61d7970044981ff82aa8
      
https://github.com/qemu/qemu/commit/7cea426c1d2e12777a2e61d7970044981ff82aa8
  Author: Peter Maydell <address@hidden>
  Date:   2020-01-23 (Thu, 23 Jan 2020)

  Changed paths:
    M docs/specs/acpi_cpu_hotplug.txt
    M hw/9pfs/virtio-9p-device.c
    M hw/acpi/cpu.c
    M hw/acpi/trace-events
    M hw/i386/acpi-build.c
    M hw/i386/pc.c
    M hw/pci-host/q35.c
    M hw/scsi/virtio-scsi.c
    M hw/virtio/vhost-vsock.c
    M hw/virtio/vhost.c
    M include/hw/pci-host/q35.h
    M include/hw/virtio/vhost-vsock.h
    M tests/data/acpi/q35/DSDT
    M tests/data/acpi/q35/DSDT.acpihmat
    M tests/data/acpi/q35/DSDT.bridge
    M tests/data/acpi/q35/DSDT.cphp
    M tests/data/acpi/q35/DSDT.dimmpxm
    M tests/data/acpi/q35/DSDT.ipmibt
    M tests/data/acpi/q35/DSDT.memhp
    M tests/data/acpi/q35/DSDT.mmio64
    M tests/data/acpi/q35/DSDT.numamem
    M tests/qtest/bios-tables-test.c
    M tests/qtest/q35-test.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

virtio, pc: fixes, features

Bugfixes all over the place.
CPU hotplug with secureboot.

Signed-off-by: Michael S. Tsirkin <address@hidden>

# gpg: Signature made Thu 23 Jan 2020 07:08:32 GMT
# gpg:                using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Michael S. Tsirkin <address@hidden>" [full]
# gpg:                 aka "Michael S. Tsirkin <address@hidden>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  vhost: coding style fix
  i386:acpi: Remove _HID from the SMBus ACPI entry
  vhost: Only align sections for vhost-user
  vhost: Add names to section rounded warning
  vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks
  virtio-scsi: convert to new virtio_delete_queue
  virtio-scsi: delete vqs in unrealize to avoid memleaks
  virtio-9p-device: convert to new virtio_delete_queue
  virtio-9p-device: fix memleak in virtio_9p_device_unrealize
  bios-tables-test: document expected file update
  acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command
  acpi: cpuhp: spec: add typical usecases
  acpi: cpuhp: introduce 'Command data 2' field
  acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0
  acpi: cpuhp: spec: fix 'Command data' description
  acpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness
  tests: q35: MCH: add default SMBASE SMRAM lock test
  q35: implement 128K SMRAM at default SMBASE address

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/be9612e8cbb4...7cea426c1d2e



reply via email to

[Prev in Thread] Current Thread [Next in Thread]