[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Memory API
From: |
Gleb Natapov |
Subject: |
Re: [Qemu-devel] [RFC] Memory API |
Date: |
Thu, 19 May 2011 21:28:09 +0300 |
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.
- Re: [Qemu-devel] [RFC] Memory API, (continued)
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API,
Gleb Natapov <=
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/20