Version: GnuPG v1
iQIcBAABAgAGBQJWsKRXAAoJENro4Ql1lpzl55YP/0sY2Nnw3S7F1JEJVai7Reil
VVumgnU6TjFZaLS3bFH7HwWUZgdwI8PkGq6XiMgvsA3O2Pso4XyorQHdWqRwrRpU
/OVHgEia8xCyDo9rw23paSMouWa/SnT9CFNKzyUg7F2e6gxVGMPp+po1cYwznxhf
Anz3DgNxf9czT8c+bP5iIoqDiLep9n5Y8/2GltKlfYqyHPTbVG/IzsqXaIa2HYCU
L3unArALVkcPt68XS72NzuU+uDeixfIwgpeFtb2Zrt7OjKLeJAps4PYYvd4wy11N
WSCPP3mfjLzX9sNIuktlmOulsJX3lO3SafJ+yD6LSraNxjyuk9jart5yQQVeUue0
zcwytwwmKdAC9Y/lfwG4H8+S7VgE0q1rmq9V/EHC5TaOWnIjs2UbjjYfGAQDoclo
d2pujO7AADQIvVcSPVAOX+S/aB62LB0qyUWRDs2YCfZPtMltOMSWhQP7a5Y+A7mw
LxJmly8l800R6I5wZaBntv+8/MqbjBjG/fdIXrud6LiKmLLdRidUR0cNkyK1smR5
GYwgD5ZsVpoJRErcCUWMMXGBqCyj0CVsASV2CpRUsZkNLfOjWnYoEaVm5UFnGzJG
rXAYRs2wGwctLkOINC7M/YuvuJyyRviBE7+E81+dFeV52J0r9jYHwMz+ZukZbJDX
AxN6BCDe1PZ/8b53NwdU
=stmx
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/elmarco/tags/ivshmem-pull-request' into staging
# gpg: Signature made Tue 02 Feb 2016 12:43:03 GMT using RSA key ID 75969CE5
# gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>"
# gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5
* remotes/elmarco/tags/ivshmem-pull-request:
char: remove qemu_chr_open_eventfd
ivshmem: use a single eventfd callback, get rid of CharDriver
ivshmem: generalize ivshmem_setup_interrupts
ivshmem-test: test both msi & irq cases
libqos: remove some leaks
ivshmem-test: leak fixes
ivshmem: remove redundant assignment, fix crash with msi=off
ivshmem: no need for opaque argument
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The gd_vc_handler() callback is using g_malloc0() to
allocate the CharDriverState struct. As a result the
logfd field is getting initialized to 0, instead of
-1 when no logfile is requested.
The result is that when running
$ qemu-system-i386 -nodefaults -chardev vc,id=mon0 -mon chardev=mon0
qemu duplicates all monitor output to stdout as well
as the GTK window.
Not using qemu_chr_alloc() was already a bug, but harmless
until this commit
commit d0d7708ba2
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Jan 11 12:44:41 2016 +0000
qemu-char: add logfile facility to all chardev backends
which exposed the problem as a behaviour regression
Reported-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Hervé Poussineau <hpoussin@reactos.org>
Message-id: 1453377386-10190-1-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The qcrypto_hash_digest_len method was accidentally inside
a CONFIG_GNUTLS_HASH block, even though it doesn't depend
on gnutls. Re-arrange it to be unconditionally defined.
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1453138432-8324-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Broken since d0d7708ba2, since the backend is NULL.
And now no longer needed by ivshmem.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Simplify the interrupt handling by having a single callback on irq&msi
cases. Remove usage of CharDriver, replace it with
qemu_set_fd_handler(). Use event_notifier_test_and_clear() to read the
eventfd.
Before this patch, ivshmem writes the first byte received to
s->intrstatus. But ivshmem_device_spec.txt says "The status register is
set to 1 when an interrupt occurs." Fortunately, the byte usually comes
from another ivshmem device, and those always write 1.
After this commit, follows the specification, set to 1 when an interrupt
occurs.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Call ivshmem_setup_interrupts() with or without MSI, always allocate
msi_vectors that is going to be used in all case in the following patch.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Recent commit 660c97ee introduced a regression in irq case, make
sure this code path is also tested.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Add a cleanup_vm() function to free QPCIDevice & QPCIBus when cleaning
up the IVState.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Fix crash when msi=false introduced in 660c97ee (msi_vectors is NULL in
this case)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Background on QEMU boot indices
-------------------------------
Normally, the "bootindex" property is configured for bootable devices
with:
DEVICE_instance_init()
device_add_bootindex_property(..., "bootindex", ...)
object_property_add(..., device_get_bootindex,
device_set_bootindex, ...)
and when the bootindex is set on the QEMU command line, with
-device DEVICE,...,bootindex=N
the setter that was configured above is invoked:
device_set_bootindex()
/* parse boot index */
visit_type_int32()
/* verify unicity */
check_boot_index()
/* store parsed boot index */
...
/* insert device path to boot order */
add_boot_device_path()
In the last step, add_boot_device_path() ensures that an OpenFirmware
device path will show up in the "bootorder" fw_cfg file, at a position
corresponding to the device's boot index. Thus guest firmware (SeaBIOS and
OVMF) can try to boot off the device with the right priority.
NVMe boot index
---------------
In QEMU commit 33739c7129,
nvma: ide: add bootindex to qom property
the following generic setters / getters:
- device_set_bootindex()
- device_get_bootindex()
were open-coded for NVMe, under the names
- nvme_set_bootindex()
- nvme_get_bootindex()
Plus nvme_instance_init() was added to configure the "bootindex" property
manually, designating the open-coded getter & setter, rather than calling
device_add_bootindex_property().
Crucially, nvme_set_bootindex() avoided the final add_boot_device_path()
call. This fact is spelled out in the message of commit 33739c7129, and
it was presumably the entire reason for all of the code duplication.
Now, Vladislav filed an RFE for OVMF
<https://github.com/tianocore/edk2/issues/48>; OVMF should boot off NVMe
devices. It is simple to build edk2's existent NvmExpressDxe driver into
OVMF, but the boot order matching logic in OVMF can only handle NVMe if
the "bootorder" fw_cfg file includes such devices.
Therefore this patch converts the NVMe device model to
device_set_bootindex() all the way.
Device paths
------------
device_set_bootindex() accepts an optional parameter called "suffix". When
present, it is expected to take the form of an OpenFirmware device path
node, and it gets appended as last node to the otherwise auto-generated
OFW path.
For NVMe, the auto-generated part is
/pci@i0cf8/pci8086,5845@6[,1]
^ ^ ^ ^
| | PCI slot and (present when nonzero)
| | function of the NVMe controller, both hex
| "driver name" component, built from PCI vendor & device IDs
PCI root at system bus port, PIO
to which here we append the suffix
/namespace@1,0
^ ^
| big endian (MSB at lowest address) numeric interpretation
| of the 64-bit IEEE Extended Unique Identifier, aka EUI-64,
| hex
32-bit NVMe namespace identifier, aka NSID, hex
resulting in the OFW device path
/pci@i0cf8/pci8086,5845@6[,1]/namespace@1,0
The reason for including the NSID and the EUI-64 is that an NVMe device
can in theory produce several different namespaces (distinguished by
NSID). Additionally, each of those may (optionally) have an EUI-64 value.
For now, QEMU only provides namespace 1.
Furthermore, QEMU doesn't even represent the EUI-64 as a standalone field;
it is embedded (and left unused) inside the "NvmeIdNs.res30" array, at the
last eight bytes. (Which is fine, since EUI-64 can be left zero-filled if
unsupported by the device.)
Based on the above, we set the "unit address" part of the last
("namespace") node to fixed "1,0".
OVMF will then map the above OFW device path to the following UEFI device
path fragment, for boot order processing:
PciRoot(0x0)/Pci(0x6,0x1)/NVMe(0x1,00-00-00-00-00-00-00-00)
^ ^ ^ ^ ^ ^
| | | | | octets of the EUI-64 in address order
| | | | NSID
| | | NVMe namespace messaging device path node
| PCI slot and function
PCI root bridge
Cc: Keith Busch <keith.busch@intel.com> (supporter:nvme)
Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core)
Cc: qemu-block@nongnu.org (open list:nvme)
Cc: Gonglei <arei.gonglei@huawei.com>
Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kevin O'Connor <kevin@koconnor.net>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gonglei <arei.gonglei@huawei.com>
Acked-by: Keith Busch <keith.busch@intel.com>
Tested-by: Vladislav Vovchenko <vladislav.vovchenko@sk.com>
Message-id: 1453850483-27511-1-git-send-email-lersek@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently accumulated patches for target-ppc, pseries machine type and
related devices.
* Cleanup of error handling code in spapr
* A number of fixes for Macintosh devices for the benefit of MacOS 9 and X
* Remove some abuses of the RTAS memory access functions in spapr
* Fixes for the gdbstub (and monitor debug) for VMX and VSX extensions.
* Fix pseries machine hotplug memory under TCG
* Clean up and extend handling of multiple page sizes with 64-bit hash MMUs
* Fix to the TCG implementation of mcrfs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWrsLSAAoJEGw4ysog2bOS8/AQAIFdKPrWUbtWi5Wrt8odLiIh
BDYi01pbWuU8BdzcTS3yBP8TIl8/FTo68Cpd42PmBtseT3M+jS7RdgKrdfzx9T+j
ebJSoIf08zoR1Y57rr8CYX7p23w1N5MqlOTrJ7JYExWoIHokO0AegB4EfTFO5tfE
gNK4Z5oZigVz3sZmm6juXRtpYxLWit8WOJxZ+CwVH26RfiI2pV922KYbed8t0oih
vv07crJgRUptiarjf9woU9HW7J2fzrOXIY6QfyjdVxc8SUBFfCjvRekMBFuU2bex
+QQOiI2u5QPNNO8fi5MXAlYF2uUEnG6tWKqpw2tWojPX8/xnscvFVEwDWrn0txl5
VTbvpKToicX+xLjSWiHIawwCbaFkw9jYc7B8/xuKCo8g/eMz6xMbjw1j7YCS+yGk
98cEwe+JNOgsk3QRttp3t7Vo76XL8HtA0AK7SkYCMfb6SlHHeghQq4zWWq76S5Bp
DYeA2wRjeBkKAnbSDYIKbVLuZj10QYJTl1Jr3At8YHqEm7Fdth5Dk5VqqR3KZQF+
OyU9+GT2WEAu8t1aYTNGKNFJVcEPZ5BfrkjLK1YJTQk56V+M1wRs51voVJkxlKMO
8JEYefxf1OCXwA1/DPKJgAtwCjtGzHrsW6UEhAvmuzHXx3bE1Zjy5SCeR3I6ib0F
xwPcSf+/eS5lFKtE3etg
=F5Nl
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into staging
ppc patch queue for 2016-02-01
Currently accumulated patches for target-ppc, pseries machine type and
related devices.
* Cleanup of error handling code in spapr
* A number of fixes for Macintosh devices for the benefit of MacOS 9 and X
* Remove some abuses of the RTAS memory access functions in spapr
* Fixes for the gdbstub (and monitor debug) for VMX and VSX extensions.
* Fix pseries machine hotplug memory under TCG
* Clean up and extend handling of multiple page sizes with 64-bit hash MMUs
* Fix to the TCG implementation of mcrfs
# gpg: Signature made Mon 01 Feb 2016 02:28:34 GMT using RSA key ID 20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-2.6-20160201: (40 commits)
target-ppc: mcrfs should always update FEX/VX and only clear exception bits
target-ppc: Make every FPSCR_ macro have a corresponding FP_ macro
target-ppc: Allow more page sizes for POWER7 & POWER8 in TCG
target-ppc: Helper to determine page size information from hpte alone
target-ppc: Add new TLB invalidate by HPTE call for hash64 MMUs
target-ppc: Split 44x tlbiva from ppc_tlb_invalidate_one()
target-ppc: Remove unused mmu models from ppc_tlb_invalidate_one
target-ppc: Use actual page size encodings from HPTE
target-ppc: Rework SLB page size lookup
target-ppc: Rework ppc_store_slb
target-ppc: Convert mmu-hash{32,64}.[ch] from CPUPPCState to PowerPCCPU
target-ppc: Remove unused kvmppc_read_segment_page_sizes() stub
uninorth.c: add support for UniNorth kMacRISCPCIAddressSelect (0x48) register
cuda.c: return error for unknown commands
pseries: Allow TCG h_enter to work with hotplugged memory
target-ppc: gdbstub: Add VSX support
target-ppc: gdbstub: fix spe registers for little-endian guests
target-ppc: gdbstub: fix altivec registers for little-endian guests
target-ppc: gdbstub: introduce avr_need_swap()
target-ppc: gdbstub: fix float registers for little-endian guests
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This converts the tlscredsx509, tlscredsanon and secret objects
to register their properties against the class rather than object.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Here is the description of the mcrfs instruction from the PowerPC Architecture
Book, Version 2.02, Book I: PowerPC User Instruction Set Architecture
(http://www.ibm.com/developerworks/systems/library/es-archguide-v2.html), found
on page 120:
The contents of FPSCR field BFA are copied to Condition Register field BF.
All exception bits copied are set to 0 in the FPSCR. If the FX bit is
copied, it is set to 0 in the FPSCR.
Special Registers Altered:
CR field BF
FX OX (if BFA=0)
UX ZX XX VXSNAN (if BFA=1)
VXISI VXIDI VXZDZ VXIMZ (if BFA=2)
VXVC (if BFA=3)
VXSOFT VXSQRT VXCVI (if BFA=5)
However, currently every bit in FPSCR field BFA is set to 0, including ones not
on that list.
This can be seen in the following simple C program:
#include <fenv.h>
#include <stdio.h>
int main(int argc, char **argv) {
int ret;
ret = fegetround();
printf("Current rounding: %d\n", ret);
ret = fesetround(FE_UPWARD);
printf("Setting to FE_UPWARD (%d): %d\n", FE_UPWARD, ret);
ret = fegetround();
printf("Current rounding: %d\n", ret);
ret = fegetround();
printf("Current rounding: %d\n", ret);
return 0;
}
which gave the output (before this commit):
Current rounding: 0
Setting to FE_UPWARD (2): 0
Current rounding: 2
Current rounding: 0
instead of (after this commit):
Current rounding: 0
Setting to FE_UPWARD (2): 0
Current rounding: 2
Current rounding: 2
The relevant disassembly is in fegetround(), which, on my system, is:
__GI___fegetround:
<+0>: mcrfs cr7, cr7
<+4>: mfcr r3
<+8>: clrldi r3, r3, 62
<+12>: blr
What happens is that, the first time fegetround() is called, FPSCR field 7 is
retrieved. However, because of the bug in mcrfs, the entirety of field 7 is set
to 0, which includes the rounding mode.
There are other issues this will fix, such as condition flags not persisting
when they should if read, and if you were to read a specific field with some
exception bits set, but no others were set in the entire register, then the
bits would be cleared correctly, but FEX/VX would not be updated to 0 as they
should be.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that the TCG and spapr code has been extended to allow (semi-)
arbitrary page encodings in the CPU's 'sps' table, we can add the many
page sizes supported by real POWER7 and POWER8 hardware that we previously
didn't support in TCG.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
h_enter() in the spapr code needs to know the page size of the HPTE it's
about to insert. Unlike other paths that do this, it doesn't have access
to the SLB, so at the moment it determines this with some open-coded
tests which assume POWER7 or POWER8 page size encodings.
To make this more flexible add ppc_hash64_hpte_page_shift_noslb() to
determine both the "base" page size per segment, and the individual
effective page size from an HPTE alone.
This means that the spapr code should now be able to handle any page size
listed in the env->sps table.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
When HPTEs are removed or modified by hypercalls on spapr, we need to
invalidate the relevant pages in the qemu TLB.
Currently we do that by doing some complicated calculations to work out the
right encoding for the tlbie instruction, then passing that to
ppc_tlb_invalidate_one()... which totally ignores the argument and flushes
the whole tlb.
Avoid that by adding a new flush-by-hpte helper in mmu-hash64.c.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Currently both the tlbiva instruction (used on 44x chips) and the tlbie
instruction (used on hash MMU chips) are both handled via
ppc_tlb_invalidate_one(). This is silly, because they're invoked from
different places, and do different things.
Clean this up by separating out the tlbiva instruction into its own
handling. In fact the implementation is only a stub anyway.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
ppc_tlb_invalidate_one() has a big switch handling many different MMU
types. However, most of those branches can never be reached:
It is called from 3 places: from remove_hpte() and h_protect() in
spapr_hcall.c (which always has a 64-bit hash MMU type), and from
helper_tlbie() in mmu_helper.c.
Calls to helper_tlbie() are generated from gen_tlbiel, gen_tlbiel and
gen_tlbiva. The first two are only used with the PPC_MEM_TLBIE flag,
set only with 32-bit or 64-bit hash MMU models, and gen_tlbiva() is
used only on 440 and 460 models with the BookE mmu model.
These means the exhaustive list of MMU types which may call
ppc_tlb_invalidate_one() is: POWERPC_MMU_SOFT_6xx, POWERPC_MMU_601,
POWERPC_MMU_32B, POWERPC_MMU_SOFT_74xx, POWERPC_MMU_64B, POWERPC_MMU_2_03,
POWERPC_MMU_2_06, POWERPC_MMU_2_07 and POWERPC_MMU_BOOKE.
Clean up by removing logic for all other MMU types from
ppc_tlb_invalidate_one().
This means that ppc4xx_tlb_invalidate_virt() now has no callers, or rather,
makes it obvious that it has no callers. So, we remove that function as
well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present the 64-bit hash MMU code uses information from the SLB to
determine the page size of a translation. We do need that information to
correctly look up the hash table. However the MMU also allows a
possibly larger page size to be encoded into the HPTE itself, which is used
to populate the TLB. At present qemu doesn't check that, and so doesn't
support the MPSS "Multiple Page Size per Segment" feature.
This makes a start on allowing this, by adding an hpte_page_shift()
function which looks up the page size of an HPTE. We use this to validate
page sizes encodings on faults, and populate the qemu TLB with larger
page sizes when appropriate.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Currently, the ppc_hash64_page_shift() function looks up a page size based
on information in an SLB entry. It open codes the bit translation for
existing CPUs, however different CPU models can have different SLB
encodings. We already store those in the 'sps' table in CPUPPCState, but
we don't currently enforce that that actually matches the logic in
ppc_hash64_page_shift.
This patch reworks lookup of page size from SLB in several ways:
* ppc_store_slb() will now fail (triggering an illegal instruction
exception) if given a bad SLB page size encoding
* On success ppc_store_slb() stores a pointer to the relevant entry in
the page size table in the SLB entry. This is looked up directly from
the published table of page size encodings, so can't get out ot sync.
* ppc_hash64_htab_lookup() and others now use this precached page size
information rather than decoding the SLB values
* Now that callers have easy access to the page_shift,
ppc_hash64_pte_raddr() amounts to just a deposit64(), so remove it and
have the callers use deposit64() directly.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
ppc_store_slb updates the SLB for PPC cpus with 64-bit hash MMUs.
Currently it takes two parameters, which contain values encoded as the
register arguments to the slbmte instruction, one register contains the
ESID portion of the SLBE and also the slot number, the other contains the
VSID portion of the SLBE.
We're shortly going to want to do some SLB updates from other code where
it is more convenient to supply the slot number and ESID separately, so
rework this function and its callers to work this way.
As a bonus, this slightly simplifies the emulation of segment registers for
when running a 32-bit OS on a 64-bit CPU.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Like a lot of places these files include a mixture of functions taking
both the older CPUPPCState *env and newer PowerPCCPU *cpu. Move a step
closer to cleaning this up by standardizing on PowerPCCPU, except for the
helper_* functions which are called with the CPUPPCState * from tcg.
Callers and some related functions are updated as well, the boundaries of
what's changed here are a bit arbitrary.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
This stub function is in the !KVM ifdef in target-ppc/kvm_ppc.h. However
no such function exists on the KVM side, or is ever used.
I think this originally referenced a function which read host page size
information from /proc, for we we now use the KVM GET_SMMU_INFO extension
instead.
In any case, it has no function now, so remove it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Darwin/OS X use the undocumented kMacRISCPCIAddressSelect (0x48) to
configure PCI memory space size for mac99 machines. Without this
register, warnings similar to below are emitted to the console during boot:
AppleMacRiscPCI: bad range 2(80000000:01000000)
AppleMacRiscPCI: bad range 2(81000000:00001000)
AppleMacRiscPCI: bad range 2(81080000:00080000)
Based upon the algorithm in Darwin's AppleMacRiscPCI.cpp driver, set the
kMacRISCPCIAddressSelect register so that Darwin considers the PCI
memory space to be at 0x80000000 (size 0x10000000) which matches that
currently used by QEMU and OpenBIOS.
Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
[commit message and comment revised as suggested by Mark Cave-Ayland]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This avoids MacsBug hanging at startup in the absence of ADB mouse
input, by replying with an error (which is also what MOL does) when
it sends an unknown command (0x1c).
Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The implementation of the H_ENTER hypercall for PAPR guests needs to
enforce correct access attributes on the inserted HPTE. This means
determining if the HPTE's real address is a regular RAM address (which
requires attributes for coherent access) or an IO address (which requires
attributes for cache-inhibited access).
At the moment this check is implemented with (raddr < machine->ram_size),
but that only handles addresses in the base RAM area, not any hotplugged
RAM.
This patch corrects the problem with a new helper.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Add the XML and functions to get and set VSX registers.
Signed-off-by: Anton Blanchard <anton@samba.org>
(fixed little-endian guests)
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Let's reuse the ppc_maybe_bswap_register() helper, like we already do
with the general registers.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Altivec registers are 128-bit wide. They are stored in memory as two
64-bit values that must be byteswapped when the guest is little-endian.
Let's reuse the ppc_maybe_bswap_register() helper for this.
We also need to fix the ordering of the 64-bit elements according to
the target endianness, for both system and user mode.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This helper will be used to support Altivec registers in little-endian guests.
This patch does not change functionnality.
Note: I had to put the helper some lines away from the gdb_*_avr_reg()
routines to get a more readable patch.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Let's reuse the ppc_maybe_bswap_register() helper, like we already do
with the general registers.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This helper will be used to support FP, Altivec and VSX registers when
the guest is little-endian.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
On VSX capable CPUs, the 32 FP registers are mapped to the high-bits
of the 32 first VSX registers. So if you have:
VSR31 = (uint128) 0x0102030405060708090a0b0c0d0e0f00
then
FPR31 = (uint64) 0x0102030405060708
The kernel stores the VSX registers in the fp_state struct following the
host endian element ordering.
On big-endian:
fp_state.fpr[31][0] = 0x0102030405060708
fp_state.fpr[31][1] = 0x090a0b0c0d0e0f00
On little-endian:
fp_state.fpr[31][0] = 0x090a0b0c0d0e0f00
fp_state.fpr[31][1] = 0x0102030405060708
The KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls preserve this ordering, but
QEMU considers it as big-endian and always copies element [0] to the
fpr[] array and element [1] to the vsr[] array. This does not work with
little-endian hosts, and you will get:
(qemu) p $f31
0x90a0b0c0d0e0f00
instead of:
(qemu) p $f31
0x102030405060708
This patch fixes the element ordering for little-endian hosts.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The functions for migrating the hash page table on pseries machine type
(htab_save_setup() and htab_load()) can report some errors with an
explicit fprintf() before returning an appropriate error code. Change some
of these to use error_report() instead. htab_save_setup() is omitted for
now to avoid conflicts with some other in-progress work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
This function includes a number of explicit fprintf()s for errors.
Change these to use error_report() instead.
Also replace the single exit(EXIT_FAILURE) with an explicit exit(1), since
the latter is the more usual idiom in qemu by a large margin.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Use the error handling infrastructure to pass an error out from
try_create_xics() instead of assuming &error_abort - the caller is in a
better position to decide on error handling policy.
Also change the error handling from an &error_abort to &error_fatal, since
this occurs during the initial machine construction and could be triggered
by bad configuration rather than a program error.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
The errors detected in this function necessarily indicate bugs in the rest
of the qemu code, rather than an external or configuration problem.
So, a simple assert() is more appropriate than any more complex error
reporting.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Use error_setg() to return an error rather than an explicit exit().
Previously it was an exit(0) instead of a non-zero exit code, which was
simply a bug. Also improve the error message.
While we're at it change the type of spapr_vga_init() to bool since that's
how we're using it anyway.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Use error_setg() and return an error, rather than using an explicit exit().
Also improve messages, and be more explicit about which constraint failed.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Currently spapr_cpu_init() is hardcoded to handle any errors as fatal.
That works for now, since it's only called from initial setup where an
error here means we really can't proceed.
However, we'll want to handle this more flexibly for cpu hotplug in future
so generalize this using the error reporting infrastructure. While we're
at it make a small cleanup in a related part of ppc_spapr_init() to use
error_report() instead of an old-style explicit fprintf().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
