All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Jordan Justen <jljusten@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	patches@linaro.org, jordan.l.justen@intel.com,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Use of flash for x86 BIOS
Date: Fri, 22 Mar 2013 20:48:15 +0100	[thread overview]
Message-ID: <87vc8jdxmo.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <CAFe8ug-k_ZQq1XKUaZtNH7f0YU96zjSgpx0RWy1RiAm2pDHfQg@mail.gmail.com> (Jordan Justen's message of "Fri, 22 Mar 2013 12:09:21 -0700")

Jordan Justen <jljusten@gmail.com> writes:

> On Thu, Mar 21, 2013 at 12:45 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> x86 maintainers may wish to *switch it off* until it's done fully and
>> properly, by setting "pc-sysfw" property "rom_only" to 1.
>
> This would completely disable the flash support.

Unless the user enables it explicitly with something like "-global
pc-sysfw.rom_only=0".

>                                                  At the time this
> feature was added, I think it was well understood that kvm would not
> support the flash mode, while plain qemu could. If it was not a
> show-stopper to integrating the feature originally, what has changed?

Nothing changed, and that's the problem.

Merging the feature was okay, I think.  Defaulting it to "on" with TCG
and "off" with KVM was a mistake, because that made enabling/disabling
KVM guest-visible (see item 2. below).  The default needs to be the same
both with and without KVM.  Since the thing still doesn't work with KVM,
the default needs to be "off".

A possible explanation for making this mistake is that people assumed it
would soon work with KVM.  That turned out not to be the case.

> rom_only was added as part of the flash support enabling. I guess in a
> way it would be amusing to use it to disabled that same feature.
>
>> 1. The "pc-sysfw" device is mostly harmless.
>
> Indeed, and it's only marginally of interest until kvm supports it.
>
> Admittedly, I've been completely ineffectual in resolving the kvm
> portion. More recently I tried to make use of KVM_MEM_READONLY to
> address this. I was able to get an VM exit on writes to flash, but not
> able to get the memory region to convert to full device mode so VM
> exits would occur on reads as well. I am once again stalled...

Have you discussed your difficulties on kvm@vger.kernel.org?

>> 2. Enabling/disabling KVM is guest-visible!  With KVM disabled, you get
>>    a flash memory device.  With KVM enabled, you get a ROM.  Not good;
>>    KVM should be as transparent as possible to the guest.
>> 
>>    I raised this issue last August, Jordan told me he's working on
>>    it[*], and I let the matter rest then.  That was a mistake.
>> 
>> [*] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg03178.html

  reply	other threads:[~2013-03-22 19:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 18:24 [Qemu-devel] [PATCH 0/2] Implement migration support for pflash_cfi01 Peter Maydell
2013-03-19 18:24 ` [Qemu-devel] [PATCH 1/2] pflash_cfi01: Drop unused 'bypass' field Peter Maydell
2013-03-19 18:24 ` [Qemu-devel] [PATCH 2/2] pflash_cfi01: Implement migration support Peter Maydell
2013-03-26 13:32   ` Peter Maydell
2013-03-21  7:45 ` [Qemu-devel] Use of flash for x86 BIOS (was: [PATCH 0/2] Implement migration support for pflash_cfi01) Markus Armbruster
2013-03-22 16:42   ` Peter Maydell
2013-03-22 18:51     ` [Qemu-devel] Use of flash for x86 BIOS Markus Armbruster
2013-03-22 19:09   ` [Qemu-devel] Use of flash for x86 BIOS (was: [PATCH 0/2] Implement migration support for pflash_cfi01) Jordan Justen
2013-03-22 19:48     ` Markus Armbruster [this message]
2013-04-03 13:48       ` [Qemu-devel] Use of flash for x86 BIOS Laszlo Ersek
2013-04-03 18:38       ` Jordan Justen
2013-04-12 15:33         ` Markus Armbruster
2013-04-08  6:06     ` Xiao Guangrong
2013-04-08  8:18       ` Jordan Justen
2013-04-08  8:43         ` Gleb Natapov
2013-04-08  9:19           ` Xiao Guangrong

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=87vc8jdxmo.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=jljusten@gmail.com \
    --cc=jordan.l.justen@intel.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=xiaoguangrong@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.