* mjt/mjt-iov2:
rewrite iov_send_recv() and move it to iov.c
cleanup qemu_co_sendv(), qemu_co_recvv() and friends
export iov_send_recv() and use it in iov_send() and iov_recv()
rename qemu_sendv to iov_send, change proto and move declarations to iov.h
change qemu_iovec_to_buf() to match other to,from_buf functions
consolidate qemu_iovec_copy() and qemu_iovec_concat() and make them consistent
allow qemu_iovec_from_buffer() to specify offset from which to start copying
consolidate qemu_iovec_memset{,_skip}() into single function and use existing iov_memset()
rewrite iov_* functions
change iov_* function prototypes to be more appropriate
virtio-serial-bus: use correct lengths in control_out() message
Conflicts:
tests/Makefile
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Commit ff71f2e8ca prevent the possible
crash during initialization of linux driver by checking the operating
mode.This seems too strict as:
- the real card could still work in mode other than normal
- some buggy driver who does not set correct opmode after eeprom
access
So, considering rx ring address were reset to zero (which could be
safely trated as an address not intened to DMA to), in order to
both letting old guest work and preventing the unexpected DMA to
guest, we can forbid packet receiving when rx ring address is zero.
Tested-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* mst/tags/for_anthony:
pci_bridge_dev: fix error path in pci_bridge_dev_initfn()
qdev: release parent properties on dc->init failure
msi: Use msi/msix_present more consistently
msi: Invoke msi/msix_write_config from PCI core
msi: Guard msi/msix_write_config with msi_present
msi: Invoke msi/msix_reset from PCI core
msi: Guard msi_reset with msi_present
ahci: Clean up reset functions
intel-hda: Fix reset of MSI function
ahci: Fix reset of MSI function
rtl8139: honor RxOverflow flag in can_receive method
shpc: unparent device before free
Reorder arguments to be more natural, readable and
consistent with other iov_* functions, and change
argument names, from:
iov_from_buf(iov, iov_cnt, buf, iov_off, size)
to
iov_from_buf(iov, iov_cnt, offset, buf, bytes)
The result becomes natural English:
copy data to this `iov' vector with `iov_cnt'
elements starting at byte offset `offset'
from memory buffer `buf', processing `bytes'
bytes max.
(Try to read the original prototype this way).
Also change iov_clear() to more general iov_memset()
(it uses memset() internally anyway).
While at it, add comments to the header file
describing what the routines actually does.
The patch only renames argumens in the header, but
keeps old names in the implementation. The next
patch will touch actual code to match.
Now, it might look wrong to pay so much attention
to so small things. But we've so many badly designed
interfaces already so the whole thing becomes rather
confusing or error prone. One example of this is
previous commit and small discussion which emerged
from it, with an outcome that the utility functions
like these aren't well-understdandable, leading to
strange usage cases. That's why I paid quite some
attention to this set of functions and a few
others in subsequent patches.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Some drivers (Linux' 8139too among them) rely on the NIC
injecting an interrupt in the event of a receive buffer overflow
and, accordingly, set the RxOverflow bit in the interrupt
mask. Unfortunately rtl8139's can_receive method ignores the
RxOverflow flag, which may lead to a situation where rtl8139
stops receiving packets (can_receive returns 0) when the receive
buffer becomes full.
If the driver eventually read from the receive buffer or reset
the card the emulator could recover from this situation. However
some implementations only do this upon receiving an interrupt
with either RxOK or RxOverflow set in the ISR; interrupt that
will never come because QEMU's flow control mechanisms would
prevent rtl8139 from receiving any packet.
Letting packets go through when the overflow interrupt is enabled
makes the QEMU emulator compliant to the spec and solves the
problem.
This patch should fix a relatively common (in our experience)
network stall observed when running enterprise distros with
rtl8139 as the NIC; in some cases the 8139too device driver gets
loaded and when under heavy load the network eventually stops
working.
Reported-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Acked-by: Igor Kovalenko <igor.v.kovalenko@gmail.com>
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This reverts commit ff71f2e8ca. This is because
the linux 8139cp driver would leave the card in "Config Register Write Enable"
mode after the eeprom were read or write ( which is unexpected in the spec
). Also a physical 8139 card can still DMA into host memory in modes other than
Normal mode, so we need revert this commit to align with the behavior of
physical card.
The issue of 8139cp driver should be fixed in linux seperately.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Commit afe0a59535 added byte reads for TxStatus/TxAddr, but
broke 32-bit reads; the mask generation
(1 << (8 * size)) - 1
is unspecified in C for size >= sizeof(int), and in fact returns 0
on x86.
Fix by using a larger type.
Fixes (at least) Fedora 9 i386 with -machine kernel_irqchip=on. I
didn't see it with the qemu APIC implementation; may be due to timing
or (more likely) a tester error.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit afe0a59535 ("rtl8139: support byte
read to TxStatus registers") reused rtl8139_TxStatus_read() for reading
TxAddr registers. It relies on the fact that TxStatus[] and TxAddr[]
are adjacent.
This causes a gcc warning because the compiler can detect that array
access is out-of-bounds:
hw/rtl8139.c:2501:27: error: array subscript is above array bounds [-Werror=array-bounds]
This patch refactors the function so that we don't rely on out-of-bounds
accesses.
Cc: Jason Wang <jasonwang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
According the spec, the card works in network/host communication mode only when
both EEM1 and EEM0 are unset in 93C46 Command Register (normal op
mode). So this patch check these bits before trying to receive packets.
As some guest driver (such as linux, see cp_init_hw() in 8139cp.c)
allocate rx ring after the recevier were enabled, this would cause our
emulation codes tries to dma into guest memory when the rx descriptor
is not properly configured. This patch fixes this.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
According to the spec, only when opmode is "Config. Register Write
Enable" could driver write to CONFIG0,1,3,4 and bits 13,12,8 of BMCR.
Currently, we allow modifying to those registers also when 8139 is in
"Auto-load" mode and "93C46 (93C56) Programming" mode. This patch
fixes this.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Some drivers (such as win7) use byte read for TxStatus registers, so we need to
support this to let guest driver behave correctly.
For writing, only double-word access is allowed by spec.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The tx buffer would be re-allocated for tx descriptor with big size
and without LS bit set, this would make guest driver could easily let
qemu to allocate unlimited.
In linux host, a glib failure were easy to be triggered:
GLib-ERROR **: gmem.c:176: failed to allocate 18446744071562067968 bytes
This patch fix this by adding a limit. As the spec didn't tell the maximum size
of buffer allowed, stick it to current CP_TX_BUFFER_SIZE (65536).
Changes from V1:
Drop the while statement and s->cplus_txbuffer check.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Replace device_init() with generalized type_init().
While at it, unify naming convention: type_init([$prefix_]register_types)
Also, type_init() is a function, so add preceding blank line where
necessary and don't put a semicolon after the closing brace.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: malc <av1474@comtv.ru>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This was done in a mostly automated fashion. I did it in three steps and then
rebased it into a single step which avoids repeatedly touching every file in
the tree.
The first step was a sed-based addition of the parent type to the subclass
registration functions.
The second step was another sed-based removal of subclass registration functions
while also adding virtual functions from the base class into a class_init
function as appropriate.
Finally, a python script was used to convert the DeviceInfo structures and
qdev_register_subclass functions to TypeInfo structures, class_init functions,
and type_register_static calls.
We are almost fully converted to QOM after this commit.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Right now, DeviceInfo acts as the class for qdev. In order to switch to a
proper ObjectClass derivative, we need to ween all of the callers off of
interacting directly with the info pointer.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch removes some unnecessary casts in the rtl8139 device,
introduced by commit 3ada003aee
'rtl8139: Use PCI DMA stub functions'.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch makes iPXE work with the rtl8139 emulation. The rtl8139
driver in iPXE issues a 16bit access on the ChipCmd register
(offset 0x37) to check the status of the rx buffer. The offset of the
ioport access was getting fixed up to 0x36 in qemu, causing the value
read in iPXE to be invalid.
This fixes an issue with iPXE reporting timeouts during TFTP transfers.
Reposting this here because it is trivial enough and the original post
on qemu-devel didn't attract much attention.
Also, the inw() which was causing the issue has been replaced with an
inb() in upstream iPXE:
https://git.ipxe.org/ipxe.git/commit/91dd64ad25baa27954a7518e73df4fca8a2d0c93
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This updates the rtl8139 device emulation to use the explicit PCI DMA
functions, instead of directly calling physical memory access functions.
Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fix up some erroneous comments in code:
interrupt pins are named A-D, the
interrupt pin register is always readonly
and isn't zeroed out on reset.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
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>
Reviewed-by: Richard Henderson <rth@twiddle.net>
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>
Compilation for Windows needs a different declaration for the
printf format attribute, so use the macro which was defined for
this purpose.
Cc: Benjamin Poirier <benjamin.poirier@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
gcc can check the format string for correctness even when debugging output is
not enabled.
Have to make sure arguments are always available. They are optimized out if
unneeded.
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Cc: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Removes double (( )) to make DEBUG_PRINT compatible with real function calls.
Change the name to DPRINTF to be consistent with other DPRINTF macros
throughout qemu.
Include the "RTL8139: " prefix in the macro. This changes some debug output
slightly since the prefix wasn't present on all lines.
Part of the change was done using the "coccinelle" tool with the following
small semantic match:
@@ expression E; @@
- DEBUG_PRINT((E))
+ DPRINTF(E)
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Cc: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Prevents a compilation failure when DEBUG_RTL8139 is defined:
CC libhw32/rtl8139.o
cc1: warnings being treated as errors
hw/rtl8139.c: In function ‘rtl8139_cplus_transmit_one’:
hw/rtl8139.c:1960: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 5 has type ‘target_phys_addr_t’
make[1]: *** [rtl8139.o] Error 1
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Cc: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Cc: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Cc: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx detagging but should not assume that it was done. Under
Linux, the mac layer will catch the vlan ethertype. I only added this
part for completeness (to emulate the hardware more truthfully...)
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
clean out ifdef's around ethernet checksum calculation
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Acked-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This was done with:
sed -i 's/qemu_get_clock\>/qemu_get_clock_ns/' \
$(git grep -l 'qemu_get_clock\>' )
sed -i 's/qemu_new_timer\>/qemu_new_timer_ns/' \
$(git grep -l 'qemu_new_timer\>' )
after checking that get_clock and new_timer never occur twice
on the same line. There were no missed occurrences; however, even
if there had been, they would have been caught by the compiler.
There was exactly one false positive in qemu_run_timers:
- current_time = qemu_get_clock (clock);
+ current_time = qemu_get_clock_ns (clock);
which is of course not in this patch.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
Signed-off-by: William Dauchy <wdauchy@gmail.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
rtl8139 includes a cpu_register_io_memory acquired value in it's
migration data. This is not only unecessary, but we should treat
these values as unique to the VM instances since the value depends
on call order. In most cases, this miraculously still works.
However, if devices are added or removed from the system, it may
represent an ordering change, which could cause the target rtl8139
device to make use of another device's cpu_register_io_memory value.
If we detect that a hot-add/remove has occured, include a subsection
to restrict migrations only to driver versions known to include this
fix.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
As stated before, devices can be little, big or native endian. The
target endianness is not of their concern, so we need to push things
down a level.
This patch adds a parameter to cpu_register_io_memory that allows a
device to choose its endianness. For now, all devices simply choose
native endian, because that's the same behavior as before.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
