Commit Graph

4 Commits

Author SHA1 Message Date
Neel Natu
9b1aa8d622 Restructure memory allocation in bhyve to support "devmem".
devmem is used to represent MMIO devices like the boot ROM or a VESA framebuffer
where doing a trap-and-emulate for every access is impractical. devmem is a
hybrid of system memory (sysmem) and emulated device models.

devmem is mapped in the guest address space via nested page tables similar
to sysmem. However the address range where devmem is mapped may be changed
by the guest at runtime (e.g. by reprogramming a PCI BAR). Also devmem is
usually mapped RO or RW as compared to RWX mappings for sysmem.

Each devmem segment is named (e.g. "bootrom") and this name is used to
create a device node for the devmem segment (e.g. /dev/vmm/testvm.bootrom).
The device node supports mmap(2) and this decouples the host mapping of
devmem from its mapping in the guest address space (which can change).

Reviewed by:	tychon
Discussed with:	grehan
Differential Revision:	https://reviews.freebsd.org/D2762
MFC after:	4 weeks
2015-06-18 06:00:17 +00:00
John Baldwin
b3e9732a76 Implement a PCI interrupt router to route PCI legacy INTx interrupts to
the legacy 8259A PICs.
- Implement an ICH-comptabile PCI interrupt router on the lpc device with
  8 steerable pins configured via config space access to byte-wide
  registers at 0x60-63 and 0x68-6b.
- For each configured PCI INTx interrupt, route it to both an I/O APIC
  pin and a PCI interrupt router pin.  When a PCI INTx interrupt is
  asserted, ensure that both pins are asserted.
- Provide an initial routing of PCI interrupt router (PIRQ) pins to
  8259A pins (ISA IRQs) and initialize the interrupt line config register
  for the corresponding PCI function with the ISA IRQ as this matches
  existing hardware.
- Add a global _PIC method for OSPM to select the desired interrupt routing
  configuration.
- Update the _PRT methods for PCI bridges to provide both APIC and legacy
  PRT tables and return the appropriate table based on the configured
  routing configuration.  Note that if the lpc device is not configured, no
  routing information is provided.
- When the lpc device is enabled, provide ACPI PCI link devices corresponding
  to each PIRQ pin.
- Add a VMM ioctl to adjust the trigger mode (edge vs level) for 8259A
  pins via the ELCR.
- Mark the power management SCI as level triggered.
- Don't hardcode the number of elements in Packages in the source for
  the DSDT.  iasl(8) will fill in the actual number of elements, and
  this makes it simpler to generate a Package with a variable number of
  elements.

Reviewed by:	tycho
2014-05-15 14:16:55 +00:00
John Baldwin
e6c8bc291a Rework the DSDT generation code a bit to generate more accurate info about
LPC devices.  Among other things, the LPC serial ports now appear as
ACPI devices.
- Move the info for the top-level PCI bus into the PCI emulation code and
  add ResourceProducer entries for the memory ranges decoded by the bus
  for memory BARs.
- Add a framework to allow each PCI emulation driver to optionally write
  an entry into the DSDT under the \_SB_.PCI0 namespace.  The LPC driver
  uses this to write a node for the LPC bus (\_SB_.PCI0.ISA).
- Add a linker set to allow any LPC devices to write entries into the
  DSDT below the LPC node.
- Move the existing DSDT block for the RTC to the RTC driver.
- Add DSDT nodes for the AT PIC, the 8254 ISA timer, and the LPC UART
  devices.
- Add a "SuperIO" device under the LPC node to claim "system resources"
  aling with a linker set to allow various drivers to add IO or memory
  ranges that should be claimed as a system resource.
- Add system resource entries for the extended RTC IO range, the registers
  used for ACPI power management, the ELCR, PCI interrupt routing register,
  and post data register.
- Add various helper routines for generating DSDT entries.

Reviewed by:	neel (earlier version)
2014-01-02 21:26:59 +00:00
Neel Natu
ea7f1c8cd2 Add support for PCI-to-ISA LPC bridge emulation. If the LPC bus is attached
to a virtual machine then we implicitly create COM1 and COM2 ISA devices.

Prior to this change the only way of attaching a COM port to the virtual
machine was by presenting it as a PCI device that is mapped at the legacy
I/O address 0x3F8 or 0x2F8.

There were some issues with the original approach:
- It did not work at all with UEFI because UEFI will reprogram the PCI device
  BARs and remap the COM1/COM2 ports at non-legacy addresses.
- OpenBSD GENERIC kernel does not create a /dev/console because it expects
  the uart device at the legacy 0x3F8/0x2F8 address to be an ISA device.
- It was functional with a FreeBSD guest but caused the console to appear
  on /dev/ttyu2 which was not intuitive.

The uart emulation is now independent of the bus on which it resides. Thus it
is possible to have uart devices on the PCI bus in addition to the legacy
COM1/COM2 devices behind the LPC bus.

The command line option to attach ISA COM1/COM2 ports to a virtual machine is
"-s <bus>,lpc -l com1,stdio".

The command line option to create a PCI-attached uart device is:
"-s <bus>,uart[,stdio]"

The command line option to create PCI-attached COM1/COM2 device is:
"-S <bus>,uart[,stdio]". This style of creating COM ports is deprecated.

Discussed with:	grehan
Reviewed by:	grehan
Submitted by:	Tycho Nightingale (tycho.nightingale@pluribusnetworks.com)

M    share/examples/bhyve/vmrun.sh
AM   usr.sbin/bhyve/legacy_irq.c
AM   usr.sbin/bhyve/legacy_irq.h
M    usr.sbin/bhyve/Makefile
AM   usr.sbin/bhyve/uart_emul.c
M    usr.sbin/bhyve/bhyverun.c
AM   usr.sbin/bhyve/uart_emul.h
M    usr.sbin/bhyve/pci_uart.c
M    usr.sbin/bhyve/pci_emul.c
M    usr.sbin/bhyve/inout.c
M    usr.sbin/bhyve/pci_emul.h
M    usr.sbin/bhyve/inout.h
AM   usr.sbin/bhyve/pci_lpc.c
AM   usr.sbin/bhyve/pci_lpc.h
2013-10-29 00:18:11 +00:00