- 22 10月, 2014 1 次提交
-
-
由 Peter Maydell 提交于
The function g_assert_cmpint() is not in glib 2.12, which is our current minimum requirement. Rephrase the recently added assertion to avoid it. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NGonglei <arei.gonglei@huawei.com>
-
- 03 10月, 2014 2 次提交
-
-
由 John Snow 提交于
This patch implements the backend for the Q35 board for us to be able to pick up and use drives defined by the -cdrom, -hda, or -drive if=ide shorthand options. Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Message-id: 1412187569-23452-7-git-send-email-jsnow@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 John Snow 提交于
This patch adds the 'units_per_default_bus' property which allows individual boards to declare their desired index => (bus,unit) mapping for their default HBA, so that boards such as Q35 can specify that its default if_ide HBA, AHCI, only accepts one unit per bus. This property only overrides the mapping for drives matching the block_default_type interface. This patch also adds this property to *all* past and present Q35 machine types. This retroactive addition is justified because the previous erroneous index=>(bus,unit) mappings caused by lack of such a property were not utilized due to lack of initialization code in the Q35 init routine. Further, semantically, the Q35 board type has always had the property that its default HBA, AHCI, only accepts one unit per bus. The new code added to add devices to drives relies upon the accuracy of this mapping. Thus, the property is applied retroactively to reduce complexity of allowing IDE HBAs with different units per bus. Examples: Prior to this patch, all IDE HBAs were assumed to use 2 units per bus (Master, Slave). When using Q35 and AHCI, however, we only allow one unit per bus. -hdb foo.qcow2 would become index=1, or bus=0,unit=1. -hdd foo.qcow2 would become index=3, or bus=1,unit=1. -drive file=foo.qcow2,index=5 becomes bus=2,unit=1. These are invalid for AHCI. They now become, under Q35 only: -hdb foo.qcow2 --> index=1, bus=1, unit=0. -hdd foo.qcow2 --> index=3, bus=3, unit=0. -drive file=foo.qcow2,index=5 --> bus=5,unit=0. The mapping is adjusted based on the fact that the default IF for the Q35 machine type is IF_IDE, and units-per-default-bus overrides the IDE mapping from its default of 2 units per bus to just 1 unit per bus. Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Message-id: 1412187569-23452-4-git-send-email-jsnow@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 25 8月, 2014 1 次提交
-
-
由 Michael S. Tsirkin 提交于
commit 868270f2 acpi-build: tweak acpi migration limits broke kernel loading with -kernel/-initrd: it doubled the size of ACPI tables but did not reserve enough memory. As a result, issues on boot and halt are observed. Fix this up by doubling reserved memory for new machine types. Cc: qemu-stable@nongnu.org Reported-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 16 8月, 2014 1 次提交
-
-
由 John Snow 提交于
Currently, the ioapic device can not be found in a qtest environment when requesting "irq_interrupt_in ioapic" via the qtest socket. By mirroring how the ioapic is added in i44ofx (hw/i440/pc_piix.c), as a child of "q35," the device is able to be seen by qtest. Signed-off-by: NJohn Snow <jsnow@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 14 8月, 2014 2 次提交
-
-
由 Markus Armbruster 提交于
pc_fw_cfg_guest_info() never does anything, because has_pci_info is always false. Introduced in commit f8c457b8 "pc: pass PCI hole ranges to Guests", disabled in commit 9604f70f "pc: disable pci-info for 1.6", and hasn't been enabled since. Obviously a dead end. Get of it. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Jan Kiszka 提交于
Yet identical to 2.1. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 29 7月, 2014 1 次提交
-
-
由 Paolo Bonzini 提交于
Changing the ACPI table size causes migration to break, and the memory hotplug work opened our eyes on how horribly we were breaking things in 2.0 already. The ACPI table size is rounded to the next 4k, which one would think gives some headroom. In practice this is not the case, because the user can control the ACPI table size (each CPU adds 97 bytes to the SSDT and 8 to the MADT) and so some "-smp" values will break the 4k boundary and fail to migrate. Similarly, PCI bridges add ~1870 bytes to the SSDT. This patch concerns itself with fixing migration from QEMU 2.0. It computes the payload size of QEMU 2.0 and always uses that one. The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size should always be enough; non-AML tables can change depending on the configuration (especially MADT, SRAT, HPET) but they remain the same between QEMU 2.0 and 2.1, so we only compute our padding based on the sizes of the SSDT and DSDT. Migration from QEMU 1.7 should work for guests that have a number of CPUs other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140. It was already broken from QEMU 1.7 to QEMU 2.0 in the same way, though. Even with this patch, QEMU 1.7 and 2.0 have two different ideas of "-M pc-i440fx-2.0" when there are PCI bridges. Igor sent a patch to adopt the QEMU 1.7 definition. I think distributions should apply it if they move directly from QEMU 1.7 to 2.1+ without ever packaging version 2.0. Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Tested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 18 7月, 2014 1 次提交
-
-
由 Stefan Weil 提交于
arbitary -> arbitrary basicly -> basically Signed-off-by: NStefan Weil <sw@weilnetz.de> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
- 29 6月, 2014 1 次提交
-
-
由 Eduardo Habkost 提交于
For each compat property on PC_Q35_COMPAT_*, there are only two possibilities: * If the device is never instantiated when using a machine other than pc-q35, then the compat property can be safely added to PC_COMPAT_*; * If the device can be instantiated when using a machine other than pc-q35, that means the other machines also need the compat property to be set. That means we don't need separate PC_Q35_COMPAT_* macros at all, today. The hpet.hpet-intcap case is interesting: piix and q35 do have something that emulates different defaults, but the machine-specific default is applied _after_ compat_props are applied, by simply checking if the property is zero (which is the real default on the hpet code). The hpet.hpet-intcap=0x4 compat property can (should?) be applied to piix too, because 0x4 was the default on both piix and q35 before the hpet-intcap property was introduced. Now, if one day we change the default HPET intcap on one of the PC machine-types again, we may want to introduce PC_{Q35,I440FX}_COMPAT macros. But while we don't need that, we can keep the code simple. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com> Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 23 6月, 2014 3 次提交
-
-
由 Don Slutz 提交于
This is a pc & q35 only machine opt. If you add enough PCI devices then all mmio for them will not fit below 4G which may not be the layout the user wanted. This allows you to increase the below 4G address space that PCI devices can use (aka decrease ram below 4G) and therefore in more cases not have any mmio that is above 4G. For example using "-machine pc,max-ram-below-4g=2G" on the command line will limit the amount of ram that is below 4G to 2G. Note: this machine option cannot be used to increase the amount of ram below 4G. Signed-off-by: NDon Slutz <dslutz@verizon.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> MST: fix 32 bit
-
由 Don Slutz 提交于
This is just below_4g_mem_size and above_4g_mem_size which is used later in QEMU. Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NDon Slutz <dslutz@verizon.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Eduardo Habkost 提交于
pc-q35-1.4 was incorrectly using PC_COMPAT_1_4 instead of PC_Q35_COMPAT_1_4. The only side-effect was that the hpet compat property (inherited from PC_Q35_COMPAT_1_7) was missing. Without this patch, pc-q35-1.4 inicorrectly initializes hpet-intcap to 0xff0104 (behavior introduced in QEMU 2.0, by commit 7a10ef51). Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
-
- 19 6月, 2014 4 次提交
-
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NHu Tao <hutao@cn.fujitsu.com> Reviewed-By: NIgor Mammedov <imammedo@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Igor Mammedov 提交于
the link will used later to access device implementing ACPI functions instead of adhoc lookup in QOM tree. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Igor Mammedov 提交于
'etc/reserved-memory-end' will allow QEMU to tell BIOS where PCI BARs mapping could safely start in high memory. Allowing BIOS to start mapping 64-bit PCI BARs at address where it wouldn't conflict with other mappings QEMU might place before it. That permits QEMU to reserve extra address space before 64-bit PCI hole for memory hotplug. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Igor Mammedov 提交于
it will be used for PC specific options/variables Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 28 5月, 2014 1 次提交
-
-
由 Marcel Apfelbaum 提交于
Total removal of QEMUMachineInitArgs struct. QEMUMachineInitArgs's fields are copied into MachineState. Removed duplicated fields from MachineState. All the other changes are only mechanical refactoring, no semantic changes. Signed-off-by: NMarcel Apfelbaum <marcel.a@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> (s390) Reviewed-by: Michael S. Tsirkin <mst@redhat.com> (PC) [AF: Renamed ms -> machine, use MACHINE_GET_CLASS()] Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 07 5月, 2014 1 次提交
-
-
由 Gabriel L. Somlo 提交于
Add the "boilerplate" necessary for subsequent patches to simply drop in compat_props for pc machines 2.0 and older. This patch contains no functional changes. Signed-off-by: NGabriel Somlo <somlo@cmu.edu> Acked-by: NAlexander Graf <agraf@suse.de> Reviewed-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 05 5月, 2014 3 次提交
-
-
由 Gabriel L. Somlo 提交于
Build an aggregate set of smbios tables and an entry point structure. Insert tables and entry point into fw_cfg respectively under "etc/smbios/smbios-tables" and "etc/smbios/smbios-anchor". Machine types <= 2.0 will for now continue using field-by-field overrides to SeaBIOS defaults, but for machine types 2.1 and up we expect the BIOS to look for and use the aggregate tables generated by this patch. Signed-off-by: NGabriel Somlo <somlo@cmu.edu> [ kraxel: fix 32bit build ] Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 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 1 次提交
-
-
由 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>
-