summaryrefslogtreecommitdiffstats
path: root/sys/x86
Commit message (Collapse)AuthorAgeFilesLines
...
* Registers definitions for the new capabilities from the version 2.4 ofkib2015-02-112-4/+67
| | | | | | | | | | | VT-d specification. Also add definitions for the interrupt remapping table and IEC. Print new capabilities on boot. although there is no hardware which support it. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* vm_page_lookup() accepts read-locked object.kib2015-02-111-4/+2
| | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Add x2APIC support. Enable it by default if CPU is capable. Thekib2015-02-097-115/+365
| | | | | | | | | | | | | | | | | | | | | | | | | hw.x2apic_enable tunable allows disabling it from the loader prompt. To closely repeat effects of the uncached memory ops when accessing registers in the xAPIC mode, the x2APIC writes to MSRs are preceeded by mfence, except for the EOI notifications. This is probably too strict, only ICR writes to send IPI require serialization to ensure that other CPUs see the previous actions when IPI is delivered. This may be changed later. In vmm justreturn IPI handler, call doreti_iret instead of doing iretd inline, to handle corner conditions. Note that the patch only switches LAPICs into x2APIC mode. It does not enables FreeBSD to support > 255 CPUs, which requires parsing x2APIC MADT entries and doing interrupts remapping, but is the required step on the way. Reviewed by: neel Tested by: pho (real hardware), neel (on bhyve) Discussed with: jhb, grehan Sponsored by: The FreeBSD Foundation MFC after: 2 months
* Revert the IPI startup sequence to match what is described in thejhb2015-02-061-14/+14
| | | | | | | | | | | | | | Intel Multiprocessor Specification v1.4. The Intel SDM claims that the INIT IPIs here are invalid, but other systems follow the MP spec instead. While here, fix the IPI wait routine to accept a timeout in microseconds instead of a raw spin count, and don't spin forever during AP startup. Instead, panic if a STARTUP IPI is not delivered after 20 us. PR: 196542 Differential Revision: https://reviews.freebsd.org/D1719 MFC after: 2 weeks
* Add interface to derive a TSC frequency from the pvclockbryanv2015-02-042-0/+16
| | | | | | | This can later use this to determine the TSC frequency like is done with VMware, instead of using a DELAY loop that is not always accurate in an VM. MFC after: 1 month
* Generalized parts of the XEN timer code into a generic pvclockbryanv2015-02-042-0/+246
| | | | | | | | | KVM clock shares the same data structures between the guest and the host as Xen so it makes sense to just have a single copy of this code. Differential Revision: https://reviews.freebsd.org/D1429 Reviewed by: royger (eariler version) MFC after: 1 month
* Opt for performance over power-saving on Intel CPUs that have ajhb2015-01-291-5/+10
| | | | | | | | | P-state but not C-state invariant TSC by changing the default behavior to leaving the TSC enabled as the timecounter and disabling C2+ instead of disabling the TSC by default. Discussed with: jkim Tested by: Jan Kokemuller <jan.kokemueller@gmail.com>
* loader: fix the size of MODINFOMD_MODULEProyger2015-01-201-1/+1
| | | | | | | | | The data in MODINFOMD_MODULEP is packed by the loader as a 4 byte type, but the amd64 kernel expects a vm_paddr_t, which is of size 8 bytes. Fix this by saving it as 8 bytes in the loader and retrieving it using the proper type in the kernel. Sponsored by: Citrix Systems R&D
* Update the vdso timehands only via tc_windup().neel2015-01-201-6/+7
| | | | | | | | | Prior to this change CLOCK_MONOTONIC could go backwards when the timecounter hardware was changed via 'sysctl kern.timecounter.hardware'. This happened because the vdso timehands update was missing the special treatment in tc_windup() when changing timecounters. Reviewed by: kib
* Include mca_machdep.h.imp2015-01-181-0/+3
|
* Need to include opt_mca.h to test for DEV_MCA.imp2015-01-171-0/+1
|
* loader: implement multiboot support for Xen Dom0royger2015-01-151-5/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
* For x86, read MAXPHYADDR, defined in SDM vol 3 4.1.4 Enumeration of Pagingkib2015-01-121-0/+3
| | | | | | | | | Features by CPUID as CPUID.80000008H:EAX[7:0], into variable cpu_maxphyaddr. Reviewed by: alc Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Right now, for non-coherent DMARs, page table update code flushes thekib2015-01-114-21/+54
| | | | | | | | | | | | | | | | | | | | | | cache for whole page containing modified pte, and more, only last page in the series of the consequtive pages is flushed (i.e. the affected mappings should be larger than 2MB). Avoid excessive flushing and do missed neccessary flushing, by splitting invalidation and unmapping. For now, flush exactly the range of the changed pte. This is still somewhat bigger than neccessary, since pte is 8 bytes, while cache flush line is at least 32 bytes. The originator of the issue reports that after the change, 'dmar_bus_dmamap_unload went from 13,288 cycles down to 3,257. dmar_bus_dmamap_load_buffer went from 9,686 cycles down to 3,517. and I am now able to get line 1GbE speed with Netperf TCP (even with 1K message size).' Diagnosed and tested by: Nadav Amit <nadav.amit@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Fix calculation of requester for PCI device behind PCIe/PCI bridge.kib2015-01-101-25/+27
| | | | | | | | | | | | | | | | | | | In my case on the test machine, I have hierarchy of pcib2 (PCIe port on host bridge with PCIe capability) -> pci2 -> pcib3 (ITE PCIe/PCI bridge) -> pci3 -> em1 The device to check PCIe capability is pcib2 and not pcib3, as it is currently done in the code. Also, in case of the bridge, we shall step to pcib2 for the loop iteration, since pcib3 does not carry PCIe capability info and would force wrong recalculation of rid. Also change the returned requester to the PCIe bus which provides port for the bridge. This only results in changing hw.busdma.pciX.X.X.X.bounce tunable to force identity-mapped context for the device. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Print rid when announcing DMAR context creation. Print sid when faultkib2015-01-102-4/+5
| | | | | | | | occurs. This allows to connect dots in case the requester is calculated erronously. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Fix DMAR context allocations for the devices behind PCIe->PCI bridgeskib2015-01-091-1/+1
| | | | | | | | | after dmar driver was converted to use rids. The bus component to calculate context page must be taken from the requestor rid, which is a bridge, and not from the device bus number. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Update Features2 to display SDBG capability of processor. This issbruno2015-01-082-1/+2
| | | | | | | | | | | | | | showing up on Haswell-class CPUs From the Intel SDM, "Table 3-20. Feature Information Returned in the ECX Register" 11 | SDBG | A value of 1 indicates the processor supports IA32_DEBUG_INTERFACE MSR for silicon debug. Submitted by: jiashiun@gmail.com Reviewed by: jhb neel MFC after: 2 weeks
* Create a cpuset mask for each NUMA domain that is available in thejhb2015-01-081-1/+2
| | | | | | | | | | | kernel via the global cpuset_domain[] array. To export these to userland, add a CPU_WHICH_DOMAIN level that can be used to fetch the mask for a specific domain. Add a -d flag to cpuset(1) that can be used to fetch the mask for a given domain. Differential Revision: https://reviews.freebsd.org/D1232 Submitted by: jeff (kernel bits) Reviewed by: adrian, jeff
* Factor out duplicated code from dumpsys() on each architecture into genericmarkj2015-01-072-333/+96
| | | | | | | | | | | | | | code in sys/kern/kern_dump.c. Most dumpsys() implementations are nearly identical and simply redefine a number of constants and helper subroutines; a generic implementation will make it easier to implement features around kernel core dumps. This change does not alter any minidump code and should have no functional impact. PR: 193873 Differential Revision: https://reviews.freebsd.org/D904 Submitted by: Conrad Meyer <conrad.meyer@isilon.com> Reviewed by: jhibbits (earlier version) Sponsored by: EMC / Isilon Storage Division
* On some Intel CPUs with a P-state but not C-state invariant TSC the TSCjhb2015-01-051-6/+6
| | | | | | | | | | | | may also halt in C2 and not just C3 (it seems that in some cases the BIOS advertises its C3 state as a C2 state in _CST). Just play it safe and disable both C2 and C3 states if a user forces the use of the TSC as the timecounter on such CPUs. PR: 192316 Differential Revision: https://reviews.freebsd.org/D1441 No objection from: jkim MFC after: 1 week
* Fix warning about possible use of uninitialized variable.hselasky2015-01-021-1/+1
|
* xen/intr: balance dynamic interrupts across available vCPUsroyger2014-12-101-0/+11
| | | | | | | | | | | | By default Xen binds all event channels to vCPU#0, and FreeBSD only shuffles the interrupt sources once, at the end of the boot process. Since new event channels might be created after this point (because new devices or backends are added), try to automatically shuffle them at creation time. This does not affect VIRQ or IPI event channels, that are already bound to a specific vCPU as requested by the caller. Sponsored by: Citrix Systems R&D
* xen: mask event channels while binding them to a vCPUroyger2014-12-101-11/+12
| | | | | | | | Mask the event channel source before trying to bind it to a CPU, this prevents stray interrupts from firing while assigning them and hitting the KASSERT in xen_intr_handle_upcall. Sponsored by: Citrix Systems R&D
* xen: convert the Grant-table code to a NewBus deviceroyger2014-12-101-9/+0
| | | | | | | This allows the Grant-table code to attach directly to the xenpv bus, allowing us to remove the grant-table initialization done in xenpv. Sponsored by: Citrix Systems R&D
* xen: create a new PCI bus overrideroyger2014-12-091-46/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When running as a Xen PVH Dom0 we need to add custom buses that override some of the functionality present in the ACPI PCI Bus and the PCI Bus. We currently override the ACPI PCI Bus, but not the PCI Bus, so add a new override for the PCI Bus and share the generic functions between them. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D conf/files.amd64: - Add the new files. x86/xen/xen_pci_bus.c: - Generic file that contains the PCI overrides so they can be used by the several PCI specific buses. xen/xen_pci.h: - Prototypes for the generic overried functions. dev/xen/pci/xen_pci.c: - Xen specific override for the PCI bus. dev/xen/pci/xen_acpi_pci.c: - Xen specific override for the ACPI PCI bus.
* xen: notify ACPI about SCI overrideroyger2014-12-091-0/+9
| | | | | | | | If the SCI is remapped to a non-ISA global interrupt notify the ACPI subsystem about the override. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D
* Improve support for XSAVE with debuggers.jhb2014-11-212-12/+22
| | | | | | | | | | | | | | | | | | | - Dump an NT_X86_XSTATE note if XSAVE is in use. This note is designed to match what Linux does in that 1) it dumps the entire XSAVE area including the fxsave state, and 2) it stashes a copy of the current xsave mask in the unused padding between the fxsave state and the xstate header at the same location used by Linux. - Teach readelf() to recognize NT_X86_XSTATE notes. - Change PT_GET/SETXSTATE to take the entire XSAVE state instead of only the extra portion. This avoids having to always make two ptrace() calls to get or set the full XSAVE state. - Add a PT_GET_XSTATE_INFO which returns the length of the current XSTATE save area (so the size of the buffer needed for PT_GETXSTATE) and the current XSAVE mask (%xcr0). Differential Revision: https://reviews.freebsd.org/D1193 Reviewed by: kib MFC after: 2 weeks
* MFamd64: Add support for extended FPU states on i386. This includesjhb2014-11-021-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | support for AVX on i386. - Similar to amd64, move the FPU save area out of the PCB and instead store saved FPU state in a variable-sized buffer after the PCB on the stack. - To support the variable PCB location, alter the locore code to only use the bottom-most page of proc0stack for init386(). init386() returns the correct stack pointer to locore which adjusts the stack for thread0 before calling mi_startup(). - Don't bother setting cr3 in thread0's pcb in locore before calling init386(). It wasn't used (init386() overwrote it at the end) and it doesn't work with the variable-sized FPU save area. - Remove the new-bus attachment from npx. This was only ever useful for external co-processors using IRQ13, but those have not been supported for several years. npxinit() is now called much earlier during boot (init386()) similar to amd64. - Implement PT_{GET,SET}XSTATE and I386_GET_XFPUSTATE. - npxsave() is now only called from context switch contexts so it can use XSAVEOPT. Differential Revision: https://reviews.freebsd.org/D1058 Reviewed by: kib Tested on: FreeBSD/i386 VM under bhyve on Intel i5-2520
* Rework virtual machine hypervisor detection.jhb2014-10-283-74/+174
| | | | | | | | | | | | | | | - Move the existing code to x86/x86/identcpu.c since it is x86-specific. - If the CPUID2_HV flag is set, assume a hypervisor is present and query the 0x40000000 leaf to determine the hypervisor vendor ID. Export the vendor ID and the highest supported hypervisor CPUID leaf via hv_vendor[] and hv_high variables, respectively. The hv_vendor[] array is also exported via the hw.hv_vendor sysctl. - Merge the VMWare detection code from tsc.c into the new probe in identcpu.c. Add a VM_GUEST_VMWARE to identify vmware and use that in the TSC code to identify VMWare. Differential Revision: https://reviews.freebsd.org/D1010 Reviewed by: delphij, jkim, neel
* Output a summary of optional SVM features in dmesg similar to CPU features.grehan2014-10-271-0/+65
| | | | | | | | | If bootverbose is enabled, a detailed list is provided; otherwise, a single-line summary is displayed. Differential Revision: https://reviews.freebsd.org/D1008 Reviewed by: jhb, neel MFC after: 1 week
* xen: implement the privcmd user-space deviceroyger2014-10-221-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This device is only attached to priviledged domains, and allows the toolstack to interact with Xen. The two functions of the privcmd interface is to allow the execution of hypercalls from user-space, and the mapping of foreign domain memory. Sponsored by: Citrix Systems R&D i386/include/xen/hypercall.h: amd64/include/xen/hypercall.h: - Introduce a function to make generic hypercalls into Xen. xen/interface/xen.h: xen/interface/memory.h: - Import the new hypercall XENMEM_add_to_physmap_range used by auto-translated guests to map memory from foreign domains. dev/xen/privcmd/privcmd.c: - This device has the following functions: - Allow user-space applications to make hypercalls into Xen. - Allow user-space applications to map memory from foreign domains, this is accomplished using the newly introduced hypercall (XENMEM_add_to_physmap_range). xen/privcmd.h: - Public ioctl interface for the privcmd device. x86/xen/hvm.c: - Remove declaration of hypercall_page, now it's declared in hypercall.h. conf/files: - Add the privcmd device to the build process.
* xen: allow to register event channels without handlersroyger2014-10-221-17/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed by the event channel user-space device, that requires registering event channels without unmasking them. intr_add_handler will unconditionally unmask the event channel, so we avoid calling it if no filter/handler is provided, and then the user will be in charge of calling it when ready. In order to do this, we need to change the opaque type xen_intr_handle_t to contain the event channel port instead of the opaque cookie returned by intr_add_handler, since now registration of event channels without handlers are allowed. The cookie will now be stored inside of the private xenisrc struct. Also, introduce a new function called xen_intr_add_handler that allows adding a filter/handler after the event channel has been registered. Sponsored by: Citrix Systems R&D x86/xen/xen_intr.c: - Leave the event channel without a handler if no filter/handler is provided to xen_intr_bind_isrc. - Don't perform an evtchn_mask_port, intr_add_handler will already do it. - Change the opaque type xen_intr_handle_t to contain a pointer to the event channel port number, and make the necessary changes to related functions. - Introduce a new function called xen_intr_add_handler that can be used to add filter/handlers to an event channel after registration. xen/xen_intr.h: - Add prototype of xen_intr_add_handler.
* xen: fix usage of kern_getenv in PVH coderoyger2014-10-221-1/+4
| | | | | | | | The value returned by kern_getenv should be freed using freeenv. Reported by: Coverity CID: 1248852 Sponsored by: Citrix Systems R&D
* Virtual machines can easily have more than 16 option ROMs andmarcel2014-10-221-2/+2
| | | | | | | | | when that happens, we happily access our resource array out of bounds. Make sure we stay within the MAX_ROMS limit. While here, bump MAX_ROMS from 16 to 32 to minimize the chance of leaving option ROMs unaccounted for. Obtained from: Juniper Networks, Inc.
* Fix multiple incorrect SYSCTL arguments in the kernel:hselasky2014-10-211-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Wrong integer type was specified. - Wrong or missing "access" specifier. The "access" specifier sometimes included the SYSCTL type, which it should not, except for procedural SYSCTL nodes. - Logical OR where binary OR was expected. - Properly assert the "access" argument passed to all SYSCTL macros, using the CTASSERT macro. This applies to both static- and dynamically created SYSCTLs. - Properly assert the the data type for both static and dynamic SYSCTLs. In the case of static SYSCTLs we only assert that the data pointed to by the SYSCTL data pointer has the correct size, hence there is no easy way to assert types in the C language outside a C-function. - Rewrote some code which doesn't pass a constant "access" specifier when creating dynamic SYSCTL nodes, which is now a requirement. - Updated "EXAMPLES" section in SYSCTL manual page. MFC after: 3 days Sponsored by: Mellanox Technologies
* Merge from projects/bhyve_svm all the changes outside vmm.ko or bhyve utilities:neel2014-10-201-0/+14
| | | | | | | | | | | | | | | | | Add support for AMD's nested page tables in pmap.c: - Provide the correct bit mask for various bit fields in a PTE (e.g. valid bit) for a pmap of type PT_RVI. - Add a function 'pmap_type_guest(pmap)' that returns TRUE if the pmap is of type PT_EPT or PT_RVI. Add CPU_SET_ATOMIC_ACQ(num, cpuset): This is used when activating a vcpu in the nested pmap. Using the 'acquire' variant guarantees that the load of the 'pm_eptgen' will happen only after the vcpu is activated in 'pm_active'. Add defines for various AMD-specific MSRs. Submitted by: Anish Gupta (akgupt3@gmail.com)
* Follow up to r225617. In order to maximize the re-usability of kernel codedavide2014-10-163-3/+3
| | | | | | | | in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv(). This fixes a namespace collision with libc symbols. Submitted by: kmacy Tested by: make universe
* Support Intel-specific MSRs that are accessed when booting up a linux in bhyve:neel2014-10-091-0/+4
| | | | | | | | | - MSR_PLATFORM_INFO - MSR_TURBO_RATIO_LIMITx - MSR_RAPL_POWER_UNIT Reviewed by: grehan MFC after: 1 week
* Missing from previous commit - keep the VM domain -> PXM mappingadrian2014-10-091-8/+28
| | | | | | | array and use it to map PXM -> VM domain when needed. Differential Revision: D906 Reviewed by: jhb
* Pass up the error status of minidumpsys() to its callers.markj2014-10-081-4/+3
| | | | | | PR: 193761 Submitted by: Conrad Meyer <conrad.meyer@isilon.com> Sponsored by: EMC / Isilon Storage Division
* Fix build for i386 kernels with out 'I686_CPU'.jhb2014-10-061-1/+1
| | | | | PR: 193660 Submitted by: holger@freyther.de
* xen: add the Xen implementation of pci_child_added methodroyger2014-09-301-0/+24
| | | | | | | | | | | Add the Xen specific implementation of pci_child_added to the Xen PCI bus. This is needed so FreeBSD can register the devices it finds with the hypervisor. Sponsored by: Citrix Systems R&D x86/xen/xen_pci.c: - Add the Xen pci_child_added method.
* msi: add Xen MSI implementationroyger2014-09-307-1/+344
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for MSI interrupts when running on Xen. Apart from adding the Xen related code needed in order to register MSI interrupts this patch also makes the msi_init function a hook in init_ops, so different MSI implementations can have different initialization functions. Sponsored by: Citrix Systems R&D xen/interface/physdev.h: - Add the MAP_PIRQ_TYPE_MULTI_MSI to map multi-vector MSI to the Xen public interface. x86/include/init.h: - Add a hook for setting custom msi_init methods. amd64/amd64/machdep.c: i386/i386/machdep.c: - Set the default msi_init hook to point to the native MSI initialization method. x86/xen/pv.c: - Set the Xen MSI init hook when running as a Xen guest. x86/x86/local_apic.c: - Call the msi_init hook instead of directly calling msi_init. xen/xen_intr.h: x86/xen/xen_intr.c: - Introduce support for registering/releasing MSI interrupts with Xen. - The MSI interrupts will use the same PIC as the IO APIC interrupts. xen/xen_msi.h: x86/xen/xen_msi.c: - Introduce a Xen MSI implementation. x86/xen/xen_nexus.c: - Overwrite the default MSI hooks in the Xen Nexus to use the Xen MSI implementation. x86/xen/xen_pci.c: - Introduce a Xen specific PCI bus that inherits from the ACPI PCI bus and overwrites the native MSI methods. - This is needed because when running under Xen the MSI messages used to configure MSI interrupts on PCI devices are written by Xen itself. dev/acpica/acpi_pci.c: - Lower the quality of the ACPI PCI bus so the newly introduced Xen PCI bus can take over when needed. conf/files.i386: conf/files.amd64: - Add the newly created files to the build process.
* xen: add proper copyright attributionroyger2014-09-261-0/+1
| | | | Noted by: jmallett
* ddb: allow specifying the exact address of the symtab and strtabroyger2014-09-251-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the FreeBSD kernel is loaded from Xen the symtab and strtab are not loaded the same way as the native boot loader. This patch adds three new global variables to ddb that can be used to specify the exact position and size of those tables, so they can be directly used as parameters to db_add_symbol_table. A new helper is introduced, so callers that used to set ksym_start and ksym_end can use this helper to set the new variables. It also adds support for loading them from the Xen PVH port, that was previously missing those tables. Sponsored by: Citrix Systems R&D Reviewed by: kib ddb/db_main.c: - Add three new global variables: ksymtab, kstrtab, ksymtab_size that can be used to specify the position and size of the symtab and strtab. - Use those new variables in db_init in order to call db_add_symbol_table. - Move the logic in db_init to db_fetch_symtab in order to set ksymtab, kstrtab, ksymtab_size from ksym_start and ksym_end. ddb/ddb.h: - Add prototype for db_fetch_ksymtab. - Declate the extern variables ksymtab, kstrtab and ksymtab_size. x86/xen/pv.c: - Add support for finding the symtab and strtab when booted as a Xen PVH guest. Since Xen loads the symtab and strtab as NetBSD expects to find them we have to adapt and use the same method. amd64/amd64/machdep.c: arm/arm/machdep.c: i386/i386/machdep.c: mips/mips/machdep.c: pc98/pc98/machdep.c: powerpc/aim/machdep.c: powerpc/booke/machdep.c: sparc64/sparc64/machdep.c: - Use the newly introduced db_fetch_ksymtab in order to set ksymtab, kstrtab and ksymtab_size.
* Restructure the MSR handling so it is entirely handled by processor-specificneel2014-09-201-0/+4
| | | | | | | | | | | | | | | | | | | code. There are only a handful of MSRs common between the two so there isn't too much duplicate functionality. The VT-x code has the following types of MSRs: - MSRs that are unconditionally saved/restored on every guest/host context switch (e.g., MSR_GSBASE). - MSRs that are restored to guest values on entry to vmx_run() and saved before returning. This is an optimization for MSRs that are not used in host kernel context (e.g., MSR_KGSBASE). - MSRs that are emulated and every access by the guest causes a trap into the hypervisor (e.g., MSR_IA32_MISC_ENABLE). Reviewed by: grehan
* Migrate ie->ie_assign_cpu and associated code to use an int for CPU ratheradrian2014-09-171-2/+2
| | | | | | | | | | | | | | | | | than u_char. Migrate post_filter to use an int for a CPU rather than u_char. Change intr_event_bind() to use an int for CPU rather than u_char. It touches the ppc, sparc64, arm and mips machdep code but it should (hah!) be a no-op. Tested: * i386, AMD64 laptops Reviewed by: jhb
* xen: don't set suspend/resume methods for the PIRQ PICroyger2014-09-151-2/+0
| | | | | | | | | The suspend/resume of event channels is already handled by the xen_intr_pic. If those methods are set on the PIRQ PIC they are just called twice, which breaks proper resume. This fix restores migration of FreeBSD guests to a working state. Sponsored by: Citrix Systems R&D
* To workaround an errata on certain Pentium Pro CPUs, i386 disablesjhb2014-09-101-10/+1
| | | | | | | the local APIC in initializecpu() and re-enables it if the APIC code decides to use the local APIC after all. Rework this workaround slightly so that initializecpu() won't re-disable the local APIC if it is called after the APIC code re-enables the local APIC.
OpenPOWER on IntegriCloud