KVM call agenda for 2014-04-15

KVM call agenda for 2014-04-15

[Juan Quintela]

Hi

Please, send any topic that you are interested in covering.

Thanks, Juan.

Call details:

15:00 CEST
13:00 UTC
09:00 EDT

Every two weeks

If you need phone number details,  contact me privately.

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

[Alexander Graf]

On 04/14/2014 07:37 PM, Juan Quintela wrote:
> Hi
>
> Please, send any topic that you are interested in covering.

As mentioned in the last email I still have the sysbus -device topic on 
the list. If Alexey shows up I would also like to discuss the IOMMU bus 
patch and why we need a bus solely for live migration.


Alex

>
> Thanks, Juan.
>
> Call details:
>
> 15:00 CEST
> 13:00 UTC
> 09:00 EDT
>
> Every two weeks
>
> If you need phone number details,  contact me privately.
>

Re: KVM call agenda for 2014-04-15

[Juan Quintela]

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.

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

[Markus Armbruster]

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

Re: KVM call agenda for 2014-04-15

[Alexander Graf]

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

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

Best Regards

Eric


> 
> 
> Alex
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander Graf]

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

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

[Peter Maydell]

Some fuller comments below on the parts of the call which
I had opinions on.

On 15 April 2014 15:55, Alexander Graf <agraf@suse.de> wrote:
>
> 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.

I think the "create a full machine" part of this very
definitely needs to be done by taking a wider view of
the design, fixing or reworking parts of our system which
aren't sufficiently QOMified, etc first. Then you can get
to the point where you can create a board model from a
config file or script; and then maybe you can think about
the command line. Starting from "on the command line" is
definitely the wrong end. Most of my comments below are
suggestions about what direction I think we should be going
if we want to tackle this.

The VFIO case, on the other hand, might potentially be solvable
with a more limited set of changes. Unfortunately I can't currently
see anything we can do here which isn't going to be irredeemably
ugly :-(

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

I think my point was not necessarily "unrealistic" but more
that we don't need to feel obliged to stick with this design
if we have a better idea. I don't think that moving to a more
QOM-aware irq/gpio connection scheme necessarily requires
stateful Pin objects.

Is it possible to move to stateful Pin objects without breaking
migration compatibility for everything?

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

I think QOMifying qemu_irqs would be nice anyway: we could
as part of this arrange to be able to give them names, so
that you could connect "mmc.card-present" to "sysctl.mmc-card-present"
rather than having to wire up output 0 to input 1, and you
could have the ARM GIC have several different arrays of
inputs rather than the current scheme of encoding them all
as different parts of the single gpio in array.

> b) Memory Regions
>
> The "Anthony" approach was to turn memory regions into QOM objects. That
> allows to expose memory region links as QOM links.

I think this is worth pursuing; it links up with some of Edgar's
recent patches to make CPUs use particular AddressSpaces for
dispatch, and so on. Parts of this have obvious QOM property
syntax: a device can expose its MemoryRegions as suitable
kinds of QOM properties or links, just as is proposed above
for its IRQ lines. (And again, we would be able to give them
sensible names like "regs", "pci-io-window", "pci-mem-window-1",
"pci-mem-window-2", etc.) And where a QOM object wants to
accept a MemoryRegion (because it is a transaction master like
a CPU or DMA controller) that also seems straightforward, in
analogy to how an interrupt controller has inbound GPIO lines.
The unanswered question for command line syntax is how you
would deal with what we currently do in C where a board
model or a SoC device creates a container MemoryRegion and
populates it before feeding it to a transaction master.
I think you could probably handle this by having some kind
of special case syntax for "map memory region X into memory
region Y at offset Z", eg "-global board.memmap[0x3000] = mydevice.regs".

We also talked about the issue that if we allow users to do
this sort of thing on the command line we're effectively
making our QOM hierarchy ABI, in that if we rearrange how
we instantiate devices this will break some command lines.
One suggestion here to ameliorate this was to provide aliases,
so you could say "interrupt-controller" rather than
"board/a15mpcore/gic"; then this would be nicer for users and
also we could say "only the aliases are guaranteed not to break".

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

I really don't like this idea at all. It seems to be completely
ducking any attempt to address the wider issues here.

thanks
-- PMM

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

[Markus Armbruster]

Alexander Graf <agraf@suse.de> writes:

> 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:
[...]
> 2) -device for non-PCI devices

Interesting stuff, hate to have missed it.

Can we please ensure more useful advance notice than "monitor the IRC
channel around call time"?  Decide call / no call the night before would
work nicely for me.

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

[Alexander Graf]

> Am 15.04.2014 um 18:56 schrieb Markus Armbruster <armbru@redhat.com>:
> 
> Alexander Graf <agraf@suse.de> writes:
> 
>>> 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:
> [...]
>> 2) -device for non-PCI devices
> 
> Interesting stuff, hate to have missed it.
> 
> Can we please ensure more useful advance notice than "monitor the IRC
> channel around call time"?  Decide call / no call the night before would
> work nicely for me.

I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet.

Alex

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

[Markus Armbruster]

Alexander Graf <agraf@suse.de> writes:

>> Am 15.04.2014 um 18:56 schrieb Markus Armbruster <armbru@redhat.com>:
>> 
>> Alexander Graf <agraf@suse.de> writes:
>> 
>>>> 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:
>> [...]
>>> 2) -device for non-PCI devices
>> 
>> Interesting stuff, hate to have missed it.
>> 
>> Can we please ensure more useful advance notice than "monitor the IRC
>> channel around call time"?  Decide call / no call the night before would
>> work nicely for me.
>
> I sent an email to the list earlier this werk as reply to the last
> call, because there was no mail for this week's agenda yet.

That's probably why Juan didn't pick it up.  Explanation, not
criticizing either of you.

If we post the call's agenda the night before, there's time to correct
omissions.

I'm fine with late agenda changes.  I really don't like last minute call
/ no call decisions.

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

[Alexander Graf]

> Am 16.04.2014 um 08:26 schrieb Markus Armbruster <armbru@redhat.com>:
> 
> Alexander Graf <agraf@suse.de> writes:
> 
>>> Am 15.04.2014 um 18:56 schrieb Markus Armbruster <armbru@redhat.com>:
>>> 
>>> Alexander Graf <agraf@suse.de> writes:
>>> 
>>>>> 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:
>>> [...]
>>>> 2) -device for non-PCI devices
>>> 
>>> Interesting stuff, hate to have missed it.
>>> 
>>> Can we please ensure more useful advance notice than "monitor the IRC
>>> channel around call time"?  Decide call / no call the night before would
>>> work nicely for me.
>> 
>> I sent an email to the list earlier this werk as reply to the last
>> call, because there was no mail for this week's agenda yet.
> 
> That's probably why Juan didn't pick it up.  Explanation, not
> criticizing either of you.
> 
> If we post the call's agenda the night before, there's time to correct
> omissions.
> 
> I'm fine with late agenda changes.  I really don't like last minute call
> / no call decisions.

How about we post the agenda mail for next time right after the last meeting? Then people have 2 weeks to gather ideas.

Alex

Re: KVM call agenda for 2014-04-15

[陈梁]

Hi
Do we have any plan to support migration by multi net card?

Thanks
ChenLiang

> 
> Hi
> 
> Please, send any topic that you are interested in covering.
> 
> Thanks, Juan.
> 
> Call details:
> 
> 15:00 CEST
> 13:00 UTC
> 09:00 EDT
> 
> Every two weeks
> 
> If you need phone number details,  contact me privately.
>