similar to: [PATCH] paravirt: helper to disable all IO space

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

paravirt_disable_iospace() isn't used anywhere. Remove it. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt_types.h | 2 -- arch/x86/kernel/paravirt.c | 19 ------------------- 2 files changed, 21 deletions(-) diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 7465d6fe336f..7a5de42cb465 100644

Make sure everything is backed out if it fails. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> --- arch/i386/kernel/paravirt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) =================================================================== --- a/arch/i386/kernel/paravirt.c +++ b/arch/i386/kernel/paravirt.c @@ -254,8 +254,11 @@ int paravirt_disable_iospace(void)

smbldap-tools 0.8.7 FreeBSD 5.4-RC2 Samba 3.1.14 Perl 5.8.2 When I try to use any of the tools, the following message appears. Any hints on how to fix it are welcome. Bareword "print_banner" not allowed while "strict subs" in use at /usr/local/sbin/smbldap-useradd line 43. Execution of /usr/local/sbin/smbldap-useradd aborted due to compilation errors. Per olof

Hi David, On Thu, 3 Oct 2013 00:19:56 +0200 David Herrmann <dh.herrmann at gmail.com> wrote: > >> And your PCI-BAR adjustment doesn't change > >> anything either, sorry. > > > > I simply tried another approach to pacify the resource checker. > > > > However, there is some difference. nvidiafb cannot access the > > resources if

Hi Pavel On Fri, Oct 4, 2013 at 12:10 AM, Pavel Roskin <proski at gnu.org> wrote: > Hi David, > > On Thu, 3 Oct 2013 00:19:56 +0200 > David Herrmann <dh.herrmann at gmail.com> wrote: > >> >> And your PCI-BAR adjustment doesn't change >> >> anything either, sorry. >> > >> > I simply tried another approach to pacify the

Hello! I have spent some time on the issue. I'm not sure it's a nouveau bug. I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. GRUB actually uses graphic mode on my card. That mode is supported by simplefb. However, the resource conflict happens regardless of whether simplefb is enabled. It's sysfb_simplefb that causes it, a completely different driver. If GRUB

Hi Pavel On Wed, Oct 2, 2013 at 11:46 PM, Pavel Roskin <proski at gnu.org> wrote: > On Wed, 2 Oct 2013 16:47:29 +0200 > David Herrmann <dh.herrmann at gmail.com> wrote: > >> Thanks for your investigations. I finally sent my patch and put you on >> CC. Sorry for the delay, but I have mostly catched up with all emails >> now. >> >> This really just

On Fri, 4 Oct 2013 01:08:34 +0200 David Herrmann <dh.herrmann at gmail.com> wrote: > > CONFIG_X86_SYSFB is always defined. I doubt an x86 kernel would > > compile without it. create_simplefb() is used in > > arch/x86/kernel/sysfb.c that is compiled unconditionally and that > > function is defined in arch/x86/kernel/sysfb_simplefb.c that is only > > compiled

This patch series is against 2.6.20; some things are in flux, so there might be issues as other things flow into the latest -git tree. >From the documentation: Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the minimum of complexity. Nonetheless, it should have sufficient features to make it useful for

This patch series is against 2.6.20; some things are in flux, so there might be issues as other things flow into the latest -git tree. >From the documentation: Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the minimum of complexity. Nonetheless, it should have sufficient features to make it useful for

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

On 26/09/13 23:37, Pavel Roskin wrote: > Hello! > > I have spent some time on the issue. I'm not sure it's a nouveau bug. > I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. > > GRUB actually uses graphic mode on my card. That mode is supported by > simplefb. However, the resource conflict happens regardless of whether > simplefb is enabled.

On 31.08.20 11:35, Pankaj Gupta wrote: >> Some add_memory*() users add memory in small, contiguous memory blocks. >> Examples include virtio-mem, hyper-v balloon, and the XEN balloon. >> >> This can quickly result in a lot of memory resources, whereby the actual >> resource boundaries are not of interest (e.g., it might be relevant for >> DIMMs, exposed via

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> --- arch/x86/entry/entry_64_compat.S | 10 ++-------- arch/x86/include/asm/paravirt.h | 5 ----- arch/x86/include/asm/paravirt_types.h | 8 -------- arch/x86/kernel/asm-offsets_64.c | 1 - arch/x86/kernel/paravirt.c | 5 -----

It's not used, and we can be explicit in a paravirt_ops about which native pieces are preferred, so it's not needed. Also, the loop is a bit dodgy (works ok, since sizeof(unsigned int) is 4 on x86, but...) Before I commit, any objections? Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- diff -r ea8912509a0e arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Wed