lkml.org 
[lkml]   [2009]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5] enable x2APIC without interrupt remapping under KVM
On 07/05/2009 03:22 AM, Eric W. Biederman wrote:
> Gleb Natapov<gleb@redhat.com> writes:
>
>
>>> Therefore I don't see the point of supporting one without the other.
>>>
>> x2apic provide us with other benefits as commit message explains, and
>> doesn't add any problems that we don't have now already.
>>
>
> If this code has a legitimate place on real hardware I am all for it.
>

As I understood it, x2apic without interrupt remapping will work but is
not a validated configuration. Interrupt remapping is only necessary if
you have > 255 hardware threads + ioapics. The features are logically
separate and are only tied together by the vendor's validation practices.


> If this is just a hack to make virtualization faster I don't like the
> extra code paths in the middle core architecture code. That will
> be a support burden for the foreseeable future. More code to
> test etc.
>

There aren't any extra code paths. The patch separates a long function
into two smaller ones that each do one thing, and adds a check for kvm.

Maybe it should be split into two to makes that clear. The first patch
simplifies the code, the second adds a kvm check.

> Quickly skimming the patch it just appears to stir a mess.
> Plus it adds weird paravirtualization checks, ???
>

It adds exactly one "weird paravirtualization check ???", then one
described in the patch description.

> If we are going to have a special code path for virtual hardware
> can we do it right and have something nice to use that makes life
> simpler?

You mean, instead of adding one check in an initialization code path,
create a new irqchip, a way of describing the topology to the guest,
support code in kvm (as host)?

> For what we want to do with ioapics they suck and are
> really not suitable. The only thing that recommends them is that
> they are standard. But you are deviating from the standard so
> what is the point.
>

All of the code continues to work.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



\
 
 \ /
  Last update: 2009-07-05 07:31    [W:0.095 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site