From: Ingo Molnar <mingo@elte.hu>
To: Avi Kivity <avi@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Joerg Roedel <joerg.roedel@amd.com>,
Benjamin Serebrin <benjamin.serebrin@amd.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>
Subject: Re: kvm vmload/vmsave vs tss.ist
Date: Thu, 25 Dec 2008 16:17:57 +0100 [thread overview]
Message-ID: <20081225151757.GA25117@elte.hu> (raw)
In-Reply-To: <49539FD0.7070103@redhat.com>
* Avi Kivity <avi@redhat.com> wrote:
> I would like to remove this limitation. I see several ways to go about
> it:
>
> 1. Drop the use of IST
>
> This would reduce the (perceived) reliability of the kernel and would
> probably not be welcomed.
> hpa/Ingo, any opinions?
i think we should actually do #1 unconditionally.
ISTs are bad for the native kernel too. They have various nasty
complications in the stack walker (and hence they _reduce_ reliability in
practice), and they are non-preemptible as well. Plus we have the
maximum-stack-footprint ftrace plugin now, which can remove any perception
about how bad the worst-case stack footprint is in practice.
If it ever becomes an issue we could also soft-switch to a larger (per
CPU) exception stack from the exception handlers themselves. The
architectural stack footprint of the various critical exceptions are
calculatable and low - so we could switch away and get almost the kind of
separation that ISTs give. There's no deep reason to actually make use of
hw switched ISTs.
So feel free to send a patch that just standardizes the critical
exceptions to use the regular kernel stack. (I havent actually tried this
but it should be relatively simple to implement. Roadblocks are possible.)
Ingo
next prev parent reply other threads:[~2008-12-25 15:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-25 14:59 kvm vmload/vmsave vs tss.ist Avi Kivity
2008-12-25 15:17 ` Ingo Molnar [this message]
2008-12-25 15:46 ` Avi Kivity
2008-12-25 16:21 ` Ingo Molnar
2008-12-25 16:42 ` Ingo Molnar
2008-12-25 17:40 ` Avi Kivity
2008-12-25 17:58 ` Ingo Molnar
2008-12-25 18:12 ` Avi Kivity
2008-12-25 18:18 ` Ingo Molnar
2008-12-25 18:19 ` Avi Kivity
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=20081225151757.GA25117@elte.hu \
--to=mingo@elte.hu \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=benjamin.serebrin@amd.com \
--cc=hpa@zytor.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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