KVM call agenda for 2013-06-25

KVM call agenda for 2013-06-25

[Juan Quintela]

Hi

Now we have moved to one call each other week.
Please, send any topic that you are interested in covering.

Thanks, Juan.

PD.  If you want to attend and you don't have the call details,
      contact me.

Re: KVM call agenda for 2013-06-25

[Michael R. Hines]

I don't think my presence on the call is necessary,
but I would appreciate it you put RDMA on the agenda.

The patches have been thoroughly bug-tested and reviewed.

- Michael

On 06/11/2013 11:52 AM, Juan Quintela wrote:
> Hi
>
> Now we have moved to one call each other week.
> Please, send any topic that you are interested in covering.
>
> Thanks, Juan.
>
> PD.  If you want to attend and you don't have the call details,
>        contact me.
>

Re: [Qemu-devel] KVM call agenda for 2013-06-25

[Alexander Graf]

On 11.06.2013, at 17:52, Juan Quintela wrote:

> 
> Hi
> 
> Now we have moved to one call each other week.
> Please, send any topic that you are interested in covering.

VFIO for device tree based platforms


Alex

> 
> Thanks, Juan.
> 
> PD.  If you want to attend and you don't have the call details,
>      contact me.
> 

KVM call agenda for 2013-06-25

[Michael S. Tsirkin]

Please, send any topic that you are interested in covering.

Thanks, MST

-- 
MST

Re: KVM call agenda for 2013-06-25

[Alexander Graf]

On 20.06.2013, at 14:47, Michael S. Tsirkin wrote:

> Please, send any topic that you are interested in covering.

VFIO with platform devices


Alex

Re: KVM call agenda for 2013-06-25

[Antonios Motakis]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Hello,

How can one follow those calls? We are especially interested in VFIO with
platform/device tree based devices.


On Sat, Jun 22, 2013 at 3:01 AM, Alexander Graf <agraf@suse.de> wrote:

>
> On 20.06.2013, at 14:47, Michael S. Tsirkin wrote:
>
> > Please, send any topic that you are interested in covering.
>
> VFIO with platform devices
>
>
> Alex
>
>
>

[-- Attachment #2: Type: text/html, Size: 738 bytes --]

Re: KVM call agenda for 2013-06-25

[Igor Mammedov]

On Tue, 11 Jun 2013 17:52:53 +0200
Juan Quintela <quintela@redhat.com> wrote:

> 
> Hi
> 
> Now we have moved to one call each other week.
> Please, send any topic that you are interested in covering.
> 
> Thanks, Juan.
> 
> PD.  If you want to attend and you don't have the call details,
>       contact me.
> 

Using static vs. dynamic properties vs. globals in particular case 
for CPU feature properties. Anthony suggested on IRC to use static
properties for it but recently it was questioned why not used dynamic
properties for it (afaerber):

1. static properties:

* using default values in static properties to define CPU models at
  class_init() time

* static properties could eventually evolve onto class properties,
  probably without much effort required.

* allows to simplify x86_cpu_initfn() and replace several custom
  property setters with a generic static property setters as result
  reducing code base and duplication.

2. introduce post_initfn() hook and move setting defaults of
  static properties and globals into it. So that property setters
  won't have to operate on partially initialized object instance.
  It also would allow to use dynamic properties in globals and
  compat_props.

3. using globals for simplifying cpu_model parsing and possibly getting
   rid of it in favor of -device FOO_CPU and eventually replacing
   cpu_init(cpu_model) with all its complexity by simple generic
   device_add() sequence.
   
   as one of the steps to it, cpu_model "-cpu FOO_CPU,feat1=x,feat2=y"
   which is the template for N CPUs created in machine_init() and which
   is parsed by target specific parser in cpu_*_init(), could be internally
   transformed into a set of global properties, like:
      FOO_CPU.feat1=x FOO_CPU.feat2=y
   then target specific parsers could be modified to CPU_CLASS hook that would
   keep compatibility code and make this remapping instead of parsing cpu_model
   string for each CPU and operating directly on CPU object instance.
   That would allow to treat CPUs as usual devices during hot-plug and use
   device-add. And open possibility to create individual CPUs on QEMU CLI
   using -device (which is important for migration and arbitrary CPU hot-add/remove)
   and heterogeneous CPUs machines.