Re: [Qemu-devel] [RFC] Memory API

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/19/2011 01:28 PM, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
>> On 05/19/2011 12:39 PM, Gleb Natapov wrote:
>> With the exception of the few regions that the chipset treats
>> specially, RAM accesses don't get a chance to be intercepted by the
>> PCI bus.
>>
>>> More
>>> interesting is what happens when guest reprogram PCI BAR to other address
>>> - the RAM that was at the previous address just disappears. Obviously
>>>    this is crazy behaviour, but the question is how do we want to handle
>>
>> The CPU should continue to access RAM at this address.
> I think it should continue using it even when PCI BAR is still mapped to the
> RAM address.

Agreed.  Minus PAM and SMM, RAM is always RAM.  When a CPU accesses it, 
it's always the same.

This is not the case for device accesses to RAM but this is probably a 
separate topic.

>>                                                          It's unclear
>> to me what the right behavior is for device-to-device I/O but I'm
>> pretty certain it doesn't matter.
>>
> For PC may be. But IIRC this thread already had request to support
> different memory view from different devices.

All platforms have in common the fact that I/O is dispatched in a 
hierarchical fashion.  The reason is quite simple--physics only allow so 
many point-to-point connections between components.  So I/O access is 
always going to fan out.  The components closer to the source of the I/O 
access are always able to overrule the lower components.

Regards,

Anthony Liguori

>>> it? One option is to disallow such overlapping registration, another is
>>> to restore RAM mapping after PCI BAR is reprogrammed. If we chose second
>>> one the PCI will not know that _overlap() should be called.
>>>
>>> Another example may be APIC region and PCI. They overlap, but neither
>>> CPU nor PCI knows about it.
>>
>> And APIC always wins when accesses are coming from the CPU.
>>
> Of course, my question is how proposed API handles this.



>
> --
> 			Gleb.
>