[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 1/4] isapc: Fix non-KVM qemu boot (read/write

From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v7 1/4] isapc: Fix non-KVM qemu boot (read/write memory for isapc BIOS)
Date: Fri, 31 May 2013 14:40:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6

On 05/31/13 06:41, Jordan Justen wrote:
> On Thu, May 30, 2013 at 7:06 PM, Kevin O'Connor <address@hidden> wrote:
>> On Wed, May 29, 2013 at 01:27:24AM -0700, Jordan Justen wrote:
>>> The isapc machine with seabios currently requires the BIOS region
>>> to be read/write memory rather than read-only memory.
>>> KVM currently cannot support the BIOS as a ROM region, but qemu
>>> in non-KVM mode can. Based on this, isapc machine currently only
>>> works with KVM.
>>> To work-around this isapc issue, this change avoids marking the
>>> BIOS as readonly for isapc.
>> How about changing the code to always make the ROM read/write (instead
>> of doing it only on isapc).  Currently, if the rom is marked as
>> read-only, then SeaBIOS makes it read/write as the first thing it
>> does.  So, making it read-only doesn't really serve any purpose.
> Are you talking about PAM registers? I think these should only affect
> 0xe0000-0xfffff and 0xfffe000-0xffffffff. So, the PAM registers should
> only impact part of the potential ROM range.
> Also, I think the PAM registers should default to ROM mode after reset
> and on power-on.

I think we've been here before...

- always resetting the PAM registers broke S3 resume:

- there was a patch to distinguish soft reset from hard reset:

- another approach for soft vs. hard, and how it relates to resume:

I believe currently qemu doesn't distinguish soft from hard reset. Hard
reset would have to reset PAM registers, soft reset must not. Since we
only have one (mixed?) kind, and S3 resume depends on PAM registers
being intact, we can't clear them during the one kind of reset that we
currently have.

No idea what the final resolution was, but I vaguely believe none of the
"distinguish soft from hard reset" submissions got all aspects right, or
some such.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]