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
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 only Greg (temply
off), me
11 matches
Mail list logo
