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 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 Wed, 2007-10-10 at 15:37 +0800, Fengguang Wu wrote:
> Hi Zachary,
>
> One of my friends' vmware "hangs" on booting Linux 2.6.23, and then get
> it to work by applying your patch at http://lkml.org/lkml/2007/8/4/72.
>
> It would be nice to see your fix going into mainline :-)
I thought that pa
On Fri, 2007-09-28 at 11:49 -0700, Jeremy Fitzhardinge wrote:
> > We shouldn't need to export pv_init_ops.
>
> No. The only ones I export are:
>
> EXPORT_SYMBOL_GPL(pv_time_ops);
> EXPORT_SYMBOL_GPL(pv_cpu_ops);
> EXPORT_SYMBOL_GPL(pv_mmu_ops);
> EXPORT_SYMBOL_GPL(pv_apic_ops);
> EXPORT_SYMBOL
On Fri, 2007-09-28 at 11:49 -0700, Jeremy Fitzhardinge wrote:
> > We shouldn't need to export pv_init_ops.
>
> No. The only ones I export are:
>
> EXPORT_SYMBOL_GPL(pv_time_ops);
> EXPORT_SYMBOL_GPL(pv_cpu_ops);
> EXPORT_SYMBOL_GPL(pv_mmu_ops);
> EXPORT_SYMBOL_GPL(pv_apic_ops);
> EXPORT_SYMBOL
On Fri, 2007-09-28 at 11:10 -0700, Jeremy Fitzhardinge wrote:
> This patch refactors the paravirt_ops structure into groups of
> functionally related ops:
>
> pv_info - random info, rather than function entrypoints
> pv_init_ops - functions used at boot time (some for module_init too)
> pv_misc_op
On Fri, 2007-09-28 at 11:10 -0700, Jeremy Fitzhardinge wrote:
> This patch refactors the paravirt_ops structure into groups of
> functionally related ops:
>
> pv_info - random info, rather than function entrypoints
> pv_init_ops - functions used at boot time (some for module_init too)
> pv_misc_op
On Wed, 2007-09-19 at 10:08 -0500, Anthony Liguori wrote:
> Ryan Harper wrote:
> > * Avi Kivity <[EMAIL PROTECTED]> [2007-09-19 03:58]:
> >
> >> Ryan Harper wrote:
> >>
> We have a test which verifies #GP is not caused by setting the bits on
> either AMD or Intel chips. "Stray" b
On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
> > noticed
> > > > that whenever we launch a VM within the gu
On Sun, 2007-09-16 at 07:56 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Well, containerization deserves its own menu, but the question is does i
> > it belong under this menu?
>
> No, I don't think so. While there are some broad similarities in
> effect, the technology is complet
On Sun, 2007-09-16 at 07:56 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Well, containerization deserves its own menu, but the question is does i
> > it belong under this menu?
>
> No, I don't think so. While there are some broad similarities in
> effect, the technology is complet
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
> So then each module creates a hypercall page using this magic MSR and
> the hypervisor has to keep track of it so that it can appropriately
> change the page on migration. The page can only contain a single
> instruction or else it ca
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
> So then each module creates a hypercall page using this magic MSR and
> the hypervisor has to keep track of it so that it can appropriately
> change the page on migration. The page can only contain a single
> instruction or else it ca
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> >> This patch refactors the current hypercall infrastructure to better
> >> support live
> >> migration and SMP. It eliminates the hypercall page by trapping the UD
> >> exce
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> >> This patch refactors the current hypercall infrastructure to better
> >> support live
> >> migration and SMP. It eliminates the hypercall page by trapping the UD
> >> exce
On Thu, 2007-09-06 at 06:37 +1000, Rusty Russell wrote:
> On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
> > I recently sent off a fix for lazy vmalloc faults which can happen under
> > paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
> > b
On Thu, 2007-09-06 at 06:37 +1000, Rusty Russell wrote:
> On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
> > I recently sent off a fix for lazy vmalloc faults which can happen under
> > paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
> > b
On Thu, 2007-09-06 at 02:33 +1000, Rusty Russell wrote:
> On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
> > Rusty Russell wrote:
> > > static inline void arch_flush_lazy_mmu_mode(void)
> > > {
> > > - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
> > > + if (unlikely(__get_cpu_
On Thu, 2007-09-06 at 02:33 +1000, Rusty Russell wrote:
> On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
> > Rusty Russell wrote:
> > > static inline void arch_flush_lazy_mmu_mode(void)
> > > {
> > > - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
> > > + if (unlikely(__get_cpu_
Benjamin Herrenschmidt wrote:
On Wed, 2007-08-22 at 16:25 +1000, Rusty Russell wrote:
On Wed, 2007-08-22 at 08:34 +0300, Avi Kivity wrote:
Zachary Amsden wrote:
This patch provides hypercalls for the i386 port I/O instructions,
which vastly helps guests which use native-style
Benjamin Herrenschmidt wrote:
On Wed, 2007-08-22 at 16:25 +1000, Rusty Russell wrote:
On Wed, 2007-08-22 at 08:34 +0300, Avi Kivity wrote:
Zachary Amsden wrote:
This patch provides hypercalls for the i386 port I/O instructions,
which vastly helps guests which use native-style
?
Handled-By : Zachary Amsden <[EMAIL PROTECTED]>
Status : problem is being debugged
Zach seemed to think that this is already fixed - I am not in a
position to test it immediately so if we know what fixed this - can be
closed. I'll report back once I get a chance to test
Jeremy Fitzhardinge wrote:
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
Agree 100%. It is the lazy mode flush that might happen when preempt is
enabled, but lazy mode is disabled. In that case,
Jeremy Fitzhardinge wrote:
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
Agree 100%. It is the lazy mode flush that might happen when preempt is
enabled, but lazy mode is disabled. In that case,
-preemptible.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED](none)>
---
arch/i386/kernel/vmi.c| 14 ++
arch/i386/xen/enlighten.c |4 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..9e669cb
-preemptible.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED](none)>
---
arch/i386/kernel/vmi.c| 14 ++
arch/i386/xen/enlighten.c |4 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..9e669cb
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
Andi Kleen wrote:
We might benefit from it, but would the
BusLogic driver? It sets a nasty precedent for maintenance as different
hypervisors and emulators hack up different drivers for their own
performance.
I still think it's preferable to change some drivers than everybody.
AFAIK
Andi Kleen wrote:
We might benefit from it, but would the
BusLogic driver? It sets a nasty precedent for maintenance as different
hypervisors and emulators hack up different drivers for their own
performance.
I still think it's preferable to change some drivers than everybody.
AFAIK
Alan Cox wrote:
I still think it's preferable to change some drivers than everybody.
AFAIK BusLogic as real hardware is pretty much dead anyways,
so you're probably the only primary user of it anyways.
Go wild on it!
I don't believe anyone is materially maintaining the buslogic driver and
Alan Cox wrote:
I still think it's preferable to change some drivers than everybody.
AFAIK BusLogic as real hardware is pretty much dead anyways,
so you're probably the only primary user of it anyways.
Go wild on it!
I don't believe anyone is materially maintaining the buslogic driver and
Andi Kleen wrote:
How is that measured? In a loop? In the same pipeline state?
It seems a little dubious to me.
I did the experiments in a controlled environment, with interrupts
disabled and care to get the pipeline in the same state. It was a
perfectly repeatable experiment. I don't
Andi Kleen wrote:
How is that measured? In a loop? In the same pipeline state?
It seems a little dubious to me.
I did the experiments in a controlled environment, with interrupts
disabled and care to get the pipeline in the same state. It was a
perfectly repeatable experiment. I don't
Andi Kleen wrote:
On Wed, Aug 22, 2007 at 09:48:25AM -0700, Zachary Amsden wrote:
Andi Kleen wrote:
On Tue, Aug 21, 2007 at 10:23:14PM -0700, Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically
Andi Kleen wrote:
On Wed, Aug 22, 2007 at 09:48:25AM -0700, Zachary Amsden wrote:
Andi Kleen wrote:
On Tue, Aug 21, 2007 at 10:23:14PM -0700, Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically
Andi Kleen wrote:
On Tue, Aug 21, 2007 at 10:23:14PM -0700, Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest
Andi Kleen wrote:
On Tue, Aug 21, 2007 at 10:23:14PM -0700, Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest
Avi Kivity wrote:
Since this is only for newer kernels, won't updating the driver to use
a hypercall be more efficient? Or is this for existing out-of-tree
drivers?
Actually, it is for in-tree drivers that we emulate but don't want to
pollute, and one out of tree driver (that will hopefull
Avi Kivity wrote:
Since this is only for newer kernels, won't updating the driver to use
a hypercall be more efficient? Or is this for existing out-of-tree
drivers?
Actually, it is for in-tree drivers that we emulate but don't want to
pollute, and one out of tree driver (that will hopefull
Jeremy Fitzhardinge wrote:
No, under Xen the kernel/hypervisor PMD is not shared between processes,
so this is still used when PAE is enabled.
Ahh, yes. So this was a lucky catch for us. Non-PAE kernels seem to be
increasing in value at antique sales.
Zach
_
Jeremy Fitzhardinge wrote:
No, under Xen the kernel/hypervisor PMD is not shared between processes,
so this is still used when PAE is enabled.
Ahh, yes. So this was a lucky catch for us. Non-PAE kernels seem to be
increasing in value at antique sales.
Zach
-
To unsubscribe from this li
H. Peter Anvin wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest OS.
Not only is the trap for a #GP
H. Peter Anvin wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest OS.
Not only is the trap for a #GP
Avi Kivity wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance
problems. The I/O can not be completed physically, but must be
virtualized. This means trapping and decoding port I/O instructions
from the guest OS. Not only is the trap for a #GP
Avi Kivity wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance
problems. The I/O can not be completed physically, but must be
virtualized. This means trapping and decoding port I/O instructions
from the guest OS. Not only is the trap for a #GP
make use of this feature.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index ea962c0..4d0d150 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -329,6 +329,18 @@ struct paravirt_ops paravi
make use of this feature.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index ea962c0..4d0d150 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -329,6 +329,18 @@ struct paravirt_ops paravi
kport to -stable as well.
Zach
Touching vmalloc memory in the middle of a lazy mode update can generate
a kernel PDE update, which must be flushed immediately. The fix is to
leave lazy mode when doing a vmalloc sync.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
d
kport to -stable as well.
Zach
Touching vmalloc memory in the middle of a lazy mode update can generate
a kernel PDE update, which must be flushed immediately. The fix is to
leave lazy mode when doing a vmalloc sync.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
d
Chris Wright wrote:
* Chris Wright ([EMAIL PROTECTED]) wrote:
Now that I understand the problem, I do have a very simple (slightly
overkill) fix for paravirt patching. This can be cleaned up to avoid
the copies when they aren't needed, but that will take a little more
auditing of the various
Chris Wright wrote:
* Chris Wright ([EMAIL PROTECTED]) wrote:
Now that I understand the problem, I do have a very simple (slightly
overkill) fix for paravirt patching. This can be cleaned up to avoid
the copies when they aren't needed, but that will take a little more
auditing of the various
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
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
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
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
Rusty Russell wrote:
If a Guest makes hypercall which sets a GDT entry to not present, we
currently set any segment registers using that GDT entry to 0.
Unfortunately, this is not sufficient: there are other ways of
altering GDT entries which will cause a fault.
The correct solution to do what L
Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compresse
Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compresse
Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compresse
Andi Kleen wrote:
In the boot decompressor for the kernel in the image Iouri provided, I
32bit or 64bit image?
As you can plainly see, the call to memcpy (which is redefined in
boot/compressed/misc.c) is made using stack calling convention.
Unfortunately, the compiler generated the me
Andi Kleen wrote:
In the boot decompressor for the kernel in the image Iouri provided, I
32bit or 64bit image?
As you can plainly see, the call to memcpy (which is redefined in
boot/compressed/misc.c) is made using stack calling convention.
Unfortunately, the compiler generated the me
Andi Kleen wrote:
In the boot decompressor for the kernel in the image Iouri provided, I
32bit or 64bit image?
As you can plainly see, the call to memcpy (which is redefined in
boot/compressed/misc.c) is made using stack calling convention.
Unfortunately, the compiler generated the me
Andi Kleen wrote:
In the boot decompressor for the kernel in the image Iouri provided, I
32bit or 64bit image?
As you can plainly see, the call to memcpy (which is redefined in
boot/compressed/misc.c) is made using stack calling convention.
Unfortunately, the compiler generated the me
H. Peter Anvin wrote:
I just got the following message on the syslinux mailing list:
2. On some platforms (vmware for example :), READING from the video memory
in the 32bit mode is impossible (causes an exeption). Taking in to account
that the scroll function in ilinux/arch/i386/boot/c
H. Peter Anvin wrote:
I just got the following message on the syslinux mailing list:
2. On some platforms (vmware for example :), READING from the video memory
in the 32bit mode is impossible (causes an exeption). Taking in to account
that the scroll function in ilinux/arch/i386/boot/c
Gabriel Barazer wrote:
Hi,
After upgrading kernel to 2.6.22 on a Vmware workstation guest version
5.5 and 6 , the kernel decompression stage ("Decompressing Linux...")
is hanging for a very long time (~5 minutes) before finally
succeeding (displaying "done.\nBooting the kernel.\n"). During t
Rusty Russell wrote:
Otherwise we end up with $NARCH copies of that Kconfig, each slightly
different. The top-level entry can be made to depend on the archs that
actually have some virt capability, so as not to show empty an menu.
I dislike the duplication, too, but
1) it's a CPU capab
Rusty Russell wrote:
Otherwise we end up with $NARCH copies of that Kconfig, each slightly
different. The top-level entry can be made to depend on the archs that
actually have some virt capability, so as not to show empty an menu.
I dislike the duplication, too, but
1) it's a CPU capab
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt code I worry about.
Paravirt and alternatives should all be ok because they are done before
SMP bringup and with NM
Andi Kleen wrote:
+ *addr = opcode;
+ /* Not strictly needed, but can speed CPU recovery up */
+ if (cpu_has_clflush)
+ asm("clflush (%0) " :: "r" (addr) : "memory");
+ if (addr != oaddr)
+ vunmap(addr);
clflush should take oaddr.
If you h
Rusty Russell wrote:
> The main effect is to change the definition of "struct desc_struct" to
> a union of more complex types.
>
Yay! Someone finally killed it. Every time I tried to kill it, I ended
up off in the weeds chasing some bug.
>
> diff -r 656f3ff2c9ce arch/i386/kernel/process.c
Rusty Russell wrote:
The main effect is to change the definition of "struct desc_struct" to
a union of more complex types.
Yay! Someone finally killed it. Every time I tried to kill it, I ended
up off in the weeds chasing some bug.
diff -r 656f3ff2c9ce arch/i386/kernel/process.c
@@ -
Jeremy Fitzhardinge wrote:
Here's a first attempt at splitting up paravirt_ops into more specific
chunks. Its pretty clunky and chunky; mostly just a lot of
replacement. The grouping of ops is very first cut; I'm open to
suggestions about what groups should exist and what ops they each
shoul
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I though about it, but it gets really ugly. You need wrappers for
all the MMU ops in pvops generic code, which means either another
layer of wrappers or a bunch of CONFIG_DEBUG_PARAVIRT
Oh, yes, more wrappers please! We could do it at the
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I though about it, but it gets really ugly. You need wrappers for
all the MMU ops in pvops generic code, which means either another
layer of wrappers or a bunch of CONFIG_DEBUG_PARAVIRT
Oh, yes, more wrappers please! We could do it at the
Jeremy Fitzhardinge wrote:
I never merged the whole bit upstream because it added a field to
struct page.
Hm, is that a big problem? It would be OK for a debug config option,
wouldn't it? Also, it doesn't seem particularly vmi-specific. Could
it be made part of the pvops infrastructure?
Jeremy Fitzhardinge wrote:
I never merged the whole bit upstream because it added a field to
struct page.
Hm, is that a big problem? It would be OK for a debug config option,
wouldn't it? Also, it doesn't seem particularly vmi-specific. Could
it be made part of the pvops infrastructure?
Chris Wright wrote:
* Stefan Richter ([EMAIL PROTECTED]) wrote:
-#ifdef CONFIG_DEBUG_PAGE_TYPE
+#if 0 /* debug page type */
This misnamed CONFIG_DEBUG_PAGE_TYPE (it's not a Kconfig variable) has
about 120 lines debug code dangling on it. So, replacing it by #if 0
will hopefully
Chris Wright wrote:
* Stefan Richter ([EMAIL PROTECTED]) wrote:
-#ifdef CONFIG_DEBUG_PAGE_TYPE
+#if 0 /* debug page type */
This misnamed CONFIG_DEBUG_PAGE_TYPE (it's not a Kconfig variable) has
about 120 lines debug code dangling on it. So, replacing it by #if 0
will hopefully
Stefan Richter wrote:
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
Maintainers are apparently those under "PARAVIRT_OPS INTERFACE".
CCs added.
index c12720d..e3ce5c8 100644
--- a/arch
Stefan Richter wrote:
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
Maintainers are apparently those under "PARAVIRT_OPS INTERFACE".
CCs added.
index c12720d..e3ce5c8 100644
--- a/arch
Martin Schwidefsky wrote:
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Nobody is using ptep_test_and_clear_dirty and ptep_clear_flush_dirty.
Remove the functions from all architectures.
-static inline int
-ptep_test_and_clear_dirty (struct vm_area_struct *vma, unsigned long addr,
pte_t *ptep)
H. Peter Anvin wrote:
Zachary Amsden wrote:
I'm failing to understand exactly what the failure here is. Can you
provide sample code that generates the problem? Surely, it should be
possible to read the framebuffer.
The supposed test case was leaving the cursor at the botto
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
You mean "is a real failure"? Or "is triggered by particular
instructions"? It seems profoundly bogus (as in, surely DOS or
something reads the framebuffer).
A r
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose
migration restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is to
Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>> Unless you also migrate the hypercall page itself and impose
>> migration restrictions on compatible hypercall pages.
>
> Seems unreasonable, especially if you support migration between VT and
> SVM machines. The wh
Jeremy Fitzhardinge wrote:
Hm, you need to quiesce the kernel in some way when you do a migrate,
so making sure it isn't in a hypercall would be just part of that. In
general you'd make sure all but one CPU is parked somewhere, and the
remaining CPU is doing the suspend, right?
The tricky
Jeremy Fitzhardinge wrote:
>
> Hm, you need to quiesce the kernel in some way when you do a migrate,
> so making sure it isn't in a hypercall would be just part of that. In
> general you'd make sure all but one CPU is parked somewhere, and the
> remaining CPU is doing the suspend, right?
>
> Th
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you cann
Anthony Liguori wrote:
> I've been thinking about this wrt the hypercall page in KVM. The
> problem is that in a model like KVM (or presumably VMI), migration
> gets really difficult if you have anything but a trivial hypercall
> page since the hypercall page will change after migration.
>
> If
Anthony Liguori wrote:
Zachary Amsden wrote:
Anthony Liguori wrote:
But what's the value in having it not in the kernel? Let's take Xen
and lhype out of the picture because it clearly has to be there for
them. You have a little less in the kernel now but then your kernel
boots m
Anthony Liguori wrote:
> Zachary Amsden wrote:
>> Anthony Liguori wrote:
>>> But what's the value in having it not in the kernel? Let's take Xen
>>> and lhype out of the picture because it clearly has to be there for
>>> them. You have a litt
Anthony Liguori wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handf
Anthony Liguori wrote:
> Zachary Amsden wrote:
>> Jeremy Fitzhardinge wrote:
>>> Anthony Liguori wrote:
>>>
>>>> I don't agree that having paravirt_ops within a normal module is all
>>>> that useful. By the time modules can be loaded, the
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations and they aren't large so I
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> I don't agree that having paravirt_ops within a normal module is all
>> that useful. By the time modules can be loaded, the kernel has
>> completely booted. There should only be a handful of paravirt_ops
>> implementations and they aren'
Jeremy Fitzhardinge wrote:
Well, I was suggesting we could print the banner later rather than
forcing an earlier init.
The important part is that you set your pv_ops before patching occurs,
since that will bake the function calls into the rest of the kernel, and
it will ignore any further change
Jeremy Fitzhardinge wrote:
> Well, I was suggesting we could print the banner later rather than
> forcing an earlier init.
>
> The important part is that you set your pv_ops before patching occurs,
> since that will bake the function calls into the rest of the kernel, and
> it will ignore any furth
Anthony Liguori wrote:
I don't see a compelling reason to paravirtualize earlier although I
also don't see a compelling reason not too. I noticed that VMI hooks
setup.c. It wasn't immediately obvious why it was hooking there but
perhaps it worthwhile to have a common hook? I suspect VMI an
501 - 600 of 1203 matches
Mail list logo
