Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
I had just sent this out for internal review...
I think Jan's approach is better if it works (since there's no
compromise), but this is better if you want to get something working
in the near term.
yeah.
Jeremy Fitzhardinge wrote:
I think Jan's approach is better if it works (since there's no
compromise), but this is better if you want to get something working in
the near term.
Is Jan dynamically relinking the vdso at runtime? Because that is what
we will need. Adding support for
PAT_VDSO
kernels to relocate the fixmap as well, just disable the VDSO if they do so.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r fad0910252d2 arch/i386/kernel/sysenter.c
--- a/arch/i386/kernel/sysenter.c Mon Mar 05 15:24:04 2007 -0800
+++ b/arch/i386/kernel/sysenter.c
Ingo Molnar wrote:
there's no need to disable the VDSO for old userspace ...
Well, apart from the obvious question to which nobody actually knows the
answer, (how many people run old user space that required
CONFIG_COMPAT_VDSO), what do you think of reversing the boot option?
Andi Kleen wrote:
The boot option is already there, but boot options for is not my
idea of user friendly binary compatibility.
Yes, not friendly. Perhaps we can reverse the boot option? I.e make
vdso_enable=force re-activate the vdso even if it gets moved by a
hypervisor and COMPAT_VDSO
Andi Kleen wrote:
But this still means I would need to decide between a PARAVIRT
kernel that either supports xen/VMI or cannot boot old user land without
weird options. I don't think that's the correct solution. The goal
is a single binary that runs everywhere and is still compatible.
Andi Kleen wrote:
But this still means I would need to decide between a PARAVIRT
kernel that either supports xen/VMI or cannot boot old user land without
weird options. I don't think that's the correct solution. The goal
is a single binary that runs everywhere and is still compatible.
Andi Kleen wrote:
The boot option is already there, but boot options for is not my
idea of user friendly binary compatibility.
Yes, not friendly. Perhaps we can reverse the boot option? I.e make
vdso_enable=force re-activate the vdso even if it gets moved by a
hypervisor and COMPAT_VDSO
to relocate the fixmap as well, just disable the VDSO if they do so.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r fad0910252d2 arch/i386/kernel/sysenter.c
--- a/arch/i386/kernel/sysenter.c Mon Mar 05 15:24:04 2007 -0800
+++ b/arch/i386/kernel/sysenter.c Mon Mar 05 15:27:31 2007
Jeremy Fitzhardinge wrote:
I think Jan's approach is better if it works (since there's no
compromise), but this is better if you want to get something working in
the near term.
Is Jan dynamically relinking the vdso at runtime? Because that is what
we will need. Adding support for
Andi Kleen wrote:
But this still means I would need to decide between a PARAVIRT
kernel that either supports xen/VMI or cannot boot old user land without
weird options. I don't think that's the correct solution. The goal
is a single binary that runs everywhere and is still compatible.
Andi Kleen wrote:
The boot option is already there, but boot options for is not my
idea of user friendly binary compatibility.
Yes, not friendly. Perhaps we can reverse the boot option? I.e make
vdso_enable=force re-activate the vdso even if it gets moved by a
hypervisor and COMPAT_VDSO
Ingo Molnar wrote:
there's no need to disable the VDSO for old userspace ...
Well, apart from the obvious question to which nobody actually knows the
answer, (how many people run old user space that required
CONFIG_COMPAT_VDSO), what do you think of reversing the boot option?
to relocate the fixmap as well, just disable the VDSO if they do so.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r fad0910252d2 arch/i386/kernel/sysenter.c
--- a/arch/i386/kernel/sysenter.c Mon Mar 05 15:24:04 2007 -0800
+++ b/arch/i386/kernel/sysenter.c Mon Mar 05 15:27:31 2007
Jeremy Fitzhardinge wrote:
I think Jan's approach is better if it works (since there's no
compromise), but this is better if you want to get something working in
the near term.
Is Jan dynamically relinking the vdso at runtime? Because that is what
we will need. Adding support for
Ingo Molnar wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
I had just sent this out for internal review...
I think Jan's approach is better if it works (since there's no
compromise), but this is better if you want to get something working
in the near term.
yeah. (plus
VMI_PAGE_PMD);
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
g long (*custom_sched_clock)(void);
int tsc_disable;
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.ht
.
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
Acked-by: Zachary Amsden [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(*custom_sched_clock)(void);
int tsc_disable;
Acked-by: Zachary Amsden [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
);
Acked-by: Zachary Amsden [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeremy Fitzhardinge wrote:
I can deal with the change going into -git, but it does seem awkward
knowing that it is the wrong change and it will be replaced by something
else almost immediately.
Well, it is not quite wrong - it is appropriate for -git. That it will
be replaced soon is a
Jeremy Fitzhardinge wrote:
Those are bugs that can occur, but they don't apply in this case. The
vmi implementation of kmap_atomic_pte() would be:
static void *vmi_kmap_atomic_pte(struct page *page, enum km_type type)
{
void *ptep = kmap_atomic(page, type);
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yeah, actually that does work, since you pass the km_type, we can use
that. But I would rather not respin this for 2.6.21; getting this
100% right can be tricky, and we've already done a good deal of
testing on this patch the way
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yeah, actually that does work, since you pass the km_type, we can use
that. But I would rather not respin this for 2.6.21; getting this
100% right can be tricky, and we've already done a good deal of
testing on this patch the way
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared
Jeremy Fitzhardinge wrote:
Those are bugs that can occur, but they don't apply in this case. The
vmi implementation of kmap_atomic_pte() would be:
static void *vmi_kmap_atomic_pte(struct page *page, enum km_type type)
{
void *ptep = kmap_atomic(page, type);
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yeah, actually that does work, since you pass the km_type, we can use
that. But I would rather not respin this for 2.6.21; getting this
100% right can be tricky, and we've already done a good deal of
testing on this patch the way
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to
Jeremy Fitzhardinge wrote:
Those are bugs that can occur, but they don't apply in this case. The
vmi implementation of kmap_atomic_pte() would be:
static void *vmi_kmap_atomic_pte(struct page *page, enum km_type type)
{
void *ptep = kmap_atomic(page, type);
Jeremy Fitzhardinge wrote:
I can deal with the change going into -git, but it does seem awkward
knowing that it is the wrong change and it will be replaced by something
else almost immediately.
Well, it is not quite wrong - it is appropriate for -git. That it will
be replaced soon is a
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
this is done in the common infrastructure.
This actually fixes a timer bug as well, that was caused by do_settimeofday
no longer being callable with interrupts disabled due to the use of
on_each_cpu().
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 5d41588419ab arch/i386/Kconfig
--- a/arc
it,
which is the time init function used for native hardware. Paravirt
guests have the chance to override this when they setup the paravirt-ops
table, and should need no change.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 2ae8eb19b227 arch/i386/kernel/paravirt.c
--- a/arch/i386/ke
Critical fixes for SMP.
Fix a couple functions which needed to be __devinit and fix a bogus
parameter to AP startup that just so happened to work because the
low virtual mapping of memory was still established.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r baf2e278a482 arc
done. Basically, we should never assume that the ROM implements
a specific set of functions, and always allow fallback to the native
implementation.
This is critical for future compatibility.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EMAIL
of misvirtualization bugs, and Alan and Pavel argued pretty strongly
against it. We were the only client, and now want to clean up this cruft.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 135d1b73c878 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 16
for
this header.
This patch is absolutely required for HIGHPTE kernels to operate properly
with VMI.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 87bf6b2d338d arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 14:14:34 2007 -0800
+++ b/arch/i386/kernel/para
the guest
can make accurate time calculations with the cycle counters.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r b8b315c897bb arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cTue Feb 27 14:04:43 2007 -0800
+++ b/arch/i386/kernel/vmi.cTue Feb 27 14:06:46 2007 -0800
@@
. This is useful as a last
minute workaround, or testing measure.
4) The code to skip the IO_APIC timer testing (no_timer_check) should be
conditional on IO_APIC, not SMP, since UP kernels can have this configured
in as well.
Signed-off-by: Dan Hecht <[EMAIL PROTECTED]>
Signed-off-by: Z
ashamedly admit I hacked
in to try to get this to work earlier, and then even got in the wrong units.
Please apply.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r d58e6ddfdfa9 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Thu Feb 15 23:52:41 2007 -0800
+++ b/arc
Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code.
Please apply. If there are objections to certain pieces, they can be
reworked, but they are pretty much all needed for correctness. We are
hoping to get these in the next 2.6.21-rc release.
We had quite a few
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Things like what? Do you mean the %[foo] asm parameter syntax? I think
those versions are no longer supported - Arjan posted a patch a few days
ago to convert a pile of asms to this form. Or do you mean something
else?
I meant
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Fix a few clobbers to include the return register. The clobbers set
is the set of all registers modified (or may be modified) by the code
snippet, regardless of whether it was deliberate or accidental.
Signed
Rusty Russell <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
---
include/asm-i386/paravirt.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
===
--- a/include/asm-i386/paravirt.h
+++ b/include/a
Andrew Morton wrote:
The handler for smp_call_function() is called with local interrupts
disabled (from the IPI handler).
So to provide a consistent call environment for that handler, on_each_cpu()
will also disable local interrupts when making the direct call on this CPU.
Similarly the
Andrew Morton wrote:
On Thu, 01 Mar 2007 03:34:18 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
Why is it a bug? Because there's a deadlock where this CPU is waiting for
CPU A to take the IPI, but CPU A is waiting (with interrupts disabled) for
this CPU to take
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
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
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Because I need a hook for do stuff after mem_map is valid too.
We didn't add a hook, but I can say it was somewhere in
arch/i386/kernel/setup.c - should be after zone_sizes_init().
I'm no longer sure how to resurrect the original
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Things like what? Do you mean the %[foo] asm parameter syntax? I think
those versions are no longer supported - Arjan posted a patch a few days
ago to convert a pile of asms to this form. Or do you mean something
else?
I
Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code.
Please apply. If there are objections to certain pieces, they can be
reworked, but they are pretty much all needed for correctness. We are
hoping to get these in the next 2.6.21-rc release.
We had quite a few
for
this header.
This patch is absolutely required for HIGHPTE kernels to operate properly
with VMI.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 87bf6b2d338d arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 14:14:34 2007 -0800
+++ b/arch/i386/kernel/paravirt.c
of misvirtualization bugs, and Alan and Pavel argued pretty strongly
against it. We were the only client, and now want to clean up this cruft.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 135d1b73c878 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 16:23:56 2007
done. Basically, we should never assume that the ROM implements
a specific set of functions, and always allow fallback to the native
implementation.
This is critical for future compatibility.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff
Critical fixes for SMP.
Fix a couple functions which needed to be __devinit and fix a bogus
parameter to AP startup that just so happened to work because the
low virtual mapping of memory was still established.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r baf2e278a482 arch/i386
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
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 state
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
Andrew Morton wrote:
On Thu, 01 Mar 2007 03:34:18 -0800 Zachary Amsden [EMAIL PROTECTED] wrote:
Why is it a bug? Because there's a deadlock where this CPU is waiting for
CPU A to take the IPI, but CPU A is waiting (with interrupts disabled) for
this CPU to take an IPI
Andrew Morton wrote:
The handler for smp_call_function() is called with local interrupts
disabled (from the IPI handler).
So to provide a consistent call environment for that handler, on_each_cpu()
will also disable local interrupts when making the direct call on this CPU.
Similarly the
Russell [EMAIL PROTECTED]
Cc: Zachary Amsden [EMAIL PROTECTED]
---
include/asm-i386/paravirt.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
===
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Fix a few clobbers to include the return register. The clobbers set
is the set of all registers modified (or may be modified) by the code
snippet, regardless of whether it was deliberate or accidental.
Signed
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Things like what? Do you mean the %[foo] asm parameter syntax? I think
those versions are no longer supported - Arjan posted a patch a few days
ago to convert a pile of asms to this form. Or do you mean something
else?
I meant
Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code.
Please apply. If there are objections to certain pieces, they can be
reworked, but they are pretty much all needed for correctness. We are
hoping to get these in the next 2.6.21-rc release.
We had quite a few
. This is useful as a last
minute workaround, or testing measure.
4) The code to skip the IO_APIC timer testing (no_timer_check) should be
conditional on IO_APIC, not SMP, since UP kernels can have this configured
in as well.
Signed-off-by: Dan Hecht [EMAIL PROTECTED]
Signed-off-by: Zachary Amsden
ashamedly admit I hacked
in to try to get this to work earlier, and then even got in the wrong units.
Please apply.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r d58e6ddfdfa9 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Thu Feb 15 23:52:41 2007 -0800
+++ b/arch/i386
the guest
can make accurate time calculations with the cycle counters.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r b8b315c897bb arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cTue Feb 27 14:04:43 2007 -0800
+++ b/arch/i386/kernel/vmi.cTue Feb 27 14:06:46 2007 -0800
@@ -874,6
of misvirtualization bugs, and Alan and Pavel argued pretty strongly
against it. We were the only client, and now want to clean up this cruft.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 135d1b73c878 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 16:23:56 2007
for
this header.
This patch is absolutely required for HIGHPTE kernels to operate properly
with VMI.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 87bf6b2d338d arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Feb 27 14:14:34 2007 -0800
+++ b/arch/i386/kernel/paravirt.c
done. Basically, we should never assume that the ROM implements
a specific set of functions, and always allow fallback to the native
implementation.
This is critical for future compatibility.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff
Critical fixes for SMP.
Fix a couple functions which needed to be __devinit and fix a bogus
parameter to AP startup that just so happened to work because the
low virtual mapping of memory was still established.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r baf2e278a482 arch/i386
is the time init function used for native hardware. Paravirt
guests have the chance to override this when they setup the paravirt-ops
table, and should need no change.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 2ae8eb19b227 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c
this is done in the common infrastructure.
This actually fixes a timer bug as well, that was caused by do_settimeofday
no longer being callable with interrupts disabled due to the use of
on_each_cpu().
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 5d41588419ab arch/i386/Kconfig
--- a/arch/i386
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
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
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
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
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
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
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
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
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 absolutely must.
+
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
accessed
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
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 precluded
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
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
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
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 ensu
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.
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 from this list: s
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
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 ensures that no (non
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
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 precluded
901 - 1000 of 1360 matches
Mail list logo
