search for: allocate_pages

Hi Rich, I find it more readable (and safer to review) to avoid lines longer than 80 columns. When reviewing changes that wrap, I've noticed that it is harder to spot certain types of mistakes in the wrapped portion of a long line. >From 930118b380b35bb33e7719b0eb2ab6b31fa2d7e4 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Wed, 13 Apr 2011 16:08:57

I am trying to add UEFI support to my existing PXE environment for kickstarting CentOS 7.0. With bios boot all is working well. I have added syslinux.efi and ldlinux.e64 from syslinux 6.03 to my tftp server and altered my dhcp server to boot syslinux.efi. I get to my usual menu fine, the server downloads vmlinuz and initrd.img fine but then bails out with "Failed to allocate memory for

Hello Richard As discussed in the IRC channel, when merging a moderately large reg file (~35MB) to a hiv file (~118 MB); hivex generates a huge hiv file (~580 MB). These changes address that by creating a list of unallocated blocks and reassigning unused blocks. I used https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md as a reference for the

From: Sylvain Gault <sylvain.gault at gmail.com> I found something suspicious while hunting another bug a while ago. The conditions for that bug to occur seems quite hard to meet, but it's still code quality improvement. See the commit message for details. Sylvain Gault (1): efi: Suspicious size reduction in emalloc efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3

Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> > > --- > > 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/i386/kernel/vmi.c > +++ b/arch/i386/kernel/vmi.c > @@ -235,7 +235,7 @@ static

Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> > > --- > > 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/i386/kernel/vmi.c > +++ b/arch/i386/kernel/vmi.c > @@ -235,7 +235,7 @@ static

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

Hi Peter, Removal of VMI(VMware's para-virtualization technique) is scheduled for 2.6.37, I was wondering what would be the right time frame for submitting a patch which does that. Does the x86-tip tree have any next branch where we can park this patch ? Below is the patch for your reference which just removes VMI specific bits, applies on top of x86-tip. There is also an opportunity to

Hi Peter, Removal of VMI(VMware's para-virtualization technique) is scheduled for 2.6.37, I was wondering what would be the right time frame for submitting a patch which does that. Does the x86-tip tree have any next branch where we can park this patch ? Below is the patch for your reference which just removes VMI specific bits, applies on top of x86-tip. There is also an opportunity to

From: Sylvain Gault <sylvain.gault at gmail.com> It could happen on 32 bits architecture that the memory size really allocated could be less than required. On 64 bits, allocate_pages may be called more times than needed. This closes bug #39. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/efi/main.c b/efi/main.c index 0e6b137..94878f9 100644 --- a/efi/main.c +++ b/efi/main.c...

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] 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

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] 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