On Wed, 2007-07-11 at 09:34 +0800, Dong, Eddie wrote:
> No, what you mean is only for external irq. IDT_Vectoring can happen for
> any exception injection.
Well, yes, but that really is just an attribute the irq.deferred
"source" needs to maintain, right? I had been thinking of adding
something
> I had already solved these types of issues neatly in the lapic branch,
> so perhaps you can model a solution from that (at least in
> spirit). For
> instance, the irq.deferred source has the IDT_Vectoring state,
> irq.pending has the vcpu interrupt state (NMI, EXTINT, etc),
> kvm->isa_int has t
On Tue, 2007-07-10 at 22:08 +0800, Dong, Eddie wrote:
> > I don't think live migration is particularly difficult. You
> > need a APIs
> > to read and write the PIC+LAPIC states, and you write the
> > state into the
>
> This is partily true party not.
I agree with Avi here. The system is alread
> I don't think live migration is particularly difficult. You
> need a APIs
> to read and write the PIC+LAPIC states, and you write the
> state into the
This is partily true party not. Like what did in Xen, a live migration
in kernel side need to consider not only device state, but also cpu
stat
Dong, Eddie wrote:
>> If we release a kernel with pic but not lapic, and userspace that
>> defaults to user-pic+lapic, then that kernel will not work
>> with a newer
>> userspace that defaults to in-kernel pic+lapic.
>>
>> We need to switch in one go. I don't mind checking in patches to the
>> lap
> If we release a kernel with pic but not lapic, and userspace that
> defaults to user-pic+lapic, then that kernel will not work
> with a newer
> userspace that defaults to in-kernel pic+lapic.
>
> We need to switch in one go. I don't mind checking in patches to the
> lapic2 branch, and continua
Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
>
>> Avi Kivity wrote:
>>
>>> Dong, Eddie wrote:
>>>
Avi:
To make lapic code into mainline earlier, I am thinking what
should the user space code look like. If we wait till lapic branch
has all same functionality a
[EMAIL PROTECTED] wrote:
> Avi Kivity wrote:
>> Dong, Eddie wrote:
>>> Avi:
>>> To make lapic code into mainline earlier, I am thinking what
>>> should the user space code look like. If we wait till lapic branch
>>> has all same functionality as mainline have today i.e. live
>>> migration, all
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi:
>> To make lapic code into mainline earlier, I am thinking what
>> should the user space code look like. If we wait till lapic branch
>> has all same functionality as mainline have today i.e. live
>> migration, all guests etc, we may have very lo
Dong, Eddie wrote:
> Avi:
> To make lapic code into mainline earlier, I am thinking what
> should the user space code look like. If we wait till lapic branch has
> all same functionality as mainline have today i.e. live migration, all
> guests etc, we may have very long way to go given that
10 matches
Mail list logo
