On Fri, Jan 31, 2014 at 05:52:57PM +0100, Paolo Bonzini wrote:
> Il 31/01/2014 17:42, Eduardo Habkost ha scritto:
> >>> It looks like only -device would be able to create actual CPU models,
> >>> but for -device to work we need as minimum this series and conversion
> >>> of CPU features to properti
Il 31/01/2014 17:42, Eduardo Habkost ha scritto:
> It looks like only -device would be able to create actual CPU models,
> but for -device to work we need as minimum this series and conversion
> of CPU features to properties in tree. Then I guess we can override
> cannot_instantiate_with_device_a
On Fri, Jan 31, 2014 at 05:06:21PM +0100, Igor Mammedov wrote:
> On Fri, 31 Jan 2014 13:17:53 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
> > > Il 31/01/2014 15:48, Igor Mammedov ha scritto:
> > > >that's abusing of object-add interface and
On Fri, 31 Jan 2014 13:17:53 -0200
Eduardo Habkost wrote:
> On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
> > Il 31/01/2014 15:48, Igor Mammedov ha scritto:
> > >that's abusing of object-add interface and due to recent changes,
> > >object-add
> > >won't accept arbitrary objects
On Fri, 31 Jan 2014 12:30:17 +0100
Andreas Färber wrote:
>
> Further, I was under the impression that this series depends on Igor's
> feature property series, which I haven't found time to rework and
> haven't noticed anyone else do either. So if there's no prereqs (why
> uq/master?) I'll happil
On Thu, 30 Jan 2014 17:48:52 -0200
Eduardo Habkost wrote:
> Is there any hope to get this into QEMU 2.0, or it is now too late? I got
> almost no feedback on take 6 (submitted November 27).
>
> This is the main blocker to allow libvirt finally implement an equivalent to
> the
> "enforce" flag,
On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
> Il 31/01/2014 15:48, Igor Mammedov ha scritto:
> >that's abusing of object-add interface and due to recent changes, object-add
> >won't accept arbitrary objects.
>
> I hope that sooner or later device hotplug will be doable with
> ob
Il 31/01/2014 15:48, Igor Mammedov ha scritto:
that's abusing of object-add interface and due to recent changes, object-add
won't accept arbitrary objects.
I hope that sooner or later device hotplug will be doable with
object-add too. But yes, in the meanwhile device_add could work, and
this
(CCing Luiz, in case he can give some advice about the expectations of
QMP semantics stability)
On Fri, Jan 31, 2014 at 03:48:53PM +0100, Igor Mammedov wrote:
> On Thu, 30 Jan 2014 17:48:52 -0200
> Eduardo Habkost wrote:
>
> > Is there any hope to get this into QEMU 2.0, or it is now too late? I
Il 31/01/2014 16:10, Eduardo Habkost ha scritto:
I don't mind which command is used, as long as we have the same effect.
I used object-add in my example because device_add rejects the CPU
classes by now (because they have cannot_instantiate_with_device_add_yet=true).
But now I have one question:
On Fri, Jan 31, 2014 at 12:42:08PM +0100, Paolo Bonzini wrote:
> Il 31/01/2014 12:30, Andreas Färber ha scritto:
> >Further, I was under the impression that this series depends on Igor's
> >feature property series, which I haven't found time to rework and
> >haven't noticed anyone else do either. S
On Fri, Jan 31, 2014 at 12:30:17PM +0100, Andreas Färber wrote:
> Am 30.01.2014 22:47, schrieb Paolo Bonzini:
> > Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
> >> Is there any hope to get this into QEMU 2.0, or it is now too late? I got
> >> almost no feedback on take 6 (submitted November 27)
Il 31/01/2014 12:30, Andreas Färber ha scritto:
Further, I was under the impression that this series depends on Igor's
feature property series, which I haven't found time to rework and
haven't noticed anyone else do either. So if there's no prereqs (why
uq/master?) I'll happily start reviewing an
Am 30.01.2014 22:47, schrieb Paolo Bonzini:
> Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
>> Is there any hope to get this into QEMU 2.0, or it is now too late? I got
>> almost no feedback on take 6 (submitted November 27).
>
> It's not too late, not for me at least. I wanted to send the nex
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
Is there any hope to get this into QEMU 2.0, or it is now too late? I got
almost no feedback on take 6 (submitted November 27).
It's not too late, not for me at least. I wanted to send the next
uq/master pull request tomorrow or Tuesday, after
Is there any hope to get this into QEMU 2.0, or it is now too late? I got
almost no feedback on take 6 (submitted November 27).
This is the main blocker to allow libvirt finally implement an equivalent to the
"enforce" flag, finally making the CPU configuration safe and sane (today
libvirt simply
16 matches
Mail list logo
