Re: [PATCH v4] enable x2APIC without interrupt remapping under KVM

[Avi Kivity <avi@redhat.com>]

On 06/30/2009 08:00 PM, Eric W. Biederman wrote:
> Gleb Natapov<gleb@redhat.com>  writes:
>
>    
>> On Tue, Jun 30, 2009 at 12:18:19AM -0700, Yinghai Lu wrote:
>>      
>>> how about kexec second kernel in KVM ?
>>>
>>> x2apic_preenabled will be set in second kernel.
>>>
>>>        
>> By the way anybody knows why kexec does not use BIOS reset code
>> (cmos 0xf offset) to jump into new kernel after hard reset?
>>      
>
> After a hard reset.  That simply isn't possible. A hard
> reset clears everything even memory.
>
>    

So the jump-to-vector reset code cannot work on real hardware?  It works 
in qemu, but of course that's easy.

> You might be able to get a full cpu reset but not a reset of the I/O
> devices.
>
> The premise of kexec is that we are doing things on our own, and don't
> get a 3rd piece of software involved that has not been heavily tested
> on the path we want to use.  Occassionally it is a pain to do everything
> ourselves but at least when we do and we test it we know it is going
> to work.
>
> Cpu designers lately seem fond of adding features that require all
> kind of coordination to turn on and off.  We handle the hardware
> virtualization mode features now, and if x2apic has similar problems
> being turned on and off I am certain we can handle that case in a
> similar fashion.
>
> When we can my preference is to keep code like that out of the
> kexec on panic path if we can figure out how to write the software
> to do something reasonable.
>
> Once we figure out how to work without putting the interrupt controllers
> in legacy mode to handle the timer interrupts I expect all kinds of
> things will become simpler.
>    

I think it makes sense to add full reset support as a non-default 
option.  Leaving hardware running and dmaing left and right has its risks.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.