From: Juan Quintela <quintela@redhat.com>
To: KVM devel mailing list <kvm@vger.kernel.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: KVM call minutes for 2013-06-26 and 2013-07-08
Date: Wed, 10 Jul 2013 00:40:11 +0200 [thread overview]
Message-ID: <87a9lvfjck.fsf@elfo.elfo> (raw)
Hi
I forgto to sent the minutes for previous call. So two in one:
2013-07-08
----------
- How to handle compatibility in propierties
- Static qdev vs dynamic QOM
Array of properties defined as an array of types
Global: we can enumerate the propierties without instatiating the device/class
Change the point in time that the global propierties are applied to obects.
Or change dynamic propierties to static ones
Do we want to change the way propierties are moved from static to dynamic?
This is the best mechanism that we have for compatibility
Are propierties associated with the class or the object?
We need create/initialization for objects to be able to apply
globals to dynamic objects
Pushing globals to objects: this are legacy static propierties
this is what Anthony is against.
If one propierty is set multiple times, last assigment wins. It is
not replacement, just adding to the list.
Converting static proprierties to dynamic: no problem, really we
don't have a choice (Anthony)
Anthony will take a look at the patches on the malinig list
"target-i386: convert CPU features into properties, part 1"
-
2013-06-25
----------
- VFIO for device tree based platforms (alex)
Use device assignment for irqs
how to describe devices where ramdom irq's are wired to the SOC
platform device assigment vs how to describe platform devices
platform board can describe this kind of things
device assignment in a (non)structured way?
- open ended: you need to describe all relations
- symbolic: device knows how it is conected once you say it is connected
knowledge of the device is not needed at qemu level for Alex platforms
vfio only exist for security point of view. We could mmap things
directly into the guest.
should we need a list of platform devices in qemu to "manage" the
device tree
define a platform bus with the "interesting" regions and irq's of
that SOC, and then you can use -device without troubles (anthony)
vfio just allows to handle device passthrough and mmio configuration.
Abstracting two interfaces: kernel-to-qemu and qemu-to-guest
We want to share the kernel interface with arm.
reply other threads:[~2013-07-09 15:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a9lvfjck.fsf@elfo.elfo \
--to=quintela@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox