On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
> On 2008-02-05 13:34, Arjan van de Ven wrote:
> [...]
> >>1) To have compiled it I had to replace global_flush_tlb()
> >> call with __flush_tlb_all() and still guessing was it(?) a correct
> >> replacment at all :-)
> >
> > it is
> 32-bit or 64-bit guest kernel?
> >
> > 32-bit.
> >
> > Yep, this fixed the problem.
>
> great! I've added:
>
>Tested-by: Jeff Chua <[EMAIL PROTECTED]>
>
> to the commit message as well, if you dont mind. Full patch is below.
Acked-by:
as well, if you dont mind. Full patch is below.
Acked-by: Zachary Amsden [EMAIL PROTECTED]
Thanks, Ingo!
--
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
On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
On 2008-02-05 13:34, Arjan van de Ven wrote:
[...]
1) To have compiled it I had to replace global_flush_tlb()
call with __flush_tlb_all() and still guessing was it(?) a correct
replacment at all :-)
it is not;
I
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > The first fix is not even specific for PARAVIRT, and it's actually
> > > preventing the whole tree from booting.
> >
> > on CONFIG_EFI, indeed :)
>
> but in exchange you broke all of 32-bit
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
The first fix is not even specific for PARAVIRT, and it's actually
preventing the whole tree from booting.
on CONFIG_EFI, indeed :)
but in exchange you broke all of 32-bit with
ks boxes got upgraded so I
can't test, but install base is really big.
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/maj
On Fri, 2008-01-11 at 18:08 +, Alan Cox wrote:
> This lets us remove port 0x80 use on the PCI systems. It also speeds
> up
> some of the later 8390 based cores where we know the device does not
> need
> delay loops either because it has internal handling or in most cases a
> faster device
On Fri, 2008-01-11 at 18:08 +, Alan Cox wrote:
This lets us remove port 0x80 use on the PCI systems. It also speeds
up
some of the later 8390 based cores where we know the device does not
need
delay loops either because it has internal handling or in most cases a
faster device anyway.
so I
can't test, but install base is really big.
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
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
> Zachary Amsden wrote:
> >
> > According to Phoenix Technologies book "System BIOS for IBM PCs,
> > Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
> >
> > port 0080h
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
Zachary Amsden wrote:
According to Phoenix Technologies book System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition, the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > BTW, it isn't ever safe to pass port 0x80 through to hardware from a
> > virtual machine; some OSes use port 0x80 as a hardware available scratch
> > register (I believe Darwin/x8
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> On 09-01-08 06:30, Christer Weinigel wrote:
> I'd not expect very time crtical. The current outb_p use gives a delay
> somewhere between .5 and 2 microseconds as per earlier survey meaning a
> udelay(1) or 2 would be enough -- again, at the
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
On 09-01-08 06:30, Christer Weinigel wrote:
I'd not expect very time crtical. The current outb_p use gives a delay
somewhere between .5 and 2 microseconds as per earlier survey meaning a
udelay(1) or 2 would be enough -- again, at the
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
Zachary Amsden wrote:
BTW, it isn't ever safe to pass port 0x80 through to hardware from a
virtual machine; some OSes use port 0x80 as a hardware available scratch
register (I believe Darwin/x86 did/does this during boot
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> Alan Cox wrote:
> > The natsemi docs here say otherwise. I trust them not you.
> >
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say use
On Mon, 2007-11-26 at 14:06 -0800, Yinghai Lu wrote:
> >> diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
> >> index 500670c..966d124 100644
> >> --- a/arch/x86/kernel/smpboot_64.c
> >> +++ b/arch/x86/kernel/smpboot_64.c
> >> @@ -912,7 +912,7 @@ void __init
On Mon, 2007-11-26 at 00:38 -0800, Yinghai Lu wrote:
> [PATCH] x86_64: not set boot cpu in cpu_online_map at smp_prepare_boot_cpu
>
> in init/main.c boot_cpu_init() does that before
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kernel/smpboot_64.c
On Mon, 2007-11-26 at 00:38 -0800, Yinghai Lu wrote:
[PATCH] x86_64: not set boot cpu in cpu_online_map at smp_prepare_boot_cpu
in init/main.c boot_cpu_init() does that before
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/smpboot_64.c
On Mon, 2007-11-26 at 14:06 -0800, Yinghai Lu wrote:
diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
index 500670c..966d124 100644
--- a/arch/x86/kernel/smpboot_64.c
+++ b/arch/x86/kernel/smpboot_64.c
@@ -912,7 +912,7 @@ void __init smp_prepare_cpus(unsigned int
On Wed, 2007-11-21 at 02:25 -0800, Roland McGrath wrote:
> This consolidates the four different places that implemented the same
> encoding magic for the GDT-slot 32-bit TLS support. The old tls32.c is
> renamed and only slightly modified to be the shared implementation guts.
> -#define
On Wed, 2007-11-21 at 02:20 -0800, Roland McGrath wrote:
> This changes a couple of places to use the get_desc_base function.
> They were duplicating the same calculation with different equivalent code.
>
> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/ia32/tls32.c
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file
On Wed, 2007-11-21 at 02:25 -0800, Roland McGrath wrote:
This consolidates the four different places that implemented the same
encoding magic for the GDT-slot 32-bit TLS support. The old tls32.c is
renamed and only slightly modified to be the shared implementation guts.
-#define
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
Where the device is implemented is an implementation detail that should
be hidden from the guest, isn't that one of the strengths of
virtualization? Two examples: a file-based block device implemented in
qemu gives you fancy file
On Wed, 2007-11-21 at 02:20 -0800, Roland McGrath wrote:
This changes a couple of places to use the get_desc_base function.
They were duplicating the same calculation with different equivalent code.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
diff --git a/arch/x86/ia32/tls32.c
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This makes x86_64's ia32 emulation support share the sources used in the
> 32-bit kernel for the 32-bit vDSO and much of its setup code.
>
> The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
> The abi.syscall32
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This changes the 64-bit kernel's support for the 32-bit sysenter
> instruction to use stored fields rather than constants for the
> user-mode return address, as the 32-bit kernel does. This adds a
> sysenter_return field to struct
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
This changes the 64-bit kernel's support for the 32-bit sysenter
instruction to use stored fields rather than constants for the
user-mode return address, as the 32-bit kernel does. This adds a
sysenter_return field to struct
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
This makes x86_64's ia32 emulation support share the sources used in the
32-bit kernel for the 32-bit vDSO and much of its setup code.
The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
The abi.syscall32 sysctl
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
> On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
> > Subject: x86/paravirt: revert exports to restore old behaviour
> >
> > Subdividing the paravirt_ops structure caused a regression in certain
> > non-GPL modules
On Tue, 2007-11-13 at 08:18 -0500, Gregory Haskins wrote:
> Since PCI was designed as a hardware solution it has all kinds of stuff
> specifically geared towards hardware constraints. Those constraints
> are different in a virtualized platform, so some things do not translate
> well to an
On Tue, 2007-11-13 at 08:18 -0500, Gregory Haskins wrote:
Since PCI was designed as a hardware solution it has all kinds of stuff
specifically geared towards hardware constraints. Those constraints
are different in a virtualized platform, so some things do not translate
well to an optimal
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try
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
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-ordering
On Tue, 2007-10-30 at 10:02 -0200, Glauber de Oliveira Costa wrote:
> > No, if no paravirt clocksource is detected, nothing can override the
> > perfect TSC hardware clocksource rating of 400. And if a paravirt
> > clocksource is detected, it is always better than TSC.
>
> Why always? tsc is
On Tue, 2007-10-30 at 10:02 -0200, Glauber de Oliveira Costa wrote:
No, if no paravirt clocksource is detected, nothing can override the
perfect TSC hardware clocksource rating of 400. And if a paravirt
clocksource is detected, it is always better than TSC.
Why always? tsc is the best
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > Not every guest support paravirt, but for correctness, all guests
> > require TSC, which must be exposed all the way up to userspace, no
> > matter what the
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> if it's inaccurate why are you exposing it to the guest then? Native
> only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but for correctn
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> tsc is very good time source (when it does not have drifts, does not
> change it's frequency, i.e. when it works), so it should have its rating
> raised to a value greater
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than,
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
Not every guest support paravirt, but for correctness, all guests
require TSC, which must be exposed all the way up to userspace, no
matter what the efficiency or accuracy may
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but for correctness, all guests
require
On Thu, 2007-10-25 at 16:57 -0700, Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > The conditional add/sub using carry trick is not generally bogus.
> > But for registers it's a fine optimization.
>
> For registers it's fine. For memory, it's a disaster. It's more than
On Thu, 2007-10-25 at 16:57 -0700, Linus Torvalds wrote:
On Fri, 26 Oct 2007, Andi Kleen wrote:
The conditional add/sub using carry trick is not generally bogus.
But for registers it's a fine optimization.
For registers it's fine. For memory, it's a disaster. It's more than just
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:
> > > > >
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 Fitzhardinge
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
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 the
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
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 patch
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);
>
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)
>
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_ops -
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 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
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 completely
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
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
> >>
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
exception that would
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
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
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
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
bit on fixing this. I neglected
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 late
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,
-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 latest git.
Parag
-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 100644
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
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
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 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
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
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
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
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
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 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:
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
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
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
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
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
to 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
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]>
diff
to 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 paravirt_ops
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
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]
diff --git
1 - 100 of 740 matches
Mail list logo
