[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM call agenda for 2014-04-15
From: |
Eric Auger |
Subject: |
Re: [Qemu-devel] KVM call agenda for 2014-04-15 |
Date: |
Tue, 15 Apr 2014 17:32:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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
- [Qemu-devel] KVM call agenda for 2014-04-15, Juan Quintela, 2014/04/14
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Alexander Graf, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Juan Quintela, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Markus Armbruster, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Peter Maydell, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Markus Armbruster, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Alexander Graf, 2014/04/15
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Markus Armbruster, 2014/04/16
- Re: [Qemu-devel] KVM call agenda for 2014-04-15, Alexander Graf, 2014/04/16
Re: [Qemu-devel] KVM call agenda for 2014-04-15, 陈梁, 2014/04/15