Convert the device models where initialization obviously can't fail.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Pavel Dovgalyuk reports that TimerExpire and the timer are not restored
correctly on the receiving end of migration.
It is not clear to me whether this is really the case, but we can take
the occasion to get rid of the complicated code that computes PCSTimeout
on the fly upon changes to IntrStatus/IntrMask. Just always keep a
timer running, it will fire every ~130 seconds at most if the interrupt
is masked with TimerInt != 0.
This makes rtl8139_set_next_tctr_time idempotent (when the virtual clock
is stopped between two calls, as is the case during migration).
Tested with Frediano's qtest.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1421765099-26190-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
All NICs have a cleanup function that, in most cases, zeroes the pointer
to the NICState. In some cases, it frees data belonging to the NIC.
However, this function is never called except when exiting from QEMU.
It is not necessary to NULL pointers and free data here; the right place
to do that would be in the device's unrealize function, after calling
qemu_del_nic. Zeroing the NIC multiple times is also wrong for multiqueue
devices.
This cleanup function gets in the way of making the NetClientStates for
the NIC hold an object_ref reference to the object, so get rid of it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Coverity spot:
Assigning: iov = struct iovec [3]({{buf, 12UL},
{(void *)dot1q_buf, 4UL},
{buf + 12, size - 12}})
(address of temporary variable of type struct iovec [3]).
out_of_scope: Temporary variable of type struct iovec [3] goes out of scope.
Pointer to local outside scope (RETURN_LOCAL)
use_invalid:
Using iov, which points to an out-of-scope temporary variable of type struct iovec [3].
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
On this way, we can assure the new bootindex take effect
during vm rebooting.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function is empty after the previous patch, so remove it.
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After previous Peter patch, they are redundant. This way we don't
assign them except when needed. Once there, there were lots of case
where the ".fields" indentation was wrong:
.fields = (VMStateField []) {
and
.fields = (VMStateField []) {
Change all the combinations to:
.fields = (VMStateField[]){
The biggest problem (appart from aesthetics) was that checkpatch complained
when we copy&pasted the code from one place to another.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
This reverts commit cd5be5829c.
Digging into hardware specs shows this does not
actually make QEMU behave more like hardware:
There are valid arguments backed by the spec to indicate why the version
of e1000 prior to cd5be582 was more correct: the high byte actually
includes a valid bit, this is why all guests write it last.
For rtl8139 there's actually a separate undocumented valid bit, but we
don't implement it yet.
To summarize all the drivers we know about behave in one way
that allows us to make an assumption about write order and avoid
spurious, incorrect mac address updates to the monitor.
Let's stick to the tried heuristic for 1.7 and
possibly revisit for 1.8.
Reported-by: Vlad Yasevich <vyasevic@redhat.com>
Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
Cc: Amos Kong <akong@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We currently just update the HMP NIC info when the last bit of macaddr
is written. This assumes that guest driver will write all the macaddr
from bit 0 to bit 5 when it changes the macaddr, this is the current
behavior of linux driver (e1000/rtl8139cp), but we can't do this
assumption.
The macaddr that is used for rx-filter will be updated when every bit
is changed. This patch updates the e1000/rtl8139 nic to update HMP NIC
info when every bit is changed. It will be same as virtio-net.
Signed-off-by: Amos Kong <akong@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Message-id: 1383650238-16015-1-git-send-email-akong@redhat.com
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
This includes some pretty big changes:
- pci master abort support by Marcel
- pci IRQ API rework by Marcel
- acpi generation support by myself
Everything has gone through several revisions, latest versions have been on
list for a while without any more comments, tested by several
people.
Please pull for 1.7.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQEcBAABAgAGBQJSXNO8AAoJECgfDbjSjVRp7VAH/0B73mCOiyVACGx7fazK3SGK
X8TxZWVtG5A77ISqKyrtjLAhK9DCQjEzQTbMNhXHM3Ar6crwo7nJZnQvH2Gh1X2p
34BOQSVc4rtXz5pwDIr48dBLrxeslwXub79chUs+IK1/4RSn3h3nuS3k6JVkmLJN
rcHMj4ljJmi4Hd9vOpmS1jo/a61usi36hhU7CMgcrsXzStZycBBzCozOB3VW8p1X
/iwyf91YjmNPkn9gA3/aViGjszu8jE91dkA0C+ljwvcGbs2yEl3LCWEJfsMvoh5P
2M+k0XXbHwq/P9PFMa/2/lWOo4EO4Oxa+G/6QvovJrteYnktr+E9DqjU8pCT7yI=
=CVfs
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'mst/tags/for_anthony' into staging
pci, pc, acpi fixes, enhancements
This includes some pretty big changes:
- pci master abort support by Marcel
- pci IRQ API rework by Marcel
- acpi generation support by myself
Everything has gone through several revisions, latest versions have been on
list for a while without any more comments, tested by several
people.
Please pull for 1.7.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Tue 15 Oct 2013 07:33:48 AM CEST using RSA key ID D28D5469
# gpg: Can't check signature: public key not found
* mst/tags/for_anthony: (39 commits)
ssdt-proc: update generated file
ssdt: fix PBLK length
i386: ACPI table generation code from seabios
pc: use new api to add builtin tables
acpi: add interface to access user-installed tables
hpet: add API to find it
pvpanic: add API to access io port
ich9: APIs for pc guest info
piix: APIs for pc guest info
acpi/piix: add macros for acpi property names
i386: define pc guest info
loader: allow adding ROMs in done callbacks
i386: add bios linker/loader
loader: use file path size from fw_cfg.h
acpi: ssdt pcihp: updat generated file
acpi: pre-compiled ASL files
acpi: add rules to compile ASL source
i386: add ACPI table files from seabios
q35: expose mmcfg size as a property
q35: use macro for MCFG property name
...
Message-id: 1381818560-18367-1-git-send-email-mst@redhat.com
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
rtl8139 has same problem as e1000, nic info isn't updated when macaddr
is changed in guest.
This patch updates the nic info when the last bit of macaddr is written.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
macaddr is reset during device reset, but nic info
isn't updated, this problem exists in e1000 & rtl8139
Signed-off-by: Amos Kong <akong@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
pci_set_irq and the other pci irq wrappers use
PCI_INTERRUPT_PIN config register to compute device
INTx pin to assert/deassert.
An irq is allocated using pci_allocate_irq wrapper
only if is needed by non pci devices.
Removed irq related fields from state if not used anymore.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This is an autogenerated patch using scripts/switch-timer-api.
Switch the entire code base to using the new timer API.
Note this patch may introduce some line length issues.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The category will be used to sort the devices displayed in
the command line help.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Message-id: 1375107465-25767-4-git-send-email-marcel.a@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Replace direct uses of RTL8139State::dev with QOM casts and rename it to
parent_obj.
Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Define and use standard QOM cast macro. Remove usages of DO_UPCAST()
and direct -> style upcasting.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Net queues support efficient "receive disable". For example, tap's file
descriptor will not be polled while its peer has receive disabled. This
saves CPU cycles for needlessly copying and then dropping packets which
the peer cannot receive.
rtl8139 is missing the qemu_flush_queued_packets() call that wakes the
queue up when receive becomes possible again.
As a result, the Windows 7 guest driver reaches a state where the
rtl8139 cannot receive packets. The driver has actually refilled the
receive buffer but we never resume reception.
The bug can be reproduced by running a large FTP 'get' inside a Windows
7 guest:
$ qemu -netdev tap,id=tap0,...
-device rtl8139,netdev=tap0
The Linux guest driver does not trigger the bug, probably due to a
different buffer management strategy.
Reported-by: Oliver Francke <oliver.francke@filoo.de>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
