[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] KVM call minutes for 2014-05-13
|
From: |
Markus Armbruster |
|
Subject: |
[Qemu-devel] KVM call minutes for 2014-05-13 |
|
Date: |
Tue, 13 May 2014 16:36:21 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
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
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] KVM call minutes for 2014-05-13,
Markus Armbruster <=