We seem to only use these functions when de-activating the
MSI - so just log errors.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To help with troubleshooting in the field.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
We do not want to have two entries to cache the guest configuration
registers: XenPTReg->data and dev.config. Instead we want to use
only the dev.config.
To do without much complications we rip out the ->data field
and replace it with an pointer to the dev.config. This way we
have the type-checking (uint8_t, uint16_t, etc) and as well
and pre-computed location.
Alternatively we could compute the offset in dev.config by
using the XenPTRRegInfo and XenPTRegGroup every time but
this way we have the pre-computed values.
This change also exposes some mis-use:
- In 'xen_pt_status_reg_init' we used u32 for the Capabilities Pointer
register, but said register is an an u16.
- In 'xen_pt_msgdata_reg_write' we used u32 but should have only use u16.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
It should never happen, but in case it does (an developer adds
a new register and the 'init_val' expands past the register
size) we want to report. The code will only write up to
reg->size so there is no runtime danger of the register spilling
across other ones - however to catch this sort of thing
we still return an error.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
For a passthrough device we maintain a state of emulated
registers value contained within d->config. We also consult
the host registers (and apply ro and write masks) whenever
the guest access the registers. This is done in xen_pt_pci_write_config
and xen_pt_pci_read_config.
Also in this picture we call pci_default_write_config which
updates the d->config and if the d->config[PCI_COMMAND] register
has PCI_COMMAND_MEMORY (or PCI_COMMAND_IO) acts on those changes.
On startup the d->config[PCI_COMMAND] are the host values, not
what the guest initial values should be, which is exactly what
we do _not_ want to do for 64-bit BARs when the guest just wants
to read the size of the BAR. Huh you say?
To get the size of 64-bit memory space BARs, the guest has
to calculate ((BAR[x] & 0xFFFFFFF0) + ((BAR[x+1] & 0xFFFFFFFF) << 32))
which means it has to do two writes of ~0 to BARx and BARx+1.
prior to this patch and with XSA120-addendum patch (Linux kernel)
the PCI_COMMAND register is copied from the host it can have
PCI_COMMAND_MEMORY bit set which means that QEMU will try to
update the hypervisor's P2M with BARx+1 value to ~0 (0xffffffff)
(to sync the guest state to host) instead of just having
xen_pt_pci_write_config and xen_pt_bar_reg_write apply the
proper masks and return the size to the guest.
To thwart this, this patch syncs up the host values with the
guest values taking into account the emu_mask (bit set means
we emulate, PCI_COMMAND_MEMORY and PCI_COMMAND_IO are set).
That is we copy the host values - masking out any bits which
we will emulate. Then merge it with the initial emulation register
values. Lastly this value is then copied both in
dev.config _and_ XenPTReg->data field.
There is also reg->size accounting taken into consideration
that ends up being used in patch.
xen/pt: Check if reg->init function sets the 'data' past the reg->size
This fixes errors such as these:
(XEN) memory_map:add: dom2 gfn=fffe0 mfn=fbce0 nr=20
(DEBUG) 189 pci dev 04:0 BAR16 wrote ~0.
(DEBUG) 200 pci dev 04:0 BAR16 read 0x0fffe0004.
(XEN) memory_map:remove: dom2 gfn=fffe0 mfn=fbce0 nr=20
(DEBUG) 204 pci dev 04:0 BAR16 wrote 0x0fffe0004.
(DEBUG) 217 pci dev 04:0 BAR16 read upper 0x000000000.
(XEN) memory_map:add: dom2 gfn=ffffffff00000 mfn=fbce0 nr=20
(XEN) p2m.c:883:d0v0 p2m_set_entry failed! mfn=ffffffffffffffff rc:-22
(XEN) memory_map:fail: dom2 gfn=ffffffff00000 mfn=fbce0 nr=20 ret:-22
(XEN) memory_map:remove: dom2 gfn=ffffffff00000 mfn=fbce0 nr=20
(XEN) p2m.c:920:d0v0 gfn_to_mfn failed! gfn=ffffffff00000 type:4
(XEN) p2m.c:920:d0v0 gfn_to_mfn failed! gfn=ffffffff00001 type:4
..
(XEN) memory_map: error -22 removing dom2 access to [fbce0,fbcff]
(DEBUG) 222 pci dev 04:0 BAR16 read upper 0x0ffffffff.
(XEN) memory_map:remove: dom2 gfn=ffffffff00000 mfn=fbce0 nr=20
(XEN) memory_map: error -22 removing dom2 access to [fbce0,fbcff]
[The DEBUG is to illustate what the hvmloader was doing]
Also we swap from xen_host_pci_long to using xen_host_pci_get_[byte,word,long].
Otherwise we get:
xen_pt_config_reg_init: Offset 0x0004 mismatch! Emulated=0x0000, host=0x2300017, syncing to 0x2300014.
xen_pt_config_reg_init: Error: Offset 0x0004:0x2300014 expands past register size(2)!
which is not surprising. We read the value as an 32-bit (from host),
then operate it as a 16-bit - and the remainder is left unchanged.
We end up writing the value as 16-bit (so 0014) to dev.config
(as we use proper xen_set_host_[byte,word,long] so we don't spill
to other registers) but in XenPTReg->data it is as 32-bit (0x2300014)!
It is harmless as the read/write functions end up using an size mask
and never modify the bits past 16-bit (reg->size is 2).
This patch fixes the warnings by reading the value using the
proper size.
Note that the check for size is still left in-case the developer
sets bits past the reg->size in the ->init routines. The author
tried to fiddle with QEMU_BUILD_BUG to make this work but failed.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
During init time we treat the dev.config area as a cache
of the host view. However during execution time we treat it
as guest view (by the generic PCI API). We need to sync Xen's
code to the generic PCI API view. This is the first step
by replacing all of the code that uses dev.config or
pci_get_[byte|word] to get host value to actually use the
xen_host_pci_get_[byte|word] functions.
Interestingly in 'xen_pt_ptr_reg_init' we also needed to swap
reg_field from uint32_t to uint8_t - since the access is only
for one byte not four bytes. We can split this as a seperate
patch however we would have to use a cast to thwart compiler
warnings in the meantime.
We also truncated 'flags' to 'flag' to make the code fit within
the 80 characters.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
If XEN_PT_LOGGING_ENABLED is enabled the XEN_PT_LOG macros start
using the first argument. Which means if within the function there
is only one user of the argument ('d') and XEN_PT_LOGGING_ENABLED
is not set, we get compiler warnings. This is not the case now
but with the "xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config"
we will hit - so this sync up the function to the rest of them.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
We would like to know what the MSI register value is to help
in troubleshooting in the field. As such modify the logging
logic to include such details in xen_pt_msgctrl_reg_write.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In Xen 4.6 commit cd2f100f0f61b3f333d52d1737dd73f02daee592
"libxc: Fix do_memory_op to return negative value on errors"
made the libxc API less odd-ball: On errors, return value is
-1 and error code is in errno. On success the return value
is either 0 or an positive value.
Since we could be running with an old toolstack in which the
Exx value is in rc or the newer, we add an wrapper around
the xc_domain_add_to_physmap (called xen_xc_domain_add_to_physmap)
which will always return the EXX.
Xen 4.6 did not change the libxc functions mentioned (same parameters)
so we piggyback on the fact that Xen 4.6 has a new function:
commit 504ed2053362381ac01b98db9313454488b7db40 "tools/libxc: Expose
new hypercall xc_reserved_device_memory_map" and check for that.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Suggested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
However the init routines assume that on errors the return
code is -1 (as the libxc API is) - while those xen_host_* routines follow
another paradigm - negative errno on return, 0 on success.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
As we do not use it outside our code.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
It has changed but the comments still refer to the old names.
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. The hypervisor side gets I/O req server creation
extended so we can indicate that we're using suitable atomic accesses
where needed, allowing it to atomically canonicalize both pointers when
both have gone through at least one cycle.
The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) went in already (commit b7007bc6f9).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
.errors - as it will most likely have the proper error value.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.
This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).
The original patch is from Jean Guyader <jean.guyader@eu.citrix.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Currently we just register this isa bridge when we use IGD
passthrough in Xen side.
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Currently IGD drivers always need to access PCH by 1f.0. But we
don't want to poke that directly to get ID, and although in real
world different GPU should have different PCH. But actually the
different PCH DIDs likely map to different PCH SKUs. We do the
same thing for the GPU. For PCH, the different SKUs are going to
be all the same silicon design and implementation, just different
features turn on and off with fuses. The SW interfaces should be
consistent across all SKUs in a given family (eg LPT). But just
same features may not be supported.
Most of these different PCH features probably don't matter to the
Gfx driver, but obviously any difference in display port connections
will so it should be fine with any PCH in case of passthrough.
So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
scenarios, 0x9cc3 for BDW(Broadwell).
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Now we retrieve VGA bios like kvm stuff in qemu but we need to
fix Device Identification in case if its not matched with the
real IGD device since Seabios is always trying to compare this
ID to work out VGA BIOS.
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
We will try to reuse assign_dev_load_option_rom in xen side, and
especially its a good beginning to unify pci assign codes both on
kvm and xen in the future.
[Fix build for Windows]
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Implement a pci host bridge specific to passthrough. Actually
this just inherits the standard one. And we also just expose
a minimal real host bridge pci configuration subset.
[Replace pread with lseek and read to fix Windows build]
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
IGD passthrough wants to supply a different pci and
host devices, inheriting i440fx devices. Make types
configurable.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
- various bugfixes (css/event-facility)
- more efficient adapter interrupt routes setup
- gdb enhancement
- sclp got treated with a lot of remodelling/cleanup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJV7aJjAAoJEN7Pa5PG8C+v1fgQALFLDq1zNaq4/mZkYLMqaFnt
nRQsZLzecxHJAVKdFBc5QlCBSRCFjSRLeLeiULu8UkREFO+iZ1HhdnwlTB83cs/3
iHuz+NzJI1C++ATIzqGJpZSXZgYqftar7LKAANwpwjSkANOytrs/m7Y31UYl4zkT
MgfAD0AYWITrOEyefMSXkPL4ddY0otzx7d9az16sIbarSlkItoNj/AVFVmKfPIFa
8cI54YNG582L4gWavC2HGNC95Fau8/oZhNzFAprerIOdCx0bqE5Pmlkohz6AJg+U
e5PyVfIV+fnZtnFtII68HtTwFz0JcBgtga0xWiqlVU+ICrXvyADJDmqeTsU6QMMR
sxTzHNtuSAvJ4JgwXz3nNq7nbUPDAo6SX/YwsTcKPWmFLG5ZctSAYxPBvNY27Mrw
NdywJ8xif6yK8Fc53Dey0+ZYnNTaI6sd/EMPGpeP4B7PU6iZU3z8YOtevSYGib5B
vonGo1YA+Z2DxM+WdT8rjSwgU/MRbRWdWSA4FBr/7K4dkG18d4Pi8Wng4BXlHz+w
kUzXhANJ2QvIfVlPlm8EKudPDVPMeXGG0SGSIDeUKnh/vZQ56LCUTYTasTsx3+MU
XbKJeDBbn+nB33KEOZB9weBL51BIjSB6iGEzVrKQSAsK85iUyqv7NzkrMPVYSB/e
ZQV4lfk6pJTQ2LaBp1Fb
=Ax4r
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20150907' into staging
s390x fixes and improvements:
- various bugfixes (css/event-facility)
- more efficient adapter interrupt routes setup
- gdb enhancement
- sclp got treated with a lot of remodelling/cleanup
# gpg: Signature made Mon 07 Sep 2015 15:42:43 BST using RSA key ID C6F02FAF
# gpg: Good signature from "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
* remotes/cohuck/tags/s390x-20150907: (23 commits)
s390/sclp: simplify calculation of rnmax
s390/sclp: store the increment_size in the sclp device
s390: unify allocation of initial memory
s390: move memory calculation into the sclp device
s390/sclp: ignore memory hotplug operations if it is disabled
s390: disallow memory hotplug for the s390-virtio machine
s390: no need to manually parse for slots and maxmem
s390/sclp: move sclp_service_interrupt into the sclp device
s390/sclp: move sclp_execute related functions into the SCLP class
s390/sclp: introduce a root sclp device
s390/sclp: temporarily fix unassignment/reassignment of memory subregions
s390/sclp: replace sclp event types with proper defines
s390/sclp: rework sclp event facility initialization + device realization
sclp/s390: rework sclp cpu hotplug device notification
s390x/gdb: support reading/writing of control registers
s390x/kvm: make setting of in-kernel irq routes more efficient
pc-bios/s390-ccw: rebuild image
pc-bios/s390-ccw: Device detection in higher subchannel sets
s390x/event-facility: fix location of receive mask
s390x/css: start with cleared cstat/dstat
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
rnmax can be directly calculated using machine->maxram_size.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's calculate it once and reuse it.
Suggested-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Now that the calculation of the initial memory is hidden in the sclp
device, we can unify the allocation of the initial memory.
The remaining ugly part is the reserved memory for the virtio queues,
but that can be cleaned up later.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The restrictions for memory calculation belong to the sclp device.
Let's move the calculation to that point, so we are able to unify it for
both s390 machines. The sclp device is the first device to be initialized.
It performs the calculation and safely stores it in the machine, where
other parts of the system can access an reuse it.
The memory hotplug device is now only created when it is really needed.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
If no memory hotplug device was created, the sclp command facility is
not exposed (SCLP_FC_ASSIGN_ATTACH_READ_STOR). We therefore have no
memory hotplug and should correctly report SCLP_RC_INVALID_SCLP_COMMAND
if any such command is executed.
This gets rid of these ugly asserts that could have been triggered
for the s390-virtio machine.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
That machine type doesn't currently support memory hotplug, so let's abort
if it is requested. Reason is, that the virtio queues are allocated for now
at the end of the initial ram - extending the ram is therefore not possible.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
ram_slots and maxram_size has already been parsed and verified by
common code for us.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's make that function a method of the new sclp device, keeping
the wrapper for existing users.
We can now let go of get_event_facility().
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's move the sclp_execute related functions into the SCLP class
and pass the device state as parameter, so we have easy access to
the SCLPDevice later on.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's create a root sclp device, which has other sclp devices as
children (e.g. the event facility for now) and can later be used
for migration of sclp specific attributes and setup of memory.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Commit 374f2981d1 ("memory: protect current_map by RCU") broke
unassignment of standby memory on s390x. Looks like that the new
parallelism allows races with our (semi broken) memory hotplug code. The
flatview_unref() can now be executed after our unparenting. Therefore
memory_region_unref() tries to unreference the MemoryRegion itself instead
of the parent.
In theory, MemoryRegions are now bound to separate devices that control
their lifetime. We don't have this yet, so we really want to control their
lifetime manually.
This patch fixes it temporarily, until we have a proper rework. The only
drawback is that they won't pop up in "info qom-tree", but that's better
than qemu crashes.
We have to release the reference to a memory region after a
memory_region_find, as it automatically takes a reference. As we're now
able to reassign memory, the MemoryRegion is in fact deleted (otherwise
vmstate_register_ram() would complain).
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Introduce TYPE_SCLP_QUIESCE and make use of it. Also use
TYPE_SCLP_CPU_HOTPLUG where applicable.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The current code only works by chance. The event facility is a sysbus
device, but specifies in its class structure as parent the DeviceClass
(instead of a device class).
The init function in return lies therefore at the same position as
the init function of SysBusDeviceClass and gets triggered instead -
a very bad idea of doing that (e.g. the parameter types don't match).
Let's bring the initialization code up to date, initializing the event
facility + child events in .instance_init and moving the realization of
the child events out of the init call, into the realization step.
Device realization is now automatically performed when the event facility
itself is realized. That realization implicitly triggers realization of
the child bus, which in turn initializes the events.
Please note that we have to manually propagate the realization of the bus
children, common code still has a TODO set for that task.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's get rid of this strange local variable + irq logic and
work directly on the QOM. (hint: what happens if two such devices
are created?)
We could introduce proper QOM class + state for the cpu hotplug device,
however that would result in too much overhead for a simple
"trigger_signal" function.
Also remove one unnecessary class function initialization.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Let's support reading and writing of control registers for kvm and tcg.
We have to take care of flushing the tlb (tcg) and pushing the changed
registers into kvm.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
When we add new adapter routes we call kvm_irqchip_add_route() for every
virtqueue and in the same step also do the KVM_SET_GSI_ROUTING ioctl.
This is unnecessary costly as the interface allows us to set multiple
routes in one go. Let's first add all routes to the table stored in the
global kvm_state and then do the ioctl to commit the routes to the
in-kernel irqchip.
This saves us several ioctls to the kernel where for each call a list
is reallocated and populated.
Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
If no bootdevice was specified, we try to autodetect a suitable IPL
device. Current code only searched in subchannel set 0; extend this
search to higher subchannel sets as well.
Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
For read event mask, we assumed that the layout of the sccb was
|sccb header|event buffer header|receive mask|...|
The correct layout, however, is
|sccb header|receive mask|...|
as in-buffer and
|sccb header|event buffer header|...|
as out-buffer.
Fix this: This makes selective read work.
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
When executing the start function, we should start with a clear state
regarding subchannel and device status; it is easy to forget updating one
of them after the ccw has been processed.
Note that we don't need to care about resetting the various control
fields: They are cleared by tsch(), and if they were still pending,
we wouldn't be able to execute the start function in the first
place.
Also note that we don't want to clear cstat/dstat if a suspended
subchannel is resumed.
This fixes a bug where we would continue to present channel-program
check in cstat even though later ccw requests for the subchannel
finished without error (i.e. cstat should be 0).
Cc: qemu-stable@nongnu.org
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
For selective read event, we need to check if any event is requested
that is not active instead of whether none of the requested events is
active.
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Type-0 ccws need to have a count > 0 for any command other than TIC.
Generate a channel-program check if this is not the case.
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
