Displaying 20 results from an estimated 400 matches similar to: "[RFC, PATCH 18/24] i386 Vmi tlbflush header"
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
[RFC, PATCH 13/24] i386 Vmi system header
Fairly straightforward code motion in system.h into the sub-arch
layer. Affected functionality include control register accessors,
which are virtualizable but with great overhead due to the #GP
cost; wbinvd, and most importantly, halt and interrupt control,
which is non-virtualizable.
Since read_cr4_safe can never fault on a VMI kernel (P5+ processor
is required for VMI), we can omit the fault
2007 Apr 18
0
[RFC, PATCH 13/24] i386 Vmi system header
Fairly straightforward code motion in system.h into the sub-arch
layer. Affected functionality include control register accessors,
which are virtualizable but with great overhead due to the #GP
cost; wbinvd, and most importantly, halt and interrupt control,
which is non-virtualizable.
Since read_cr4_safe can never fault on a VMI kernel (P5+ processor
is required for VMI), we can omit the fault
2007 Apr 18
1
[RFC, PATCH 16/24] i386 Vmi io header
Move I/O instruction building to the sub-arch layer. Some very crafty
but esoteric macros are used here to get optimized native instructions
for port I/O in Linux be writing raw instruction strings. Adding a
wrapper layer here is fairly easy, and makes the full range of I/O
instructions available to the VMI interface.
Also, slowing down I/O is not a useful operation in a VM, so there
is a VMI
2007 Apr 18
1
[RFC, PATCH 16/24] i386 Vmi io header
Move I/O instruction building to the sub-arch layer. Some very crafty
but esoteric macros are used here to get optimized native instructions
for port I/O in Linux be writing raw instruction strings. Adding a
wrapper layer here is fairly easy, and makes the full range of I/O
instructions available to the VMI interface.
Also, slowing down I/O is not a useful operation in a VM, so there
is a VMI
2007 Apr 18
0
[RFC, PATCH 15/24] i386 Vmi apic header
Move APIC read / write accessors to sub-arch layer. Note that we
don't bother to implement apic_write_atomic any different, as it
is only present to work around old processor erratums (Pentium
Processor Spec update 11AP), and VMI kernels do not offer support
for this class of processor.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Daniel Arai <arai@vmware.com>
2007 Apr 18
0
[RFC, PATCH 15/24] i386 Vmi apic header
Move APIC read / write accessors to sub-arch layer. Note that we
don't bother to implement apic_write_atomic any different, as it
is only present to work around old processor erratums (Pentium
Processor Spec update 11AP), and VMI kernels do not offer support
for this class of processor.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Daniel Arai <arai@vmware.com>
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2007 Apr 18
2
[RFC, PATCH 17/24] i386 Vmi msr patch
Fairly straightforward code motion of MSR / TSC / PMC accessors
to the sub-arch level. Note that rdmsr/wrmsr_safe functions are
not moved; Linux relies on the fault behavior here in the event
that certain MSRs are not supported on hardware, and combining
this with a VMI wrapper is overly complicated. The instructions
are virtualizable with trap and emulate, not on critical code
paths, and only
2007 Apr 18
2
[RFC, PATCH 17/24] i386 Vmi msr patch
Fairly straightforward code motion of MSR / TSC / PMC accessors
to the sub-arch level. Note that rdmsr/wrmsr_safe functions are
not moved; Linux relies on the fault behavior here in the event
that certain MSRs are not supported on hardware, and combining
this with a VMI wrapper is overly complicated. The instructions
are virtualizable with trap and emulate, not on critical code
paths, and only
2007 Apr 18
0
[RFC, PATCH 23/24] i386 Vmi timer patch
In a virtualized environment, virtual machines will time share the system
with each other and with other processes running on the host system.
Therefore, a VM's virtual CPUs (VCPUs) will be executing on the host's
physical CPUs (pcpus) for only some portion of time.
The VMI exposes a paravirtual view of time to the guest operating systems
so that they may operate more effectively in a
2007 Apr 18
0
[RFC, PATCH 23/24] i386 Vmi timer patch
In a virtualized environment, virtual machines will time share the system
with each other and with other processes running on the host system.
Therefore, a VM's virtual CPUs (VCPUs) will be executing on the host's
physical CPUs (pcpus) for only some portion of time.
The VMI exposes a paravirtual view of time to the guest operating systems
so that they may operate more effectively in a
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
Macros to use VMI calls from assembly and C languages are introduced.
The macros are quite complex, but the end result is rather impressive.
The result is that when compiling a VMI kernel, the native code is
emitted inline, with no function call overhead, and some wiggle room
for register allocation. The hypervisor compatibility code is emitted
out of line into a separate section, and patched
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
Macros to use VMI calls from assembly and C languages are introduced.
The macros are quite complex, but the end result is rather impressive.
The result is that when compiling a VMI kernel, the native code is
emitted inline, with no function call overhead, and some wiggle room
for register allocation. The hypervisor compatibility code is emitted
out of line into a separate section, and patched
2004 Dec 02
0
[LLVMdev] Adding xadd instruction to X86
On Thu, 2 Dec 2004, Brent Monroe wrote:
> I'm trying to add the xadd instruction to the X86 back end.
> xadd r/m32, r32
> exchanges r/m32 and r32, and loads the sum into r/m32. I'm
> interested in the case where the destination operand is a
> memory location.
>
> I've added the following entry to X86InstrInfo.td:
> def XADD32mr : I<0x87, MRMDestMem,
>
2004 Dec 02
3
[LLVMdev] Adding xadd instruction to X86
Hi,
I'm trying to add the xadd instruction to the X86 back end.
xadd r/m32, r32
exchanges r/m32 and r32, and loads the sum into r/m32. I'm
interested in the case where the destination operand is a
memory location.
I've added the following entry to X86InstrInfo.td:
def XADD32mr : I<0x87, MRMDestMem,
(ops i32mem:$src1, R32:$src2),
"xadd{l}
2004 Dec 03
2
[LLVMdev] Adding xadd instruction to X86
Chris Lattner wrote:
> On Thu, 2 Dec 2004, Brent Monroe wrote:
>
>>I'm trying to add the xadd instruction to the X86 back end.
>>xadd r/m32, r32
>>exchanges r/m32 and r32, and loads the sum into r/m32. I'm
>>interested in the case where the destination operand is a
>>memory location.
>>
>>I've added the following entry to
2007 Apr 18
1
[RFC, PATCH 19/24] i386 Vmi mmu changes
MMU code movement. Unfortunately, this one is a little bit more
complicated than the rest. We have to override the default accessors
that directly write to page table entries. Because of the 2/3-level
PAE split in Linux, this turned out to be really ugly at first, but
by allowing the sub-arch layer to override the definitions and keeping
the native definitions in place, the code becomes much