qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: pc/i386: legacy memory attributes - write only?


From: Andriy Gapon
Subject: [Qemu-devel] Re: pc/i386: legacy memory attributes - write only?
Date: Fri, 03 Oct 2008 17:10:49 +0300
User-agent: Thunderbird 2.0.0.17 (X11/20080929)

Also, it seems that reads from unassigned memory are supposed to return
values with all bits set (e.g. 0xff). At least this is what bochs does
and what apparently happens on real hardware.
By unassigned memory I mean, for instance, the case where reads are
directed to (ISA) expansion ROM, but there is no actual ROM there.
This is for x86, of course.

I think that this can be fixed as simple as adding UINT_MAX return value
to unassigned_mem_readb (under PC ifdef).

For reference please see init_memory() method in memory/misc_mem.cc of
bochs:
memset(BX_MEM_THIS rom, 0xff, BIOSROMSZ + EXROMSIZE + 4096);


on 01/10/2008 18:50 Andriy Gapon said the following:
> Sorry for top-posting. More on this topic.
> I looked at the code in hw/piix_pci.c, namely update_pam() and the code
> seems to do things quite differently from what I expected.
> 
> Cases for values 0 (-R-W) and 3 (+R+W) seem to be correct: in one case
> both types of requests are directed to ROM and in the other they are
> directed to RAM.
> 
> But cases for 1 (+R-W) and 2 (-R+W) seem to be quite broken:
> 1: effectively this should specify read-only access to RAM (write access
> is directed to PCI interface of ROM and ignored there), but the code
> does something different here.
> Example: set type of memory region to 3, write some data there, set the
> type to 1 - after that the memory contains some different data from what
> was written.
> 
> 2: the code simply treats this case as the zero case (everything goes to
> ROM)
> 
> Sorry for providing only a complaint (and some analysis) and not
> providing any patches. It is not too obvious from
> cpu_register_physical_memory "API" how to obtain the desired/correct
> behavior.
> 
> 
> on 17/09/2008 19:05 Andriy Gapon said the following:
>> I am working on a BIOS-ish code geared towards 440BX/PIIX4 chipset, so I
>> decided to try it under qemu emulation.
>>
>> There is a snippet in the code that works as best described in 82443BX
>> documentation:
>>> As an example, consider a BIOS that is implemented on the expansion
>>> bus. During the initialization process, the BIOS can be shadowed in
>>> main memory to increase the system performance. When BIOS is shadowed
>>> in main memory, it should be copied to the same address location. To
>>> shadow the BIOS, the attributes for that address range should be set
>>> to write only. The BIOS is shadowed by first doing a read of that
>>> address. This read is forwarded to the expansion bus. The host then
>>> does a write of the same address, which is directed to main memory.
>>> After the BIOS is shadowed, the attributes for that memory area are
>>> set to read only so that all writes are forwarded to the expansion
>>> bus.
>> The code tries to do exactly that by writing 20h to PCI configuration
>> register 20h (of device 0:0:0). Then reading and writing back the whole
>> F0000h-FFFFFh region and then setting the register to 10h.
>>
>> But in qemu I see that after the above operation the corresponding RAM
>> region contains all zero bytes.
>>
>> I think that behavior of 440BX and 440FX which qemu emulates should be
>> identical in this respect.
>> Does qemu perform proper emulation of attributes for legacy memory
>> segments?
>> Should the above work in qemu? Maybe there is some bug in my code.
>>
> 
> 


-- 
Andriy Gapon




reply via email to

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