From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Simon Horman <horms@verge.net.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Matthew Wilcox <matthew@wil.cx>,
tglx@linutronix.de, mingo@redhat.com,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
macro@linux-mips.org, kamezawa.hiroyu@jp.fujitsu.com,
eike-kernel@sf-tec.de
Subject: Re: [PATCH 1/2] x86: ioremap: fix wrong physical address handling
Date: Thu, 08 Jul 2010 22:33:08 -0700 [thread overview]
Message-ID: <4C36B494.6060801@goop.org> (raw)
In-Reply-To: <20100709042421.GB2951@verge.net.au>
On 07/08/2010 09:24 PM, Simon Horman wrote:
>> I think it would be a pretty large change. From the Xen's perspective,
>> any machine even approximately approaching the 2^44 limit will be
>> capable of running Xen guests in hvm mode, so PV isn't really a concern.
>>
> Hi Jeremy,
>
> Is the implication of that statement that HVM is preferred where
> supported by HW?
>
I wouldn't go that far; the PV vs HVM choice is pretty complex, and
depends on what your workload is and what hardware you have available.
All I meant was what I said: that if you're running on a machine with a
large amount of memory, then you should run your 32-bit domains as HVM
rather than PV. Though Xen could easily keep domains limited to memory
that they can actually use (it already does this, in fact).
J
next prev parent reply other threads:[~2010-07-09 5:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 1:28 [BUG][PATCH 0/2 (v.2)] x86: ioremap() problem in X86_32 PAE Kenji Kaneshige
2010-06-17 1:30 ` [PATCH 1/2] x86: ioremap: fix wrong physical address handling Kenji Kaneshige
2010-06-17 2:50 ` Matthew Wilcox
2010-06-17 4:22 ` H. Peter Anvin
2010-06-17 4:55 ` Kenji Kaneshige
2010-06-17 6:03 ` H. Peter Anvin
2010-06-17 6:21 ` Kenji Kaneshige
2010-06-17 9:35 ` Jeremy Fitzhardinge
2010-06-17 9:38 ` Jeremy Fitzhardinge
2010-06-17 13:46 ` H. Peter Anvin
2010-06-18 0:32 ` Kenji Kaneshige
2010-06-18 0:22 ` Kenji Kaneshige
2010-07-09 4:24 ` Simon Horman
2010-07-09 5:33 ` Jeremy Fitzhardinge [this message]
2010-07-09 6:10 ` Simon Horman
2010-06-17 6:28 ` Kenji Kaneshige
2010-07-09 18:31 ` [tip:x86/mm] x86, pae: Fix handling of large physical addresses in ioremap tip-bot for Kenji Kaneshige
2010-07-09 18:43 ` H. Peter Anvin
2010-06-17 1:31 ` [PATCH 2/2] x86: ioremap: fix normal ram range check Kenji Kaneshige
2010-07-09 18:31 ` [tip:x86/mm] x86, ioremap: Fix " tip-bot for Kenji Kaneshige
-- strict thread matches above, loose matches on Subject: below --
2010-06-18 3:21 [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE Kenji Kaneshige
2010-06-18 3:22 ` [PATCH 1/2] x86: ioremap: fix wrong physical address handling Kenji Kaneshige
2010-06-18 11:07 ` Jeremy Fitzhardinge
2010-06-21 1:40 ` Kenji Kaneshige
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=4C36B494.6060801@goop.org \
--to=jeremy@goop.org \
--cc=eike-kernel@sf-tec.de \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=matthew@wil.cx \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.