Jan Beulich [Tue, 9 Jun 2015 15:32:24 +0000 (16:32 +0100)]
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>
Jan Beulich [Tue, 9 Jun 2015 15:32:00 +0000 (16:32 +0100)]
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>
Jan Beulich [Tue, 9 Jun 2015 15:31:57 +0000 (16:31 +0100)]
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>
Petr Matousek [Wed, 6 May 2015 07:48:59 +0000 (09:48 +0200)]
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>
(cherry picked from commit 4de1422ea306832b6ef2cba34e9febb73dd139a7)
Jan Beulich [Tue, 31 Mar 2015 15:27:45 +0000 (16:27 +0100)]
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>
(cherry picked from commit ab42b4408cb4fc4f869d73218e3d2034e6f5e8ac)
Jan Beulich [Mon, 2 Feb 2015 16:49:59 +0000 (16:49 +0000)]
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>
(cherry picked from commit a4b276b4ce49c8d70dd841ff885b900ec652b994)
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 ]
Andrew Cooper [Wed, 18 Dec 2013 15:25:14 +0000 (15:25 +0000)]
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>
Matthew Daley [Wed, 4 Dec 2013 02:16:18 +0000 (15:16 +1300)]
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)
}
}
Olaf Hering [Tue, 15 Oct 2013 09:42:26 +0000 (11:42 +0200)]
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.
Ian Campbell [Wed, 31 Jul 2013 15:16:16 +0000 (16:16 +0100)]
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.
Ian Jackson [Mon, 17 Jun 2013 16:39:51 +0000 (17:39 +0100)]
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.
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>
Ian Jackson [Tue, 21 May 2013 13:57:23 +0000 (14:57 +0100)]
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)
Alex Bligh [Fri, 15 Mar 2013 18:25:15 +0000 (18:25 +0000)]
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>
Ian Jackson [Fri, 22 Feb 2013 18:04:40 +0000 (18:04 +0000)]
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.
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.
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>
Ian Jackson [Thu, 17 Jan 2013 15:52:16 +0000 (15:52 +0000)]
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>
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. ]
Roger Pau Monne [Thu, 6 Dec 2012 12:35:58 +0000 (12:35 +0000)]
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>
Ian Jackson [Thu, 6 Sep 2012 16:05:30 +0000 (17:05 +0100)]
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>
Frediano Ziglio [Tue, 7 Aug 2012 17:17:27 +0000 (18:17 +0100)]
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>
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
Jan Beulich [Fri, 29 Jun 2012 15:58:05 +0000 (16:58 +0100)]
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.
Jan Beulich [Fri, 29 Jun 2012 15:47:34 +0000 (16:47 +0100)]
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.
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>
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>
Roger Pau Monne [Thu, 7 Jun 2012 18:44:01 +0000 (19:44 +0100)]
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.
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>
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>
Christoph Egger [Thu, 7 Jun 2012 18:35:28 +0000 (19:35 +0100)]
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.
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>
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>
Yang Zhang [Tue, 3 Apr 2012 14:44:48 +0000 (15:44 +0100)]
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.
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
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.
George Dunlap [Mon, 13 Feb 2012 17:00:13 +0000 (17:00 +0000)]
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>
Jan Beulich [Tue, 7 Feb 2012 18:42:56 +0000 (18:42 +0000)]
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()
Jan Beulich [Thu, 5 Jan 2012 17:16:46 +0000 (17:16 +0000)]
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>
Jan Beulich [Thu, 5 Jan 2012 17:15:46 +0000 (17:15 +0000)]
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>
Ian Jackson [Thu, 22 Dec 2011 14:46:31 +0000 (14:46 +0000)]
qemu: clean up MSI-X table handling
This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.
Ian Jackson [Thu, 8 Dec 2011 16:36:03 +0000 (16:36 +0000)]
qemu_get_timer: always read the 64 bit value from the savefile
qemu_get_timer: the 64 bit value needs to be read from the save file
even when the timer is not initialized otherwise following reads from
the savefile will read the wrong fields.
xen: don't initialize the RTC timers if xen is available
Xen doesn't need full RTC emulation in Qemu because the RTC is already
emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
available so that Qemu doesn't need to wake up needlessly.
Ian Jackson [Mon, 28 Nov 2011 17:16:52 +0000 (17:16 +0000)]
qemu-dm: open char devices "file:..." with O_APPEND
The "file:..." character open method is used by serial and parallel
ports, to divert the output to a file (and these devices never produce
any input). This is like a logfile, and so should be opened for
append.
In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Register the vkbd backend even when running as device emulator for HVM
guests: it is useful because it doesn't need a frequent timer like usb.
Check whether the XenInput DisplayState has been set in the initialise
state, rather than the input state.
In case the DisplayState hasn't been set and there is no vfb for this
domain, then set the XenInput DisplayState to the default one.
An equivalent patch has already been committed in upstream qemu.
I have just proposed a patch to add this to xen-unstable.hg as
docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
look for docs, plus we are transitioning to upstream qemu.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Tue, 28 Jun 2011 12:49:35 +0000 (13:49 +0100)]
passthrough: mask out upper bits in vendor id
Making vendor_id u16 eliminates potential bogus upper bits that are
not part of the actual 16-bit vendor ID. On some systems, upper bits
shows up with 0xffff.
mapcache: remember the last page address rather then the last address_index
A single address_index corresponds to multiple pages that might or
might not be mapped. It is better to just remember the last page
address for the sake of this optimization, so that we are sure that it
is mapped.
Ian Jackson [Tue, 1 Feb 2011 17:32:38 +0000 (17:32 +0000)]
vnc, xen: write vnc address and password to xenstore
The xend protocol as actually implemented is:
* xend writes:
/vm/UUID/vncpasswd = "PASS" (n0,rDOMID)
/local/domain/0/backend/vfb/DOMID/0/vncunused = "0" (n0,rDOMID)
/local/domain/0/backend/vfb/DOMID/0/vnc = "1" (n0,rDOMID)
/local/domain/0/backend/vfb/DOMID/0/vnclisten = "ADDR" (n0,rDOMID)
/local/domain/0/backend/vfb/DOMID/0/vncdisplay = "PORT" (n0,rDOMID)
/local/domain/0/backend/vfb/DOMID/0/vncpasswd = "PASS" (n0,rDOMID)
* qemu reads /vm/UUID/vncpasswd and overwrites it with "\0"
* qemu writes
/local/domain/DOMID/console/vnc-port = "PORT" (n0,rDOMID)
* xm vncviewer reads entries from backend/vfb,
as well as console/vnc-port.
Much of this is insane.
xl quite properly does not create anything in backend/vfb for an HVM
domain with no vfb. But xl vncviewer needs to know the port number
and the address and the password.
So, for now, have qemu write these nodes too:
/local/domain/DOMID/console/vnc-listen = "ADDR" (n0,rDOMID)
/local/domain/DOMID/console/vnc-pass = "PASS" (n0,rDOMID)
This corresponds to the protocol actually currently implemented in
libxl.
We will revisit this after the 4.1 release and invent a non-insane
protocol.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
If there are no devices assigned to the domain at boot, we don't read
the default pci passthrough parameters. This patch fixes it. Reading
num_devs is completely useless hence I am removing it.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
qemu-xen: disable buffering on the save file for stubdoms
We need to issue reads with the exact number of bytes to read the
qemu-xen save file, and to do that this patch disables buffering on all
the savevm reads/writes for stubdoms.
[This is pretty horrid; hopefully there will be better solution for 4.2 -iwj]
qemu-xen: use dynticks instead of a static 10ms timeout
Use dynticks instead of polling the timers every 10ms.
This allows a qemu running in dom0 to wake up only when the next timer
goes off (that is every 100ms, because of the buffer_io_timer) instead
of every 10ms.
For the moment stubdoms still run with the old 10ms timeout because
minios doesn't support the posix timer_create interface yet.
Also disable the nographic_timer when CONFIG_DM because it is only
useful with tcg.
Chun Yan Liu [Wed, 5 Jan 2011 23:48:36 +0000 (23:48 +0000)]
fix '|' key display problem in en-us with altgr processing
Commit f95d202ed644 handles altgr-insert problem. Unfortunately, with
that patch, there is a problem in En-us keyboard: '|' (bar) cannot be
displayed. After checking keymap files, we found there are two
definitions to "bar" in en-us: bar 0x56 altgr (in "common") bar 0x2b
shift (in "en-us") First line is actually invalid in en-us
lanuage. The 2nd definition will cover the 1st one.
The previous change in didn't consider multi-definition case. It scans
keymap files, if keysym needs altgr, it will records that, after that,
if keysym is pressed but altgr not pressed, it will add an altgr press
opeartion. It is correct if all keysyms are unique and valid. But in
the above multi-definition case, there is problem: when reading bar
0x56 altgr (in "common") it will record altgr needed, but in fact,
that definition won't be used, it always use the 2nd definition and
won't need altgr. Then if the keysym is pressed, the code will still
add an altgr press operation, that will cause problem.
So, if we cannot avoid multi-definition in keymap files, the altgr
flag (whether altgr needed or not) should also be refreshed according
to the 2nd defintion. In the above case, when reading the 1st line, it
records altgr needed; then reading 2nd line, 2nd definition will cover
the 1st, meanwhile the altgr flag should be reset (the 2nd definition
doesn't need altgr, so altgr flag should be removed.)
Following patch supplements f95d202ed644, and solve the
problem.
Signed-off-by: Chun Yan Liu <cyliu@novell.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
The technique is the same used with MSI: if the guest enables an MSIX
passing 0 as vector number, then read the address and use it as pirq
number for the following mapping request to Xen.
Ian Jackson [Tue, 14 Dec 2010 18:39:14 +0000 (18:39 +0000)]
xenfb: let xenfb_guest_copy() handle dept h=32 case
In hw/xenfb.c, xenfb_guest_copy only handles xenfb->depth=8 and 24
cases, I guess it assumes in xenfb->depth=16 or 32 cases, buffer is
shared. But that's not always the case: the code path that allows us
to have a shared buffer when xenfb->depth=16 or 32 is xenfb->do_resize
set, but on a guest vnc console, when enter CTRL+ALT+2 switch to qemu
monitor console then CTRL+ALT+1 back to guest window, the
xenfb->do_resize is not set, that is, buffer is not shared, and
xenfb_guest_copy does not handle xenfb->depth=32 case, the result is:
guest screen cannot be restored.
To fix above problem, this patch does two things:
1. Set xenfb->do_resize in xenfb_invalidate so that in console switch
case, buffer is shared when xenfb->depth=16 or 32. The screen cannot
be restored bug in above description can be solved.
2. To avoid that other special cases have the same problem, it's
better to let xenfb_guest_copy handle all cases, so add processing to
xenfb->depth=16 and 32 in xenfb_guest_copy.
Signed-off-by: Chun Yan Liu <cyliu@novell.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Jackson [Tue, 23 Nov 2010 17:52:44 +0000 (17:52 +0000)]
xen_disk: backport from upstream qemu
xen_disk is a pure userspace blkback implementation that can be used to
provided a disk backend called qdisk.
It is particularly useful with a dom0 kernel that doesn't have blktap2
(Linux 2.6.37).
[ This is a cherry pick of git commit 62d23efac8905a46277f666c909e826f91c12aa1
aka git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7223 c046a42c-6fe2-441c-8c8c-71466251a162
originally from Gerd Hoffman and Anthony Ligouri, edited
by Stefano to fit into current qemu-xen-unstable. -iwj ]
Ian Jackson [Tue, 23 Nov 2010 16:40:08 +0000 (16:40 +0000)]
qemu-xen: build adjustments to support out-of-tree builds
QEMU by itself can be built outside of its source directory. With the
qemu repository being separate from the hypervisor/tools one it seems
to make sense to make use of this feature, but doing so requires a
couple of adjustments to the Xen changes to it. Basically, if
CONFIG_QEMU is found to indicate an existing directory, this directory
will be used rather than cloning the git repo into the build tree.
projects / qemu-xen-4.5-testing.git / log