Re: [Qemu-devel] [PATCH 2/3] memory: add API for creating ROM/device regions

Anthony Liguori
2011-08-14T15:51:12Z

On 08/14/2011 10:43 AM, Alexander Graf wrote:
>
> Am 14.08.2011 um 06:29 schrieb Anthony Liguori<anthony@codemonkey.ws>:
>
>> On 08/13/2011 10:05 PM, Avi Kivity wrote:
>>> On 08/12/2011 06:48 AM, Anthony Liguori wrote:
>>>>> target_phys_addr_t offset_in_region;
>>>>> AddrRange addr;
>>>>> uint8_t dirty_log_mask;
>>>>> + bool readable;
>>>> @@ -125,6 +125,7 @@ struct FlatRange {
>>>>
>>>> In a follow up, it might be good to add a comment explaining that this
>>>> whole readable thing is not just an optimization, but a hard
>>>> requirement for KVM in order to be able to execute code from ROM.
>>>
>>> This has nothing to do with kvm (in fact, I think we cannot support it
>>> under kvm with current interfaces). It's there to support devices that
>>> sometimes act as RAM and sometimes as mmio.
>>
>> That is not a functional behavior but rather an optimization. Functionally speaking, there is absolutely no different between "acting as RAM" and "acting as mmio".
>>
>> But you cannot remove the optimization because of the aforementioned limitation in KVM.
>>
>> Maybe it's just me but I find this to be a very subtle detail so a comment would be helpful :-)
>
> Well, TCG also can't execute from MMIO, right?

Yes, it can. To be fully correct, you basically have to. During BIOS
initialization, the BIOS uses PAM to move itself from ROM to RAM to
speed up BIOS execution. During this time period, memory reads come
from one location (ROM) but writes go to another location (RAM).

Since we can't do this in KVM, SeaBIOS carries a hack to just skip this
step if it detects its runnning on KVM.

> So it's at least not KVM specific - TCG also gets the speedup from mapping roms as ram.

Don't get me wrong, the optimization is important. I'm just suggesting
to document it since as can be demonstrated by this conversation, it's a
subtle detail :-)

Regards,

Anthony Liguori

>
> Alex
>
>>
>