- 05 5月, 2014 2 次提交
-
-
由 Gabriel L. Somlo 提交于
Rename the following symbols: - smbios_set_type1_defaults() to the more general smbios_set_defaults(); - bool smbios_type1_defaults to the more general smbios_defaults; - smbios_get_table() to smbios_get_table_legacy(); This patch contains no functional changes. Signed-off-by: NGabriel Somlo <somlo@cmu.edu> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Michael S. Tsirkin 提交于
At the moment, 2.1 and 2.0 machines are identical. As several people are working on incompatible changes to the PC machine, collaboration will be made easier by merging this place-holder. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 14 3月, 2014 1 次提交
-
-
由 Eduardo Habkost 提交于
When on KVM mode, enable x2apic by default on all CPU models. Normally we try to keep the CPU model definitions as close as the real CPUs as possible, but x2apic can be emulated by KVM without host CPU support for x2apic, and it improves performance by reducing APIC access overhead. x2apic emulation is available on KVM since 2009 (Linux 2.6.32-rc1), there's no reason for not enabling x2apic by default when running KVM. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 11 3月, 2014 1 次提交
-
-
由 Michael S. Tsirkin 提交于
Since commit 04920fc0 loader: store FW CFG ROM files in RAM RAM MRs including ROM files in FW CFGs are created and named using the file basename. This becomes problematic if these names are supplied by user, since the basename might not be unique. There are two cases we care about: - option-rom flag. - option ROM for devices. This triggers e.g. when using rombar=0. At the moment we get an assert. E.g qemu -option-rom /usr/share/ipxe/8086100e.rom -option-rom /usr/share/ipxe.efi/8086100e.rom RAMBlock "/rom@genroms/8086100e.rom" already registered, abort! This is a regression from 1.6. For now let's keep it simple and just avoid creating the MRs in case of option ROMs. when using 1.7 machine types, enable option ROMs in RAM to match that version. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 10 3月, 2014 1 次提交
-
-
由 Michael S. Tsirkin 提交于
we put copy of ROMs in MR for migration. but the name rom_in_ram makes one think we load it in guest RAM. Rename has_mr to make intent clearer. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 26 1月, 2014 2 次提交
-
-
由 Michael S. Tsirkin 提交于
Document the logic behind the below/above 4G split. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Gerd Hoffmann 提交于
Map 2G (q35) of memory below 4G, so the RAM pieces are nicely aligned to gigabyte borders. Keep old memory layout for (a) old machine types and (b) in case all memory fits below 4G and thus we don't have to split RAM into pieces in the first place. The later makes sure this change doesn't take away memory from 32bit guests. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 12 12月, 2013 1 次提交
-
-
由 Liu Ping Fan 提交于
Owning to some different hardware design, piix and q35 need different compat. So making them diverge. On q35, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23 can be assigned to hpet as guest chooses. So we introduce intcap property to do that. Consider the compat and piix/q35, we finally have the following value for intcap: For piix, hpet's intcap is hard coded as IRQ2. For pc-q35-1.7 and earlier, we use IRQ2 for compat reason. Otherwise IRQ2, IRQ8, and IRQ16~23 are allowed. Signed-off-by: NLiu Ping Fan <pingfank@linux.vnet.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 10 12月, 2013 2 次提交
-
-
由 Markus Armbruster 提交于
Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs, no version. Best SeaBIOS can do, but we can provide better defaults: manufacturer QEMU, product & version taken from QEMUMachine desc and name. Take care to do this only for new machine types, of course. Note: Michael Tsirkin doesn't trust us to keep values of QEMUMachine member product stable in the future. Use copies instead, and in a way that makes it obvious that they're guest ABI. Note that we can be trusted to keep values of member name, because that has always been ABI. Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Paolo Bonzini 提交于
It doesn't make sense for a region to be INT64_MAX in size: memory core uses UINT64_MAX as a special value meaning "all 64 bit" this is what was meant here. While this should never affect the PC system which at the moment always has < 63 bit size, this makes us hit all kind of corner case bugs with sub-pages, so users are probably better off if we just use UINT64_MAX instead. Reported-by: NLuiz Capitulino <lcapitulino@redhat.com> Tested-by: NLuiz Capitulino <lcapitulino@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 06 12月, 2013 1 次提交
-
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 02 12月, 2013 1 次提交
-
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 22 11月, 2013 1 次提交
-
-
由 Paolo Bonzini 提交于
This causes two slight backwards-incompatibilities between "-M pc-1.5" and 1.5's "-M pc": (1) a fw_cfg file is removed with this patch. This is only a problem if migration stops the virtual machine exactly during fw_cfg enumeration. (2) after migration, a VM created without an explicit "-device pvpanic" will stop reporting panics to management. The first problem only occurs if migration is done at a very, very early point (and I'm not sure it can happen in practice for reasonable-size VMs, since it will likely take more time to send the RAM to destination, than it will take for BIOS to scan fw_cfg). The second problem only occurs if the guest panics _and_ has a guest driver _and_ management knows to look at the crash event, so it is mostly theoretical at this point in time. Thus keep the code simple, and pretend it was never broken. Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 14 11月, 2013 1 次提交
-
-
由 Igor Mammedov 提交于
The BIOS that we ship in 1.7 does not use pci info from host and so far isn't going to use it. Taking in account problems it caused see 9604f70f and to avoid future incompatibility issues, it's safest to disable that interface by default for all machine types including 1.7 as it was never exposed/used by guest. And properly remove/cleanup it during 1.8 development cycle. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 14 10月, 2013 1 次提交
-
-
由 Michael S. Tsirkin 提交于
This adds C code for generating ACPI tables at runtime, imported from seabios git tree commit 51684b7ced75fb76776e8ee84833fcfb6ecf12dd Although ACPI tables come from a system BIOS on real hw, it makes sense that the ACPI tables are coupled with the virtual machine, since they have to abstract the x86 machine to the OS's. This is widely desired as a way to avoid the churn and proliferation of QEMU-specific interfaces associated with ACPI tables in bios code. Notes: As BIOS can reprogram devices prior to loading ACPI tables, we pre-format ACPI tables but defer loading hardware configuration there until tables are loaded. The code structure was intentionally kept as close to the seabios original as possible, to simplify comparison and making sure we didn't lose anything in translation. Minor code duplication results, to help ensure there are no functional regressions, I think it's better to merge it like this and do more code changes in follow-up patches. Cross-version compatibility concerns have been addressed: ACPI tables are exposed to guest as FW_CFG entries. When running with -M 1.5 and older, this patch disables ACPI table generation, and doesn't expose ACPI tables to guest. As table content is likely to change over time, the following measures are taken to simplify cross-version migration: - All tables besides the RSDP are packed in a single FW CFG entry. This entry size is currently 23K. We round it up to 64K to avoid too much churn there. - Tables are placed in special ROM blob (not mapped into guest memory) which is automatically migrated together with the guest, same as BIOS code. - Offsets where hardware configuration is loaded in ACPI tables are also migrated, this is in case future ACPI changes make us rearrange the tables in memory. This patch reuses some code from SeaBIOS, which was originally under LGPLv2 and then relicensed to GPLv3 or LGPLv3, in QEMU under GPLv2+. This relicensing has been acked by all contributors that had contributed to the code since the v2->v3 relicense. ACKs approving the v2+ relicensing are listed below. The list might include ACKs from people not holding copyright on any parts of the reused code, but it's better to err on the side of caution and include them. Affected SeaBIOS files (GPLv2+ license headers added) <http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5949>: src/acpi-dsdt-cpu-hotplug.dsl src/acpi-dsdt-dbug.dsl src/acpi-dsdt-hpet.dsl src/acpi-dsdt-isa.dsl src/acpi-dsdt-pci-crs.dsl src/acpi.c src/acpi.h src/ssdt-misc.dsl src/ssdt-pcihp.dsl src/ssdt-proc.dsl tools/acpi_extract.py tools/acpi_extract_preprocess.py Each one of the listed people agreed to the following: > If you allow the use of your contribution in QEMU under the > terms of GPLv2 or later as proposed by this patch, > please respond to this mail including the line: > > Acked-by: Name <email address> Acked-by: NGerd Hoffmann <kraxel@redhat.com> Acked-by: NJan Kiszka <jan.kiszka@siemens.com> Acked-by: NJason Baron <jbaron@akamai.com> Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com> Acked-by: NGleb Natapov <gleb@redhat.com> Acked-by: NMarcelo Tosatti <mtosatti@redhat.com> Acked-by: NDave Frodin <dave.frodin@se-eng.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NKevin O'Connor <kevin@koconnor.net> Acked-by: NLaszlo Ersek <lersek@redhat.com> Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: NIsaku Yamahata <yamahata@valinux.co.jp> Acked-by: NMagnus Christensson <magnus.christensson@intel.com> Acked-by: NHu Tao <hutao@cn.fujitsu.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Tested-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Tested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 10 9月, 2013 1 次提交
-
-
由 Anthony PERARD 提交于
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 06 9月, 2013 1 次提交
-
-
由 Vincenzo Maffione 提交于
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.pdfSigned-off-by: NVincenzo Maffione <v.maffione@gmail.com> Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines) Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 01 9月, 2013 1 次提交
-
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@redhat.com>
-
- 28 8月, 2013 1 次提交
-
-
由 Markus Armbruster 提交于
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: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 22 8月, 2013 3 次提交
-
-
由 Eduardo Habkost 提交于
It just needs to set has_pvpanic=false after calling it. This way, it won't be a special case anymore. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Armbruster 提交于
Don't explode when the variable is used just a few times, and never changed. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 21 8月, 2013 2 次提交
-
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 13 8月, 2013 2 次提交
-
-
由 Anthony Liguori 提交于
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: NMarkus Armbruster <armbru@redhat.com> Reported-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Marcel Apfelbaum 提交于
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: NMarcel Apfelbaum <marcel.a@redhat.com> Reviewed-by: NHu Tao <hutao@cn.fujitsu.com> Message-id: 1376233843-19410-2-git-send-email-marcel.a@redhat.com Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 12 8月, 2013 3 次提交
-
-
由 Eduardo Habkost 提交于
Commit 41cb383f 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: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Paolo Bonzini 提交于
Move the code to hw/i386, the sole remaining property is available as !pci_enabled. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-id: 1376069702-22330-4-git-send-email-aliguori@us.ibm.com Rebased. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Michael S. Tsirkin 提交于
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: NRichard Henderson <rth@twiddle.net> Reviewed-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 30 7月, 2013 1 次提交
-
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NAndreas Färber <afaerber@suse.de> Message-id: 1375109277-25561-5-git-send-email-imammedo@redhat.com Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 23 7月, 2013 1 次提交
-
-
由 Hu Tao 提交于
And remove variables if possible. Signed-off-by: NHu Tao <hutao@cn.fujitsu.com> [AF: Converted remaining access and renamed to parent_obj] Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 04 7月, 2013 3 次提交
-
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@redhat.com>
-
由 Michael S. Tsirkin 提交于
Will be used to pass hole ranges to guests. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 11 6月, 2013 2 次提交
-
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 13 5月, 2013 1 次提交
-
-
由 Paolo Bonzini 提交于
This reverts commit 9953f882. 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: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NAnthony Liguori <aliguori@us.ibm.com> Message-id: 1368189483-7915-1-git-send-email-pbonzini@redhat.com Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 12 5月, 2013 1 次提交
-
-
由 Dong Xu Wang 提交于
Signed-off-by: NDong Xu Wang <wdongxu@linux.vnet.ibm.com> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
- 07 5月, 2013 1 次提交
-
-
由 Borislav Petkov 提交于
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: NBorislav Petkov <bp@suse.de> [ehabkost: added compat code to disable MOVBE on pc-*-1.4 and older] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 01 5月, 2013 1 次提交
-
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-