From: Zachary Amsden <zamsden@redhat.com>
To: qemu-devel@nongnu.org
Cc: jan.kiszka@siemens.com, Glauber Costa <glommer@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH] register a single area for vga bios and option roms
Date: Fri, 10 Apr 2009 21:41:34 -1000 [thread overview]
Message-ID: <49E049AE.2090508@redhat.com> (raw)
In-Reply-To: <49DE34D2.3000803@us.ibm.com>
Anthony Liguori wrote:
> Glauber Costa wrote:
>> Those guys are not different in nature. They're all roms,
>> not blessed with the graces of being written to. So there's
>> not need to issue multiple requests to memory registration areas:
>> just treat them as brothers, and put them all in the same
>> region.
>>
>> It also has the nice side effect of improving the loading code
>> a little bit.
>>
>> Signed-off-by: Glauber Costa <glommer@redhat.com>
>>
>
> The vga bios is just an option rom, right? So why can't we treat the
> vga bios as an option rom and eliminate the specific code for dealing
> with VGA bios.
>
> The real problem here is that we should be registering the option rom
> space once and doing that in page boundaries.
Um... are we sure about this? First off, option roms can be written to,
it's part of the PnP option ROM spec.. they are to be backed in RAM and
the init code will actually write to the ROM to resize it (allowing it
to jettison startup / init code); they get remapped read-only again
later. Will registering the roms as one physical memory region prevent
this possibility? Sorry I am still naive and coming up to speed on qemu
if this is a naive question.
Second thing, option roms are not necessarily on page boundaries,
technically they are mapped in chunks, which are 512 byte blocks, at the
discretion of the BIOS / chipset. This is mostly a non-issue as all
modern BIOS will map them on page boundaries but worth noting.
Zach
next prev parent reply other threads:[~2009-04-11 7:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 15:53 [Qemu-devel] [PATCH] register a single area for vga bios and option roms Glauber Costa
2009-04-09 17:48 ` [Qemu-devel] " Anthony Liguori
2009-04-09 20:49 ` Carl-Daniel Hailfinger
2009-04-09 22:15 ` Glauber Costa
2009-04-11 7:41 ` Zachary Amsden [this message]
2009-04-09 17:55 ` [Qemu-devel] " Paul Brook
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=49E049AE.2090508@redhat.com \
--to=zamsden@redhat.com \
--cc=glommer@redhat.com \
--cc=jan.kiszka@siemens.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).