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

[Gleb Natapov <gleb@redhat.com>]

On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
> On 05/19/2011 12:39 PM, Gleb Natapov wrote:
> >On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> >>On 2011-05-19 15:36, Anthony Liguori wrote:
> >>>On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> >>>>On 2011-05-18 15:12, Avi Kivity wrote:
> >>>>>void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t
> >>>>>addr);
> >>>>
> >>>>OK, let's allow overlapping, but make it explicit:
> >>>>
> >>>>void cpu_register_memory_region_overlap(MemoryRegion *mr,
> >>>>                                          target_phys_addr_t addr,
> >>>>                                          int priority);
> >>>
> >>>The device doesn't actually know how overlapping is handled.  This is
> >>>based on the bus hierarchy.
> >>
> >>Devices don't register their regions, buses do.
> >>
> >Today PCI device may register region that overlaps with any other
> >registered memory region without even knowing it. Guest can write any
> >RAM address into PCI BAR and this RAM address will be come mmio are.
> 
> Right, but this is not how a real machine works.
> 
Very likely.

> 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.

>                                                         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.

> >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.