Today's agenda: - QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite) Here are my notes; please correct mistakes. Peter C: Everything with a connection becomes a QOM object, references become links Peter Maydell: Okay PC: Don't include address spaces in v1, just memory regions and GPIO PM: Okay What's the root memory region's canonical path? PM: There is no root What about the big memory region in exec.c? PM: Should go away eventually Andreas Färber: Converting to types is a no-brainer, but property names and such are ABI, need to be very careful What's the connection to Edgar's CPU work? AF: Not everyone one the call is a memory API expert, please explain address space and memory regions PM: Address space is flattended memory regions, needed for actual memory access when constructing machines, we deal with memory regions, not address spaces AF+PM: Each CPU should have its own address space Does this duplicate address spaces? PM: Yes, but it's okay, because (a) they don't change very often (b) if performance turns out to suffer, we can cache or share AF: How much memory do address spaces use? PM: Don't know, guess not much Do busmasters get their own address space, too? PM: Yes Back to canonical paths Can we get them right? [I missed details here] Where to start? PC[?] suggests softip [I almost certainly got this name wrong] has CPUs with private memory, good example for separate address spaces How do separate address spaces affect gdbstub? threads can have their own view of memory already, we should be fine AF: Does per-CPU address space imply per-CPU memory regions? PM: Not necessarily, depends on board Back to canonical path of memory region AF: the memory region object needs to go *somewhere*! possible solution: if board code doesn't put the global memory region anywhere, put it in machine/unattached When does a QOM object need a path? AF: it should always have a path, but it really needs one when it's referenced via QMP or by a link General direction seems uncontroversial PC intends to post patches soon How is this work connected to vfio hotplug, and how to move best vfio hotplug forward? Alex Graf intends to respin his platform device patches -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
