This removes @next_irq from sPAPREnvironment which was used in old
IRQ allocator as XICS is now responsible for IRQs and keeps track of
allocated IRQs.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The current allocator returns IRQ numbers from a pool and does not
support IRQs reuse in any form as it did not keep track of what it
previously returned, it only keeps the last returned IRQ. Some use
cases such as PCI hot(un)plug may require IRQ release and reallocation.

This moves an allocator from SPAPR to XICS.

This switches IRQ users to use new API.

This uses LSI/MSI flags to know if interrupt is allocated.

The interrupt release function will be posted as a separate patch.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Since islsi[] array has been merged into the ICSState struct,
we must not reset flags as they tell if the interrupt is in use.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

PAPR allows having multiple interrupt sources such as PHB.

This adds a source lookup function and makes use of it.

Since at the moment QEMU only supports a single source,
no change in behaviour is expected.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The existing interrupt allocation scheme in SPAPR assumes that
interrupts are allocated at the start time, continously and the config
will not change. However, there are cases when this is not going to work
such as:

1. migration - we will have to have an ability to choose interrupt
numbers for devices in the command line and this will create gaps in
interrupt space.

2. PCI hotplug - interrupts from unplugged device need to be returned
back to interrupt pool, otherwise we will quickly run out of interrupts.

This replaces a separate lslsi[] array with a byte in the ICSIRQState
struct and defines "LSI" and "MSI" flags. Neither of these flags set
signals that the descriptor is not allocated and not in use.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add support for the SPLPAR Characteristics parameter to the emulated
RTAS call ibm,get-system-parameter.

The support provides just enough information to allow "cat
/proc/powerpc/lparcfg" to succeed without generating a kernel error
message.

Without this patch the above command will produce the following kernel
message: arch/powerpc/platforms/pseries/lparcfg.c \
parse_system_parameter_string Error calling get-system-parameter \
(0xfffffffd)
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add support for the UUID parameter to the emulated RTAS call
ibm,get-system-parameter.

Return the guest's UUID as the value for the RTAS UUID system
parameter, or null (a zero length result) if it is not set.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This allows the ibm,get-system-parameter RTAS call to succeed for the
DIAGNOSTICS_RUN_MODE system parameter.

The problem can be seen with "ppc64_cpu --run-mode" from the
powerpc-utils package which fails before this patch with "Machine does
not support diagnostic run mode".

This is corrected by using the rtas_st_buffer() function to write to
the buffer.

The RTAS constants are also moved out into a header file, some new
constants added and the surrounding code slightly simplified.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
[agraf: remove some commentary]
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add a function to write lengh + data into a buffer as required for the
emulation of the RTAS ibm,get-system-parameter call.

If the destination is smaller than the source, the write is truncated
and success is returned. This matches the behaviour of pHyp.

This will be used in following patches.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This adds a v2.1 machine to support backward compatibility
for newer macines in the case if they ever be implemented.

This adds a "pseries-2.1" machine as a child of the "pseries"
machine and only changes visible machine name.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Every single sPAPR QOM object has small first "s".
Most (not all yet) QOM objects have "State" suffix.

This replaces SPAPRMachine with sPAPRMachineState to conform with QEMU
code style and removes redundant empty line.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

At the moment QEMU knows about one version of POWER8 CPU with
PVR 0x4B.0000. This CPU class is defined as "POWER8". The linux
kernel names it as "POWER8E" which is different from the name QEMU uses.

Now we get another version of POWER8 which is architecturally equivalent
to POWER8E but has different PVR 0x4D.0000 so QEMU fails to find
a PPC CPU class on these machines. The linux kernel names these CPUs as
"POWER8".

This renames the existing "POWER8" to "POWER8E" to be more precise and
stay in sync with the linux kernel.

This adds a new "POWER8" family which calls POWER8E class init function
and defines own PVR mask (used to match a CPU class) and desc (used to
create dynamic version-less CPU class).

This does not change CPU class fw_name attribute as the host POWER8
firmware keeps using "PowerPC,POWER8" on both POWER8 and POWER8E.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Fix PCI hole size to match that what is found on real hardware.
(OpenBIOS already uses the correct length.)
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Change the order of creating devices for New World Mac emulation so
that devices on the motherboard are added first and PCI cards (VGA and
NIC) come later. As a side effect, this also causes OpenBIOS to map
the motherboard devices into the MMIO space to the same addresses as
on real hardware and allow clients that hardcode these addresses (e.g.
MorphOS) to find and use them until OpenBIOS is tought to map devices
to specific addresses. (On real hardware the graphics and network
cards are really on separate buses but we don't model that yet.) This
brings the memory map closer to what is found on PowerMac3,1.
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The gen_qemu_ld8s() function is unused; remove it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Remove the definition of the IMM and d extract helpers; these seem to have
been added as part of the initial PPC support in 2003 but never actually
used.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This turns the sPAPR support on and enables VFIO container use
in the kernel.

This extends vfio_connect_container to support VFIO_SPAPR_TCE_IOMMU type
in the host kernel.

This registers a memory listener which sPAPR IOMMU will notify when
executing H_PUT_TCE/etc DMA calls. The listener then will notify the host
kernel about DMA map/unmap operation via VFIO_IOMMU_MAP_DMA/
VFIO_IOMMU_UNMAP_DMA ioctls.

This executes VFIO_IOMMU_ENABLE ioctl to make sure that the IOMMU is free
of mappings and can be exclusively given to the user. At the moment SPAPR
is the only platform requiring this call to be implemented.

Note that the host kernel function implementing VFIO_IOMMU_DISABLE
is called automatically when container's fd is closed so there is
no need to call it explicitly from QEMU. We may need to call
VFIO_IOMMU_DISABLE explicitly in the future for some sort of dynamic
reconfiguration (PCI hotplug or dynamic IOMMU group management).
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The patch adds a spapr-pci-vfio-host-bridge device type
which is a PCI Host Bridge with VFIO support. The new device
inherits from the spapr-pci-host-bridge device and adds an "iommu"
property which is an IOMMU id. This ID represents a minimal entity
for which IOMMU isolation can be guaranteed. In SPAPR architecture IOMMU
group is called a Partitionable Endpoint (PE).

Current implementation supports one IOMMU id per QEMU VFIO PHB. Since
SPAPR allows multiple PHB for no extra cost, this does not seem to
be a problem. This limitation may change in the future though.

Example of use:
Configure and Add 3 functions of a multifunctional device to QEMU:
(the NEC PCI USB card is used as an example here):
-device spapr-pci-vfio-host-bridge,id=USB,iommu=4,index=7 \
-device vfio-pci,host=4:0:1.0,addr=1.0,bus=USB,multifunction=true
-device vfio-pci,host=4:0:1.1,addr=1.1,bus=USB
-device vfio-pci,host=4:0:1.2,addr=1.2,bus=USB

where:
* index=7 is a QEMU PHB index (used as source for MMIO/MSI/IO windows
offset);
* iommu=4 is an IOMMU id which can be found in sysfs:
[aik@vpl2 ~]$ cd /sys/bus/pci/devices/0004:00:00.0/
[aik@vpl2 0004:00:00.0]$ ls -l iommu_group
lrwxrwxrwx 1 root root 0 Jun  5 12:49 iommu_group -> ../../../kernel/iommu_groups/4
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

While most operations with VFIO IOMMU driver are generic and used inside
vfio.c, there are still some operations which only specific VFIO IOMMU
drivers implement. The first example of it will be reading a DMA window
start from the host.

This adds a helper which passes an ioctl request to the container's fd.

The helper will check if @req is known. For this, stub is added. This return
-1 on any requests for now.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

POWER KVM supports an KVM_CAP_SPAPR_TCE capability which allows allocating
TCE tables in the host kernel memory and handle H_PUT_TCE requests
targeted to specific LIOBN (logical bus number) right in the host without
switching to QEMU. At the moment this is used for emulated devices only
and the handler only puts TCE to the table. If the in-kernel H_PUT_TCE
handler finds a LIOBN and corresponding table, it will put a TCE to
the table and complete hypercall execution. The user space will not be
notified.

Upcoming VFIO support is going to use the same sPAPRTCETable device class
so KVM_CAP_SPAPR_TCE is going to be used as well. That means that TCE
tables for VFIO are going to be allocated in the host as well.
However VFIO operates with real IOMMU tables and simple copying of
a TCE to the real hardware TCE table will not work as guest physical
to host physical address translation is requited.

So until the host kernel gets VFIO support for H_PUT_TCE, we better not
to register VFIO's TCE in the host.

This adds a place holder for KVM_CAP_SPAPR_TCE_VFIO capability. It is not
in upstream yet and being discussed so now it is always false which means
that in-kernel VFIO acceleration is not supported.

This adds a bool @vfio_accel flag to the sPAPRTCETable device telling
that sPAPRTCETable should not try allocating TCE table in the host kernel
for VFIO. The flag is false now as at the moment there is no VFIO.

This adds an vfio_accel parameter to spapr_tce_new_table(), the semantic
is the same. Since there is only emulated PCI and VIO now, the flag is set
to false. Upcoming VFIO support will set it to true.

This is a preparation patch so no change in behaviour is expected
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

At the moment spapr_rtas_register() allocates a new token number for every
new RTAS callback so numbers are not fixed and depend on the number of
supported RTAS handlers and the exact order of spapr_rtas_register() calls.
These tokens are copied into the device tree and remain the same during
the guest lifetime.

When we start another guest to receive a migration, it calls
spapr_rtas_register() as well. If the number of RTAS handlers or their
order is different in QEMU on source and destination sides, the "/rtas"
node in the device tree will differ. Since migration overwrites the device
tree (as it overwrites the entire RAM), the actual RTAS config on
the destination side gets broken.

This defines global contant values for every RTAS token which QEMU
is using today.

This changes spapr_rtas_register() to accept a token number instead of
allocating one. This changes all users of spapr_rtas_register().

This changes XICS-KVM not to cache tokens registered with KVM as they
constant now.

This makes TOKEN_BASE global as RTAS_XXX use TOKEN_BASE as
a base. TOKEN_MAX is moved and renamed too and its value is changed
to the last token + 1. Boundary checks for token values are adjusted.

This reserves token numbers for "os-term" handlers and PCI hotplug
which we are working on.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The Apple gdbstub protocol is different from the normal gdbstub protocol
used on PowerPC. Add support for the different variant, so that we can use
Apple's gdb to debug guest code.

Keep in mind that the switch is a compile time option. We can't detect
during runtime whether a gdb connecting to us is an upstream gdb or an
Apple gdb.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Fixed bug in gen_mcrxr() in target-ppc/translate.c:
The XER[SO], XER[OV], and XER[CA] flags are stored in the least
significant bit (bit 0) of their respective registers. They need
to be shifted left (by their respective offsets) to generate the final
XER value. The old translation code for the 'mcrxr' instruction
was assuming that  the flags are stored in bit 2, and was shifting them
right (incorrectly)
Signed-off-by: NSorav Bansal <sbansal@cse.iitd.ernet.in>
Reviewed-by: NTom Musta <tommusta@gmail.com>
Tested-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This is required to enable boot menu display during booting
Signed-off-by: NAvik Sil <aviksil@linux.vnet.ibm.com>
Signed-off-by: NNikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Set bits in the AT_HWCAP2 entry of the AUXV.  Specifically, detect and set bits
for bctar, ISEL and ISA 2.07.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add VSX, DFP and ISA 2.06 to the bits identified in the AT_HWCAP
entry of the AUXV.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Decimal Floating Point is emulated, so add it the mask.  This will
fix the erroneous message:

  Warning: Disabling some instructions which are not emulated by TCG (0x0, 0x4)
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Set the AT_ICACHEBSIZE and AT_DCACHEBSIZE entries of the AUXV to match the
CPU model's cache line sizes.  This fixes memory clobbering problems on more
recent Book 3s implementations; memset(p, 0, N) will use the dcbz instruction
when N is sufficiently large and many of the newer server CPUs have cache lines
sizes of 128 bytes.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

A gcc codegen bug in x86_64-w64-mingw32-gcc (GCC) 4.6.3 means that
non-debug builds of QEMU for Windows tend to assert when using
coroutines. Work around this by marking qemu_coroutine_switch
as noinline.

If we allow gcc to inline qemu_coroutine_switch into
coroutine_trampoline, then it hoists the code to get the
address of the TLS variable "current" out of the while() loop.
This is an invalid transformation because the SwitchToFiber()
call may be called when running thread A but return in thread B,
and so we might be in a different thread context each time
round the loop. This can happen quite often.  Typically.
a coroutine is started when a VCPU thread does bdrv_aio_readv:

     VCPU thread

     main VCPU thread coroutine      I/O coroutine
        bdrv_aio_readv ----->
                                     start I/O operation
                                       thread_pool_submit_co
                       <------------ yields
        back to emulation

Then I/O finishes and the thread-pool.c event notifier triggers in
the I/O thread.  event_notifier_ready calls thread_pool_co_cb, and
the I/O coroutine now restarts *in another thread*:

     iothread

     main iothread coroutine         I/O coroutine (formerly in VCPU thread)
        event_notifier_ready
          thread_pool_co_cb ----->   current = I/O coroutine;
                                     call AIO callback

But on Win32, because of the bug, the "current" being set here the
current coroutine of the VCPU thread, not the iothread.

noinline is a good-enough workaround, and quite unlikely to break in
the future.

(Thanks to Paolo Bonzini for assistance in diagnosing the problem
and providing the detailed example/ascii art quoted above.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1403535303-14939-1-git-send-email-peter.maydell@linaro.org
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

X86CPU

* Filter out MONITOR for KVM
* Fix filtering for TCG
* -cpu foo,check and -cpu foo,enforce support for TCG
* -cpu host migration support (-cpu host,migratable=no to disable)
* Add invtsc feature support
* New model: Broadwell

# gpg: Signature made Wed 25 Jun 2014 22:55:04 BST using RSA key ID 3E7E013F
# gpg: Good signature from "Andreas Färber <afaerber@suse.de>"
# gpg:                 aka "Andreas Färber <afaerber@suse.com>"

* remotes/afaerber/tags/qom-cpu-for-2.1:
  target-i386: Broadwell CPU model
  target-i386: Fix indentation of CPU model definitions
  target-i386: Support "invariant tsc" flag
  target-i386: block migration and savevm if invariant tsc is exposed
  savevm: check vmsd for migratability status
  target-i386: Set migratable=yes by default on "host" CPU mooel
  target-i386: Add "migratable" property to "host" CPU model
  target-i386: Support check/enforce flags in TCG mode, too
  target-i386: Loop-based feature word filtering in TCG mode
  target-i386: Loop-based copying and setting/unsetting of feature words
  target-i386: Define TCG_*_FEATURES earlier in cpu.c
  target-i386: Filter KVM and 0xC0000001 features on TCG
  target-i386: Filter FEAT_7_0_EBX TCG features too
  target-i386: Make TCG feature filtering more readable
  target-i386: Isolate KVM-specific code on CPU feature filtering logic
  target-i386: Pass FeatureWord argument to report_unavailable_features()
  target-i386: Merge feature filtering/checking functions
  target-i386: Simplify reporting of unavailable features
  target-i386: kvm: Don't enable MONITOR by default on any CPU model
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Otherwise, Windows fails with a deadlock.
Reported-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1403679897-11480-1-git-send-email-pbonzini@redhat.com
Tested-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Message-id: 1403683241-20678-1-git-send-email-imammedo@redhat.com
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This adds a new CPU model named "Broadwell". It has all the features
from Haswell, plus PREFETCHW, RDSEED, ADX, SMAP.

PREFETCHW was already supported as "3dnowprefetch".

RDSEED, ADX was added on Linux v3.15-rc1.

SMAP was added on Linux v3.15-rc2.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Cc: Wang, Yong Y <yong.y.wang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Dugger, Donald D <donald.d.dugger@intel.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Expose "Invariant TSC" flag, if KVM is enabled. From Intel documentation:

17.13.1 Invariant TSC The time stamp counter in newer processors may
support an enhancement, referred to as invariant TSC. Processor’s
support for invariant TSC is indicated by CPUID.80000007H:EDX[8].
The invariant TSC will run at a constant rate in all ACPI P-, C-.
and T-states. This is the architectural behavior moving forward. On
processors with invariant TSC support, the OS may use the TSC for wall
clock timer services (instead of ACPI or HPET timers). TSC reads are
much more efficient and do not incur the overhead associated with a ring
transition or access to a platform resource.
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
[ehabkost: redo feature filtering to use .tcg_features]
[ehabkost: add CPUID_APM_INVTSC macro, add it to .unmigratable_flags]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Invariant TSC documentation mentions that "invariant TSC will run at a
constant rate in all ACPI P-, C-. and T-states".

This is not the case if migration to a host with different TSC frequency
is allowed, or if savevm is performed. So block migration/savevm.
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
[AF+mtosatti: Updated error message]
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Check vmsd for unmigratable field, allowing migratibility status
to be modified after vmstate_register.

Cc: Juan Quintela <quintela@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Having only migratable flags reported by default on the "host" CPU model
is safer for the following reasons:

 * Existing users may expect "-cpu host" to be migration-safe, if they
   take care of always using compatible host CPUs, host kernels, and
   QEMU versions.
 * Users who don't care aboug migration and want to enable all features
   supported by the host kernel can simply change their setup to use
   migratable=no.

Without this change, people using "-cpu host" will stop being able to
migrate, because now "invtsc" is getting enabled by default.

We are not setting migratable=yes by default on all X86CPU subclasses,
because users should be able to get non-migratable features enabled if
they ask for them explicitly.
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This flag will allow the user to choose between two modes:
 * All flags that can be enabled on the host, even if unmigratable
   (migratable=no);
 * All flags that can be enabled on the host, are known to QEMU
   and migratable (migratable=yes).

The default is still migratable=false, to keep current behavior, but
this will be changed to migratable=true by another patch.

My plan was to support the "migratable" flag on all CPU classes, but
have the default to "false" on all CPU models except "host". However,
DeviceClass has no mechanism to allow a child class to have a different
property default from the parent class yet, so by now only the "host"
CPU model will support the "migratable" flag.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

If enforce/check is specified in TCG mode, QEMU will ensure all CPU
features are supported by TCG, so no CPU feature is silently disabled.
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
[AF: Be explicit about TCG vs. !KVM]
Signed-off-by: NAndreas Färber <afaerber@suse.de>