From: ebiederm@xmission.com (Eric W. Biederman)
To: Gleb Natapov <gleb@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Suresh Siddha <suresh.b.siddha@intel.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sheng Yang <sheng@linux.intel.com>,
"kvm\@vger.kernel.org" <kvm@vger.kernel.org>,
"avi\@redhat.com" <avi@redhat.com>
Subject: Re: [PATCH v5] enable x2APIC without interrupt remapping under KVM
Date: Sat, 04 Jul 2009 17:22:01 -0700 [thread overview]
Message-ID: <m1prcgyo5y.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090704155002.GC24641@redhat.com> (Gleb Natapov's message of "Sat\, 4 Jul 2009 18\:50\:02 +0300")
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.
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.
Quickly skimming the patch it just appears to stir a mess.
Plus it adds weird paravirtualization checks, ???
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? 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.
Eric
next prev parent reply other threads:[~2009-07-05 0:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-01 13:30 [PATCH v5] enable x2APIC without interrupt remapping under KVM Gleb Natapov
2009-07-01 21:00 ` Suresh Siddha
2009-07-03 8:29 ` Ingo Molnar
2009-07-04 9:35 ` Eric W. Biederman
2009-07-04 9:55 ` Gleb Natapov
2009-07-04 14:33 ` Eric W. Biederman
2009-07-04 15:50 ` Gleb Natapov
2009-07-05 0:22 ` Eric W. Biederman [this message]
2009-07-05 5:27 ` Avi Kivity
2009-07-04 15:20 ` Avi Kivity
2009-07-05 14:32 ` [PATCH] " Gleb Natapov
2009-07-10 13:56 ` Ingo Molnar
2009-07-12 12:06 ` Gleb Natapov
2009-07-18 14:07 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1prcgyo5y.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sheng@linux.intel.com \
--cc=suresh.b.siddha@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox