search for: write_gdt_entri

Displaying 20 results from an estimated 119 matches for "write_gdt_entri".

Did you mean: write_gdt_entry
2007 Apr 18
3
Proposed interface change
I would like to propose an interface change to the following paravirt-ops calls: void (fastcall *write_ldt_entry)(void *dt, int entrynum, u64 entry); void (fastcall *write_gdt_entry)(void *dt, int entrynum, u64 entry); void (fastcall *write_idt_entry)(void *dt, int entrynum, u64 entry); Can we consolidate the dt and entrynum parameters and just pass dt+entrynum*8? I
2007 Dec 13
2
[PATCH] avoid ifdefs in desc.h, getting rid of pack_ldt and pack_tss
By Andi Kleen's suggestion, this patch removes pack_ldt() and pack_tss() wrappers in favour of a general wrapper. It saves us an ifdef and some lines of code, but more importantly, it's more elegant. No functional change is made. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- include/asm-x86/desc.h | 55 ++++++++++++++--------------------------------- 1 files
2007 Dec 13
2
[PATCH] avoid ifdefs in desc.h, getting rid of pack_ldt and pack_tss
By Andi Kleen's suggestion, this patch removes pack_ldt() and pack_tss() wrappers in favour of a general wrapper. It saves us an ifdef and some lines of code, but more importantly, it's more elegant. No functional change is made. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- include/asm-x86/desc.h | 55 ++++++++++++++--------------------------------- 1 files
2007 Dec 06
51
[PATCH 0/19] desc_struct integration
Hi, this is a series of patches that unify the struct desc_struct and friends across x86_64 and i386. As usual, it provides paravirt capabilities as a side-effect for x86_64. I consider the main goal, namely, of unifying the desc_struct, an ongoing effort, being this the beginning. A lot of old code has to be touched to accomplish that. I don't consider this patch ready for inclusion.
2007 Dec 06
51
[PATCH 0/19] desc_struct integration
Hi, this is a series of patches that unify the struct desc_struct and friends across x86_64 and i386. As usual, it provides paravirt capabilities as a side-effect for x86_64. I consider the main goal, namely, of unifying the desc_struct, an ongoing effort, being this the beginning. A lot of old code has to be touched to accomplish that. I don't consider this patch ready for inclusion.
2018 Jun 20
0
[PATCH v5 6/9] x86: prevent inline distortion by paravirt ops
Hi Nadav, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc1 next-20180619] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:
2007 Apr 18
3
[RFC, PATCH 10/24] i386 Vmi descriptor changes
Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for
2007 Apr 18
3
[RFC, PATCH 10/24] i386 Vmi descriptor changes
Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for
2007 Apr 18
0
someone screwed something up
On Mon, 2007-03-26 at 01:14 -0800, Andrew Morton wrote: > arch/i386/lguest/lguest.c:496: warning: assignment from incompatible pointer type > arch/i386/lguest/lguest.c:497: warning: assignment from incompatible pointer type > arch/i386/lguest/lguest.c:498: warning: assignment from incompatible pointer type > > paravirt_ops.write_ldt_entry = lguest_write_ldt_entry; >
2007 Apr 18
0
someone screwed something up
On Mon, 2007-03-26 at 01:14 -0800, Andrew Morton wrote: > arch/i386/lguest/lguest.c:496: warning: assignment from incompatible pointer type > arch/i386/lguest/lguest.c:497: warning: assignment from incompatible pointer type > arch/i386/lguest/lguest.c:498: warning: assignment from incompatible pointer type > > paravirt_ops.write_ldt_entry = lguest_write_ldt_entry; >
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
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 should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
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 should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,
2007 Apr 18
2
[PATCH] Fix CONFIG_PARAVIRT for 2.6.19-rc5-mm1
OK, at least two patches got dropped on the way from the mm tree to Andi's tree: the desc.h cleanup, and the processor.h rearrangement. Merging into Andi's tree without these patches must have been a nightmare 8( Andi then tried to fix it with x86_64-mm-paravirt-compile.patch but then it didn't boot so he disabled it in x86_64-mm-paravirt-broken.patch This patch undoes those two
2007 Apr 18
2
[PATCH] Fix CONFIG_PARAVIRT for 2.6.19-rc5-mm1
OK, at least two patches got dropped on the way from the mm tree to Andi's tree: the desc.h cleanup, and the processor.h rearrangement. Merging into Andi's tree without these patches must have been a nightmare 8( Andi then tried to fix it with x86_64-mm-paravirt-compile.patch but then it didn't boot so he disabled it in x86_64-mm-paravirt-broken.patch This patch undoes those two
2018 Aug 10
0
[PATCH 04/10] x86/paravirt: use a single ops structure
Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c
2007 Apr 18
5
[PATCH] paravirt.h
This version over last version: (1) Gets rid of the no_paravirt.h header and leaves native ops in place (with some reshuffling to keep then under one #ifdef). (2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug. (3) Puts __ex_table entry in paravirt iret. Another followup patch implements binary patching... Rusty. === Create a paravirt.h header for all the critical operations which
2007 Apr 18
5
[PATCH] paravirt.h
This version over last version: (1) Gets rid of the no_paravirt.h header and leaves native ops in place (with some reshuffling to keep then under one #ifdef). (2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug. (3) Puts __ex_table entry in paravirt iret. Another followup patch implements binary patching... Rusty. === Create a paravirt.h header for all the critical operations which
2013 Oct 31
1
[PATCH 2/3] x86: tss: Eliminate fragile calculation of TSS segment limit
Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then
2013 Oct 31
1
[PATCH 2/3] x86: tss: Eliminate fragile calculation of TSS segment limit
Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then
2007 Oct 09
2
[PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
[ 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