Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 19 11月, 2011 2 次提交
  3. 18 11月, 2011 6 次提交
    • M
      pseries: Fix qdev.id handling in the VIO bus code · 1e34d859
      由 Michael Ellerman 提交于 
      When the user creates a device on the command line with -device, they
can specify the id, using id=foo. Currently the VIO bus code overwrites
this id with it's own value. We should only set qdev.id if it is not
already set by the user.

The device tree code uses qdev.id for the device tree node name, however
we can't rely on the user specifiying the id using proper device tree
syntax, ie. device@reg. So separate the device tree node name from the
qdev.id, but use the same syntax, so they will match by default.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      1e34d859
    • D
      pseries: Allow kernel's early debug output to work · 3feef8ad
      由 David Gibson 提交于 
      The PAPR specification defines a virtual TTY/console interface for guest
OSes to use via the H_PUT_TERM_CHAR and H_GET_TERM_CHAR hypercalls.  There
can be multiple virtual ttys, so these take a "termno" parameter.  This
encodes which vty to use as the 'reg' property on the device tree node
associated with that vty.

However, with the early debug options enabled, the Linux kernel will
attempt debugging output through the vty very early, before it has read
the device tree.  In this case it always uses a termno of 0.  This works
on the existing PowerVM hypervisor, so we assume there must be a hack /
feature in there which interprets termno==0 to mean the default primary
console.

To help with debugging kernels, including existing distribution kernels,
this patch implements a similar feature / hack in qemu.  If termno==0
is supplied to H_{GET,PUT}_TERM_CHAR, they use the first available vty
device instead.

We need to be careful in the case that the user has manually created
an spapr-vty at address 0. So first we search for the specified reg and
only if that doesn't match do we fall back.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      3feef8ad
    • M
      pseries: Default reg for vty should be SPAPR_VTY_BASE_ADDRESS · 5afdec40
      由 Michael Ellerman 提交于 
      In commit b4a78527 ("Place pseries vty
devices at addresses more similar to existing machines"), we changed the
default reg for the vty to 0x30000000, however we didn't update the default
value for a user specified vty device. Fix that.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      5afdec40
    • M
      pseries: Check we have a chardev in spapr_vty_init() · 57285302
      由 Michael Ellerman 提交于 
      If qemu is run like:

 qemu-system-ppc64 -nodefaults -device spapr-vty

We end up in spapr_vty_init() with dev->chardev == NULL. Currently
that leads to a segfault because we unconditionally call
qemu_chr_add_handlers().

Although we could make that call conditional, I think a spapr-vty
without a chardev is basically useless so fail the init. This is
similar to what the serial code does for example.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      57285302
    • D
      pseries: Fix buggy spapr_vio_find_by_reg() · 5435352c
      由 David Gibson 提交于 
      The spapr_vio_find_by_reg() function in hw/spapr_vio.c is supposed to find
the device structure for a PAPR virtual IO device with the given reg value,
and return NULL if none exists.

It does the first ok, but if no device with that reg exists, it just
returns the last device traversed in the list.  This patch fixes it.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      5435352c
    • D
      pseries: Correct RAM size check for SLOF · 92c93a81
      由 David Gibson 提交于 
      The SLOF firmware used on the pseries machine needs a reasonable amount of
(guest) RAM in order to run, so we have a check in the machine init
function to check that this is available.  However, SLOF runs in real mode
(MMU off) which means it can only actually access the RMA (Real Mode Area),
not all of RAM.  In many cases the RMA is the same as all RAM, but when
running with Book3S HV KVM on PowerPC 970, the RMA must be especially
allocated to be (host) physically contiguous.  In this case, the RMA size
is determined by what the host admin allocated at boot time, and will
usually be less than the whole guest RAM size.

This patch corrects the test to see if SLOF has enough memory for this
case.

In addition, more recent versions of SLOF that were committed earlier don't
need quite as much memory as earlier versions.  Therefore, this patch also
reduces the amount of RAM we require to run SLOF.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      92c93a81
  5. 15 11月, 2011 4 次提交
  7. 14 11月, 2011 5 次提交
  9. 13 11月, 2011 1 次提交
  11. 12 11月, 2011 18 次提交
  13. 11 11月, 2011 4 次提交
    • A
      vl.c: Fail gracefully if no machine is found · d423675c
      由 Andreas Färber 提交于 
      machine defaults to find_default_machine(),
then gets overridden via -M and machine_parse().

If no -M is specified and find_default_machine() returns NULL
(when no machine compiled in), exit with an error.

Avoids a segfault when setting machine->max_cpus.
Signed-off-by: NAndreas Färber <andreas.faerber@web.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      d423675c
    • K
      block: Make cache=unsafe flush to the OS · ca716364
      由 Kevin Wolf 提交于 
      cache=unsafe completely ignored bdrv_flush, because flushing the host disk
costs a lot of performance. However, this means that qcow2 images (and
potentially any other format) can lose data even after the guest has issued a
flush if the qemu process crashes/is killed. In case of a host crash, data loss
is certainly expected with cache=unsafe, but if just the qemu process dies this
is a bit too unsafe.

Now that we have two separate flush functions, we can choose to flush
everythign to the OS, but don't enforce that it's physically written to the
disk.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ca716364
    • K
      block: Introduce bdrv_co_flush_to_os · eb489bb1
      由 Kevin Wolf 提交于 
      qcow2 has a writeback metadata cache, so flushing a qcow2 image actually
consists of writing back that cache to the protocol and only then flushes the
protocol in order to get everything stable on disk.

This introduces a separate bdrv_co_flush_to_os to reflect the split.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      eb489bb1
    • K
      block: Rename bdrv_co_flush to bdrv_co_flush_to_disk · c68b89ac
      由 Kevin Wolf 提交于 
      There are two different types of flush that you can do: Flushing one level up
to the OS (i.e. writing data to the host page cache) or flushing it all the way
down to the disk. The existing functions flush to the disk, reflect this in the
function name.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c68b89ac