This patch is a followup to 8eca6b1b,
fixing crashes when guests with 2.6.25 virtio drivers have saturated
virtio network connections.

https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521

That patch should have been whitelisting *_HOST_* rather than the the
*_GUEST_* features.

I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel +
2.6.25-virtio driver).  I saturated both the incoming, and outgoing
network connection with nc, seeing sustained 6MB/s up and 6MB/s down
bitrates for ~20 minutes.  Previously, this crashed immediately.  Now,
the guest does not crash and maintains network connectivity throughout
the test.
Signed-off-by: NDustin Kirkland <kirkland@canonical.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

A size of 0 should be valid and cannot be treated as "missing value". Use -1
for this purpose instead.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Okay, let's try re-enabling the drain-entire-queue behaviour, with a
difference - before each subsequent packet, use qemu_can_send_packet()
to check that we can send it. This is similar to how we check before
polling the tap fd and avoids having to drop a packet if the receiver
cannot handle it.

This patch should be a performance improvement since we no longer have
to go through the mainloop for each packet.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We should only return zero from receive() for a condition which we'll
get notification of when it changes. Currently, we're returning zero
if the guest driver is not ready, but we won't ever flush our queue
when that status changes.

Also, don't check buffer space in can_receive(), but instead just allow
receive() to return zero when this condition occurs and have the caller
handle queueing the packet.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Now that we disable any receiver whose queue is full, we do not require
senders to handle a zero return by supplying a sent callback.

This is a second step towards allowing can_receive() handlers to return
true even if no buffer space is available.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If a receiver returns zero, that means its queue is full and it will
notify us when room is available using qemu_flush_queued_packets().

Take note of that and disable that receiver until it flushes its queue.

This is a first step towards allowing can_receive() handlers to return
true even if no buffer space is available.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If qemu_send_packet_async() returns zero, it means the packet has been
queued and the sent callback will be invoked once it has been flushed.

This is only possible where the NIC's receive() handler returns zero
and promises to notify the networking core that room is available in its
queue again.

In the case where the receive handler does not have this capability
(and its queue fills up) it returns -1 and the networking core does not
queue up the packet. This condition is indicated by a -1 return from
qemu_send_packet_async().

Currently, tap handles this condition simply by dropping the packet. It
should do its best to avoid getting into this situation by checking such
NIC's have room for a packet before copying the packet from the tap
interface.

tap_send() used to achieve this by only reading a single packet before
returning to the mainloop. That way, tap_can_send() is called before
reading each packet.

tap_send() was changed to completely drain the tap interface queue
without taking into account the situation where the NIC returns an
error and the packet is not queued. Let's start fixing this by
reverting to the previous behaviour of reading one packet at a time.
Reported-by: NScott Tsai <scottt.tw@gmail.com>
Tested-by: NSven Rudolph <Sven_Rudolph@drewag.de>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We have code for a quite a few block formats.  While I trust that all
of these formats are useful at least for some people in some
circumstances, some of them are of a kind that friends don't let
friends use in production.

This patch provides an optional block format whitelist, default off.
If a whitelist is configured with --block-drv-whitelist, QEMU proper
can use only whitelisted formats.  Other programs, like qemu-img, are
not affected.

Drivers for formats off the whitelist still participate in format
probing, to ensure all programs probe exactly the same.  Without that,
QEMU proper would be prone to treat images with a format off the
whitelist as raw when the image's format is probed.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

These devices are created automatically, and attempting to create
another one with -device fails with "qemu: hardware error:
register_ioport_write: invalid opaque".
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Implemented for virtio-blk and for scsi
Signed-off-by: NNaphtali Sprei <nsprei@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is a slightly revised patch for adding readonly flag to the -drive command.
Even though this patch is "stand-alone", it assumes a previous related patch (in Anthony staging tree), that passes
the readonly attribute of the drive to the guest OS, applied first.

This enables sharing same image between guests, with readonly access.
Implementaion mark the drive as read_only and changes the flags when actually opening the file.
The readonly attribute of a qcow also passed to it's base file.
For ide that cannot pass the readonly attribute to the guest OS, disallow the readonly flag.

Also, return error code from bdrv_truncate for readonly drive.
Signed-off-by: NNaphtali Sprei <nsprei@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Images with disk size 0 may be used for
VM snapshots, but not to save normal block data.

It is possible to create such images using
qemu-img, but opening them later fails.

So even "qemu-img info image.qcow2" is not
possible for an image created with
"qemu-img create -f qcow2 image.qcow2 0".

This is fixed here.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

b55a37c9 moved the call to cpu_reset
to user emulators. But cpu_copy also initializes a CPU structure, so add the
call also there.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Problem: x86 systems could not survive a few system_resets.

Clear most of IDE state when reset. Implement the missing reset handlers.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow us to find bugs easier.

Furthermore, the fact that we initialize things like the cpu quite early,
leads to the need to introduce synchronization stuff like qemu_system_cond.
This patch removes it entirely. All we need to do is call qemu_system_reset()
only when we're already sure the system is up and running

I tested it with qemu (with and without io-thread) and qemu-kvm, and it
seems to be doing okay - although qemu-kvm uses a slightly different patch.

[ v2: user mode still needs cpu_reset, so put it in ifdef. ]
[ v3: leave qemu_system_cond for now. ]
Signed-off-by: NGlauber Costa <glommer@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Line counter doesn't wrap.
Signed-off-by: Nmalc <av1474@comtv.ru>

Unbreaks setup screen of Act1/PL
Signed-off-by: Nmalc <av1474@comtv.ru>

The page 108 of the SPARC Version 8 Architecture Manual describes
that addcc and addxcc shall compute carry flag the same way.
The page 110 claims the same about subcc and subxcc instructions.
This patch fixes carry computation in corner cases and removes redundant code.
The most visible effect of the patch is enabling Solaris boot when using OBP.
Signed-off-by: NArtyom Tarasenko <atar4qemu@gmail.com>
[blauwirbel@gmail.com: cleaned up formatting]
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This patch adds SHDC support (-sd sd.img, where sd.img is
larger than 1GB) to qemu.
Signed-off-by: NJason S. McMullan <jason.mcmullan@gmail.com>
Signed-off-by: NAndrzej Zaborowski <andrew.zaborowski@intel.com>

You would only see this error on a fresh clone when srcdir == objdir.  configure
will fail because roms/pcbios doesn't exist.

git submodule integration doesn't cleanup very well when switching between
branches so you'll get an roms/pcbios directory from normal operations if you
switch between old branches.

Thanks to a mistake in configure, if you build outside of srcdir, you'll also
get a valid roms/pcbios.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

  commit 71f4effc
  Author: Alexander Graf <agraf@suse.de>
  Date:   Fri Oct 30 22:27:00 2009 +0100

      Unbreak tap compilation on OS X

Broke the build on Linux due to a bad #if guard
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently compiling the tap sources breaks on Mac OS X. This is because of:

  1) tap-linux.h requiring Linux includes
  2) typos
  3) missing #includes

This patch adds what's necessary to compile tap happily on Mac OS X.
I haven't tested if using tap actually works, but I don't think that's a
major issue as that code was probably seriously untested before already.

I didn't split the patch, because it's only a few lines of code and
splitting is probably not worth the effort here.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit 94ca5a98.

This is similiar to the default with most bare metal systems.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The gPXE rom supports BEV properly.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

etherboot is deprecated and not under active development anymore.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

SeaBIOS is a port of pc-bios to GCC.  Besides using a more modern tool chain,
SeaBIOS introduces a number of new features including PMM support, better
BEV and BCV support, and better PnP support.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit:

    commit 97b15621
    virtio: use qdev properties for configuration.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

makes a guest using virtio-net see an empty macaddr because we never
copy the macaddr into the location that virtio_net_get_config() uses.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Fixes a couple of issues with msix table access:
- With misbehaving guests, misaligned 4 byte access could overflow
  msix table and cause qemu to segfault. Since PCI spec requires
  host to only issue dword-aligned accesses, as a fix,
  it's enough to mask the address low bits.
- Tables use pci format, not native format, and so
  we must use pci_[sg]et_long on read/write.
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

wmb must be at least a compiler barrier, even without SMP.
Further, we likely need some rmb()/mb() as well:
I have not audited the code but lguest has mb(),
add a comment for now.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The context parameter in paio_submit isn't used anyway, so there is no reason
why block drivers should need to remember it. This also avoids passing a Linux
AIO context to paio_submit (which doesn't do any harm as long as the parameter
is unused, but it is highly confusing).
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Sometimes when linking with gcc to get a predictable result you are suggested to also apply the compiler flags to the linker command.

For reference, please read:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Link-Options.htmlSigned-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Serial frames always start with a start bit.
This bit was missing in frame size calculation.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>