Re: [Qemu-devel] [PATCH] Re: phys_ram_base, direct access to guest memory

[Fabrice Bellard <fabrice@bellard.org>]

Blue Swirl wrote:
> On 5/13/08, Fabrice Bellard <fabrice@bellard.org> wrote:
>> Blue Swirl wrote:
>>
>>> On 5/5/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>
>>>> On Fri, May 02, 2008 at 05:52:07PM +0300, Blue Swirl wrote:
>>>>  > On 4/8/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>>  > > On Tue, Mar 25, 2008 at 11:12:57AM +0000, Ian Jackson wrote:
>>>>  > >  > I wrote:
>>>>  > >  > > In the attached patch, I remove all the direct uses of
>> phys_ram_base
>>>>  > >  > > from hw/pc.c, except for those presently needed to construct
>> the
>>>>  > >  > > arguments to the vga init functions.
>>>>  > >  >
>>>>  > >  > Is there something wrong with my patch or the general approach ?
>>>>  > >
>>>>  > >
>>>>  > > It simply doesn't work. After applying it, I get:
>>>>  > >
>>>>  > >
>>>>  > >  qemu: fatal: Trying to execute code outside RAM or ROM at
>> 0x000a0000
>>>>  >
>>>>  > I fixed the bug in the patch, cpu_physical_memory_write_rom must be
>>>>  > used instead of cpu_physical_memory_write. I also made the same
>>>>  > changes to Sparc32/64, they run fine. Does this version work for PC
>>>>  > targets?
>>>>
>>>>
>>>> Unfortunately the problem is still there, with the same error message.
>>>>
>>> There were two additional problems, the offset was incorrect and the
>>> memory was written before it was mapped. This version seems to work.
>>>
>>> Any objections? May I commit this version?
>>>
>>  OK for the kernel loading, but not for the BIOS loading : there is no
>> reason all the BIOS is mapped at a particular physical address (because this
>> address is selectable by specific chipset bits), so it must really be loaded
>> at ram addresses, not at physical addresses.
>>
>>  IMHO, it still makes sense to allow loading of data at a particular ram
>> address.
> 
> I removed the BIOS loading parts. But is it possible to adjust VGA
> BIOS and option ROM addresses by chipset? 
> [...]

Yes. At least part of the BIOS can be replaced by RAM on a real PC (a
subset is implement is piix_pci.c).

Generically speaking, loading the content of a ROM/flash at a physical
address is almost always a bug or the indication that the corresponding
hardware model is greatly simplified.

There must be generic function to load data at a given ram address. If
you want to avoid the use of phys_ram_base, then you can add a specific
memcpy function similar to the one for the physical memory.

But it is not a good idea at all to suppress the access to the RAM memory !

Regards,

Fabrice.