On 2011-12-05 14:36, Avi Kivity wrote:
> On 12/05/2011 03:29 PM, Jan Kiszka wrote:
>> On 2011-12-05 14:14, Avi Kivity wrote:
>>> On 12/05/2011 02:47 PM, Jan Kiszka wrote:
>
> (the memory API added unstable names, hopefully the QOM can take over
> the stable ones and we'll have a good wa
On 12/05/2011 03:29 PM, Jan Kiszka wrote:
> On 2011-12-05 14:14, Avi Kivity wrote:
> > On 12/05/2011 02:47 PM, Jan Kiszka wrote:
> >>>
> >>> (the memory API added unstable names, hopefully the QOM can take over
> >>> the stable ones and we'll have a good way to denote the unstable ones).
> >>>
> >>
On 2011-12-05 14:14, Avi Kivity wrote:
> On 12/05/2011 02:47 PM, Jan Kiszka wrote:
>>>
>>> (the memory API added unstable names, hopefully the QOM can take over
>>> the stable ones and we'll have a good way to denote the unstable ones).
>>>
>>
>> OK, maybe - or likely - we should make those device
On 12/05/2011 02:47 PM, Jan Kiszka wrote:
> >
> > (the memory API added unstable names, hopefully the QOM can take over
> > the stable ones and we'll have a good way to denote the unstable ones).
> >
>
> OK, maybe - or likely - we should make those device models have the same
> names in QOM once
On 2011-12-05 13:36, Avi Kivity wrote:
> On 12/05/2011 01:37 PM, Jan Kiszka wrote:
>> On 2011-12-05 11:01, Avi Kivity wrote:
>>> On 12/04/2011 11:38 PM, Jan Kiszka wrote:
>
> It should be also possible to migrate from non-KVM device to KVM
> version, different names would prevent that f
On 12/05/2011 01:37 PM, Jan Kiszka wrote:
> On 2011-12-05 11:01, Avi Kivity wrote:
> > On 12/04/2011 11:38 PM, Jan Kiszka wrote:
> >>>
> >>> It should be also possible to migrate from non-KVM device to KVM
> >>> version, different names would prevent that for ever.
> >>
> >> It is (theoretically) p
On 2011-12-05 11:01, Avi Kivity wrote:
> On 12/04/2011 11:38 PM, Jan Kiszka wrote:
>>>
>>> It should be also possible to migrate from non-KVM device to KVM
>>> version, different names would prevent that for ever.
>>
>> It is (theoretically) possible with these patches as the vmstate names
>> are t
On 12/04/2011 11:38 PM, Jan Kiszka wrote:
> >
> > It should be also possible to migrate from non-KVM device to KVM
> > version, different names would prevent that for ever.
>
> It is (theoretically) possible with these patches as the vmstate names
> are the same. KVM to TCG migration does not work
On 2011-12-04 22:31, Blue Swirl wrote:
> On Sun, Dec 4, 2011 at 16:35, Avi Kivity wrote:
>> On 12/04/2011 05:19 PM, Jan Kiszka wrote:
In the sense that kernel-apic is just an accelerated apic. From the
guest point of view, there's no difference, and that should be reflected
in
On Sun, Dec 4, 2011 at 16:35, Avi Kivity wrote:
> On 12/04/2011 05:19 PM, Jan Kiszka wrote:
>> >
>> > In the sense that kernel-apic is just an accelerated apic. From the
>> > guest point of view, there's no difference, and that should be reflected
>> > in the device model.
>>
>> That was my goal
On 12/04/2011 05:19 PM, Jan Kiszka wrote:
> >
> > In the sense that kernel-apic is just an accelerated apic. From the
> > guest point of view, there's no difference, and that should be reflected
> > in the device model.
>
> That was my goal as well: The guest should not notice the difference,
> b
On 2011-12-04 16:12, Avi Kivity wrote:
> On 12/04/2011 04:06 PM, Jan Kiszka wrote:
>> On 2011-12-04 15:04, Avi Kivity wrote:
>>> On 12/04/2011 03:51 PM, Jan Kiszka wrote:
>
> But the name becomes part of the save/restore ABI, so you can't.
Nope, the vmstate names are identical. Th
On 12/04/2011 04:06 PM, Jan Kiszka wrote:
> On 2011-12-04 15:04, Avi Kivity wrote:
> > On 12/04/2011 03:51 PM, Jan Kiszka wrote:
> >>>
> >>> But the name becomes part of the save/restore ABI, so you can't.
> >>
> >> Nope, the vmstate names are identical. That would ruin migration
> >> otherwise. It
On 2011-12-04 15:04, Avi Kivity wrote:
> On 12/04/2011 03:51 PM, Jan Kiszka wrote:
>>>
>>> But the name becomes part of the save/restore ABI, so you can't.
>>
>> Nope, the vmstate names are identical. That would ruin migration
>> otherwise. It's just the output of info qtree & co. that changes.
>
On 12/04/2011 03:51 PM, Jan Kiszka wrote:
> >
> > But the name becomes part of the save/restore ABI, so you can't.
>
> Nope, the vmstate names are identical. That would ruin migration
> otherwise. It's just the output of info qtree & co. that changes.
Oh, okay. I still think it's wrong, but now
On 2011-12-04 14:49, Avi Kivity wrote:
> On 12/04/2011 03:42 PM, Jan Kiszka wrote:
>> On 2011-12-04 14:31, Avi Kivity wrote:
>>> On 12/03/2011 01:17 PM, Jan Kiszka wrote:
From: Jan Kiszka
Introduce the alternative 'kvm-i8259' device model that exploits KVM
in-kernel acceleratio
On 12/04/2011 03:42 PM, Jan Kiszka wrote:
> On 2011-12-04 14:31, Avi Kivity wrote:
> > On 12/03/2011 01:17 PM, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Introduce the alternative 'kvm-i8259' device model that exploits KVM
> >> in-kernel acceleration.
> >>
> >> The PIIX3 initialization code
On 2011-12-04 14:31, Avi Kivity wrote:
> On 12/03/2011 01:17 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Introduce the alternative 'kvm-i8259' device model that exploits KVM
>> in-kernel acceleration.
>>
>> The PIIX3 initialization code is furthermore extended by KVM specific
>> IRQ route setu
On 12/03/2011 01:17 PM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Introduce the alternative 'kvm-i8259' device model that exploits KVM
> in-kernel acceleration.
>
> The PIIX3 initialization code is furthermore extended by KVM specific
> IRQ route setup. Moreover, GSI injection differs in KVM mode f
From: Jan Kiszka
Introduce the alternative 'kvm-i8259' device model that exploits KVM
in-kernel acceleration.
The PIIX3 initialization code is furthermore extended by KVM specific
IRQ route setup. Moreover, GSI injection differs in KVM mode from the
user space model. As we can dispatch ISA-range
20 matches
Mail list logo
