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

[Eric Auger]

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