LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Alexander van Heukelum <heukelum@fastmail.fm>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Mark McLoughlin <markmc@redhat.com>,
Alexander van Heukelum <heukelum@mailshack.com>,
Ingo Molnar <mingo@elte.hu>, Ian Campbell <ijc@hellion.org.uk>,
Andi Kleen <ak@suse.de>, Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2
Date: Tue, 04 Mar 2008 09:05:37 -0800 [thread overview]
Message-ID: <47CD8161.4090901@zytor.com> (raw)
In-Reply-To: <1204649476.5048.1240509149@webmail.messagingengine.com>
Alexander van Heukelum wrote:
>
> If this is indeed not executed, is there a way to detect whether
> we can expect the environment to behave like a normal pc in terms
> of magic addresses, bios areas, isa reserved address space and so
> on?
>
The subarch stuff (boot_params.hdr.hardware_subarch) is indeed executed,
at least with newer PV guests.
However, as far as this kind of stuff, one really have to wonder to what
extent the PV users really care about how much they perturb the guests.
The canonical view of virtualization is that you should perturb your
guests as little as possible, but that doesn't really seem to be
considered in the observable bits of the PV universe as far as I can tell.
A *massive* issue with hooks -- including paravirt_ops -- is that they
are largely undocumented both in code and in specification, and usually
hard-code the underlying implemenentation at a specific point in time: I
have yet to see any sort of specification document for paravirt_ops, and
most of the hooks are simply empty on hardware. This means that the
burden has shifted onto the kernel maintainers to test every possible
paravirt_ops client, because it is quite literally the only way to know
when it's broken.
I'm starting to feel that the PV clients need to document their
environments and their constraints better for the benefit of the core
maintainers.
-hpa
next prev parent reply other threads:[~2008-03-04 17:10 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 17:46 [PATCH] Fix alignment of early reservation for EBDA Alexander van Heukelum
2008-02-24 19:27 ` Andi Kleen
2008-02-24 19:41 ` Ingo Molnar
2008-02-24 20:53 ` Alexander van Heukelum
2008-02-25 2:18 ` H. Peter Anvin
2008-02-25 16:54 ` Alexander van Heukelum
2008-02-25 17:01 ` Ingo Molnar
2008-02-25 18:07 ` [PATCH] reserve_early end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-25 18:13 ` H. Peter Anvin
2008-02-25 19:46 ` Alexander van Heukelum
2008-02-25 21:17 ` H. Peter Anvin
2008-02-26 9:30 ` Ingo Molnar
2008-02-27 14:26 ` Andi Kleen
2008-02-27 14:38 ` [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective Andi Kleen
2008-02-27 16:44 ` H. Peter Anvin
2008-02-27 20:01 ` Alexander van Heukelum
2008-02-28 13:13 ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Alexander van Heukelum
2008-02-28 13:28 ` [RFC] use realmode code to reserve end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-28 21:12 ` Ian Campbell
2008-02-28 21:14 ` H. Peter Anvin
2008-02-28 23:16 ` Ian Campbell
2008-02-29 20:00 ` Ingo Molnar
2008-03-04 11:41 ` Mark McLoughlin
2008-03-04 14:33 ` Ingo Molnar
2008-03-04 15:12 ` Ian Campbell
2008-03-04 15:13 ` Jeremy Fitzhardinge
2008-03-04 15:25 ` Ingo Molnar
2008-03-04 16:02 ` Jeremy Fitzhardinge
2008-03-04 16:15 ` Ingo Molnar
2008-03-04 16:15 ` Mark McLoughlin
2008-03-04 16:23 ` Ingo Molnar
2008-03-04 17:44 ` Jeremy Fitzhardinge
2008-03-05 15:59 ` Eduardo Habkost
2008-03-05 16:08 ` H. Peter Anvin
2008-03-05 16:53 ` Eduardo Habkost
2008-03-05 17:28 ` H. Peter Anvin
2008-03-05 17:28 ` Jeremy Fitzhardinge
2008-03-05 17:38 ` H. Peter Anvin
2008-03-05 16:38 ` Jeremy Fitzhardinge
2008-03-05 17:27 ` H. Peter Anvin
2008-02-28 21:09 ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Ian Campbell
2008-02-29 11:49 ` Alexander van Heukelum
2008-02-29 17:14 ` Mark McLoughlin
2008-02-29 18:38 ` Alexander van Heukelum
2008-02-29 18:44 ` H. Peter Anvin
2008-02-29 18:56 ` Alexander van Heukelum
2008-02-29 22:06 ` Mark McLoughlin
2008-02-29 22:26 ` Alexander van Heukelum
2008-03-01 16:09 ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Alexander van Heukelum
2008-03-01 16:12 ` [PATCH] reserve end-of-conventional-memory to 1MB on 64-bit add-on Alexander van Heukelum
2008-03-04 11:44 ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Mark McLoughlin
2008-03-04 13:31 ` Alexander van Heukelum
2008-03-04 14:49 ` Ingo Molnar
2008-03-04 15:16 ` Mark McLoughlin
2008-03-04 15:24 ` Ingo Molnar
2008-03-04 15:18 ` Jeremy Fitzhardinge
2008-03-04 16:51 ` Alexander van Heukelum
2008-03-04 17:05 ` H. Peter Anvin [this message]
2008-03-04 17:11 ` Jeremy Fitzhardinge
2008-03-04 18:57 ` [PATCH] reserve end-of-conventional-memory to 1MB, 32-bit, use paravirt_enabled Alexander van Heukelum
2008-03-04 19:12 ` [PATCH] reserve end-of-conventional-memory to 1MB, 64-bit, " Alexander van Heukelum
2008-02-27 14:25 ` [PATCH] Fix alignment of early reservation for EBDA Andi Kleen
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=47CD8161.4090901@zytor.com \
--to=hpa@zytor.com \
--cc=ak@suse.de \
--cc=heukelum@fastmail.fm \
--cc=heukelum@mailshack.com \
--cc=ijc@hellion.org.uk \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markmc@redhat.com \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--subject='Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).