On 04/15/2014 04:55 PM, Alexander Graf wrote: > On 04/15/2014 04:00 PM, Markus Armbruster wrote: >> Juan Quintela <quintela@xxxxxxxxxx> writes: >> >>> Juan Quintela <quintela@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
