public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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