block-vvfat: fix memory leak in check_directory_consistency()

Memory pointed by cluster leaks in error handling code.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-ID: 1055917
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

block-vvfat: fix memory/handle leaks in commit_one_file()

Some handles and memory in commit_one_file are going to be leaked if
certain function calls failed.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-IDs: 1055918 1055919
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

net: Fix memory/handle leaks in net_socket_listen_init()

fd and s could be leaked in case bind/listen failed.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-IDs: 1055923 1055924
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

net: don't leak an fd after an error

fd will be leaked if launch_script failed.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-ID: 1055925
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

hw/ide: fix memory leak from qemu_allocate_irqs()

qemu_allocate_irqs would return an array of irqs, not store the allocated
array pointer, and subsequently leak it.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
(defects not identified by Coverity Scan)
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

qemu-char: fix memory leak in qemu_char_open_pty()

The momery pointed by s and chr could be leaked if openpty return a value
less then 0.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-IDs: 1055926 1055927
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

hw/device-hotplug: fix test of drive_add() return

drive_opt_idx could be -1 in case error occurs inside drive_add, so the error
check should be "if (drive_opt_idx < 0)" instead of original
"if (!drive_opt_idx)".

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-ID: 1055574
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

console: Avoid overrunning the dmask arrays

The valide range of font_data should be [0, 0xFF].

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
(defects not identified by Coverity Scan)
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

block-cow: don't close cow_fd twice on error

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-ID: 1056200
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

readline: fix memory corruption when adding history

idx can be down to 0, so TERM_MAX_CMDS-idx+1 could be TERM_MAX_CMDS+1, which
exceeds the size of term_history.

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Coverity-ID: 1055739
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

hw/msmouse.c: Fix deref_after_free and double free

msmouse_chr_close is only pointed by chr->chr_close in qemu_chr_close
function. After calling chr->chr_close, chr will be freed. So we don't
need to free it again here.

Signed-off-by: Yunlei Ding <yunlei.ding@citrix.com>
(defect not identified by Coverity Scan)
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

signal: Don't use uninitalised sival_ptr

In 64bit builds, setting sival_int to 0 doesn't clear the upper half of the
sival_ptr pointer.  Valgrind does not like this.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

pic: Don't allocate irq buffers

i8259_init() doesn't inspect its argument at all, causing the allocation to
be leaked and never used.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

smbios: Don't allocate smbus eeprom buffer

smbus_eeprom_device_init() has been disabled since 2007.  The #define turns
the actual function call into a comma expression with no effect.

Removing the leaked allocation also makes Valgrind happier.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-ID: 1090387

cmdline: Parse -pciemulation before trying to use it

Signed-off-by: Kaifeng Zhu <kaifeng.zhu@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

dma: fix incorrect bh scheduling

The following 2 cases should be avoided:

  1. DMAAIOCB has been released but continue_after_map_failure
     schedules a bh for it.
  2. Multiple bh calls are schduled on the same DMAAIOCB.

Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

ide: cancel dma operations on command abort or error

Otherwise, a guest can cause Qemu to reuse an active aio structure.

Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

cirrus_vga: fix division by 0 for color expansion rop

Commit d85d0d3883f5a567fa2969a0396e42e0a662b3fa introduces a regression
with Windows ME that leads to a division by 0 and a crash.

It uses the color expansion rop with the source pitch set to 0. This is
something allowed, as the manual explicitely says "When the source of
color-expand data is display memory, the source pitch is ignored.".

This patch fixes this regression by computing sx, sy and others
variables only if they are going to be used later, that is for a plain
copy ROP. It basically consists in moving code.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

CVE-2014-3615: vbe: rework sanity checks

Backport of qemu-upstream:
 * c1b886c45dc70f247300f549dce9833f3fa2def5

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

CVE-2014-7815: vnc: sanitize bits_per_pixel from the client

Backport of qemu-upstream:
 * e6908bfe8e07f2b452e78e677da1b45b1c0f6829

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

CVE-2014-8106: cirrus: fix blit region check

Backport of qemu-upstream:
 * bf25983345ca44aec3dd92c57142be45452bd38a
 * d3532a0db02296e687711b8cdc7791924efccea0

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

usb-linux.c: fix buffer overflow

In usb-linux.c:usb_host_handle_control, we pass a 1024-byte buffer and
length to the kernel.  However, the length was provided by the caller
of dev->handle_packet, and is not checked, so the kernel might provide
too much data and overflow our buffer.

For example, hw/usb-uhci.c could set the length to 2047.
hw/usb-ohci.c looks like it might go up to 4096 or 8192.

This causes a qemu crash, as reported here:
  http://www.mail-archive.com/kvm@vger.kernel.org/msg18447.html

This patch increases the usb-linux.c buffer size to 2048 to fix the
specific device reported, and adds a check to avoid the overflow in
any case.

Signed-off-by: Jim Paris <jim@jtan.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

block-vvfat: fix fat_chksum() buffer overrun warning

Newer GCC versions raise an undefined behaviour warning in
fat_chksum() because it overruns the name buffer.  However, this is
intentional behaviour because the extension array immediately follows.

Refactor this function to avoid the warning and make it clear it's
checksumming both parts.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-ID: 1055738

lm832x: don't overrun file buffer on save/restore

Saving and restoring an lm832x record would overrun the pwm.file array
since pwm.file is uint16_t elements and sizeof(pwm.file) twice as many
elements.

To ensure compatibility, padding bytes are added to the record.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055728 1055729

cirrus_vga: default all I/O port reads to 0xff

Some error paths in vga_ioport_read() would return undefined values.
Always default the result to 0xff.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

virtio-blk: initialise unused blkcfg.size_max field

Newer GCC warns about memcpy()ing uninitialised data.

Signed-off-by: Yunlei Ding <yunlei.ding@citrix.com>
Coverity-ID: 1056088
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Fix build after "ui/vnc: limit client_cut_text msg payload size"

That backport (which also erroneously refers to ui/vnc.c rather than
vnc.c in its commit message) broke the build because we do not have
`error_report'.  Use fprintf to stderr, like the rest of the file.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

ui/vnc: limit client_cut_text msg payload size

currently a malicious client could define a payload
size of 2^32 - 1 bytes and send up to that size of
data to the vnc server. The server would allocated
that amount of memory which could easily create an
out of memory condition.

This patch limits the payload size to 1MB max.

Please note that client_cut_text messages are currently
silently ignored.

Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit f9a70e79391f6d7c2a912d785239ee8effc1922d)
Conflicts:
ui/vnc.c

Dropped { } style changes.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

HVM: atomically access pointers in bufioreq handling

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 the intention is for Xen to assume default servers
always use suitable atomic accesses) went in already (commit
b7007bc6f9).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: Adjust description.

ide: Clear DRQ after handling all expected accesses

This is additional hardening against an end_transfer_func that fails to
clear the DRQ status bit. The bit must be unset as soon as the PIO
transfer has completed, so it's better to do this in a central place
instead of duplicating the code in all commands (and forgetting it in
some).

[ This is XSA-138 / CVE-2015-5154. ]

Signed-off-by: Kevin Wolf <kwolf@redhat.com>

ide: Check array bounds before writing to io_buffer (CVE-2015-5154)

If the end_transfer_func of a command is called because enough data has
been read or written for the current PIO transfer, and it fails to
correctly call the command completion functions, the DRQ bit in the
status register and s->end_transfer_func may remain set. This allows the
guest to access further bytes in s->io_buffer beyond s->data_end, and
eventually overflowing the io_buffer.

One case where this currently happens is emulation of the ATAPI command
START STOP UNIT.

This patch fixes the problem by adding explicit array bounds checks
before accessing the buffer instead of relying on end_transfer_func to
function correctly.

[ This is XSA-138 / CVE-2015-5154. ]

Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>

pcnet: force the buffer access to be in bounds during tx

4096 is the maximum length per TMD and it is also currently the size of
the relay buffer pcnet driver uses for sending the packet data to QEMU
for further processing. With packet spanning multiple TMDs it can
happen that the overall packet size will be bigger than sizeof(buffer),
which results in memory corruption.

Fix this by only allowing to queue maximum sizeof(buffer) bytes.

This is CVE-2015-3209.

Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Reported-by: Matt Tait <matttait@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

pcnet: fix Negative array index read

s->xmit_pos maybe assigned to a negative value (-1),
but in this branch variable s->xmit_pos as an index to
array s->buffer. Let's add a check for s->xmit_pos.

upstream-commit-id: 7b50d00911ddd6d56a766ac5671e47304c20a21b

Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

... by default. Add a per-device "permissive" mode similar to pciback's
to allow restoring previous behavior (and hence break security again,
i.e. should be used only for trusted guests).

This is part of XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>)

Since the next patch will turn all not explicitly described fields
read-only by default, those fields that have guest writable bits need
to be given explicit descriptors.

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

The adjustments are solely to make the subsequent patches work right
(and hence make the patch set consistent), namely if permissive mode
(introduced by the last patch) gets used (as both reserved registers
and reserved fields must be similarly protected from guest access in
default mode, but the guest should be allowed access to them in
permissive mode).

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

This is just to avoid having to adjust that calculation later in
multiple places.

Note that including ->ro_mask in get_throughable_mask()'s calculation
is only an apparent (i.e. benign) behavioral change: For r/o fields it
doesn't matter > whether they get passed through - either the same flag
is also set in emu_mask (then there's no change at all) or the field is
r/o in hardware (and hence a write won't change it anyway).

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
emu_mask variable - we can have the same effect by setting the field
descriptor's emu_mask member suitably right away. Note that
xen_pt_pmcsr_reg_write() is being retained in order to allow later
patches to be less intrusive.

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Without this the actual XSA-131 fix would cause the enable bit to not
get set anymore (due to the write back getting suppressed there based
on the OR of emu_mask, ro_mask, and res_mask).

Note that the fiddling with the enable bit shouldn't really be done by
qemu, but making this work right (via libxc and the hypervisor) will
require more extensive changes, which can be postponed until after the
security issue got addressed.

This is a preparatory patch for XSA-131.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

... to avoid allowing the guest to cause the control domain's disk to
fill.

This is XSA-130.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

It's being used by the hypervisor. For now simply mimic a device not
capable of masking, and fully emulate any accesses a guest may issue
nevertheless as simple reads/writes without side effects.

This is XSA-129.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

The old logic didn't work as intended when an access spanned multiple
fields (for example a 32-bit access to the location of the MSI Message
Data field with the high 16 bits not being covered by any known field).
Remove it and derive which fields not to write to from the accessed
fields' emulation masks: When they're all ones, there's no point in
doing any host write.

This fixes a secondary issue at once: We obviously shouldn't make any
host write attempt when already the host read failed.

This is XSA-128.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

fdc: force the fifo access to be in bounds of the allocated buffer

During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.

Fix this by making sure that the index is always bounded by the
allocated memory.

This is XSA-133 / CVE-2015-3456.

Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>

qemu-trad: xenstore: use relative path for device-model node

For QEMU traditional running in Dom0, there is no functional change
because it will still write to the same /local/domain/0 path.

For QEMU traditional stubdom, this is an incompatible startup
protocol change.  There is a corresponding libxl changeset "libxl:
use new QEMU xenstore protocol", which has not yet been committed
(54c2e621 was reverted in 84066dd4).

QEMU traditional stubdom was broken by a0731cca "ioreq-server: on-demand
creation of ioreq server" in 4.5. Currently there is a workaround in
-unstable dd748d12 "x86/hvm: wait for at least one ioreq server to be
enabled" (which should be backported to 4.5). QEMU traditional stubdom
works with that workaround in -unstable but it's not ideal situation.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

xen: limit guest control of PCI command register

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses (by disabling memory and/or I/O decoding
and subsequently causing [CPU side] accesses to the respective address
ranges), which (depending on system configuration) may be fatal to the
host.

This is CVE-2015-2756 / XSA-126.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

cirrus: fix an uninitialized variable

Noticed by paying attention to a compiler warning (reported for the
only caller of the function modified, vga_ioport_read()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-xen-trad: Switch to $(LIBEXEC_BIN) from $(LIBEXEC)

The meaning of LIBEXEC in the Xen build system has been made to
follow the more conventional meaning.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-xen-trad: -I tools/libxc/include and tools/xenstore/include

The public libxc and xenstore headers have been moved to
tools/libxc/include and tools/xenstore/include respectively: change the
Makefiles accordingly.

qemu-xen-trad: free all the pirqs for msi/msix when driver unloads

Pirqs are not freed when driver unloads, then new pirqs are allocated when
driver reloads. This could exhaust pirqs if do it in a loop.

This patch fixes the bug by freeing pirqs when ENABLE bit is cleared in
msi/msix control reg.

There is also other way of fixing it such as reuse pirqs between driver reload,
but this way is better.
Xen-devel: http://marc.info/?l=xen-devel&m=136800120304275&w=2

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[ This is the qemu-xen-trad version of qemu-xen-upstream
  1d4fd4f0e2fc5dcae0c60e00cc9af95f52988050 -iwj ]

qemu-traditional: Fix build warnings on Wheezy

  CC    i386-dm/eepro100.o
hw/eepro100.c: In function ‘eepro100_read4’:
hw/eepro100.c:1232:5: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
hw/eepro100.c: In function ‘eepro100_read2’:
hw/eepro100.c:1202:5: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
hw/eepro100.c: In function ‘eepro100_read1’:
hw/eepro100.c:1179:5: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Use ~0 to match the behaviour of real hardware.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

xen_disk: fix memory leak

On ioreq_release the full ioreq was memset to 0, losing all the data
and memory allocations inside the QEMUIOVector, which leads to a
memory leak. Create a new function to specifically reset ioreq.

Reported-by: Maik Wessler <maik.wessler@yahoo.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Backport to qemu-xen-traditional.

Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

hw/piix4acpi: Make writes to ACPI_DBG_IO_ADDR actually work.

The ACPI AML code has little snippets where it uses two
memory locations to stash debug information when doing PCI
hotplug, such as:

Device (S20)
{
    Name (_ADR, 0x00040000)
    Name (_SUN, 0x04)
    Method (_EJ0, 1, NotSerialized)
    {
Store (0x20, \_GPE.DPT1)
Store (0x88, \_GPE.DPT2)
Store (One, \_GPE.PH20)
    }

    Method (_STA, 0, NotSerialized)
    {
Store (0x20, \_GPE.DPT1)
Store (0x89, \_GPE.DPT2)
    }
}

and DPT1 (and DPT2) is defined as:

OperationRegion ( DG1, SystemIO, 0xb044, 0x04 )
Field ( DG1, ByteAcc, NoLock, Preserve ) {
    DPT1, 8, DPT2, 8
}

But unfortunately when we do the writes they are done
as byte writes, not as 4-byte writes (long). Hence
any debug values are never show in QEMU.

This fixes it so that we can see them in the log file.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-traditional: do not strip binaries during make install

It is wrong to strip code during make install, unless explicit
requested. Introduce a new variable INSTALL_PROG and use it along with
an optional STRIP_OPT where currently install -s -m 755 is used.
This is what upstream qemu offers in version 1.6.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

qemu-xen-traditional: allow build without blktap1

I intend this to become optional at the xen build level so it needs to become
optional here. Until the matching Xen patch is applied and exports
CONFIG_BLKTAP1=y|n there should be no change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

passthrough: Correctly expose PCH ISA bridge for IGD passthrough

The i915 driver probes chip version through PCH ISA bridge device / vendor ID.
Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in qemu-xen-trad,
which breaks the assumption of the driver. This change fixes the issue by
correctly exposing the ISA bridge to domU.

Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>

qemu-xen-traditional: disable docs

Perl 5.18 is unhappy with the qemu-xen-traditional documents, giving
this error:
  qemu.pod around line 91: Non-ASCII character seen before =encoding in
  'Schuetz.'. Assuming UTF-8 POD document had syntax errors at /usr/bin/core_pe\
rl/pod2man line 71.
  make[3]: *** [qemu.1] Error 255

We do not want these docs.  They are not really relevant to Xen users.
So instead of backporting the utf-8 fix from qemu upstream
(3179d694a8dcaa091131e3db644d445c0130713e), we just disable the docs
build.

We do this in xen-hooks.mak because qemu-xen-traditional's configure
script lacks the ability to explicitly disable the docs build.

(The docs build for upstream-based qemu-xen was already disabled by
xen.git#a0d110801d701c43e7b8c73dbd6b2444a10a7cdb)

Reported-by: jacek burghardt <jaceksburghardt@gmail.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (re 4.3 release)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Signed-off-by: Olaf Hering <olaf@aepfle.de>
CC: Eric Shelton <eshelton@pobox.com>
CC: Matt Wilson <msw@amazon.com>
CC: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu> (for 4.3 release)

piix4acpi, xen, hotplug: Fix race with ACPI AML code and hotplug.

This is a race so the amount varies but on a 4PCPU box
I seem to get only ~14 out of 16 vCPUs I want to online.

The issue at hand is that QEMU xenstore.c hotplug code changes
the vCPU array and triggers an ACPI SCI for each vCPU
online/offline change. That means we modify the array of vCPUs
as the guests ACPI AML code is reading it - resulting in
the guest reading the data only once and not changing the
CPU states appropiately.

The fix is to seperate the vCPU array changes from the ACPI SCI
notification. The code now will enumerate all of the vCPUs
and change the vCPU array if there is a need for a change.
If a change did occur then only _one_ ACPI SCI pulse is sent
to the guest. The vCPU array at that point has the online/offline
modified to what the user wanted to have.

Specifically, if a user provided this command:
 xl vcpu-set latest 16

(guest config has vcpus=1, maxvcpus=32) QEMU and the guest
(in this case Linux) would do:

QEMU:                                           Guest OS:
-xenstore_process_vcpu_set_event
 -> Gets an XenBus notification for CPU1
 -> Updates the gpe_state.cpus_state bitfield.
        -> Pulses the ACPI SCI
                                                - ACPI SCI kicks in

 -> Gets an XenBus notification for CPU2
 -> Updates the gpe_state.cpus_state bitfield.
        -> Pulses the ACPI SCI

 -> Gets an XenBus notification for CPU3
 -> Updates the gpe_state.cpus_state bitfield.
        -> Pulses the ACPI SCI
   ...
                                                 - Method(PRST) invoked

 -> Gets an XenBus notification for CPU12
 -> Updates the gpe_state.cpus_state bitfield.
        -> Pulses the ACPI SCI
                                                  - reads AF00 for CPU state
                                                    [gets 0xff]
                                                  - reads AF02 [gets 0x7f]

 -> Gets an XenBus notification for CPU13
 -> Updates the gpe_state.cpus_state bitfield.
        -> Pulses the ACPI SCI

        .. until VCPU 16
                                                 - Method PRST updates
                                                   PR01 through 13 FLG
                                                   entry.
                                                 - PR01->PR13 _MAD
                                                   invoked.

                                                 - Brings up 13 CPUs.

While QEMU updates the rest of the cpus_state bitfields the ACPI AML
only does the CPU hotplug on those it had read.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)

piix4acpi, xen: Clarify that the qemu_set_irq calls just do an IRQ pulse.

The "qemu_cpu_notify" raises and lowers the ACPI SCI line when the
vCPU state has changed.

Instead of doing the two functions, just use one function that
describes exactly what it does.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)

piix4acpi, xen, vcpu hotplug: Split the notification from the changes.

This is a prepatory patch that splits the notification
of an vCPU change from the actual changes to the vCPU array.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)

xen: Disable use of O_DIRECT by default as it results in crashes.

Due to what is almost certainly a kernel bug, writes with O_DIRECT may
continue to reference the page after the write has been marked as
completed, particularly in the case of TCP retransmit. In other
scenarios, this "merely" risks data corruption on the write, but with
Xen pages from domU are only transiently mapped into dom0's memory,
resulting in kernel panics when they are subsequently accessed.

This brings PV devices in line with emulated devices.  Removing
O_DIRECT is safe as barrier operations are now correctly passed
through.

See:
  http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
for more details.

Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Backported to qemu-xen-unstable,
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Revert "passthrough: Correctly expose PCH ISA bridge for IGD passthrough"

This reverts commit bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de.

Revert-requested-by: Jan Beulich <JBeulich@suse.com>

passthrough: Correctly expose PCH ISA bridge for IGD passthrough

Fix IGD passthrough logic to properly expose PCH ISA bridge (instead
of exposing as pci-pci bridge). The i915 driver require this to
correctly detect the PCH version and enable version specific code
path.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Timothy Guo <firemeteor@users.sourceforge.net>

qemu-xen-trad/pt_msi_disable: do not clear all MSI flags

"qemu-xen-trad: fix msi_translate with PV event delivery" added a
pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags
as a consequence. MSIs get enabled again soon after by calling
pt_msi_setup.

However the MSI flags are only setup once in the pt_msgctrl_reg_init
function, so from the QEMU point of view the device has lost some
important properties, like for example PCI_MSI_FLAGS_64BIT.

This patch fixes the bug by clearing only the MSI
enabled/mapped/initialized flags in pt_msi_disable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: G.R. <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135489879503075

cpu_ioreq_pio, cpu_ioreq_move: introduce read_phys_req_item, write_phys_reqm

The current code compare i (int) with req->count (uint32_t) in a for
loop, risking an infinite loop if req->count is >INT_MAX.  It also
does the multiplication of req->size in a too-small type, leading to
integer overflows.

Turn read_physical and write_physical into two different helper
functions, read_phys_req_item and write_phys_req_item, that take care
of adding or subtracting offset depending on sign.

This removes the formulaic multiplication to a single place where the
integer overflows can be dealt with by casting to wide-enough unsigned
types.

Reported-By: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Dongxiao Xu <dongxiao.xu@intel.com>

e1000: fix compile warning introduced by security fix, and debugging

e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
  hw/e1000.c:641: warning: 'return' with a value, in function returning void

In upstream qemu (where this change came from), e1000_receive returns
a value used by queueing machinery to decide whether to try
resubmitting the packet later.  Returning "size" means that the packet
has been dealt with and should not be retried.

In this old branch (aka qemu-xen-traditional), this machinery is
absent and e1000_receive returns void.  Fix the return statement.

Also add a debugging statement along the lines of the others in this
function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

e1000: Discard oversized packets based on SBP|LPE

Discard packets longer than 16384 when !SBP to match the hardware behavior.

Signed-off-by: Michael Contreras <michael@inetric.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 2c0331f4f7d241995452b99afaf0aab00493334a)
[ This is a security vulnerablity, XSA-41 / CVE-2012-6075 (2nd patch). ]

e1000: Discard packets that are too long if !SBP and !LPE

The e1000_receive function for the e1000 needs to discard packets longer than
1522 bytes if the SBP and LPE flags are disabled. The linux driver assumes
this behavior and allocates memory based on this assumption.

Signed-off-by: Michael Contreras <michael@inetric.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
[ This is a security vulnerability, CVE-2012-6075 / XSA-41. ]

qemu-stubdom: prevent useless medium change

qemu-stubdom was stripping the prefix from the "params" xenstore
key in xenstore_parse_domain_config, which was then saved stripped in
a variable. In xenstore_process_event we compare the "param" from
xenstore (not stripped) with the stripped "param" saved in the
variable, which leads to a medium change (even if there isn't any),
since we are comparing something like aio:/path/to/file with
/path/to/file. This only happens one time, since
xenstore_parse_domain_config is the only place where we strip the
prefix. The result of this bug is the following:

xs_read_watch() -> /local/domain/0/backend/qdisk/19/5632/params hdc
close(7)
close blk: backend=/local/domain/0/backend/qdisk/19/5632
node=/local/domain/19/device/vbd/5632
(XEN) HVM18: HVM Loader
(XEN) HVM18: Detected Xen v4.3-unstable
(XEN) HVM18: Xenbus rings @0xfeffc000, event channel 4
(XEN) HVM18: System requested ROMBIOS
(XEN) HVM18: CPU speed is 2400 MHz
(XEN) irq.c:270: Dom18 PCI link 0 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom18 PCI link 1 changed 0 -> 10
(XEN) HVM18: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom18 PCI link 2 changed 0 -> 11
(XEN) HVM18: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom18 PCI link 3 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 3 routed to IRQ5
(XEN) HVM18: pci dev 01:3 INTA->IRQ10
(XEN) HVM18: pci dev 03:0 INTA->IRQ5
(XEN) HVM18: pci dev 04:0 INTA->IRQ5
(XEN) HVM18: pci dev 02:0 bar 10 size lx: 02000000
(XEN) HVM18: pci dev 03:0 bar 14 size lx: 01000000
(XEN) HVM18: pci dev 02:0 bar 14 size lx: 00001000
(XEN) HVM18: pci dev 03:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 14 size lx: 00000100
(XEN) HVM18: pci dev 01:1 bar 20 size lx: 00000010
(XEN) HVM18: Multiprocessor initialisation:
(XEN) HVM18:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18:  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18: Testing HVM environment:
(XEN) HVM18:  - REP INSB across page boundaries ... passed
(XEN) HVM18:  - GS base MSRs and SWAPGS ... passed
(XEN) HVM18: Passed 2 of 2 tests
(XEN) HVM18: Writing SMBIOS tables ...
(XEN) HVM18: Loading ROMBIOS ...
(XEN) HVM18: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM18:   Relocating to 0xfc001000-0xfc0035bc ... done
(XEN) HVM18: Creating MP tables ...
(XEN) HVM18: Loading Cirrus VGABIOS ...
(XEN) HVM18: Loading PCI Option ROM ...
(XEN) HVM18:  - Manufacturer: http://ipxe.org
(XEN) HVM18:  - Product name: iPXE
(XEN) HVM18: Option ROMs:
(XEN) HVM18:  c0000-c8fff: VGA BIOS
(XEN) HVM18:  c9000-d8fff: Etherboot ROM
(XEN) HVM18: Loading ACPI ...
(XEN) HVM18: vm86 TSS at fc00f680
(XEN) HVM18: BIOS map:
(XEN) HVM18:  f0000-fffff: Main BIOS
(XEN) HVM18: E820 table:
(XEN) HVM18:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM18:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM18:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM18:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM18:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM18:  HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM18:  [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM18: Invoking ROMBIOS ...
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d18 entering stdvga and caching modes
(XEN) HVM18: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM18: Bochs BIOS - build: 06/23/99
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM18: Options: apmbios pcibios eltorito PMM
(XEN) HVM18:
(XEN) HVM18: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM18: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes)
(XEN) HVM18: IDE time out
(XEN) HVM18: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM18: IDE time out
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: Press F12 for boot menu.
(XEN) HVM18:
(XEN) HVM18: Booting from CD-Rom...
(XEN) HVM18: ata_is_ready returned 1
(XEN) HVM18: CDROM boot failure code : 0003
(XEN) HVM18: Boot from CD-Rom failed: could not read the boot disk
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: No bootable device.
(XEN) HVM18: Powering off in 30 seconds.
******************* BLKFRONT for /local/domain/19/device/vbd/5632 **********

backend at /local/domain/0/backend/qdisk/19/5632
Failed to read
/local/domain/0/backend/qdisk/19/5632/feature-flush-cache.
284420 sectors of 512 bytes
**************************
blk_open(/local/domain/19/device/vbd/5632) -> 7

As seen in this trace, the medium change happens just when the
guest is booting, which leads to the guest not being able to boot
because the BIOS is not able to access the device.

This is a regression from Xen 4.1, which is able to boot from "file:/"
based backends when using stubdomains.

[ By inspection, this patch does not change the flow for the
  non-stubdom case. -iwj]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Disable qemu monitor by default.  The qemu monitor is an overly
powerful feature which must be protected from untrusted (guest)
administrators.

Neither xl nor xend expect qemu to produce this monitor unless it is
explicitly requested.

This is a security problem, XSA-19.  Previously it was CVE-2007-0998
in Red Hat but we haven't dealt with it in upstream.  We hope to have
a new CVE for it here but we don't have one yet.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

console: bounds check whenever changing the cursor due to an escape code

This is XSA-17 / CVE-2012-3515

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

qemu-xen-trad: fix msi_translate with PV event delivery

When switching from msitranslate to straight msi we need to make sure
that we respect PV event delivery for the msi if the guest asked for it:

- completely disable MSI on the device in pt_disable_msi_translate;
- then enable MSI again (pt_msi_setup), mapping the correct pirq to it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Rolu <rolu@roce.org>

Revert "qemu-xen-traditional: use O_DIRECT to open disk images for IDE"

This reverts commit 1307e42a4b3c1102d75401bc0cffb4eb6c9b7a38.

In fact after a lengthy discussion, we came up with the conclusion
that WRITEBACK is OK for IDE.
See: http://marc.info/?l=xen-devel&m=133311527009773

Therefore revert this which was committed in error.

mapcache: Fix invalidate if memory requested was not bucket aligned

When memory is mapped in qemu_map_cache with lock != 0 a reverse mapping
is created pointing to the virtual address of location requested.
The cached mapped entry is saved in last_address_vaddr with the memory
location of the base virtual address (without bucket offset).
However when this entry is invalidated the virtual address saved in the
reverse mapping is used. This cause that the mapping is freed but the
last_address_vaddr is not reset.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-traditional: fix no-return-in-nonvoid-function

rpm post-build-checks found a few issues in qemu-xen-traditional and
marks them as errors.

I: Program returns random data in a function
E: xen no-return-in-nonvoid-function savevm.c:215
E: xen no-return-in-nonvoid-function /usr/src/packages/BUILD/xen-4.2.25602/non-dbg/stubdom/ioemu/xenfbfront.c:361

Signed-off-by: Olaf Hering <olaf@aepfle.de>

passthrough: fix off-by-one in PCI config space register index check

Register 255 (0xff) is still valid to be accessed.

Reported-by: Rolu <rolu@roce.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

xendisk: set maximum number of grants to be used

Legacy (non-pvops) gntdev drivers may require this to be done when the
number of grants intended to be used simultaneously exceeds a certain
driver specific default limit.

upstream-commit: 64c27e5b1fdb6d94bdc0bda3b1869d7383a35c65

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

xendisk: properly update stats in ioreq_release()

While for the "normal" case (called from blk_send_response_all())
decrementing requests_finished is correct, doing so in the parse error
case is wrong; requests_inflight needs to be decremented instead.

upstream-commit: ed5477664369c1e9de23b0e7e8f16a418573bd2a

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>

qemu-traditional: disable msitranslate by default

msitranslate is known to cause problems with some device drivers,
because it sets the real device in MSI mode while making the guest think
is actually in legacy interrupts mode. Some drivers are able to spot this
inconsistency and break (Nvidia drivers for example).

Disable the option by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

qemu-xen-trad: fix sys-queue.h usage on BSD systems

BSD systems already have a sys/queue.h file, which has more macros
than the one Qemu uses, and some header files depend on having that
macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
systems and include the native one.

This is not a backport because the original patch is too dificult to
backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.

Doing a diff -bB shows that the Qemu version is just a stripped
version of the original NetBSD header, with many macros removed, but
no new ones added.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-xen-trad/block: get right partition size

use the correct way to get the size of a disk device or partition

This this a backport of d1f6fd8d1400ab356aee776b1ecc3ed1e89dbeaa.

From: Adam Hamsik <haad@netbsd.org>
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Backport-requested-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

qemu-xen-trad/block: use a character device if a block device is given

On NetBSD a userland process is better with the character device
interface. In addition, a block device can't be opened twice; if a Xen
backend opens it, qemu can't and vice-versa.

This is a backport of 1de1ae0a7d956b3c87712bf2c09d277f99873f4c.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Backport-requested-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

xenstore: Use <xenstore.h>

<xs.h> is going away.

This change needs to be made in lockstep with xen-unstable.hg, which
will be done by a change to the QEMU_TAG in the xen-unstable.hg
changeset.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

passthrough: Intel GPU passthrough, fix OpRegion mapping

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).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

timers: use INT64_MAX as max expiration

Currently, the max expiration time is 2147483647ns(INT32_MAX ns). This
is enough when guest is busy, but when guest is idle, the next timer
will be later than INT32_MAX ns. And those meaningless alarm will harm
the pkg C-state.

PS: Since the overflow will not happen with the expression((delta /
1000) + (delta % 1000 > 0 ? 1 : 0)), so i also removed the comments"
To avoid problems with overflow limit this to 2^32."

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

xen: introduce an event channel for buffered io event notifications

Use the newly [November 2011] introduced HVM_PARAM_BUFIOREQ_EVTCHN to
receive notifications for buffered io events.  After the first
notification is received leave the event channel masked and setup a
timer to process the rest of the batch.  Once we have completed
processing the batch, unmask the event channel and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

qemu-xen-traditional: QDISK fixes

- if ioreq->postsync call bdrv_flush when the operation is actually
  completed;
- do not increment aio_inflight when not submitting any operations.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-xen-traditional: use O_DIRECT to open disk images with QDISK

Also enable batch_maps, use_aio and disable syncwrite.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-xen-traditional: use O_DIRECT to open disk images for IDE

[ Major performance fix. -iwj ]

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

qemu-traditional/passthrough: adjust MSI-X device cleanup (bug 1809)

To address http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809,
pt_unregister_regions() also needs to use the newly introduced
_pt_iomem_helper() instead of calling xc_domain_memory_mapping()
directly, to take into consideration the hole created for the MSI-X
table.

For this to work, two calls in unregister_real_device() need to be
swapped, since otherwise we'd have

unregister_real_device()
  -> pt_config_delete()
    -> pt_msix_delete() (frees [and fails to clear] ->msix)
  -> pt_unregister_regions()
    -> _pt_iomem_helper() (with the patch below)
      -> has_msix_mapping() (uses ->msix)

And to be certain to prevent (catch) further/future use-after-free
instances, let's also clear dev->msix in pt_msix_delete().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

qemu-xen: ignore console disconnect events for console/0

The first console has a different location compared to other PV devices
(console, rather than device/console/0) and doesn't obey the xenstore
state protocol. We already special case the first console in con_init
and con_initialise, we should also do it in con_disconnect.

This patch should be applied to 4.1 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Intel GPU passthrough: Host bridge config space

Expose more host bridge config space value to make the driver happy
for all the different revisions of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled

A recent changeset introduced a bug whereby an initialization function
that reads /proc/bus/pci is called from graphics set-up functions even
if pass-through graphics are not enabled.  If qemu is run without
permission to this file, this causes qemu to fail during
initialization.

This patch re-works the functions so that the initialization happens
only if we actually need to do the pci host read or write.  It also
makes failures call abort().

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

qemu-dm: fix unregister_iomem()

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). It's unclear how the function can ever have
fulfilled its purpose: the value returned by iomem_index() is *not* an
index into mmio[].

Additionally, fix two problems:
- unregister_iomem() must not clear mmio[].start, otherwise
  cpu_register_physical_memory() won't be able to re-use the previous
  slot, thus causing a leak
- cpu_unregister_io_memory() must not check mmio[].size, otherwise it
  won't properly clean up entries (temporarily) squashed through
  unregister_iomem()

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>

e1000: bounds packet size against buffer size

Otherwise we can write beyond the buffer and corrupt memory.  This is tracked
as CVE-2012-0029.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(Backported from qemu upstream 65f82df0d7a71ce1b10cd4c5ab08888d176ac840
 by Ian Campbell.)

Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>

block-vbd: update to new mini-os wait queue API (new linked list API)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

qemu-xen: adjust MSI-X related log messages

Several of these messages we coded using line continuation within a
string literal. This is generally not recommended and also lead to odd
sequences of many blanks in the middle of the messages.

The message indicating a discarded write due to MSI-X already being
enabled doesn't need to be issued when a write doesn't actually modify
the current value. Adjust the surrounding logic accordingly, and
eliminate some redundancy as well as the sometimes unnecessary access
to the physical MSI-X table.

Finally, adjust the wording of a few messages to be more precise and/or
more useful.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

qemu-xen: fix sequence of operations in pt_msix_init()

Checking the return value of mmap() must be done before adjusting the
value, otherwise failure may not be detected.

Closing the file handle, on the other hand, can be done before checking
the return value.

Finally, printing the errno value without knowing whether the previous
function actually failed is bogus (and superfluous since a subsequent
message prints the strerror() representaton anyway).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>