This will enable us to remove all remaining explicit calls of
qemu_flush_coalesced_mmio_buffer in IO handlers.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties via dedicated ops, decoupling us from
the memory core's handling of unassigned accesses.
Cc: qemu-stable@nongnu.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This reverts commit c3cb8e7780.
The scenario where I/O ports are accessed with DEVICE_LITTLE_ENDIAN
endianness now works and will soon be unit tested. Since the PortioList
indirection assumes little endian, define portio_ops the same way.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1374501278-31549-16-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Setting it to LE forces a byte swap when host != guest endian but
this makes no sense at all.
Herve made the suggestion upon observing that word writes/reads
were broken into byte writes/reads in such a way as to assume
devices are interpret registers as LE.
However, even if this were a problem, marking the region as LE is
not useful because what's essentially happening here is that LE is
open coded. So by marking it LE in MemoryRegionOps, we're doing a
superflous swap.
Now, the portio code is suspicious to begin with. The dispatch
layer really has no purpose in splitting I/O requests in the first
place...
Cc: Hervé Poussineau <hpoussin@reactos.org>
Cc: Alex Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Remove unused ioport_register and isa_unassign_ioport along with
everything that only those services used.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The current ioport dispatcher is a complex beast, mostly due to the
need to deal with old portio interface users. But we can overcome it
without converting all portio users by embedding the required base
address of a MemoryRegionPortio access into that data structure. That
removes the need to have the additional MemoryRegionIORange structure
in the loop on every access.
To handle old portio memory ops, we simply install dispatching handlers
for portio memory regions when registering them with the memory core.
This removes the need for the old_portio field.
We can drop the additional aliasing of ioport regions and also the
special address space listener. cpu_in and cpu_out now simply call
address_space_read/write. And we can concentrate portio handling in a
single source file.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Open-code isa_is_ioport_assigned via a memory region lookup. As all IO
ports are now directly or indirectly registered via the memory API, this
becomes possible and will finally allow us to drop the ioport tables.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Expression UINT64_MAX + 1 will make the range bigger than
what can be represented with a 64 bit type. This would
trigger an assert in int128_get64() after the next patch.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Previously all callers had a containing object with a destructor that
could be used to trigger cleanup of the IORange objects (typically
just freeing the containing object), but a forthcoming memory API
change doesn't fit this pattern. Rather than setting up a new global
table, extend the ioport system to support destructors.
Signed-off-by: Avi Kivity <avi@redhat.com>
memory_region_set_offset() will be going away soon, so don't use it.
Use an alias instead.
Signed-off-by: Avi Kivity <avi@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Add a type and methods for manipulating a list of disjoint I/O ports,
used in some older hardware devices.
Based on original patch by Richard Henderson.
Signed-off-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Avi Kivity <avi@redhat.com>
The I/O port space is byte addressable, even for word and long accesses.
An example is the VMware svga card, which has long ports on offsets 0,
1, and 2.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Serial and parallel devices created with -device are not reported in
the PIIX4 configuration space, and are hence not picked up by the DSDT.
This upsets Windows, which hides them altogether from the guest.
To avoid this, check at the end of machine initialization whether the
corresponding I/O ports have been registered. The new function in
ioport.c does this; this also requires a tweak to isa_unassign_ioport.
I left the comment in piix4_pm_initfn since the registers I moved do
seem to match the 82371AB datasheet. There are some quirks though.
We are setting this bit:
"Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the
device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded
to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable
the decode."
but not LPT_MON_EN (bit 18 at 50h):
LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel
port address range (LPT_DEC_SEL) to generate a device 8 (parallel
port) decode event. 0=Disable.
We're also setting the LPT_DEC_SEL field (that's the 0x60 written to
63h) to 11, which means reserved, rather than to 01 (378h-37Fh).
Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14
and bit 16 at address 50h) for the serial ports. However, we're setting
COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register
for the parallel port.
All these fields are left as they are, since they are probably only
meant to be used in the DSDT.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When failing due to conflicting I/O port registrations,
include the offending I/O port address in the message.
Cc: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The current ioport callbacks are not type-safe, in that they accept an "opaque"
pointer as an argument whose type must match the argument to the registration
function; this is not checked by the compiler.
This patch adds an alternative that is type-safe. Instead of an opaque
argument, both registation and the callback use a new IOPort type. The
callback then uses container_of() to access its main structures.
Currently the old and new methods exist side by side; once the old way is gone,
we can also save a bunch of memory since the new method requires one pointer
per ioport instead of 6.
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In the very least, a change like this requires discussion on the list.
The naming convention is goofy and it causes a massive merge problem. Something
like this _must_ be presented on the list first so people can provide input
and cope with it.
This reverts commit 99a0949b72.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The CPU state parameter is not used, remove it and adjust callers. Now we
can compile ioport.c once for all targets.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
kqemu introduces a number of restrictions on the i386 target. The worst is that
it prevents large memory from working in the default build.
Furthermore, kqemu is fundamentally flawed in a number of ways. It relies on
the TSC as a time source which will not be reliable on a multiple processor
system in userspace. Since most modern processors are multicore, this severely
limits the utility of kqemu.
kvm is a viable alternative for people looking to accelerate qemu and has the
benefit of being supported by the upstream Linux kernel. If someone can
implement work arounds to remove the restrictions introduced by kqemu, I'm
happy to avoid and/or revert this patch.
N.B. kqemu will still function in the 0.11 series but this patch removes it from
the 0.12 series.
Paul, please Ack or Nack this patch.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Using int for cpu_{in, out}[bwl] is inconsistent with other part
because for address or value, uintN_t is used by other qemu part.
At least, softmmu, CPU{Read, Write}MemoryFunc, pci, target_phys_addr_t
and the callers of cpu_{in, out}[bwl]().
This patch removes the inconsistency.
IO port has its own address space so define pio_addr_t as uint32_t
because PCI io space width is 32bit.
And use uint{32, 16, 8}_t for ioport value.
Changing signedness of value might cause subtle issue. However
only a suspicious caller is kvm_handle_io() which is ok. And other callers
pass unsigned value in the first place.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Stuart Brady <sdbrady@ntlworld.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Samuel Thibault <samuel.thibault@gnu.org>
Cc: Tristan Gingold <gingold@adacore.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
remove some #ifdef DEBUG_UNUSED_IOPORT in ioport.c
and use PRIx32 where appropriate
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
