[Qemu-devel] Modeling x86 early initialization accurately

[Qemu-devel] Modeling x86 early initialization accurately

[Carl-Daniel Hailfinger]

Hi,

current svn HEAD of QEMU assumes all RAM is available directly at x86
CPU startup. The ability to lock processor caches to function as RAM
(Cache-as-RAM) is unimplemented as well.
While that does make it easier for the shipped BIOS to set up working
RAM (i.e. it does nothing about that right now), that simplification
reduces the ability to run alternative firmwares for x86 in QEMU.
coreboot (a free x86 firmware/BIOS replacement) is unable to use
standard x86 early initialization because the MSRs for cache control
(MTRRs) are completely unimplemented and ignored.
Modeling ACPI S3 (Suspend-to-RAM) suffers from similar issues.

Things which need to be changed to model x86 better:
- Start up with all RAM being readonly. Writes should be discarded,
reads will usually return 0xff or be undefined. The "undefined" variant
would allow the code to allocate RAM once and just switch write access
on/off.
- Support MTRRs.
-- Mention MTRR support in CPUID.
-- I sent a patch to dump unknown MSR accesses in general and MTRR
reads/writes in particular. The subject was "[Qemu-devel] [PATCH] x86
MTRR access dumping".
-- It is not really needed to completely implement L1/L2 caches, but the
ability to lock the cache with the help of MTRRs should be available.
Areas with active locked cache do not send writes down to the RAM which
is still readonly. The cache locking is done on a per-page basis (or
even larger granularity), so it should be easier than having to handle
single cache lines.
- Decide what to do for RAM initialization. Do we switch RAM into
read-write mode by a simple QEMU-specific MSR write? Do we want to
implement all memory initialization hardware instead?
- Adapt the currently shipped BIOS to these tasks and/or switch to
coreboot+SeaBIOS.

I'm willing to do most of the work if I know that this won't be rejected
outright.


Regards,
Carl-Daniel

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Anthony Liguori]

Carl-Daniel Hailfinger wrote:
> Hi,
>
> current svn HEAD of QEMU assumes all RAM is available directly at x86
> CPU startup. The ability to lock processor caches to function as RAM
> (Cache-as-RAM) is unimplemented as well.
> While that does make it easier for the shipped BIOS to set up working
> RAM (i.e. it does nothing about that right now), that simplification
> reduces the ability to run alternative firmwares for x86 in QEMU.
> coreboot (a free x86 firmware/BIOS replacement) is unable to use
> standard x86 early initialization because the MSRs for cache control
> (MTRRs) are completely unimplemented and ignored.
> Modeling ACPI S3 (Suspend-to-RAM) suffers from similar issues.
>
> Things which need to be changed to model x86 better:
> - Start up with all RAM being readonly. Writes should be discarded,
> reads will usually return 0xff or be undefined. The "undefined" variant
> would allow the code to allocate RAM once and just switch write access
> on/off.
>   

This is pretty reasonable.

> - Support MTRRs.
> -- Mention MTRR support in CPUID.
> -- I sent a patch to dump unknown MSR accesses in general and MTRR
> reads/writes in particular. The subject was "[Qemu-devel] [PATCH] x86
> MTRR access dumping".
>   

Yes, I saw this patch but since it's just debugging code, it's not 
interesting for inclusion.

> -- It is not really needed to completely implement L1/L2 caches, but the
> ability to lock the cache with the help of MTRRs should be available.
> Areas with active locked cache do not send writes down to the RAM which
> is still readonly. The cache locking is done on a per-page basis (or
> even larger granularity), so it should be easier than having to handle
> single cache lines.
>   

I'm concerned that modeling this could have a non negligible overhead 
and could be very difficult in something like KVM.  Can you describe 
exactly what coreboot is expecting that we are not implementing?  How is 
it relying on cache locking?

> - Decide what to do for RAM initialization. Do we switch RAM into
> read-write mode by a simple QEMU-specific MSR write? Do we want to
> implement all memory initialization hardware instead?
> - Adapt the currently shipped BIOS to these tasks and/or switch to
> coreboot+SeaBIOS.
>   

BTW, I'd love to switch to something like coreboot but the legacy BIOS 
support payload is too incomplete.  SeaBIOS is a good option too but it 
needs some heavy regression testing first.

> I'm willing to do most of the work if I know that this won't be rejected
> outright.
>   

In general, better modeling of processor modes, provided that there 
isn't a regression in performance, is a good thing.  Dividing the effort 
into incremental bits that are posted early for inclusion is also a good 
thing.

Regards,

Anthony Liguori

> Regards,
> Carl-Daniel
>
>
>   

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Carl-Daniel Hailfinger]

On 26.11.2008 03:04, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> current svn HEAD of QEMU assumes all RAM is available directly at x86
>> CPU startup. The ability to lock processor caches to function as RAM
>> (Cache-as-RAM) is unimplemented as well.
>> While that does make it easier for the shipped BIOS to set up working
>> RAM (i.e. it does nothing about that right now), that simplification
>> reduces the ability to run alternative firmwares for x86 in QEMU.
>> coreboot (a free x86 firmware/BIOS replacement) is unable to use
>> standard x86 early initialization because the MSRs for cache control
>> (MTRRs) are completely unimplemented and ignored.
>> Modeling ACPI S3 (Suspend-to-RAM) suffers from similar issues.
>>
>> Things which need to be changed to model x86 better:
>> - Start up with all RAM being readonly. Writes should be discarded,
>> reads will usually return 0xff or be undefined. The "undefined" variant
>> would allow the code to allocate RAM once and just switch write access
>> on/off.
>>   
>
> This is pretty reasonable.

So this would be my first patch, together with a patch to change the
allocation to read/write once a special MSR is written.

Is it possible to change the type of allocation from readonly to
read/write if the backing store has been allocated with qemu_ram_alloc()?
Can I simply call cpu_register_physical_memory() again for the same
target region and the newer register will take precedence?
Is the "special MSR" solution acceptable? If yes, which number should I
pick? Or is that my choice?


>> - Support MTRRs.
>> -- Mention MTRR support in CPUID.
>> -- I sent a patch to dump unknown MSR accesses in general and MTRR
>> reads/writes in particular. The subject was "[Qemu-devel] [PATCH] x86
>> MTRR access dumping".
>>   
>
> Yes, I saw this patch but since it's just debugging code, it's not
> interesting for inclusion.

Quite a few x86 processors reset themselves if they encounter an unknown
MSR write. Should we do the same? If not, would spewing a loud debug
message be appropriate?


>> -- It is not really needed to completely implement L1/L2 caches, but the
>> ability to lock the cache with the help of MTRRs should be available.
>> Areas with active locked cache do not send writes down to the RAM which
>> is still readonly. The cache locking is done on a per-page basis (or
>> even larger granularity), so it should be easier than having to handle
>> single cache lines.
>>   
>
> I'm concerned that modeling this could have a non negligible overhead
> and could be very difficult in something like KVM.  Can you describe
> exactly what coreboot is expecting that we are not implementing?  How
> is it relying on cache locking?

Since there is no RAM before RAM initialization, we have no way to keep
a stack. That rules out implementing RAM init in C (which is fond of
using a stack for local variables, parameters and call return addresses)
unless you either can fake some RAM or have a C compiler which needs no
stack. Faking some RAM is way easier.
Basically, we use MTRRs to declare everything uncached except one small
(4-64k sized with page granularity) area in the CPU address space which
has cache type writeback. That area is called the CAR (Cache-as-RAM)
area. Reads in that area will allocate a cache line and subsequent reads
will hit the cache directly. Writes in that area will allocate a cache
line if none already exists for the given address. Writes to the area
will never be passed to RAM. Reads and writes outside the CAR area will
go directly through to RAM/ROM. Writes outside the CAR area will be
discarded. Since everything besides the CAR area is declared as uncached
and any access outside the cache area won't cause cacheline evictions,
the cache is effectively locked.

>From a firmware perspective, the following implementation is good enough:
1. CAR enable: Copy the contents of the address area designated for CAR
from the underlying (readonly RAM/ROM) backing store to a new "CAR"
read/write backing store mapped to the same CPU physical address area.
2. CAR usage: All reads/writes to the CAR area hit the "CAR" read/write
backing store. All other reads outside the CAR area hit the normal
backing store. All writes outside the CAR area are discarded if they
would have ended up in RAM. Writes to MMIO regions are still honored.
3. RAM enabling: The backing store for RAM outside the CAR area now
accepts writes.
3. CAR disabling: The "CAR" backing store is either discarded (INVD
instruction) or written to RAM (WBINVD instruction).

The runtime performance hit of this implementation should be negligible
because there is no need to check for CAR on each memory access. Only
the relevant MSR writes need to be handled to change allocation type.
Once CAR is disabled, the memory allocation and mapping should match
exactly what the current code does. That means any performance hit would
only matter during the time CAR is active. That's probably a few hundred
instructions after poweron until RAM is enabled.


>> - Decide what to do for RAM initialization. Do we switch RAM into
>> read-write mode by a simple QEMU-specific MSR write? Do we want to
>> implement all memory initialization hardware instead?
>> - Adapt the currently shipped BIOS to these tasks and/or switch to
>> coreboot+SeaBIOS.
>>   
>
> BTW, I'd love to switch to something like coreboot but the legacy BIOS
> support payload is too incomplete.  SeaBIOS is a good option too but
> it needs some heavy regression testing first.

SeaBIOS is now the official coreboot payload for any legacy BIOS needs.
The SeaBIOS maintainer is pretty responsive to bug reports, so I think
it will be working well. After all, SeaBIOS as a coreboot payload can
boot Windows XP in QEMU and on some (the number of testers is rather
limited) real hardware.


>> I'm willing to do most of the work if I know that this won't be rejected
>> outright.
>>   
>
> In general, better modeling of processor modes, provided that there
> isn't a regression in performance, is a good thing.  Dividing the
> effort into incremental bits that are posted early for inclusion is
> also a good thing.

Thanks, I'll heed your advice.

I hope the explanations I gave were precise and understandable enough.
If anything seems unclear or incomplete, feel free to ask. x86 CAR is
difficult to explain and understand and there are almost no public docs
about it.


Regards,
Carl-Daniel

> Regards,
>
> Anthony Liguori
-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Avi Kivity]

Carl-Daniel Hailfinger wrote:
>> This is pretty reasonable.
>>     
>
> So this would be my first patch, together with a patch to change the
> allocation to read/write once a special MSR is written.
>
> Is it possible to change the type of allocation from readonly to
> read/write if the backing store has been allocated with qemu_ram_alloc()?
> Can I simply call cpu_register_physical_memory() again for the same
> target region and the newer register will take precedence?
> Is the "special MSR" solution acceptable? If yes, which number should I
> pick? Or is that my choice?
>
>   

Isn't this usually a chipset function?  In this case a chipset register 
is more appropriate.  Best would be to implement the actual chipset that 
qemu qemulates.

  

>> Yes, I saw this patch but since it's just debugging code, it's not
>> interesting for inclusion.
>>     
>
> Quite a few x86 processors reset themselves if they encounter an unknown
> MSR write. Should we do the same? If not, would spewing a loud debug
> message be appropriate?
>
>   

The standard behaviour is to #GP.

  

>> I'm concerned that modeling this could have a non negligible overhead
>> and could be very difficult in something like KVM.  Can you describe
>> exactly what coreboot is expecting that we are not implementing?  How
>> is it relying on cache locking?
>>     
>
> Since there is no RAM before RAM initialization, we have no way to keep
> a stack. That rules out implementing RAM init in C (which is fond of
> using a stack for local variables, parameters and call return addresses)
> unless you either can fake some RAM or have a C compiler which needs no
> stack. Faking some RAM is way easier.
> Basically, we use MTRRs to declare everything uncached except one small
> (4-64k sized with page granularity) area in the CPU address space which
> has cache type writeback. That area is called the CAR (Cache-as-RAM)
> area. Reads in that area will allocate a cache line and subsequent reads
> will hit the cache directly. Writes in that area will allocate a cache
> line if none already exists for the given address. Writes to the area
> will never be passed to RAM. Reads and writes outside the CAR area will
> go directly through to RAM/ROM. Writes outside the CAR area will be
> discarded. Since everything besides the CAR area is declared as uncached
> and any access outside the cache area won't cause cacheline evictions,
> the cache is effectively locked.
>
> From a firmware perspective, the following implementation is good enough:
> 1. CAR enable: Copy the contents of the address area designated for CAR
> from the underlying (readonly RAM/ROM) backing store to a new "CAR"
> read/write backing store mapped to the same CPU physical address area.
> 2. CAR usage: All reads/writes to the CAR area hit the "CAR" read/write
> backing store. All other reads outside the CAR area hit the normal
> backing store. All writes outside the CAR area are discarded if they
> would have ended up in RAM. Writes to MMIO regions are still honored.
> 3. RAM enabling: The backing store for RAM outside the CAR area now
> accepts writes.
> 3. CAR disabling: The "CAR" backing store is either discarded (INVD
> instruction) or written to RAM (WBINVD instruction).
>
> The runtime performance hit of this implementation should be negligible
> because there is no need to check for CAR on each memory access. Only
> the relevant MSR writes need to be handled to change allocation type.
> Once CAR is disabled, the memory allocation and mapping should match
> exactly what the current code does. That means any performance hit would
> only matter during the time CAR is active. That's probably a few hundred
> instructions after poweron until RAM is enabled.
>   

If we can detect this, we can handle it with kvm by allocating a memory 
slot to back the cache.  But I don't see how we can detect it reliably 
(mtrrs are handled completely within the kernel, and I wouldn't want 
this hack in the kernel).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Carl-Daniel Hailfinger]

On 26.11.2008 17:36, Avi Kivity wrote:
> Carl-Daniel Hailfinger wrote:
>>> This is pretty reasonable.
>>>     
>>
>> So this would be my first patch, together with a patch to change the
>> allocation to read/write once a special MSR is written.
>>
>> Is it possible to change the type of allocation from readonly to
>> read/write if the backing store has been allocated with
>> qemu_ram_alloc()?
>> Can I simply call cpu_register_physical_memory() again for the same
>> target region and the newer register will take precedence?
>> Is the "special MSR" solution acceptable? If yes, which number should I
>> pick? Or is that my choice?
>>
>>   
>
> Isn't this usually a chipset function?  In this case a chipset
> register is more appropriate.  Best would be to implement the actual
> chipset that qemu emulates.

Yes, it is a chipset function. However, implementing complete RAM
initialization control for i440FX in a way that is compatible with any
BIOS code written to the spec is not a trivial task. Besides that, it
would make addressing/initializing more than 1 GB of RAM a real problem.
Newer Intel chipsets supporting more RAM have even more complicated
memory initialization interfaces and some have docs only under NDA.

Please don't get me wrong, accurate simulation of the RAM controller in
QEMU would be cool, but the payoff seems rather limited.

For the AMD K8 line and successors, the RAM controller is inside the CPU
and thus not a chipset function. That doesn't mean the interface would
be any easier, though.


>>> Yes, I saw this patch but since it's just debugging code, it's not
>>> interesting for inclusion.
>>>     
>>
>> Quite a few x86 processors reset themselves if they encounter an unknown
>> MSR write. Should we do the same? If not, would spewing a loud debug
>> message be appropriate?  
>
> The standard behaviour is to #GP.

Grepping the source code didn't find any code signaling a #GP. I'd be
thankful for any hints so I can create a patch for this.
(And give a warning to the ReactOS developers because their latest code
will #GP with that change. They read and write MSR 0x0000008b which is
unimplemented in QEMU).


>>> I'm concerned that modeling this could have a non negligible overhead
>>> and could be very difficult in something like KVM.  Can you describe
>>> exactly what coreboot is expecting that we are not implementing?  How
>>> is it relying on cache locking?
>>>     
>>
>> Since there is no RAM before RAM initialization, we have no way to keep
>> a stack. That rules out implementing RAM init in C (which is fond of
>> using a stack for local variables, parameters and call return addresses)
>> unless you either can fake some RAM or have a C compiler which needs no
>> stack. Faking some RAM is way easier.
>> Basically, we use MTRRs to declare everything uncached except one small
>> (4-64k sized with page granularity) area in the CPU address space which
>> has cache type writeback. That area is called the CAR (Cache-as-RAM)
>> area. Reads in that area will allocate a cache line and subsequent reads
>> will hit the cache directly. Writes in that area will allocate a cache
>> line if none already exists for the given address. Writes to the area
>> will never be passed to RAM. Reads and writes outside the CAR area will
>> go directly through to RAM/ROM. Writes outside the CAR area will be
>> discarded. Since everything besides the CAR area is declared as uncached
>> and any access outside the cache area won't cause cacheline evictions,
>> the cache is effectively locked.
>>
>> From a firmware perspective, the following implementation is good
>> enough:
>> 1. CAR enable: Copy the contents of the address area designated for CAR
>> from the underlying (readonly RAM/ROM) backing store to a new "CAR"
>> read/write backing store mapped to the same CPU physical address area.
>> 2. CAR usage: All reads/writes to the CAR area hit the "CAR" read/write
>> backing store. All other reads outside the CAR area hit the normal
>> backing store. All writes outside the CAR area are discarded if they
>> would have ended up in RAM. Writes to MMIO regions are still honored.
>> 3. RAM enabling: The backing store for RAM outside the CAR area now
>> accepts writes.
>> 3. CAR disabling: The "CAR" backing store is either discarded (INVD
>> instruction) or written to RAM (WBINVD instruction).
>>
>> The runtime performance hit of this implementation should be negligible
>> because there is no need to check for CAR on each memory access. Only
>> the relevant MSR writes need to be handled to change allocation type.
>> Once CAR is disabled, the memory allocation and mapping should match
>> exactly what the current code does. That means any performance hit would
>> only matter during the time CAR is active. That's probably a few hundred
>> instructions after poweron until RAM is enabled.
>>   
>
> If we can detect this, we can handle it with kvm by allocating a
> memory slot to back the cache.  But I don't see how we can detect it
> reliably (mtrrs are handled completely within the kernel, and I
> wouldn't want this hack in the kernel).

AFAICS MTRRs of x86 targets are ignored completely by QEMU. They are
handled as unknown MSR reads/writes and do not fault. See
target-i386/op_helper.c:helper_rdmsr() and helper_wrmsr(). I'm not
familiar with how KVM handles the MTRRs and the KVM code in the QEMU
doesn't provide that many clues. Your statement about MTRR handling in
the kernel is not entirely clear to me. Are all MSR writes handled in
the kernel by KVM?

Detection of the CAR mode activation can be performed in two ways,
depending on how close to hardware we want to get:
1. Coreboot specific, triggering on the exact sequence of MSR writes
performed by coreboot.
2. BIOS/firmware agnostic, triggering anytime the cache control bits and
any of the MTRR MSRs are in the right state.


Regards,
Carl-Daniel

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

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Avi Kivity]

Carl-Daniel Hailfinger wrote:
> Grepping the source code didn't find any code signaling a #GP. I'd be
> thankful for any hints so I can create a patch for this.
>   

See helper_wrmsr(), the default: case (which is even commented).

> (And give a warning to the ReactOS developers because their latest code
> will #GP with that change. They read and write MSR 0x0000008b which is
> unimplemented in QEMU).
>
>   

This may be an architectural msr (oxymoron, yes) which is guaranteed to 
exist.  In that case qemu should implement it.

  

>> If we can detect this, we can handle it with kvm by allocating a
>> memory slot to back the cache.  But I don't see how we can detect it
>> reliably (mtrrs are handled completely within the kernel, and I
>> wouldn't want this hack in the kernel).
>>     
>
> AFAICS MTRRs of x86 targets are ignored completely by QEMU. 

But not kvm.

> They are
> handled as unknown MSR reads/writes and do not fault. See
> target-i386/op_helper.c:helper_rdmsr() and helper_wrmsr(). I'm not
> familiar with how KVM handles the MTRRs and the KVM code in the QEMU
> doesn't provide that many clues. Your statement about MTRR handling in
> the kernel is not entirely clear to me. Are all MSR writes handled in
> the kernel by KVM?
>
> Detection of the CAR mode activation can be performed in two ways,
> depending on how close to hardware we want to get:
> 1. Coreboot specific, triggering on the exact sequence of MSR writes
> performed by coreboot.
>   

Definitely not.

> 2. BIOS/firmware agnostic, triggering anytime the cache control bits and
> any of the MTRR MSRs are in the right state.
>   

What is the right state?  Total writeback memory spanned by MTRRs <= 
cache size?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Carl-Daniel Hailfinger]

On 27.11.2008 14:28, Avi Kivity wrote:
> Carl-Daniel Hailfinger wrote:
>> Grepping the source code didn't find any code signaling a #GP. I'd be
>> thankful for any hints so I can create a patch for this.
>>   
>
> See helper_wrmsr(), the default: case (which is even commented).

Both current QEMU SVN and KVM GIT
http://git.kernel.org/?p=linux/kernel/git/avi/kvm-userspace.git;a=blob_plain;f=qemu/target-i386/op_helper.c
have this code for the default wrmsr:

    default:
        /* XXX: exception ? */
        break;
    }


My question was probably phrased the wrong way. I did know where to put
the #GP, but not how to cause it to be delivered inside the machine.


>> (And give a warning to the ReactOS developers because their latest code
>> will #GP with that change. They read and write MSR 0x0000008b which is
>> unimplemented in QEMU).  
>
> This may be an architectural msr (oxymoron, yes) which is guaranteed
> to exist.  In that case qemu should implement it.

The "Intel 64 and IA-32 Architectures Software Developer's Manual Volume
3B: System Programming Guide, Part 2" says this about MSR 0x8b:
MSR 0x8b: IA32_BIOS_SIGN_ID
MSR/Bit Description:
BIOS Update Signature (RO)
Returns the microcode update signature following the execution of
CPUID.01H. A processor may prevent writing to this MSR when loading
guest states on VM entries or saving guest states on VM exits.
Bit 31:0  Reserved
Bit 63:32 It is recommended that this field be pre-loaded with 0 prior
to executing CPUID. If the field remains 0 following the execution of
CPUID; this indicates that no microcode update is loaded. Any non-zero
value is the microcode update signature.

Unless we want to simulate microcode updates, this can be implemented
easily. I'll send a patch.


There are also a few MSRs we don't implement although they are part of
the common subset of x86/x86-64 MSRs. Then again, if nothing uses them,
no harm is done.


>>> If we can detect this, we can handle it with kvm by allocating a
>>> memory slot to back the cache.  But I don't see how we can detect it
>>> reliably (mtrrs are handled completely within the kernel, and I
>>> wouldn't want this hack in the kernel).
>>>     
>>
>> AFAICS MTRRs of x86 targets are ignored completely by QEMU. 
>
> But not kvm.

Where can I look? The QEMU tree in KVM userspace GIT seems to ignore
them as well.
Am I looking at the wrong tree?


>> They are
>> handled as unknown MSR reads/writes and do not fault. See
>> target-i386/op_helper.c:helper_rdmsr() and helper_wrmsr(). I'm not
>> familiar with how KVM handles the MTRRs and the KVM code in the QEMU
>> doesn't provide that many clues. Your statement about MTRR handling in
>> the kernel is not entirely clear to me. Are all MSR writes handled in
>> the kernel by KVM?
>>
>> Detection of the CAR mode activation can be performed in two ways,
>> depending on how close to hardware we want to get:
>> 1. Coreboot specific, triggering on the exact sequence of MSR writes
>> performed by coreboot.
>>   
>
> Definitely not.

Good.


>> 2. BIOS/firmware agnostic, triggering anytime the cache control bits and
>> any of the MTRR MSRs are in the right state.
>>   
>
> What is the right state?  Total writeback memory spanned by MTRRs <=
> cache size?

That would work, yes. It will support some cases which are not working
on real hardware, but on the plus side, that approach is a catch-all for
CAR implementations across various CPU generations from Intel and AMD.
I'd recommend to make sure MTRRdefType has default memory type set to UC
(uncacheable) when activating CAR. Otherwise you'd have to use MTRRs to
declare anything except the CAR area as uncached and that may fail due
to alignment requirements.


Regards,
Carl-Daniel

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

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Paul Brook]

> - Start up with all RAM being readonly. Writes should be discarded,
> reads will usually return 0xff or be undefined. The "undefined" variant
> would allow the code to allocate RAM once and just switch write access
> on/off.

Does anything actually rely on this behavior?
I can see the need to the other bits, but it seems kinda strange that anything 
would rely on RAM being readonly. This seems more like a coreboot bug than 
anything else.

Paul

Re: [Qemu-devel] Modeling x86 early initialization accurately

[Carl-Daniel Hailfinger]

On 26.11.2008 12:37, Paul Brook wrote:
>> - Start up with all RAM being readonly. Writes should be discarded,
>> reads will usually return 0xff or be undefined. The "undefined" variant
>> would allow the code to allocate RAM once and just switch write access
>> on/off.
>>     
>
> Does anything actually rely on this behavior?
>   

No, but it would model hardware more closely. And it may be needed for a
correct implementation of Suspend-to-RAM.

> I can see the need to the other bits, but it seems kinda strange that anything 
> would rely on RAM being readonly. This seems more like a coreboot bug than 
> anything else.
>   

coreboot doesn't rely on this. Once you use Suspend-to-RAM on x86, the
need to avoid clobbering RAM contents during resume will strongly
suggest this change. Alas, this is not important for my current goal of
getting coreboot to run with actual i586 CPU code.

Regards,
Carl-Daniel

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