Avi Kivity wrote:
We haven't seen any issue with the 2.6.22 boot decompressor. Which of
the four (fs, gs, ldt, or tr) were proving problematic and why?
It was tr that was affecting Workstation, since we boot through normal
BIOS path, and only a 16-bit task was loaded at this point.
Just t
Parag Warudkar wrote:
CONFIG_VMI seems to be broken, but I am not sure when - the last
kernel I was running was 2.6.22-rc4 which used to boot fine and use
VMI. Current git with same configuration causes the kernel to reboot
early. Logs below.
Deselecting CONFIG_VMI and rebuilding allows the kern
On Tue, 2007-10-23 at 01:35 +0200, Andi Kleen wrote:
> On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
> > On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote:
> > > On Mon, Oct 22, 2007 at 11:40:52AM -0700, Jeremy Fitzhardinge wrote:
> > > > Andi Kleen wrote:
> > > > > Jeremy
On Tue, 2007-10-16 at 00:03 +0200, Andi Kleen wrote:
> > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> > upsetting Xen
>
> This should be probably done unconditionally because it's a undefined
> dangerous condition everywhere.
Should be done unconditionally. One could remap
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
Rusty Russell wrote:
On Mon, 2006-12-25 at 01:53 +0100, Rene Herman wrote:
Rene Herman wrote:
Use adding __init to romsignature() (it's only called from probe_roms()
which is itself __init) as an excuse to submit a pedantic cleanup.
Hmm, by the way, if romsignature() needs this
Christoph Lameter wrote:
On Sat, 17 Feb 2007, Andi Kleen wrote:
That was always its intention. It's not a direct interface to a hypervisor,
but an somewhat abstracted interface to a "hypervisor driver"
I thought that hypervisor driver was some binary blob that can be directly
accesse
Andi Kleen wrote:
/*
+* Temporary hack: zero gs now that we've saved it so that Xen
+* doesn't try to reload the old value after changing the GDT
+* during the context switch. This can go away once Xen has
+* been taught to only reload %gs when it absolute
Anthony Liguori wrote:
Hi Zach,
It seems to me that the APIC paravirt_ops should be filled by
para_fill() instead of vmi_get_function(). vmi_get_function() returns
a nop when the relocation type is NONE. para_fill() leaves the native
code in place.
The native version of the apic write ops
Anthony Liguori wrote:
It would be really great if one could write a ROM by just specifying a
GetRelocationInfo function that always returns rel.type == NONE.
Right now, there are a half a dozen or so ops that have to be
implemented b/c of the vmi_get_function stuff.
Yes, I need to clean t
Andrew Morton wrote:
On Thu, 01 Mar 2007 02:34:02 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
I think on_each_cpu has a serious bug now that hrtimers has been
integrated. Basically, there are many callsites of clock_was_set, none
of which actually know the current interrupt
Rusty Russell wrote:
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
What would be really, really nice would be to statically check all
callsites that issue irq disables actually keep irqs disabled.
Presumably, there was a reason they disabled irqs, and re-enabling them
A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the
timer code to work for 2.6.21, which had a number of changes.
These should mostly be non-controversial and beneficial to all the
paravirt-ops work.
Zach <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubs
Highres timers no longer breaks with VMI turned on because the
required function is now exported even with hrtimers turned on.
Until hrtimers becomes the default for i386, we must still support
both timer modes, NO_HZ, and also NO_IDLE_HZ, which is paravirt
specific.
Signed-off-by: Zachary Amsden
diff -r 3e746c0ebcdf arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Fri Feb 02 13:54:53 2007 -0800
+++ b/arch/i386/kernel/paravirt.c Fri Feb 02 15:27:50 2007 -0800
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
/* nop stub */
static void native_nop(void
Fix the VMI-Timer no-idle-hz code.
Do not setup a one shot alarm if we are keeping the periodic alarm
armed. Additionally, since the periodic alarm can be run at a lower
rate than HZ, let's fixup the guard to the no-idle-hz mode appropriately.
This fixes the bug where the no-idle-hz mode might ha
The time initialization changed for i386 when some code moved into time_init.
This made it no longer possible to override the PIT / HPET, which broke
paravirt guests.
Subject: Fix PIT override bug for paravirt
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r acd12d5196c7 arc
the CS
value. We don't want to be fooled by BIOS / APM segments and
try to read those stacks, so only match KERNEL_CS.
I moved some stuff in segment.h to make it prettier.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 69d0339b9997 arch/i386/kernel/time.c
--- a/arch/i386/ke
Kprobes bugfix for paravirt compatibility - RPL on the CS when inserting
BPs must match running kernel.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
CC: Eric Biederman <[EMAIL PROTECTED]>
diff -r fad1c2108c13 arch/i386/kernel/kprobes.c
--- a/arch/i386/kernel/kprobes.cF
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several injuries.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 10fac6d484e2 d
header.
If anyone can find a cleaner way to do this, please implement it and I will
mail you a beer.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 08dce48f1a50 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Fri Feb 02 16:31:59 2007 -0800
+++ b/arch/i386/
Provide a paravirtualized way to get the CPU clock frequency; this allows much
of the code in tsc.c to be shared between all paravirt implementations.
Subject: Add a CPU KHZ calibration function to paravirt-ops
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r a08f195aa92a arc
Deliberate register clobber around performance critical inline code is great for
testing, bad to leave on by default. Many people ship with DEBUG_KERNEL turned
on, so stop making DEBUG_PARAVIRT default on.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 3a8033f42ecf arc
Because timer code moves around, and we might eventually move our init to a
late_time_init hook, save and restore IRQs around this code because it is
definitely not interrupt safe.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r dd4d4324a5b3 arch/i386/kernel/vmitime.c
--- a/arc
Zachary Amsden wrote:
#include "mach_timer.h"
@@ -102,9 +103,6 @@ unsigned long long sched_clock(void)
{
unsigned long long this_offset;
- if (unlikely(custom_sched_clock))
- return (*custom_sched_clock)();
-
/*
* Fall back to jiffies if
Rusty Russell wrote:
On Mon, 2007-02-05 at 19:52 -0800, Zachary Amsden wrote:
A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the
timer code to work for 2.6.21, which had a number of changes.
These should mostly be non-controversial and beneficial to all the
paravirt-ops
Arjan van de Ven wrote:
On Tue, 2007-02-06 at 16:11 +1100, Rusty Russell wrote:
On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
Indeed, I'm expecting to push lguest this week, and this code will
effect me, so I'd like to see this in
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:23PM -0800, Zachary Amsden wrote:
Provide a paravirtualized way to get the CPU clock frequency; this allows much
of the code in tsc.c to be shared between all paravirt implementations.
Is this really needed?
Honestly, no. But it
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several
missing?
I missed a title / signed-off on this guy.
Internally, sched_clock runs in units of nanoseconds, not CPU cycles.
This was wrong in my previous patch. Fix it so everyone can use the
same cycles_2_ns code in tsc.c.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Please wr
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Scheduled (or available) time and real time are good notions. Stolen
time is debatable. But TSC is basically just always wrong. That's
why I don't want to overload the rdtsc operation.
Well, in the Xen case it is actually
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Scheduled (or available) time and real time are good notions. Stolen
time is debatable. But TSC is basically just always wrong. That's
why I don't want to overload
Andi Kleen wrote:
-#ifdef CONFIG_S390
-#ifdef CONFIG_MATHEMU
- {
- .ctl_name = KERN_IEEE_EMULATION_WARNINGS,
- .procname = "ieee_emulation_warnings",
- .data = &sysctl_ieee_emulation_warnings,
- .maxlen =
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:02PM -0800, Zachary Amsden wrote:
The time initialization changed for i386 when some code moved into time_init.
This made it no longer possible to override the PIT / HPET, which broke
paravirt guests.
Looks still fragile. Can this be
alarm can be run at a lower
rate than HZ, let's fixup the guard to the no-idle-hz mode appropriately.
This fixes the bug where the no-idle-hz mode might have a higher interrupt
rate than the non-idle case.
Signed-off-by: Dan Hecht <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EM
Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something else.
Just magically defining ud
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I need to fix both of them actually. This is virtual hardware,
but when you grab focus on a VM,
Andi Kleen wrote:
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I
Dmitry Torokhov wrote:
However I am not really fond of idea of adding constructs like this
all over the code:
#define USE_REAL_TIME_DELAY_I_REALLY_MEAN_IT_THIS_TIME_I_SWEAR
as the time passes... Drivers should be blissfully ignorant of being
run on virtual hardware.
I agree in general, but t
Rusty Russell wrote:
On Fri, 2007-02-09 at 01:35 -0800, Andrew Morton wrote:
On Fri, 09 Feb 2007 20:20:27 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote:
+#define log(...) \
+ do {\
+ m
Andi Kleen wrote:
Yes, it is a bit, umm, innovative. If it is going to be kept, even if
just for devel logging, you should disable interrupts around it.
Changing segments is not a normal thing to do.
Actually that wouldn't be needed because interrupts are not allowed to do any
user acc
Andi Kleen wrote:
My bad, I fell for the same mistake as everyone. Set_fs is just way too
You could change the name. Only 654 occurrences all over the tree @)
I'm preparing a patch. +not. This legacy thing is certainly taking a
long time to disappear. Long live x86!
It is only one of many horrors in the i386 boot code, but let's rename
the non-perpcu cpu_gdt_descr to early_gdt_descr (not boot_gdt_descr,
that's something else...)
Finally, someone not just noticed, but fixed it! Thank you Rusty. Was
on my todo list, but never bubbled up.
Jeremy Fitzhardinge wrote:
@@ -261,10 +261,12 @@ void pgd_ctor(void *pgd, struct kmem_cac
spin_unlock_irqrestore(&pgd_lock, flags);
}
-/* never called when PTRS_PER_PMD > 1 */
-void pgd_dtor(void *pgd, struct kmem_cache *cache, unsigned long unused)
+static void pgd_dtor(pgd_t *pgd)
Jeremy Fitzhardinge wrote:
Add the "nosegneg" fake capabilty to the vsyscall page notes. This is
used by the runtime linker to select a glibc version which then
disables negative-offset accesses to the thread-local segment via
%gs. These accesses require emulation in Xen (because segments are
tru
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I don't like this because now a kernel compiled with both CONFIG_XEN
and CONFIG_VMI has "nosegneg" turned on. We don't actually require
this for performance or correctness, so it would be nice to be able to
dynamically tu
Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
I assume you plan to eventually get all this stuff working but just
want to prevent configurations that the Xen paravirt-ops isn't ready
for at the moment?
Instead can you do it this way:
config XEN
depends on PARAVIRT && !PREEMPT && HZ_100 &&
Jeremy Fitzhardinge wrote:
Wrap the paravirt_ops members we want to export in wrapper functions.
Since we binary-patch the critical ones, this doesn't make a speed
impact.
I moved drm_follow_page into the core, to avoid having to wrap the
various pte ops. Unlining kernel_fpu_end and using that
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
This turned out really hideous looking to me. Can't we split the
struct into GPL'd and non-GPL'd functions instead? We still have the
same granularity, and none of this function call to an indirect
function call nonsense.
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Ok. As long as we plan on patching CR2 and CR0 / clts accessors for
FPU save during context switch and page fault paths in the future.
That's up to each backend, right? Or do these need to be patched for a
correctness reason?
Pavel Machek wrote:
On Thu 2007-02-08 07:36:12, Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized har
Alan wrote:
We'd have to audit and figure out what udelays are for hardware and
which are not, but the evidence is that the vast majority of them are
for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment wi
Alan wrote:
??? I fail to see the code bloat and also the fast paths. Which fast
paths use udelay?
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
Ok, I buy that. A 486DX / 33 Mhz processor takes 10 cycles to issue a
CALL / RET p
Pavel Machek wrote:
You know it is ugly. Alan demonstrated it even hurts performance, but
being ugly is the main problem.
No argument with that. Well, we're ok with dropping it. Actually,
reverting the entire set of udelay changes now seems wise. The same bug
that happened with i8042 c
Jeremy Fitzhardinge wrote:
Remove the ctor for the pgd cache. There's no point in having the
cache machinery do this via an indirect call when all pgd are freed in
the one place anyway.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Acked-by: Zachary Amsden <[E
gments are
truncated to protect the hypervisor address space) and avoiding them
provides a measurable performance boost.
Signed-off-by: Ian Pratt <[EMAIL PROTECTED]>
Signed-off-by: Christian Limpach <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Acke
Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)
Xen is no longer a sub-architecture, so the X86_XEN subarch config
h Xen 3.0.4 but it's a dom0 only thing so it
doesn't appear in this patchset.
Ok but we still need to get the failure to user space for domU instead
of trying what works on real hardware and failing.
Eric
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe fr
Keir Fraser wrote:
On 16/2/07 07:25, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case
that preempt_disable() I spotted is wrong-and-unneeded.
Why doesn't Xen work with preemption??
I've forgotten the details.
Keir Fraser wrote:
On 16/2/07 10:19, "Zachary Amsden" <[EMAIL PROTECTED]> wrote:
Doesn't stop_machine_run already take care of getting you out of all
kernel threads? So you can only be sleeping, not preempted, in which
case, this might not be an issue?
It
Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
t
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. Th
Keir Fraser wrote:
On 16/2/07 17:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
that we are going to have some na
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have pre
slow.
This requires moving the GS load before the load of GS_BASE, so just move
all the segments loads there to keep them together in the code.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.19/arch/x86_64/ke
ff-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
Thanks Adrian! I have some more bugfix / cleanup patches queued up, but
somehow I think you magically avoided creating conflicts with them.
Zach
-
To unsubscribe from this list: send the line "un
bool "Paravirtualization support (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ depends on !(X86_VISWS || X86_VOYAGER)
help
Paravirtualization is a way of running multiple instances of
Linux on the same machine, under a hypervisor. This opt
Jeremy Fitzhardinge wrote:
Hi Andi,
What problem do they cause together? There's certainly no problem with
Xen+vdso (in fact, its actually very useful so that it picks up the
right libc with Xen-friendly TLS).
Methinks the compat VDSO support got broken in the config? Paravirt +
COMPAT_V
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Hi Andi,
What problem do they cause together? There's certainly no problem with
Xen+vdso (in fact, its actually very useful so that it picks up the
right libc with Xen-friendly TLS).
Methink
Add VMI SMP boot hooks. This is a bit unclean (the #ifdef's), but I
wanted a quick and dirty hack to get SMP up and working.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/i386/kernel/paravirt.c
+++
VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r d8711b11c1eb arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800
+++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800
@@ -192,6 +
, there is also no demonstrated need for this
extra complexity.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 320f0d4d2280 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Dec 12 13:50:50 2006 -0800
+++ b/arch/i386/kernel/paravirt.c Tue Dec 12 13:50:53 2006
semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So for now, VMI timer is a separate module.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r d1ec5a6e3e8c arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Dec 12 13:53:09 2006 -0800
+++
The VMI backend uses explicit page type notification to track shadow
page tables. The allocation of page table roots is especially tricky.
We want to clone the root for non-PAE mode while it is protected under
the pgd lock.
Signed-off-by: Zachary Amsden <[EMAIL PROTEC
Chuck Ebbert wrote:
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 12 Dec 2006 14:54:30 -0800, Chros Wright wrote:
--- a/arch/i386/kernel/process.cTue Dec 12 13:50:50 2006 -0800
+++ b/arch/i386/kernel/process.cTue Dec 12 13:50:53 2006 -0800
@@ -665,6 +665,37 @@ struct task_struct fastcall
.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Subject: SMP boot hook for paravirt
diff -r acfb7a15715f arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Thu Dec 14 16:22:03 2006 -0800
+++ b/arch/i386/kernel/paravirt.c Thu Dec 14 16:51:48 2006 -0800
@@ -572,5 +572,7 @@
semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So for now, VMI timer is a separate module.
Subject: VMI timer patches
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 77e4058e936b arch/i386/Kconfig
--- a/arch/i386/Kconfig Thu Dec 14
These are the patches for the VMI backend to paravirt-ops. Base
kernel where I tested them was 2.6.19-git20.
Basically, there are only a couple of hooks needed that were left
out of the initial paravirt-ops merge, and then the backend code
is a very straightforward implementation of the paravirt-
ff-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -545,6 +545,12 @@ struct paravirt_ops paravirt_ops = {
.flush_tlb_kernel = native_flush
Fairly straightforward implementation of VMI backend for paravirt-ops.
Subject: VMI backend for paravirt-ops
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r d8711b11c1eb arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800
+++ b/arch/i386/Kconfig Tue Dec 12 13
, there is also no demonstrated need for this
extra complexity.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Subject: Paravirt CPU hypercall batching mode
diff -r 01f2e46c1416 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Thu Dec 14 14:26:24 2006 -0800
+++ b/arch/i386/
paravirt guests
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 8110943fd7ad arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.cThu Dec 14 16:15:20 2006 -0800
+++ b/arch/i386/kernel/process.cThu Dec 14 16:21:57 2006 -0800
@@ -665,6 +665,15 @@ struct task_struct fa
Hotfixes for VMI code from -rc2-mm1. This fixes several critical
problems, a compile fix for +PARAVIRT+VMI-SMP, a bogus indirect
call to a VMI function on native, and corrects the FS/GS startup
state for SMP to match the new FS/GS PDA changes.
-
To unsubscribe from this list: send the line "unsubs
In paravirt builds with VMI compiled in, vmi_bringup is called
unconditionally, not via a paravirt-ops table (as no other hypervisor
uses the APIC startup technique). Make the calls to setup VMI state
conditional on the presence of the VMI ROM.
Signed-off-by: Zachary Amsden <[EMAIL PROTEC
The variable no_timer_check does not exist in UP builds; don't try to
set it in the vmi init code.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 21d7686ee318 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cThu Jan 04 15:23:30 2007 -0800
+++ b/arch/i386/kernel/vmi.c
Now that Jeremy's change to move the kernel PDA to %fs has arrived,
convert the AP processor setup for SMP to use FS instead of GS.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 2ac108843573 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cThu Jan 04 20:01:52 2007
Ingo Molnar wrote:
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardware cr3-cache feature
of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
the patch is against 2.6.20-rc3 + KVM trunk and can be found
Ingo Molnar wrote:
Subject: [patch] paravirt: isolate module ops
From: Ingo Molnar <[EMAIL PROTECTED]>
only export those operations to modules that have been available to them
historically: irq disable/enable, io-delay, udelay, etc.
this isolates that functionality from other paravirtualizati
Ingo Molnar wrote:
Subject: [patch] paravirt: isolate module ops
From: Ingo Molnar <[EMAIL PROTECTED]>
only export those operations to modules that have been available to them
historically: irq disable/enable, io-delay, udelay, etc.
this isolates that functionality from other paravirtualizati
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
What you really want is more like
EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
yep. Not a big issue - what is important is to put the paravirt ops into
the read-only section so that it's somewhat harder for
Arjan van de Ven wrote:
I would suggest a slightly different carving. For one, no TLB flushes.
If you can't modify PTEs, why do you need to have TLB flushes? And I
would allow CR0 read / write for code which saves and restores FPU state
no that is abstracted away by kernel_fpu_begin/e
Ingo Molnar wrote:
* Rusty Russell <[EMAIL PROTECTED]> wrote:
+EXPORT_SYMBOL(clts);
+EXPORT_SYMBOL(read_cr0);
+EXPORT_SYMBOL(write_cr0);
mark these a _GPL export. Perhaps even mark the symbol deprecated, to be
unexported once we fix raid6.
read / write cr0 must not be GPL, since
Daniel Walker wrote:
On Fri, 2006-12-15 at 14:27 -0800, [EMAIL PROTECTED] wrote:
+
+config NO_IDLE_HZ
+ bool
+ depends on PARAVIRT
+ default y
+ help
+ Switches the regular HZ timer off when the system is going
idle.
+ This helps a hypervisor detect tha
Daniel Walker wrote:
On Sat, 2007-01-06 at 12:37 -0800, Zachary Amsden wrote:
There is already a dynamic tick (NO_HZ) system in the -mm tree .. Given
that this implementation seems unnecessary. Why do you need another
different system to do this?
We don't. This was written b
Rusty Russell wrote:
+int paravirt_write_msr(unsigned int msr, u64 val);
If binary modules using debug registers makes us nervous, the
reprogramming MSRs is also similarly bad.
+void raw_safe_halt(void);
+void halt(void);
These shouldn't be done by modules, ever. Only the scheduler
Daniel Walker wrote:
On Fri, 2006-12-15 at 14:27 -0800, [EMAIL PROTECTED] wrote:
+
+unsigned long long vmi_sched_clock(void)
+{
+ return read_available_cycles();
+}
+
This sched_clock is likely broken if it's returning something other than
nanoseconds. It looks like cycles, but
Rusty Russell wrote:
On Sat, 2007-01-06 at 12:55 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
+int paravirt_write_msr(unsigned int msr, u64 val);
If binary modules using debug registers makes us nervous, the
reprogramming MSRs is also similarly bad.
Yes, but this is
Daniel Walker wrote:
On Sat, 2007-01-06 at 23:26 -0800, Andrew Morton wrote:
diff -puN
include/asm-i386/spinlock.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix
include/asm-i386/spinlock.h
---
a/include/asm-i386/spinlock.h~spin_lock_irq-enable-interrupts-while-spi
Zachary Amsden wrote:
Now it fails with CONFIG_PARAVIRT off .
Now it compiles both ways. Or at least asm-offsets.c does. Testing
full build...
Zach
Yep, that lipstick makes the cat shine.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Andrew Morton wrote:
On Thu, 19 Oct 2006 17:09:22 -0700
Zachary Amsden <[EMAIL PROTECTED]> wrote:
Add a way to disable the timer IRQ routing check via a boot option. The
VMI timer code uses this to avoid triggering the pester Mingo code, which
probes for some very unusual and
101 - 200 of 371 matches
Mail list logo
