Re: [Qemu-devel] KVM call agenda for 2014-04-15
Alexander Graf ag...@suse.de writes: Am 15.04.2014 um 18:56 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet. That's probably why Juan didn't pick it up. Explanation, not criticizing either of you. If we post the call's agenda the night before, there's time to correct omissions. I'm fine with late agenda changes. I really don't like last minute call / no call decisions. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Am 16.04.2014 um 08:26 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: Am 15.04.2014 um 18:56 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet. That's probably why Juan didn't pick it up. Explanation, not criticizing either of you. If we post the call's agenda the night before, there's time to correct omissions. I'm fine with late agenda changes. I really don't like last minute call / no call decisions. How about we post the agenda mail for next time right after the last meeting? Then people have 2 weeks to gather ideas. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
On 15.04.14 17:32, Eric Auger wrote: On 04/15/2014 04:55 PM, Alexander Graf wrote: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: 1) pSeries IOMMU bus Live migration registers the name for a migration blob in register_savevm_live() through qdev bus enumeration. The IOMMUs in our pSeries machine don't live on any bus, so they all get the same name. That leads to problems when we change the order of -device arguments on the command line. One proposed solution to this is to create a bus for IOMMUs which allows us to give each IOMMU a unique name; patch is on the list. Another proposed solution is to give devices the chance to override their name themselves. IOMMUs do know their system wide unique ID and can easily generate a unique device name for themselves. If we keep names the way they were without this callback, we can stay backwards compatible for x86 and have our IOMMUs return unique names. 2) -device for non-PCI devices There are 2 reasons we want to create platform devices using -device on the command line. One is that Xilinx is trying to create a full machine from the command line. The other one is that we want VFIO for platform devices. a) IRQs The Anthony way of doing IRQ links between random devices is his stateful Pin object approach. Since Anthony is gone and it'd be a lot of refactoring, we don't deem this approach realistic. Andreas suggested that we could make every qemu_irq a QOM object that then gets a global name in the QOM hierarchy and can be addressed as connector for IRQ output lines of devices in the -device command line syntax. b) Memory Regions The Anthony approach was to turn memory regions into QOM objects. That allows to expose memory region links as QOM links. The currently proposed approach is to add a -sysbusdev (or -device) command line option that hard codedly puts memory region n of device x into address a of the physical address space. c) Device Granularity We talked about the granularity of VFIO platform devices per -device option. I was advocating that we should have a -device granularity that makes sense for the user, rather than individual separate components. The main reason for that is that we lose information about links of different components of a device when we make it separate devices. Hi Alex, all in last week [RFC v2 5/6] virt: Assign a VFIO platform device to a virt VM in QEMU command line, available in https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01419.html I proposed an implementation using this kind of option line -device vfio-platform,vfio_device=fff51000.ethernet,\ compat=calxeda/hb-xgmac,mmap-timeout-ms=1000 where the machine file, ie. virt.c does the bulk of the work to simplify the work for the end-user. For devices that are more complex than the Midway xgmac we could imagine to have some device specific code in virt.c. I am not satified with the implementation which calls the realize function twice. However on the principle, do you think this could make sense? That's one of the unsolved questions that we have outstanding. For the mapping I see 3 possible solutions: 1) Create a special platform bus that allows for dynamic memory region and irq placement according to children's properties 2) Loop through the QOM tree and search for unassigned devices, map them in the machine file 3) Detangle everything and do explicit links between 2 globally accessible objects somehow (-sysbusdev) The device tree generation should always happen by walking the QOM tree. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
On 04/14/2014 07:37 PM, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. As mentioned in the last email I still have the sysbus -device topic on the list. If Alexey shows up I would also like to discuss the IOMMU bus patch and why we need a bus solely for live migration. Alex Thanks, Juan. Call details: 15:00 CEST 13:00 UTC 09:00 EDT Every two weeks If you need phone number details, contact me privately. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: 1) pSeries IOMMU bus Live migration registers the name for a migration blob in register_savevm_live() through qdev bus enumeration. The IOMMUs in our pSeries machine don't live on any bus, so they all get the same name. That leads to problems when we change the order of -device arguments on the command line. One proposed solution to this is to create a bus for IOMMUs which allows us to give each IOMMU a unique name; patch is on the list. Another proposed solution is to give devices the chance to override their name themselves. IOMMUs do know their system wide unique ID and can easily generate a unique device name for themselves. If we keep names the way they were without this callback, we can stay backwards compatible for x86 and have our IOMMUs return unique names. 2) -device for non-PCI devices There are 2 reasons we want to create platform devices using -device on the command line. One is that Xilinx is trying to create a full machine from the command line. The other one is that we want VFIO for platform devices. a) IRQs The Anthony way of doing IRQ links between random devices is his stateful Pin object approach. Since Anthony is gone and it'd be a lot of refactoring, we don't deem this approach realistic. Andreas suggested that we could make every qemu_irq a QOM object that then gets a global name in the QOM hierarchy and can be addressed as connector for IRQ output lines of devices in the -device command line syntax. b) Memory Regions The Anthony approach was to turn memory regions into QOM objects. That allows to expose memory region links as QOM links. The currently proposed approach is to add a -sysbusdev (or -device) command line option that hard codedly puts memory region n of device x into address a of the physical address space. c) Device Granularity We talked about the granularity of VFIO platform devices per -device option. I was advocating that we should have a -device granularity that makes sense for the user, rather than individual separate components. The main reason for that is that we lose information about links of different components of a device when we make it separate devices. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
On 04/15/2014 04:55 PM, Alexander Graf wrote: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: 1) pSeries IOMMU bus Live migration registers the name for a migration blob in register_savevm_live() through qdev bus enumeration. The IOMMUs in our pSeries machine don't live on any bus, so they all get the same name. That leads to problems when we change the order of -device arguments on the command line. One proposed solution to this is to create a bus for IOMMUs which allows us to give each IOMMU a unique name; patch is on the list. Another proposed solution is to give devices the chance to override their name themselves. IOMMUs do know their system wide unique ID and can easily generate a unique device name for themselves. If we keep names the way they were without this callback, we can stay backwards compatible for x86 and have our IOMMUs return unique names. 2) -device for non-PCI devices There are 2 reasons we want to create platform devices using -device on the command line. One is that Xilinx is trying to create a full machine from the command line. The other one is that we want VFIO for platform devices. a) IRQs The Anthony way of doing IRQ links between random devices is his stateful Pin object approach. Since Anthony is gone and it'd be a lot of refactoring, we don't deem this approach realistic. Andreas suggested that we could make every qemu_irq a QOM object that then gets a global name in the QOM hierarchy and can be addressed as connector for IRQ output lines of devices in the -device command line syntax. b) Memory Regions The Anthony approach was to turn memory regions into QOM objects. That allows to expose memory region links as QOM links. The currently proposed approach is to add a -sysbusdev (or -device) command line option that hard codedly puts memory region n of device x into address a of the physical address space. c) Device Granularity We talked about the granularity of VFIO platform devices per -device option. I was advocating that we should have a -device granularity that makes sense for the user, rather than individual separate components. The main reason for that is that we lose information about links of different components of a device when we make it separate devices. Hi Alex, all in last week [RFC v2 5/6] virt: Assign a VFIO platform device to a virt VM in QEMU command line, available in https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01419.html I proposed an implementation using this kind of option line -device vfio-platform,vfio_device=fff51000.ethernet,\ compat=calxeda/hb-xgmac,mmap-timeout-ms=1000 where the machine file, ie. virt.c does the bulk of the work to simplify the work for the end-user. For devices that are more complex than the Midway xgmac we could imagine to have some device specific code in virt.c. I am not satified with the implementation which calls the realize function twice. However on the principle, do you think this could make sense? Best Regards Eric Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Some fuller comments below on the parts of the call which I had opinions on. On 15 April 2014 15:55, Alexander Graf ag...@suse.de wrote: 2) -device for non-PCI devices There are 2 reasons we want to create platform devices using -device on the command line. One is that Xilinx is trying to create a full machine from the command line. The other one is that we want VFIO for platform devices. I think the create a full machine part of this very definitely needs to be done by taking a wider view of the design, fixing or reworking parts of our system which aren't sufficiently QOMified, etc first. Then you can get to the point where you can create a board model from a config file or script; and then maybe you can think about the command line. Starting from on the command line is definitely the wrong end. Most of my comments below are suggestions about what direction I think we should be going if we want to tackle this. The VFIO case, on the other hand, might potentially be solvable with a more limited set of changes. Unfortunately I can't currently see anything we can do here which isn't going to be irredeemably ugly :-( a) IRQs The Anthony way of doing IRQ links between random devices is his stateful Pin object approach. Since Anthony is gone and it'd be a lot of refactoring, we don't deem this approach realistic. I think my point was not necessarily unrealistic but more that we don't need to feel obliged to stick with this design if we have a better idea. I don't think that moving to a more QOM-aware irq/gpio connection scheme necessarily requires stateful Pin objects. Is it possible to move to stateful Pin objects without breaking migration compatibility for everything? Andreas suggested that we could make every qemu_irq a QOM object that then gets a global name in the QOM hierarchy and can be addressed as connector for IRQ output lines of devices in the -device command line syntax. I think QOMifying qemu_irqs would be nice anyway: we could as part of this arrange to be able to give them names, so that you could connect mmc.card-present to sysctl.mmc-card-present rather than having to wire up output 0 to input 1, and you could have the ARM GIC have several different arrays of inputs rather than the current scheme of encoding them all as different parts of the single gpio in array. b) Memory Regions The Anthony approach was to turn memory regions into QOM objects. That allows to expose memory region links as QOM links. I think this is worth pursuing; it links up with some of Edgar's recent patches to make CPUs use particular AddressSpaces for dispatch, and so on. Parts of this have obvious QOM property syntax: a device can expose its MemoryRegions as suitable kinds of QOM properties or links, just as is proposed above for its IRQ lines. (And again, we would be able to give them sensible names like regs, pci-io-window, pci-mem-window-1, pci-mem-window-2, etc.) And where a QOM object wants to accept a MemoryRegion (because it is a transaction master like a CPU or DMA controller) that also seems straightforward, in analogy to how an interrupt controller has inbound GPIO lines. The unanswered question for command line syntax is how you would deal with what we currently do in C where a board model or a SoC device creates a container MemoryRegion and populates it before feeding it to a transaction master. I think you could probably handle this by having some kind of special case syntax for map memory region X into memory region Y at offset Z, eg -global board.memmap[0x3000] = mydevice.regs. We also talked about the issue that if we allow users to do this sort of thing on the command line we're effectively making our QOM hierarchy ABI, in that if we rearrange how we instantiate devices this will break some command lines. One suggestion here to ameliorate this was to provide aliases, so you could say interrupt-controller rather than board/a15mpcore/gic; then this would be nicer for users and also we could say only the aliases are guaranteed not to break. The currently proposed approach is to add a -sysbusdev (or -device) command line option that hard codedly puts memory region n of device x into address a of the physical address space. I really don't like this idea at all. It seems to be completely ducking any attempt to address the wider issues here. thanks -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Hi Do we have any plan to support migration by multi net card? Thanks ChenLiang Hi Please, send any topic that you are interested in covering. Thanks, Juan. Call details: 15:00 CEST 13:00 UTC 09:00 EDT Every two weeks If you need phone number details, contact me privately. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Am 15.04.2014 um 18:56 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
