Commit Graph

174 Commits

Author SHA1 Message Date
Jan Kiszka d67f679d99 vmport: Disentangle read handler type from portio
In case the latter may vanish one day, make sure the vmport read handler
type will remain unaffected. This is also conceptually cleaner.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:44 +02:00
Michael S. Tsirkin bc3e6a0d6c pvpanic: initialization cleanup
Avoid use of static variables: PC systems
initialize pvpanic device through pvpanic_init,
so we can simply create the fw_cfg file at that point.
This also makes it possible to skip device
creation completely if fw_cfg is not there, e.g. for xen -
so the ports it reserves are not discoverable by guests.

Also, make pvpanic_init void since callers ignore return
status anyway.

Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-07-04 10:42:51 +03:00
Michael S. Tsirkin f8c457b88d pc: pass PCI hole ranges to Guests
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>
2013-07-04 10:40:56 +03:00
Michael S. Tsirkin 3459a62521 pci: store PCI hole ranges in guestinfo structure
Will be used to pass hole ranges to guests.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-07-04 10:40:56 +03:00
Stefano Stabellini fc744bb10c Revert "xen: start PCI hole at 0xe0000000 (same as pc_init1 and qemu-xen-traditional)"
This reverts commit 9f24a8030a.

The start of the PCI hole is actually set to 0xf0000000 by hvmloader.
In order to retain ABI compatibility with Xen we leave the start of the
PCI hole at 0xf0000000 in QEMU (for Xen) too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2013-06-25 11:59:42 +00:00
Blue Swirl 371a775dc1 Merge branch 'realize-isa.v2' of git://github.com/afaerber/qemu-cpu
* 'realize-isa.v2' of git://github.com/afaerber/qemu-cpu:
  qdev: Drop FROM_QBUS() macro
  isa: QOM'ify ISADevice
  isa: QOM'ify ISABus
  i8259: Convert PICCommonState to use QOM realizefn
  kvm/i8259: QOM'ify some more
  i8259: QOM'ify some more
  i8254: Convert PITCommonState to QOM realizefn
  kvm/i8254: QOM'ify some more
  i8254: QOM'ify some more
  isa: Use realizefn for ISADevice
  cs4231a: QOM'ify some more
  gus: QOM'ify some more
2013-06-15 10:53:44 +00:00
Eduardo Habkost 6b11322e0f target-i386: Set level=4 on Conroe/Penryn/Nehalem
The CPUID level value on Conroe, Penryn, and Nehalem are too low. This
causes at least one known problem: the -smp "threads" option doesn't
work as expect if level is < 4, because thread count information is
provided to the guest on CPUID[EAX=4,ECX=2].EAX

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-06-10 23:33:18 +02:00
Eduardo Habkost ffce9ebbb6 target-i386: Update model values on Conroe/Penryn/Nehalem CPU models
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>
2013-06-10 23:33:18 +02:00
Andreas Färber 4a17cc4f28 isa: QOM'ify ISADevice
Rename its parent field and use DEVICE() where necessary.

Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-06-07 14:55:33 +02:00
Anthony Liguori 8819c10b5d Merge remote-tracking branch 'sstabellini/xen_fixes_20130603' into staging
* sstabellini/xen_fixes_20130603:
  xen: use pc_init_pci instead of pc_init_pci_no_kvmclock
  xen: remove xen_vcpu_init
  xen: start PCI hole at 0xe0000000 (same as pc_init1 and qemu-xen-traditional)
  xen_machine_pv: do not create a dummy CPU in machine->init
  main_loop: do not set nonblocking if xen_enabled()
  xen: simplify xen_enabled

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-06-04 14:58:58 -05:00
Stefano Stabellini 9f24a8030a xen: start PCI hole at 0xe0000000 (same as pc_init1 and qemu-xen-traditional)
We are currently setting the PCI hole to start at HVM_BELOW_4G_RAM_END,
that is 0xf0000000.
Start the PCI hole at 0xe0000000 instead, that is the same value used by
pc_init1 and qemu-xen-traditional.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: qemu-stable@nongnu.org
2013-06-03 15:41:27 +00:00
Michael S. Tsirkin 45936c8b79 fw_cfg: move typedef to qemu/typedefs.h
Less header dependencies this way.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-02 18:14:14 +03:00
Laszlo Ersek a88b362c6f refer to FWCfgState explicitly
Currently some places use pointer-to-void even though they mean
pointer-to-FWCfgState. Clean them up.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-02 18:14:02 +03:00
Anthony Liguori 95de21a430 Merge remote-tracking branch 'mjt/trivial-patches' into staging
# By Christophe Lyon (1) and others
# Via Michael Tokarev
* mjt/trivial-patches:
  target-moxie: replace target_phys_addr_t with hwaddr
  Rename hexdump to avoid FreeBSD libutil conflict
  remove some double-includes
  translate: remove redundantly included qemu/timer.h
  Remove twice include of qemu-common.h
  fix /proc/self/maps output

Message-id: 51977B44.1000302@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-22 08:22:36 -05:00
Dmitry Fleytman 644c98587d virtio-net: dynamic network offloads configuration
Virtio-net driver currently negotiates network offloads
on startup via features mechanism and have no ability to
disable and re-enable offloads later.
This patch introduced a new control command that allows
to configure device network offloads state dynamically.
The patch also introduces a new feature flag
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.

Signed-off-by: Dmitry Fleytman <dfleytma@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 20130520081814.GA8162@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-22 07:40:10 -05:00
Michael Tokarev 997aba8e25 remove some double-includes
Some source files #include the same header more than
once for no good reason.  Remove second #includes in
such cases.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2013-05-18 16:35:12 +04:00
Paolo Bonzini 9e1c2ec8fd Revert "pc: Kill the "use flash device for BIOS unless KVM" misfeature"
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>
2013-05-13 09:52:43 -05:00
Andreas Färber b2a856d992 target-i386: Change CPUID model of 486 to 8
This changes the model number of 486 to 8 (DX4) which matches the
feature set presented, and actually has the CPUID instruction.

This adds a compatibility property, to keep model=0 on pc-*-1.4 and older.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[AF: Add compat_props entry]
Tested-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-05-06 19:55:18 +02:00
Igor Mammedov c649983b58 pc: Implement QEMUMachine::hot_add_cpu hook
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-05-01 13:06:07 +02:00
Igor Mammedov 62fc403f11 target-i386: Attach ICC bus to CPU on its creation
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>
2013-05-01 13:06:06 +02:00
Hu Tao 3ab135f346 pvpanic: create pvpanic by default for machine 1.5
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-id: f840042f0e1205041f8feaf0d39ca639884f3a00.1366945969.git.hutao@cn.fujitsu.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-30 10:30:01 -05:00
Markus Armbruster 9953f8822c pc: Kill the "use flash device for BIOS unless KVM" misfeature
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>
2013-04-24 13:23:51 -05:00
Michael S. Tsirkin 0445259ba6 acpi: move declarations from pc.h to acpi.h
Functions defined in acpi/ should be declared in
acpi.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-04-15 15:16:34 +02:00
Paolo Bonzini 0d09e41a51 hw: move headers to include/
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>
2013-04-08 18:13:10 +02:00