Re: [Qemu-devel] KVM call agenda for 2013-06-25
On Tue, 11 Jun 2013 17:52:53 +0200 Juan Quintela quint...@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.
Re: [Qemu-devel] KVM call agenda for 2013-06-25
On 22.06.2013, at 03:01, Alexander Graf 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
A few notes ahead of the discussion:
-problem we are trying to solve is:
1. how the kernel can expose device tree based platform
devices to user space
2. how QEMU exposes these devices in virtual machines
-general
-this is not just a QEMU/KVM issue, we have other user space
drivers that should use the same framework (e.g. USDPAA)
-acpi/dsdt based device discovery is on the horizon, but this
should be treated separately
-we want the same linux drivers to be used in host and
guest...don't want 'paravirt' drivers in guest
-3 aspects to this
1. kernel side
-a device must be able to be unbound from the host
and bound to vfio
-vfio can determine the mappable register regions and
interrupts from the associated device tree node and
expose these to user space...details TBD
-keep it simple: expose register regions and interrupts
2. user-space/QEMU - device tree
-there is potentially a large variety of devices, the
simplest are represented by a simple self-contained
node, others get complicated and could have phandles to
other nodes (e.g. etsec has phandle to phy node). Some
devices may need device tree tweaks.
-think what we need is custom handling in QEMU for
each type of device. QEMU uses what the kernel
exposed via vfio to pass the device through and
For example to pass through
a SATA controller something like:
-device platfom-vfio-sata,dev=/soc/sata@221000,bus=platform.0
-the device specific support in QEMU knows how to
create a device tree node for the given device type
-it is up to user space to deal with device inter-
relationships if they exist
-SEC engine job ring example-- what we want ideally is a
Linux driver that can operate on plain job rings
so we don't need the complexity of dealing with the
main SEC node:
[cut]
crypto@30 {
compatible = fsl,sec-v4.0;
#address-cells = 0x1;
#size-cells = 0x1;
reg = 0x30 0x1;
ranges = 0x0 0x30 0x1;
interrupts = 0x5c 0x2 0x0 0x0;
jr@1000 {
compatible = fsl,sec-v4.0-job-ring;
reg = 0x1000 0x1000;
interrupts = 0x58 0x2 0x0 0x0;
};
jr@2000 {
compatible = fsl,sec-v4.0-job-ring;
reg = 0x2000 0x1000;
interrupts = 0x59 0x2 0x0 0x0;
};
[cut]
3. user-space/QEMU - dynamic interrupt allocation
-currently devices and interrupts on our system/platform
bus are statically allocated. We need a way to
dynamically get devices added
-simple example would be adding a virtual UART via -device
-it would be nice to solve this generally for both
ARM and Power
Re: [Qemu-devel] KVM call agenda for 2013-06-25
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 ag...@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
Re: [Qemu-devel] KVM call agenda for 2013-06-25
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: [Qemu-devel] KVM call agenda for 2013-06-25
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
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.
