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

[Anthony Liguori]

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.