- 30 Aug, 2019 28 commits
-
-
Nicholas Piggin authored
Also change argument name (n -> vec) to match others. No generated code change. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190802105709.27696-28-npiggin@gmail.com
-
Nicholas Piggin authored
Replace the 4 variants of cpp macros with one gas macro. No generated code change except BUG line number constants. Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
All other virt handlers have the prolog code in the virt vector rather than branch to the real vector. Follow this pattern in the denorm virt handler. Signed-off-by:
-
Nicholas Piggin authored
EXCEPTION_PROLOG_0 and _1 have only a single caller, so expand them into it. Rename EXCEPTION_PROLOG_2_REAL to INT_SAVE_SRR_AND_JUMP and EXCEPTION_PROLOG_2_VIRT to INT_VIRT_SAVE_SRR_AND_JUMP, which are more descriptive. No generated code change except BUG line number constants. Signed-off-by:
-
Michael Ellerman authored
The argument lists for the INT_HANDLER macro are getting a bit unwieldy. Use keyword parameters with default values to shorten them. Signed-off-by:
-
Nicholas Piggin authored
This creates a single macro that generates the exception prolog code, with variants specified by arguments, rather than assorted nested macros for different variants. The increasing length of macro argument list is not nice to read or modify, but this is a temporary condition that will be improved in later changes. No generated code change except BUG line number constants and label names. Signed-off-by:
-
Nicholas Piggin authored
This vector is not used by any supported processor, and has been implemented as an unknown exception going back to 2.6. There is nothing special about 0xb00, so remove it like other unused vectors. Signed-off-by:
-
Nicholas Piggin authored
The perf virt handler uses EXCEPTION_PROLOG_2_REAL rather than _VIRT. In practice this is okay because the _REAL variant is usable by virt mode interrupts, but should be fixed (and is a performance win). Signed-off-by:
-
Nicholas Piggin authored
Add EXC_HV_OR_STD and use it to consolidate the 0x500 external interrupt. Executed code is unchanged. Signed-off-by:
-
Nicholas Piggin authored
The head-64.h code should deal only with the head code sections and offset calculations. No generated code change except BUG line number constants. Signed-off-by:
-
Nicholas Piggin authored
This buglet goes back to before the 64/32 arch merge, but it does not seem to have had practical consequences because bad_page_fault does not use the 2nd argument, but rather regs->dar/nip. Signed-off-by:
-
Nicholas Piggin authored
Short forward and backward branches can be given number labels, but larger significant divergences in code path a more readable if they're given descriptive names. Also adjusts a comment to account for guest delivery. Signed-off-by:
-
Nicholas Piggin authored
machine_check_early_common now branches to machine_check_handle_early which is its only caller. Move interleaving code out of the way, and remove the branch. Signed-off-by:
-
Nicholas Piggin authored
Similarly to the previous change, all callers of the unrecoverable handler run relocated so can reach it with a direct branch. This makes it easy to move out of line, which makes the "normal" path less cluttered and easier to follow. MSR[ME] manipulation still requires the rfi, so that is moved out of line to its own function. Signed-off-by:
-
Nicholas Piggin authored
machine_check_handle_early_common can reach machine_check_handle_early directly now that it runs at the relocated address, so just branch directly. The rfi sequence is required to enable MSR[ME] but that step is moved into a helper function, making the code easier to follow. Signed-off-by:
-
Nicholas Piggin authored
Following convention, move the tramp code (unrelocated) above the common handlers (relocated). Signed-off-by:
-
Nicholas Piggin authored
Follow the pattern of sreset and HMI handlers more closely: use EXCEPTION_PROLOG_COMMON_1 rather than open-coding it, and run the handler at the relocated location. This helps later simplification and code sharing. Signed-off-by:
-
Nicholas Piggin authored
The powernv machine check handler copes with taking a MCE from one of three contexts, guest, kernel, and user. In each case the early handler runs first on a special stack, then: - The guest case branches to the KVM interrupt handler (via standard interrupt macros). - The user case will run the "late" handler which is like a normal interrupt that runs in virtual mode and uses the regular kernel stack. - The kernel case queues the event and schedules it for processing with irq work. The last case is important, it must not enable virtual memory because the MMU state may not be set up to deal with that (e.g., SLB might be clear), it must not use the regular kernel stack for similar reasons (e.g., might be in OPAL with OPAL stack in r1), and the kernel does not expect anything to touch its stack if interrupts are disabled. The pseries handler does not do this queueing, but instead it always runs the late handler for host MCEs, which has some of the same problems. Now that pseries is using machine_check_events, change it to do the same as powernv and queue events for kernel MCEs. Signed-off-by:
-
Nicholas Piggin authored
The common machine_check_event data structures and queues are mostly platform independent, with powernv decoding SRR1/DSISR/etc., into machine_check_event objects. This patch converts pseries to use this infrastructure by decoding fwnmi/rtas data into machine_check_event objects. This allows queueing to be used by a subsequent change to delay the virtual mode handling of machine checks that occur in kernel space where it is unsafe to switch immediately to virtual mode, similarly to powernv. Signed-off-by:
-
Nicholas Piggin authored
Re-use the code introduced in pseries to save and dump the contents of the SLB in the case of an SLB involved machine check exception. This patch also avoids allocating the SLB save array on pseries radix. Signed-off-by:
-
Nicholas Piggin authored
Bare metal machine checks run an "early" handler in real mode before running the main handler which reports the event. The main handler runs exactly as a normal interrupt handler, after the "windup" which sets registers back as they were at interrupt entry. CFAR does not get restored by the windup code, so that will be wrong when the handler is run. Restore the CFAR to the saved value before running the late handler. Signed-off-by:
-
Nicholas Piggin authored
This label has only one caller, so unwind the branch and move it inline. The location of the comment is adjusted to match similar one in system reset. Signed-off-by:
-
Nicholas Piggin authored
Now that pseries with fwnmi registered runs the early machine check handler, there is no good reason to special case the non-fwnmi case and skip the early handler. Reducing the code and number of paths is a top priority for asm code, it's better to handle this in C where possible (and the pseries early handler is a no-op if fwnmi is not registered). Signed-off-by:
-
Nicholas Piggin authored
The host kernel delivery case for powernv does RFI_TO_USER_OR_KERNEL, but should just use RFI_TO_KERNEL which makes it clear this is not a user case. This is not a bug because RFI_TO_USER_OR_KERNEL deals with kernel returns just fine. Signed-off-by:
-
Nicholas Piggin authored
The machine_check_handle_early hypervisor guest test is skipped if !HVMODE or MSR[HV]=0, which is wrong for PR or nested hypervisors that could be running a guest in this state. Test HSTATE_IN_GUEST up front and use that to branch out to the KVM handler, then MSR[PR] alone can test for this kernel's userspace. This matches all other interrupt handling. Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
fwnmi does not trigger in HV mode, so remove always-true feature test. Signed-off-by:
-
- 29 Aug, 2019 12 commits
-
-
Ryan Grimm authored
Enables running as a secure guest in platforms with an Ultravisor. Signed-off-by:
Ryan Grimm <grimm@linux.vnet.ibm.com> Signed-off-by:
Ram Pai <linuxram@us.ibm.com> Signed-off-by:
Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by:
-
Anshuman Khandual authored
SWIOTLB checks range of incoming CPU addresses to be bounced and sees if the device can access it through its DMA window without requiring bouncing. In such cases it just chooses to skip bouncing. But for cases like secure guests on powerpc platform all addresses need to be bounced into the shared pool of memory because the host cannot access it otherwise. Hence the need to do the bouncing is not related to device's DMA window and use of bounce buffers is forced by setting swiotlb_force. Also, connect the shared memory conversion functions into the ARCH_HAS_MEM_ENCRYPT hooks and call swiotlb_update_mem_attributes() to convert SWIOTLB's memory pool to shared memory. Signed-off-by:
Anshuman Khandual <khandual@linux.vnet.ibm.com> [ bauerman: Use ARCH_HAS_MEM_ENCRYPT hooks to share swiotlb memory pool. ] Signed-off-by:
-
Thiago Jung Bauermann authored
Secure guest memory is inacessible to devices so regular DMA isn't possible. In that case set devices' dma_map_ops to NULL so that the generic DMA code path will use SWIOTLB to bounce buffers for DMA. Signed-off-by:
-
Sukadev Bhattiprolu authored
Normally, the HV emulates some instructions like MSGSNDP, MSGCLRP from a KVM guest. To emulate the instructions, it must first read the instruction from the guest's memory and decode its parameters. However for a secure guest (aka SVM), the page containing the instruction is in secure memory and the HV cannot access directly. It would need the Ultravisor (UV) to facilitate accessing the instruction and parameters but the UV currently does not have the support for such accesses. Until the UV has such support, disable doorbells in SVMs. This might incur a performance hit but that is yet to be quantified. With this patch applied (needed only in SVMs not needed for HV) we are able to launch SVM guests with multi-core support. Eg: qemu -smp sockets=2,cores=2,threads=2. Fix suggested by Benjamin Herrenschmidt. Thanks to input from Paul Mackerras, Ram Pai and Michael Anderson. Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by:
-
Ryan Grimm authored
User space might want to know it's running in a secure VM. It can't do a mfmsr because mfmsr is a privileged instruction. The solution here is to create a cpu attribute: /sys/devices/system/cpu/svm which will read 0 or 1 based on the S bit of the current CPU. Signed-off-by:
-
Ram Pai authored
A new kernel deserves a clean slate. Any pages shared with the hypervisor is unshared before invoking the new kernel. However there are exceptions. If the new kernel is invoked to dump the current kernel, or if there is a explicit request to preserve the state of the current kernel, unsharing of pages is skipped. NOTE: While testing crashkernel, make sure at least 256M is reserved for crashkernel. Otherwise SWIOTLB allocation will fail and crash kernel will fail to boot. Signed-off-by:
-
Anshuman Khandual authored
Secure guests need to share the DTL buffers with the hypervisor. To that end, use a kmem_cache constructor which converts the underlying buddy allocated SLUB cache pages into shared memory. Signed-off-by:
-
Anshuman Khandual authored
LPPACA structures need to be shared with the host. Hence they need to be in shared memory. Instead of allocating individual chunks of memory for a given structure from memblock, a contiguous chunk of memory is allocated and then converted into shared memory. Subsequent allocation requests will come from the contiguous chunk which will be always shared memory for all structures. While we are able to use a kmem_cache constructor for the Debug Trace Log, LPPACAs are allocated very early in the boot process (before SLUB is available) so we need to use a simpler scheme here. Introduce helper is_svm_platform() which uses the S bit of the MSR to tell whether we're running as a secure guest. Signed-off-by:
-
Thiago Jung Bauermann authored
Helps document what the hard-coded number means. Also take the opportunity to fix an #endif comment. Suggested-by:
Alexey Kardashevskiy <aik@linux.ibm.com> Signed-off-by:
-
Sukadev Bhattiprolu authored
Protected Execution Facility (PEF) is an architectural change for POWER 9 that enables Secure Virtual Machines (SVMs). When enabled, PEF adds a new higher privileged mode, called Ultravisor mode, to POWER architecture. The hardware changes include the following: * There is a new bit in the MSR that determines whether the current process is running in secure mode, MSR(S) bit 41. MSR(S)=1, process is in secure mode, MSR(s)=0 process is in normal mode. * The MSR(S) bit can only be set by the Ultravisor. * HRFID cannot be used to set the MSR(S) bit. If the hypervisor needs to return to a SVM it must use an ultracall. It can determine if the VM it is returning to is secure. * The privilege of a process is now determined by three MSR bits, MSR(S, HV, PR). In each of the tables below the modes are listed from least privilege to highest privilege. The higher privilege modes can access all the resources of the lower privilege modes. **Secure Mode MSR Settings** +---+---+---+---------------+ | S | HV| PR|Privilege | +===+===+===+===============+ | 1 | 0 | 1 | Problem | +---+---+---+---------------+ | 1 | 0 | 0 | Privileged(OS)| +---+---+---+---------------+ | 1 | 1 | 0 | Ultravisor | +---+---+---+---------------+ | 1 | 1 | 1 | Reserved | +---+---+---+---------------+ **Normal Mode MSR Settings** +---+---+---+---------------+ | S | HV| PR|Privilege | +===+===+===+===============+ | 0 | 0 | 1 | Problem | +---+---+---+---------------+ | 0 | 0 | 0 | Privileged(OS)| +---+---+---+---------------+ | 0 | 1 | 0 | Hypervisor | +---+---+---+---------------+ | 0 | 1 | 1 | Problem (HV) | +---+---+---+---------------+ Signed-off-by:Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Claudio Carvalho <cclaudio@linux.ibm.com> Signed-off-by:
-
Ram Pai authored
These functions are used when the guest wants to grant the hypervisor access to certain pages. Signed-off-by:
-
Ram Pai authored
Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure mode. Pass kernel base address and FDT address so that the Ultravisor is able to verify the integrity of the VM using information from the ESM blob. Add "svm=" command line option to turn on switching to secure mode. Signed-off-by:
Michael Anderson <andmike@linux.ibm.com> [ bauerman: Cleaned up the code a bit. ] Signed-off-by:
-
