qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jordan Justen <jljusten@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] Remove legacy sysfw code
Date: Tue, 04 Jun 2013 08:46:50 +0200	[thread overview]
Message-ID: <51AD8D5A.6050709@redhat.com> (raw)
In-Reply-To: <CAFe8ug8ThD6jcX0hp-kTtiJ9saTocDiCRb4SJ2U5MRFdj1Jukw@mail.gmail.com>

Il 03/06/2013 23:56, Jordan Justen ha scritto:
> You seem to have a much better handle than I do on machine migration
> and backward compatibility issues within QEMU.
> 
> One difference we'll see from this series is that...
> 
> With QEMU 1.2, an error would always be generated with:
> qemu-system-x86_64 -M pc-1.2 -enable-kvm -pflash flash.bin
> 
> Whereas in QEMU 1.6 the same command may succeed if the kernel
> supports the READONLY kvm feature.
> 
> Will one other result of this series be that basically any of the
> older pc machines can now use -pflash?

Yes, that's it and it's fine (it's a new feature, it doesn't matter).
Similarly,

   qemu-system-x86_64 -M pc-1.0 -pflash flash.bin

will create flash while it would have failed in real QEMU 1.0.

The main difference is that with QEMU 1.2 this will use read-only flash:

   qemu-system-x86_64 -M pc-1.2

whereas in QEMU 1.6 the same command will always use BIOS, as has always
been the case with

   qemu-system-x86_64 -M pc-1.2 --enable-kvm

These semantics are much simpler to use and explain, and probably should
have been like that all the time.

Paolo

> Anyway, that doesn't seem like a big issue to me, so for the series:
> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
> 
> -Jordan
> 
> On Mon, Jun 3, 2013 at 8:19 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> The sysfw code to choose between ROM and flash BIOS was a bad idea,
>> because it triggered different behavior between TCG and KVM.  We
>> deleted the behavior in 1.5, but we left the code around because
>> it was close to the release.  Now it's time to delete it.
>>
>> Paolo Bonzini (3):
>>   remove read-only pc_sysfw_flash_vs_rom_bug_compatible
>>   pc_sysfw: remove the rom_only property
>>   pc_sysfw: do not make it a device anymore
>>
>>  default-configs/i386-softmmu.mak   |   1 -
>>  default-configs/x86_64-softmmu.mak |   1 -
>>  hw/block/Makefile.objs             |   1 -
>>  hw/i386/Makefile.objs              |   1 +
>>  hw/i386/pc.c                       |   5 +-
>>  hw/i386/pc_piix.c                  |  16 +----
>>  hw/i386/pc_q35.c                   |   2 +-
>>  hw/{block => i386}/pc_sysfw.c      | 135 +++----------------------------------
>>  include/hw/i386/pc.h               |   6 +-
>>  9 files changed, 18 insertions(+), 150 deletions(-)
>>  rename hw/{block => i386}/pc_sysfw.c (62%)
>>
>> --
>> 1.8.1.4
>>
>>
> 
> 

      reply	other threads:[~2013-06-04  7:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 15:19 [Qemu-devel] [PATCH 0/3] Remove legacy sysfw code Paolo Bonzini
2013-06-03 15:19 ` [Qemu-devel] [PATCH 1/3] sysfw: remove read-only pc_sysfw_flash_vs_rom_bug_compatible Paolo Bonzini
2013-06-03 20:36   ` Jordan Justen
2013-06-03 20:57     ` Paolo Bonzini
2013-06-04  9:17     ` Markus Armbruster
2013-06-04  9:14   ` Markus Armbruster
2013-06-04  9:43     ` Paolo Bonzini
2013-06-03 15:19 ` [Qemu-devel] [PATCH 2/3] pc_sysfw: remove the rom_only property Paolo Bonzini
2013-06-03 20:50   ` Jordan Justen
2013-06-03 21:00     ` Paolo Bonzini
2013-06-03 15:19 ` [Qemu-devel] [PATCH 3/3] pc_sysfw: do not make it a device anymore Paolo Bonzini
2013-06-03 20:46   ` Jordan Justen
2013-06-03 21:00     ` Paolo Bonzini
2013-06-03 21:56 ` [Qemu-devel] [PATCH 0/3] Remove legacy sysfw code Jordan Justen
2013-06-04  6:46   ` Paolo Bonzini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51AD8D5A.6050709@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jljusten@gmail.com \
    --cc=jordan.l.justen@intel.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).