[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Memory API
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [RFC] Memory API |
Date: |
Thu, 19 May 2011 13:03:01 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
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.
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. 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.
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.
Regards,
Anthony Liguori
--
Gleb.
- Re: [Qemu-devel] [RFC] Memory API, (continued)
- 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, 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 <=
- 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, 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