Skip to content

Q
Qemu

mirror_resources / Qemu
11 个月 前同步成功

通知 4
Star 0
Fork 0
Q
Qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 02 11月, 2014 4 次提交
  3. 22 10月, 2014 1 次提交
  5. 03 10月, 2014 2 次提交
    • J
      q35/ahci: Pick up -cdrom and -hda options · d93162e1
      由 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>
      d93162e1
    • J
      pc/vl: Add units-per-default-bus property · 16026518
      由 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>
      16026518
  7. 25 8月, 2014 1 次提交
  9. 16 8月, 2014 1 次提交
  11. 14 8月, 2014 2 次提交
  13. 29 7月, 2014 1 次提交
    • P
      pc: hack for migration compatibility from QEMU 2.0 · 07fb6176
      由 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>
      07fb6176
  15. 18 7月, 2014 1 次提交
  17. 29 6月, 2014 1 次提交
    • E
      pc: Move q35 compat props to PC_COMPAT_* · b8f5cfd6
      由 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>
      b8f5cfd6
  19. 23 6月, 2014 3 次提交
  21. 19 6月, 2014 4 次提交
  23. 28 5月, 2014 1 次提交
  25. 07 5月, 2014 1 次提交
  27. 05 5月, 2014 3 次提交
  29. 14 3月, 2014 1 次提交
  31. 11 3月, 2014 1 次提交
    • M
      pc: avoid duplicate names for ROM MRs · ac41881b
      由 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>
      ac41881b
  33. 10 3月, 2014 1 次提交
  35. 26 1月, 2014 2 次提交
  37. 12 12月, 2013 1 次提交
  39. 10 12月, 2013 2 次提交
  41. 06 12月, 2013 1 次提交
  43. 02 12月, 2013 1 次提交
  45. 22 11月, 2013 1 次提交
    • P
      pc: get rid of builtin pvpanic for "-M pc-1.5" · 7839ff59
      由 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>
      7839ff59
  47. 14 11月, 2013 1 次提交
  49. 14 10月, 2013 1 次提交
  51. 10 9月, 2013 1 次提交