qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: Gleb Natapov <gleb@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Michal Suchanek <hramrach@centrum.cz>,
	Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Jordan Justen <jljusten@gmail.com>
Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash
Date: Thu, 10 Mar 2011 22:41:56 +0100	[thread overview]
Message-ID: <4D7945A4.4060907@gmx.net> (raw)
In-Reply-To: <20110310114801.GC14805@redhat.com>

Auf 10.03.2011 12:48, Gleb Natapov schrieb:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>   
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>     
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue commands cannot
>>> be emulated efficiently in KVM. KVM supports either regular memory slots
>>> or IO memory, but in your proposal the same memory behaves as IO on
>>> write and regular memory on read. Better idea would be to present
>>> non-volatile flash as ISA virtio device. Should be simple to implement.
>>>       
>> Why not enhancing KVM memory slots to support direct read access while
>> writes are trapped and forwarded to a user space device model?
>>     
> Yes we can make memory slot that will be treated as memory on read and
> IO on write, but first relying on that will prevent using flash interface
> on older kernels and second it is not enough to implement the proposal.
> When magic value is written into an address, the address become IO for
> reading too, but KVM slot granularity is page, not byte, so KVM will
> have to remove the slot to make it IO, but KVM can't execute code from
> IO region (yet), so we will not be able to run firmware from flash and
> simultaneously write into the flash.
>   

If you have a Parallel/LPC/FWH flash chip in your mainboard, it is
technically impossible to execute code from flash while you are writing
to _any_ part of the flash chip because every single read from the flash
chip during an active write will toggle one bit of the read data.
So if your code already runs on real x86, you will never hit that problem.

(SPI flash is an exception, but it uses out-of-band access anyway,
usually via some southbridge interface, and that means the IO vs.
execution conflict won't happen there either.)

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

  parent reply	other threads:[~2011-03-10 21:40 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10  4:51 [Qemu-devel] RFC: emulation of system flash Jordan Justen
2011-03-10  9:10 ` [Qemu-devel] " Avi Kivity
2011-03-10 18:43   ` Jordan Justen
2011-03-10 21:52     ` Carl-Daniel Hailfinger
2011-03-10 22:14       ` Jordan Justen
2011-03-10 22:31         ` Carl-Daniel Hailfinger
2011-03-10 22:58           ` Jordan Justen
2011-03-10 23:41             ` Carl-Daniel Hailfinger
2011-03-11  2:12               ` Jordan Justen
2011-03-10  9:47 ` Gleb Natapov
2011-03-10 11:27   ` Jan Kiszka
2011-03-10 11:46     ` Jan Kiszka
2011-03-10 11:53       ` Paolo Bonzini
2011-03-10 12:07         ` Jan Kiszka
2011-03-10 19:03       ` Jordan Justen
2011-03-10 19:23         ` Anthony Liguori
2011-03-10 20:05           ` Jordan Justen
2011-03-10 11:48     ` Gleb Natapov
2011-03-10 12:06       ` Jan Kiszka
2011-03-10 12:17         ` Gleb Natapov
2011-03-10 12:27           ` Jan Kiszka
2011-03-10 19:08             ` Jordan Justen
2011-03-10 19:13               ` Gleb Natapov
2011-03-10 21:46         ` Carl-Daniel Hailfinger
2011-03-10 22:11           ` Scott Wood
2011-03-10 21:41       ` Carl-Daniel Hailfinger [this message]
2011-03-10 22:05         ` Jordan Justen
2011-03-10 18:59   ` Jordan Justen
2011-03-10 19:12     ` Gleb Natapov
2011-03-10 19:50       ` Jordan Justen
2011-03-10 20:08         ` Антон Кочков
2011-03-10 20:21         ` Gleb Natapov
2011-03-11 21:41           ` Jordan Justen
2011-03-14 14:29             ` Gleb Natapov
2011-03-10 21:37 ` [Qemu-devel] " Carl-Daniel Hailfinger
2011-03-10 21:55   ` Jordan Justen
2011-03-10 22:10     ` Carl-Daniel Hailfinger
2011-03-10 22:29       ` Jordan Justen
2011-03-10 23:53         ` Carl-Daniel Hailfinger
2011-03-11  0:19       ` [Qemu-devel] " Jan Kiszka
2011-03-11  0:27         ` Carl-Daniel Hailfinger
2011-03-11 19:09           ` Jordan Justen
2011-03-11 23:10             ` Michal Suchanek
2011-03-12  9:24             ` Jan Kiszka

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=4D7945A4.4060907@gmx.net \
    --to=c-d.hailfinger.devel.2006@gmx.net \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=hramrach@centrum.cz \
    --cc=jan.kiszka@siemens.com \
    --cc=jljusten@gmail.com \
    --cc=kevin@koconnor.net \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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 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).