[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_add
From: |
Alexander Graf |
Subject: |
Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address() |
Date: |
Thu, 21 Mar 2013 12:38:50 +0100 |
On 21.03.2013, at 12:32, Peter Maydell wrote:
> On 21 March 2013 11:29, Alexander Graf <address@hidden> wrote:
>> On 21.03.2013, at 12:22, Peter Maydell wrote:
>>> We already nest the VGIC inside another memory region (the a15mpcore
>>> container), and it works fine. This function is just iterating through
>>> "everything any device asked me to tell the kernel about".
>>
>> So kda is the real physical offset? I'm having a hard time reading that code
>> :). According to this function:
>>
>> static void kvm_arm_devlistener_add(MemoryListener *listener,
>> MemoryRegionSection *section)
>> {
>> KVMDevice *kd;
>>
>> QSLIST_FOREACH(kd, &kvm_devices_head, entries) {
>> if (section->mr == kd->mr) {
>> kd->kda.addr = section->offset_within_address_space;
>> }
>> }
>> }
>>
>> it's only the offset within its parent region, which would mean it's broken,
>> no?
>
> Address spaces are not the same thing as memory regions :-)
> The only address space involved here is the system address space.
> (As I say, we currently assume we only get mapped into one address
> space, but that could be fixed if necessary.)
Interesting. Oh well, I'll leave that one to Scott to figure out ;).
So what if I want to write an in-kernel IDE PIO accelerator? Or even better
yet: An AHCI accelerator that has one MMIO BAR and another PIO BAR that can be
remapped by the guest at any time?
The distinction on whether a region is handled by KVM really needs to be done
by the device model.
Alex
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(),
Alexander Graf <=
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Alexander Graf, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Scott Wood, 2013/03/21
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/22
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Scott Wood, 2013/03/22
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/23
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Scott Wood, 2013/03/25
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), Peter Maydell, 2013/03/21