hw/i386/pc_sysfw: support two flash drives
commit637a5acb46b36a25b506ba6545e9a53350585b03
authorLaszlo Ersek <lersek@redhat.com>
Wed, 27 Nov 2013 23:52:52 +0000 (28 00:52 +0100)
committerMichael S. Tsirkin <mst@redhat.com>
Mon, 23 Dec 2013 11:12:34 +0000 (23 13:12 +0200)
treefa4e916e5af64d36063b0744cd7c93f2b9a9b14c
parentecdbfceb0f20a3ef784bf522ed7264660aa3d150
hw/i386/pc_sysfw: support two flash drives

This patch allows the user to usefully specify

  -drive file=img_1,if=pflash,format=raw,readonly \
  -drive file=img_2,if=pflash,format=raw

on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.

(The unit number increases with command line order if not explicitly
specified.)

This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.

The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.

  00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
  00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0

(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/i386/pc_sysfw.c