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 <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 :).
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