[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:51:57 +0100 |
On 21.03.2013, at 12:49, Alexander Graf wrote:
>
> On 21.03.2013, at 12:44, Peter Maydell wrote:
>
>> On 21 March 2013 11:38, Alexander Graf <address@hidden> wrote:
>>>
>>> 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?
>>
>> Have the QEMU end of that device call (your equivalent of)
>> kvm_arm_register_device(), and provide a 'reserved' mmio region to
>> its users; the kernel end implements the standard 'tell me where I live'
>> ioctl; that's it.
>>
>>> 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?
>>
>> Guest remappable KVM regions would require enhancements, yes (it's
>> not like we have an existing mechanism for doing that on any
>> architecture at the moment). The principle of implementing the
>> mechanics of this in common code still holds, probably even more
>> so for the increased complexity.
>>
>>> The distinction on whether a region is handled by KVM really needs
>>> to be done by the device model.
>>
>> It is -- the device model is what calls kvm_arm_register_device().
>> It's just the mechanics of "how do we tell the kernel the right
>> address for this region at the point when we know it" that are
>> handled in kvm.c.
>
> I think I'm slowly grasping what you're aiming at :). Ok, that works. You do
> actually do the listener in the device model, just that you pass code
> responsibility over to kvm.c.
>
> That's perfectly valid and sounds like a good model that Scott probably wants
> to follow as well :).
s/follow/evaluate/ :).
The currently proposed device api doesn't have a generic notion of device
regions. Regions are a per-device property, because a single device can have
multiple regions.
However, maybe with a bit of brainstorming we could come up with a reasonably
generic scheme.
Alex
- Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address(), (continued)
- 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, 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(), 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