- 16 Jul, 2008 40 commits
-
-
Jeremy Fitzhardinge authored
Because the x86_64 architecture does not enforce segment limits, Xen cannot protect itself with them as it does in 32-bit mode. Therefore, to protect itself, it runs the guest kernel in ring 3. Since it also runs the guest userspace in ring3, the guest kernel must maintain a second pagetable for its userspace, which does not map kernel space. Naturally, the guest kernel pagetables map both kernel and userspace. The userspace pagetable is attached to the corresponding kernel pagetable via the pgd's page->private field. It is allocated and freed at the same time as the kernel pgd via the paravirt_pgd_alloc/free hooks. Fortunately, the user pagetable is almost entirely shared with the kernel pagetable; the only difference is the pgd page itself. set_pgd will populate all entries in the kernel pagetable, and also set the corresponding user pgd entry if the address is less than STACK_TOP_MAX. The user pagetable must be pinned and unpinned with the kernel one, but because the pagetables are aliased, pgd_walk() only needs to be called on the kernel pagetable. The user pgd page is then pinned/unpinned along with the kernel pgd page. xen_write_cr3 must write both the kernel and user cr3s. The init_mm.pgd pagetable never has a user pagetable allocated for it, because it can never be used while running usermode. One awkward area is that early in boot the page structures are not available. No user pagetable can exist at that point, but it complicates the logic to avoid looking at the page structure. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Stephen Tweedie <sct@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Mark McLoughlin <markmc@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Jeremy Fitzhardinge authored
The Xen hypercall interface is allowed to trash any or all of the argument registers, so we need to be careful that the kernel state isn't damaged. On 32-bit kernels, the hypercall parameter registers same as a regparm function call, so we've got away without explicit clobbering so far. The 64-bit ABI defines lots of caller-save registers, so save them all for safety. We can trim this set later by re-distributing the responsibility for saving all these registers. Signed-off-by:
-
Jeremy Fitzhardinge authored
64-bit hypercall interface can pass a maddr in one argument rather than splitting it. Signed-off-by:
-
Eduardo Habkost authored
We need to do this, otherwise we can get a GPF on hypercall return after TLS descriptor is cleared but %fs is still pointing to it. Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
Implement the failsafe callback, so that iret and segment register load exceptions are reported to the kernel. Signed-off-by:
-
Jeremy Fitzhardinge authored
Xen save/restore requires PM_SLEEP to be set without requiring SUSPEND or HIBERNATION. Signed-off-by:
-
Jeremy Fitzhardinge authored
Point the boot params cmd_line_ptr to the domain-builder-provided command line. Signed-off-by:
-
Jeremy Fitzhardinge authored
Rewrite pgd_walk to deal with 64-bit address spaces. There are two notible features of 64-bit workspaces: 1. The physical address is only 48 bits wide, with the upper 16 bits being sign extension; kernel addresses are negative, and userspace is positive. 2. The Xen hypervisor mapping is at the negative-most address, just above the sign-extension hole. 1. means that we can't easily use addresses when traversing the space, since we must deal with sign extension. This rewrite expresses everything in terms of pgd/pud/pmd indices, which means we don't need to worry about the exact configuration of the virtual memory space. This approach works equally well in 32-bit. To deal with 2, assume the hole is between the uppermost userspace address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole. For 32-bit, the hole is zero-sized. In all cases, the uppermost kernel address is FIXADDR_TOP. A side-effect of this patch is that the upper boundary is actually handled properly, exposing a long-standing bug in 32-bit, which failed to pin kernel pmd page. The kernel pmd is not shared, and so must be explicitly pinned, even though the kernel ptes are shared and don't need pinning. Signed-off-by: -
Eduardo Habkost authored
xen-64: implement xen_load_gs_index() Signed-off-by:
-
Eduardo Habkost authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
The x86_64 interrupt subsystem is oriented towards vectors, as opposed to a flat irq space as it is in x86-32. This patch adds a simple identity irq->vector mapping so that we can continue to feed irqs into do_IRQ() and get a good result. Ideally x86_32 will unify with the 64-bit code and use vectors too. At that point we can move to mapping event channels to vectors, which will allow us to economise on irqs (so per-cpu event channels can share irqs, rather than having to allocte one per cpu, for example). Signed-off-by:
-
Jeremy Fitzhardinge authored
Use callback_op hypercall to register callbacks in a 32/64-bit independent way (64-bit doesn't need a code segment, but that detail is hidden in XEN_CALLBACK). Signed-off-by:
-
Jeremy Fitzhardinge authored
swapgs is a no-op under Xen, because the hypervisor makes sure the right version of %gs is current when switching between user and kernel modes. This means that the swapgs "implementation" can be inlined and used when the stack is unsafe (usermode). Unfortunately, it means that disabling patching will result in a non-booting kernel... Signed-off-by:
-
Jeremy Fitzhardinge authored
Xen pushes two extra words containing the values of rcx and r11. This pvop hook copies the words back into their appropriate registers, and cleans them off the stack. This leaves the stack in native form, so the normal handler can run unchanged. Signed-off-by:
-
Eduardo Habkost authored
Changed to use the (to-be-)unified descriptor structs. Signed-off-by:
Eduardo Habkost <ehabkost@Rawhide-64.localdomain> Signed-off-by:
-
Jeremy Fitzhardinge authored
Make Xen's set_pte_mfn() use set_pte_vaddr rather than copying it. Signed-off-by:
Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Mark McLoughlin <markmc@redhat.com> Cc: Stephen Tweedie <sct@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
We need to wait until the page structure is available to use the proper pagetable page alloc/release operations, since they use struct page to determine if a pagetable is pinned. This happened to work in 32bit because nobody allocated new pagetable pages in the interim between xen_pagetable_setup_done and xen_post_allocator_init, but the 64-bit kenrel needs to allocate more pagetable levels. Signed-off-by:
-
Jeremy Fitzhardinge authored
Someone's got to do it. Signed-off-by:
-
Jeremy Fitzhardinge authored
When building initial pagetables in 64-bit kernel the pud/pmd pointer may be in ioremap/fixmap space, so we need to walk the pagetable to look up the physical address. Signed-off-by:
-
Jeremy Fitzhardinge authored
arbitrary_virt_to_machine can truncate a machine address if its above 4G. Cast the problem away. Signed-off-by:
-
Jeremy Fitzhardinge authored
Rearrange the pagetable initialization to share code with the 64-bit kernel. Rather than deferring anything to pagetable_setup_start, just set up an initial pagetable in swapper_pg_dir early at startup, and create an additional 8MB of physical memory mappings. This matches the native head_32.S mappings to a large degree, and allows the rest of the pagetable setup to continue without much Xen vs. native difference. Signed-off-by:
-
Jeremy Fitzhardinge authored
Early in boot, map a chunk of extra physical memory for use later on. We need a pool of mapped pages to allocate further pages to construct pagetables mapping all physical memory. Signed-off-by:
-
Jeremy Fitzhardinge authored
It also doesn't need the 32-bit hack version of set_pte for initial pagetable construction, so just make it use the real thing. Signed-off-by:
-
Jeremy Fitzhardinge authored
Set up the initial pagetables to map the kernel mapping into the physical mapping space. This makes __va() usable, since it requires physical mappings. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
Split xen-asm into 32- and 64-bit files, and implement the 64-bit variants. Signed-off-by:
-
Jeremy Fitzhardinge authored
Add Xen vcpu_info offsets to asm-offsets_64. Signed-off-by:
-
Jeremy Fitzhardinge authored
Add the Xen entrypoint and ELF notes to head_64.S. Adapts xen-head.S to compile either 32-bit or 64-bit. Signed-off-by:
-
Jeremy Fitzhardinge authored
A number of random changes to make xen/smp.c compile in 64-bit mode. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>a Cc: Stephen Tweedie <sct@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Mark McLoughlin <markmc@redhat.com> Signed-off-by: -
Jeremy Fitzhardinge authored
As a stopgap until Mike Travis's x86-64 gs-based percpu patches are ready, provide workaround functions for x86_read/write_percpu for Xen's use. Specifically, this means that we can't really make use of vcpu placement, because we can't use a single gs-based memory access to get to vcpu fields. So disable all that for now. Signed-off-by:
-
Jeremy Fitzhardinge authored
Move all the smp_ops setup into smp.c, allowing a lot of things to become static. Signed-off-by:
-
Jeremy Fitzhardinge authored
x86_64 stores the active_mm in the pda, so fetch it from there. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
We need extra pv_mmu_ops for 64-bit, to deal with the extra level of pagetable. Signed-off-by:
-
Jeremy Fitzhardinge authored
The 64-bit calling convention for hypercalls uses different registers from 32-bit. Annoyingly, gcc's asm syntax doesn't have a way to specify one of the extra numeric reigisters in a constraint, so we must use explicitly placed register variables. Given that we have to do it for some args, may as well do it for all. Also fix syntax gcc generates for the call instruction itself. We need a plain direct call, but the asm expansion which works on 32-bit generates a rip-relative addressing mode in 64-bit, which is treated as an indirect call. The alternative is to pass the hypercall page offset into the asm, and have it add it to the hypercall page start address to generate the call. Signed-off-by:
-
Jeremy Fitzhardinge authored
64-bit guests can pass 64-bit quantities in a single argument, so fix up the hypercalls. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Jeremy Fitzhardinge authored
Copy 64-bit definitions of various interface structures into place. Signed-off-by:
-
