Commit Graph

12 Commits

Author SHA1 Message Date
Markus Armbruster
e7b1d0ea95 pc_sysfw: Check for qemu_find_file() failure
pc_fw_add_pflash_drv() ignores qemu_find_file() failure, and happily
creates a drive without a medium.

When pc_system_flash_init() asks for its size, bdrv_getlength() fails
with -ENOMEDIUM, which isn't checked either.  It fails relatively
cleanly only because -ENOMEDIUM isn't a multiple of 4096:

    $ qemu-system-x86_64 -S -vnc :0 -bios nonexistant
    qemu: PC system firmware (pflash) must be a multiple of 0x1000
    [Exit 1 ]

Fix by handling the qemu_find_file() failure.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-01-04 14:38:04 +01:00
Paolo Bonzini
9c17d615a6 softmmu: move include files to include/sysemu/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19 08:32:45 +01:00
Christian Borntraeger
2d0d2837dc Support default block interfaces per QEMUMachine
There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a
default/standard interface to their block devices / drives. Therefore,
this patch introduces a new field default_block_type per QEMUMachine
struct. The prior use_scsi field becomes thereby obsolete and is
replaced through .default_block_type = IF_SCSI.

This patch also changes the default for s390x to IF_VIRTIO and
removes an early hack that converts IF_IDE drives.
Other parties have already claimed interest (e.g. IF_SD for exynos)

To create a sane default, for machines that dont specify a
default_block_type, this patch makes IF_IDE = 0 and IF_NONE = 1.
I checked all users of IF_NONE (blockdev.c and ww/device-hotplug.c)
as well as IF_IDE and it seems that it is ok to change the defines -
in other words, I found no obvious (to me) assumption in the code
regarding IF_NONE==0. IF_NONE is only set if there is an
explicit if=none. Without if=* the interface becomes IF_DEFAULT.

I would suggest to have some additional care, e.g. by letting
this patch sit some days in the block tree.

Based on an initial patch from Einar Lueck <elelueck@de.ibm.com>

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
CC: Igor Mitsyanko <i.mitsyanko@samsung.com>
CC: Markus Armbruster <armbru@redhat.com>
CC: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Igor Mitsyanko <i.mitsyanko@samsung.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-12-11 11:05:10 +01:00
Markus Armbruster
654598c944 pc_sysfw: Plug memory leak on pc_fw_add_pflash_drv() error path
Harmless, because we the error inevitably leads to another, fatal one
in pc_system_flash_init(): PC system firmware (pflash) not available.
Fix it anyway.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-12-07 12:34:12 +01:00
Avi Kivity
a8170e5e97 Rename target_phys_addr_t to hwaddr
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific).  Replace it with a finger-friendly,
standards conformant hwaddr.

Outstanding patchsets can be fixed up with the command

  git rebase -i --exec 'find -name "*.[ch]"
                        | xargs s/target_phys_addr_t/hwaddr/g' origin

Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-23 08:58:25 -05:00
Markus Armbruster
dfc65f1f78 Un-inline fdctrl_init_isa()
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-06-15 14:03:42 +02:00
Stefan Weil
9cf1f002d7 hw/pc_sysfw: Fix memory leak
Valgrind reported this memory leak which occured a few times.

Test scenario:

qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Andreas Färber <afaerber@suse.de>
2012-05-03 07:04:48 +02:00
Anthony Liguori
1d38574fdf pc-sysfw: make sure to call qdev_init
We're not actually calling qdev_init for the pc-sysfw device.  Since we create
the canonical path during realize, this was causing an assert to trigger when
attempting to read a link pointing to pc-sysfw.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-04-26 13:14:57 -05:00
Jordan Justen
1b89fafe47 pc_piix/pc_sysfw: enable flash by default
Now, the pc-sysfw:rom_only property will default
to false which enables flash by default.

All pc types below pc-1.1 set rom_only to true.
This prevents flash from being enabled on these
pc machine types.

For pc-1.1 rom_only will use the default (false),
which will allow flash to be used for pc-1.1.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-22 09:02:18 -06:00
Jordan Justen
bd183c79b5 hw/pc_sysfw: support system flash memory with pflash
Flash can be enabled by calling pc_system_firmware_init
with the system_flash_enabled parameter being non-zero.
If system_flash_enabled is zero, then the older qemu
rom creation method will be used.

If flash is enabled and a pflash image is found, then
it is used for the system firmware image.

If flash is enabled and a pflash image is not initially
found, then a read-only pflash device is created using
the -bios filename.

KVM cannot execute from a pflash region currently.
Therefore, when KVM is enabled, the old rom based
initialization method is used.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-22 09:02:18 -06:00
Jordan Justen
90ccf9f6bf hw/pc_sysfw: enable pc-sysfw as a qdev
Setup a pc-sysfw device type.  It contains a single
property of 'rom_only' which is defaulted to enabled.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-22 09:02:18 -06:00
Jordan Justen
cbc5b5f3aa hw/pc: move rom init to pc_sysfw.c
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-22 09:02:17 -06:00