On 21.03.2013, at 12:44, Peter Maydell wrote: > On 21 March 2013 11:38, Alexander Graf <ag...@suse.de> wrote: >> >> On 21.03.2013, at 12:32, Peter Maydell wrote: >> >>> On 21 March 2013 11:29, Alexander Graf <ag...@suse.de> 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 :). Alex