Re: [PATCH 0/1] x2apic implementation for kvm

From: Avi Kivity <avi@redhat.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: Gleb Natapov <gleb@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH 0/1] x2apic implementation for kvm
Date: Mon, 25 May 2009 13:49:04 +0300	[thread overview]
Message-ID: <4A1A77A0.7040207@redhat.com> (raw)
In-Reply-To: <200905251759.08421.sheng@linux.intel.com>

Sheng Yang wrote:
> On Monday 25 May 2009 17:22:34 Avi Kivity wrote:
>   
>> Sheng Yang wrote:
>>     
>>> I think that means the PV interface for lapic. And yes, we can support it
>>> follow MS's interface, but x2apic still seems another story as you
>>> noted... I still don't think support x2apic here would bring us more
>>> benefits.
>>>       
>> x2apic has the following benefit:
>>
>> - msr exits are faster than mmio (no page table walk, emulation)
>>     
>
> Need PV(at least part of). I don't think Hyper-V considered this, and not sure 
> the community's aptitude.
>   

Hyper-V does define MSRs for local apic access, as far as I can tell 
they're identical to x2apic except for the msr index.

>> - potential to support large guests once we add interrupt remapping
>>     
>
> Then it can be added before we have it. Compared to the workload, x2apic is 
> not the problem, interrupt remapping/VT-d is. 
>   

I'd like to have the benefit sooner.  x2apic provides two user-visible 
benefits: performance and large guests.  I don't want performance to 
wait for large guests.

>> - shared code with the Hyper-V paravirt interface
>>     
>
> So I think the key thing are ICR related(and seems no data available 
> currently). Compare the benefit of ICR improve(can it improved in another way? 
> Does Hyper-V interface has related things?), and the workload of x2apic 
> virtualization as well as guest OS support, well, I don't know, but not 
> optimistic

x2apic, without interrupt remapping, is fairly simple.

-- 
error compiling committee.c: too many arguments to function