Re: [Qemu-devel] KVM call agenda for 2014-04-15

[Alexander Graf <agraf@suse.de>]

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 <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.
> 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