# By Anthony PERARD
# Via Stefano Stabellini
* sstabellini/xen-2013-09-09:
pc_q35: Initialize Xen.
pc: Initializing ram_memory under Xen.
Message-id: alpine.DEB.2.02.1309091718030.6397@kaball.uk.xensource.com
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter "mitigation", e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione <v.maffione@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
We have a lot of code duplication between machine types,
this increases with each new machine type
and each new field.
This has already introduced a minor bug: description
for pc-1.3 says "Standard PC" while description for
pc-1.4 is "Standard PC (i440FX + PIIX, 1996)"
which makes you think 1.3 is somehow more standard,
or newer, while in fact it's a revision of the same PC.
This patch addresses this issue by using macros, along
the lines used by PC_COMPAT_X_X - only for
non-property options.
The approach can extend to non-PC machine types.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We set default boot order "cad" in every single machine definition
except "pseries" and "moxiesim", even though very few boards actually
care for boot order, and "cad" makes sense for even fewer.
Machines that care:
* pc and its variants
Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
'c', 'd' and 'n'. Reject all others (fatal with -boot).
* nseries (n800, n810)
Check whether order starts with 'n'. Silently ignored otherwise.
* prep, g3beige, mac99
Extract the first character the machine understands (subset of
'a'..'f'). Silently ignored otherwise.
* spapr
Accept an arbitrary string (vl.c restricts it to contain only
'a'..'p', no duplicates).
* sun4[mdc]
Use the first character. Silently ignored otherwise.
Strip characters these machines ignore from their default boot order.
For all other machines, remove the unused default boot order
alltogether.
Note that my rename of QEMUMachine member boot_order to
default_boot_order and QEMUMachineInitArgs member boot_device to
boot_order has a welcome side effect: it makes every use of boot
orders visible in this patch, for easy review.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It just needs to set has_pvpanic=false after calling it. This way, it
won't be a special case anymore.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Making the older compat functions call the newer compat functions at the
beginning allows the older functions undo what's done by newer compat
functions. e.g.: pc_compat_1_4() will be able to call pc_compat_1_5()
and then set has_pvpanic=false.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Don't explode when the variable is used just a few times, and never
changed.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
ROM files that are put in FW CFG are copied to guest ram, by BIOS, but
they are not backed by RAM so they don't get migrated.
Each time we change two bytes in such a ROM this breaks cross-version
migration: since we can migrate after BIOS has read the first byte but
before it has read the second one, getting an inconsistent state.
Future-proof this by creating, for each such ROM,
an MR serving as the backing store.
This MR is never mapped into guest memory, but it's registered
as RAM so it's migrated with the guest.
Naturally, this only helps for -M 1.7 and up, older machine types
will still have the cross-version migration bug.
Luckily the race window for the problem to trigger is very small,
which is also likely why we didn't notice the cross-version
migration bug in testing yet.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Make 1.4 compat code call the 1.6 one, reducing
code duplication. Add comment explaining why we can't
make 1.4 call 1.5 as usual.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Context matching caused the 'has_pvpanic = true' to be applied to
the 1.6 machine type instead of the 1.5 machine type.
Reported-by: Markus Armbruster <armbru@redhat.com>
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch is based on Hu Tao's:
http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00124.html
No need to hard-code pvpanic as part of the machine.
It can be added with "-device pvpanic" from command line (The next patch).
Anyway, for backport compatibility it is still part of 1.5
machine.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: Hu Tao <hutao@cn.fujitsu.com>
Message-id: 1376233843-19410-2-git-send-email-marcel.a@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Commit 41cb383f42 made a guest-visible
change by adding the PCLMULQDQ bit to Westmere without adding
compatibility code to keep the ABI for older machine-types.
Fix it by adding the missing compat code.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Move the code to hw/i386, the sole remaining property is available
as !pci_enabled.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1376069702-22330-4-git-send-email-aliguori@us.ibm.com
Rebased.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The BIOS that we ship in 1.6 does not use pci info
from host (yet). Several issues turned up
(e.g. around winXP boot crashes). So it's safest to disable that
interface for 1.6 machine types for now, leave it on for 1.7
as we have enough time to fix issues if any.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Message-id: 1375109277-25561-5-git-send-email-imammedo@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
And remove variables if possible.
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
[AF: Converted remaining access and renamed to parent_obj]
Signed-off-by: Andreas Färber <afaerber@suse.de>
This includes some pci enhancements:
Better support for systems with multiple PCI root buses
FW cfg interface for more robust pci programming in BIOS
Minor fixes/cleanups for fw cfg and cross-version migration -
because of dependencies with other patches
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQEcBAABAgAGBQJR2ctmAAoJECgfDbjSjVRpQpAH/Rk00yLrQ2R5ScNa8AL9LeaJ
gVFndBmmuRz4gdhyATx6lzR98ic32iTr0+YR5mL51btgmM5a0bEd/SIu34nXriWj
PsM0wdXfo/oEygdttxhvzJOH17tohRV9xg2WA2d8BEwDzrDyqoQ4J0VJlHlG7u3W
nq4KVDVUpLNQFKG8ZgJ2vW0WMw/mBSj2rluhQUALhcuvChphtvAFZ2rsSfJr6bzD
aBELrtIvfLvPGN/0WVeYs9qlp4EE03H3X6gN61QvV3/YElxubKUV5XyMDOX2dW3D
2j0NQi84LYHn0SFap2r/Kgm47/F6Q56SFk5lrgZrg60mhQTwocw7PfL8CGxjXRI=
=gxxc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'mst/tags/for_anthony' into staging
pci,misc enhancements
This includes some pci enhancements:
Better support for systems with multiple PCI root buses
FW cfg interface for more robust pci programming in BIOS
Minor fixes/cleanups for fw cfg and cross-version migration -
because of dependencies with other patches
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Sun 07 Jul 2013 03:11:18 PM CDT using RSA key ID D28D5469
# gpg: Can't check signature: public key not found
# By David Gibson (10) and others
# Via Michael S. Tsirkin
* mst/tags/for_anthony:
pci: Fold host_buses list into PCIHostState functionality
pci: Remove domain from PCIHostBus
pci: Simpler implementation of primary PCI bus
pci: Add root bus parameter to pci_nic_init()
pci: Add root bus argument to pci_get_bus_devfn()
pci: Replace pci_find_domain() with more general pci_root_bus_path()
pci: Use helper to find device's root bus in pci_find_domain()
pci: Abolish pci_find_root_bus()
pci: Move pci_read_devaddr to pci-hotplug-old.c
pci: Cleanup configuration for pci-hotplug.c
pvpanic: fix fwcfg for big endian hosts
pvpanic: initialization cleanup
MAINTAINERS: s/Marcelo/Paolo/
e1000: cleanup process_tx_desc
pc_piix: cleanup init compat handling
pc: pass PCI hole ranges to Guests
pci: store PCI hole ranges in guestinfo structure
range: add Range structure
Message-id: 1373228271-31223-1-git-send-email-mst@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Guest currently has to jump through lots of hoops to guess the PCI hole
ranges. It's fragile, and makes us change BIOS each time we add a new
chipset. Let's report the window in a ROM file, to make BIOS do exactly
what QEMU intends.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The CPUID model values on Conroe, Penryn, and Nehalem are too
conservative and don't reflect the values found on real Conroe, Penryn,
and Nehalem CPUs.
This causes at least one known problems: Windows XP disables sysenter
when (family == 6 && model <= 2), but Skype tries to use the sysenter
instruction anyway because it is reported as available on CPUID, making
it crash.
This patch sets appropriate model values that correspond to real Conroe,
Penryn, and Nehalem CPUs.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Some CPU model fixes are going to be included and they will require
compatibility properties in the pc-*-1.5 machine-types.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This reverts commit 9953f8822c.
While Markus's analysis is entirely correct, there are 1.6 patches
that fix the bug for real and without requiring machine type hacks.
Let's think of the children who will have to read this code, and
avoid a complicated mess of semantics that differ between <1.5,
1.5, and >1.5.
Conflicts:
hw/i386/pc_piix.c
hw/i386/pc_q35.c
include/hw/i386/pc.h
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1368189483-7915-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The Atom core (cpu name "n270" in QEMU speak) supports MOVBE. This is
needed when booting 3.8 and later linux kernels built with the MATOM
target because we require MOVBE in order to boot properly now.
Signed-off-by: Borislav Petkov <bp@suse.de>
[ehabkost: added compat code to disable MOVBE on pc-*-1.4 and older]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
X86CPU should have parent bus so it could provide bus for child APIC.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Provides a hotpluggable bus for APIC and CPU.
* icc-bridge will serve as a parent for icc-bus and provide
mmio mapping services to child icc-devices.
* icc-device will replace SysBusDevice as a parent of APIC
and IOAPIC devices.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Use of a flash memory device for the BIOS was added in series "[PATCH
v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1.
Flash vs. ROM is a guest-visible difference. Thus, flash use had to
be suppressed for machine types pc-1.0 and older. This was
accomplished by adding a dummy device "pc-sysfw" with property
"rom_only":
* Non-zero rom_only means "use ROM". Default for pc-1.0 and older.
* Zero rom_only means "maybe use flash". Default for newer machines.
Not only is the dummy device ugly, it was also retroactively added to
the older machine types! Fortunately, it's not guest-visible (thus no
immediate guest ABI breakage), and has no vmstate (thus no immediate
migration breakage). Breakage occurs only if the user unwisely
enables flash by setting rom_only to zero. Patch review FAIL #1.
Why "maybe use flash"? Flash didn't (and still doesn't) work with
KVM. Therefore, rom_only=0 really means "use flash, except when KVM
is enabled, use ROM". This is a Bad Idea, because it makes enabling/
disabling KVM guest-visible. Patch review FAIL #2.
Aside: it also precludes migrating between KVM on and off, but that's
not possible for other reasons anyway.
Fix as follows:
1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts,
or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything
for older machines (to remain bug-compatible).
2. Change the default value from 0 to 1 for these machines.
Necessary, because 0 doesn't work with KVM. Once it does, we can flip
the default back to 0.
3. Don't revert the retroactive addition of device "pc-sysfw" to older
machine types. Seems not worth the trouble.
4. Add a TODO comment asking for device "pc-sysfw" to be dropped once
flash works with KVM.
Net effect is that you get a BIOS ROM again even when KVM is disabled,
just like for machines predating the introduction of flash.
To get flash instead, use "--global pc-sysfw.rom_only=0".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
