Re: KVM call agenda for 2014-04-15

[Alexander Graf <agraf@suse.de>]

On 04/15/2014 04:00 PM, Markus Armbruster wrote:
> Juan Quintela <quintela@redhat.com> writes:
>
>> Juan Quintela <quintela@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