bhyve: Support legacy PCI interrupts on arm64

This allows us to remove various #ifdef hacks and enable building more
PCI devices.

Note that a hole is left in the interrupt mapping for the RTC rathe

bhyve: Support legacy PCI interrupts on arm64

This allows us to remove various #ifdef hacks and enable building more
PCI devices.

Note that a hole is left in the interrupt mapping for the RTC rather
than having the two core devices straddle the PCIe interrupts. QEMU's
virt machine also takes this approach.

Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD

show more ...

bhyve: Do not compile PCI passthrough support on arm64

Some required kernel functionality is not yet implemented.

For now this means that one cannot specify host PCI register values, but
that funct

bhyve: Do not compile PCI passthrough support on arm64

Some required kernel functionality is not yet implemented.

For now this means that one cannot specify host PCI register values, but
that functionality is only used by amd64-specific device models for now.
Note that this limitation is rather artificial; it arises only because
pci_host_read_config() lives in pci_passthru.c.

Reviewed by: corvink, andrew, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41738

show more ...

bhyve: Make gdb support optional

Add a BHYVE_GDB_SUPPORT make variable that can be set by per-arch
makefiles. When set, BHYVE_GDB is defined and can be used as a
preprocessor predicate. Use it to

bhyve: Make gdb support optional

Add a BHYVE_GDB_SUPPORT make variable that can be set by per-arch
makefiles. When set, BHYVE_GDB is defined and can be used as a
preprocessor predicate. Use it to guard gdb stub calls in MI code.

The arm64 bhyve port currently does not have a functional gdb stub, but
that's not critical to landing the port, so this mechanism slightly
reduces the friction of adding support for a new platform.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40986

show more ...

bhyve: Make most I/O port handling specific to amd64

- The qemu_fwcfg interface, as implemented, is I/O port-based, but QEMU
implements an MMIO interface that we'll eventually want to port for
a

bhyve: Make most I/O port handling specific to amd64

- The qemu_fwcfg interface, as implemented, is I/O port-based, but QEMU
implements an MMIO interface that we'll eventually want to port for
arm64.
- Retain support for I/O space PCI BARs, simply treat them like MMIO
BARs for most purposes, similar to what the arm64 kernel does. Such
BARs are created by virtio devices.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40741

show more ...

bhyve: Conditionally compile framebuffer-related code

The arm64 port does not implement VGA, so move the device model sources.
Compile framebuffer code only on amd64 for now, but do not move the
sou

bhyve: Conditionally compile framebuffer-related code

The arm64 port does not implement VGA, so move the device model sources.
Compile framebuffer code only on amd64 for now, but do not move the
sources, as we ought to be able to add support later.

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40740

show more ...

bhyve: Move legacy PCI interrupt handling under amd64/

Specifically, move IO-APIC, LPC and PIRQ routing code under amd64/.

Use ifdefs to conditionally compile related code in other files. In
parti

bhyve: Move legacy PCI interrupt handling under amd64/

Specifically, move IO-APIC, LPC and PIRQ routing code under amd64/.

Use ifdefs to conditionally compile related code in other files. In
particular, legacy PCI interrupt handling is now compiled only on amd64.
This is not too invasive, but suggestions for a more modular approach
would be appreciated.

I am not sure why qemu fwcfg handling is tied to LPC, and I suspect it
should be decoupled. In this commit I just apply an ifdef hammer, but
we will eventually want fwcfg on arm64 as well.

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40739

show more ...

bhyve: Compile some device models only on amd64

These models register legacy PCI interrupts, which won't be supported in
the arm64 port. In principle it should be possible to make these models
work

bhyve: Compile some device models only on amd64

These models register legacy PCI interrupts, which won't be supported in
the arm64 port. In principle it should be possible to make these models
work on arm64 with a bit of effort, so don't move the sources to the
amd64 subdirectory.

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40738

show more ...

bhyve: Move AP startup code to amd64/

This code is only invoked via MD vmexit handlers. No functional change
intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differe

bhyve: Move AP startup code to amd64/

This code is only invoked via MD vmexit handlers. No functional change
intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40737

show more ...

bhyve: Move the gvt-d driver to amd64/

It is amd64-only. No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews

bhyve: Move the gvt-d driver to amd64/

It is amd64-only. No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40736

show more ...

bhyve: Move power management code to amd64/

This implements various x86-specific interfaces. No functional change
intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Di

bhyve: Move power management code to amd64/

This implements various x86-specific interfaces. No functional change
intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40735

show more ...

bhyve: Move the RTC driver to amd64/

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40734

bhyve: Move MSR emulation into amd64/

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40733

bhyve: Move kernemu to amd64/

This code handles instruction emulation for accesses to various
amd64-specific MMIO regions.

No functional change intended.

Reviewed by: corvink, jhb, emaste
MFC afte

bhyve: Move kernemu to amd64/

This code handles instruction emulation for accesses to various
amd64-specific MMIO regions.

No functional change intended.

Reviewed by: corvink, jhb, emaste
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40554

show more ...

bhyve: Move more amd64-specific code under amd64/

mptable and the e820 are both rather amd64-specific and can be moved
easily.

In the case of e820, move the registration with qemu_fwcfg into e820.c

bhyve: Move more amd64-specific code under amd64/

mptable and the e820 are both rather amd64-specific and can be moved
easily.

In the case of e820, move the registration with qemu_fwcfg into e820.c,
as it simplifies bhyverun.c a bit and I can't see any downsides.

No functional change intended.

Reviewed by: corvink, jhb, emaste
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40552

show more ...

bhyve: Move some more amd64-specific drivers to their own subdir

No functional change intended.

Reviewed by: corvink, jhb, emaste
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision:

bhyve: Move some more amd64-specific drivers to their own subdir

No functional change intended.

Reviewed by: corvink, jhb, emaste
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40551

show more ...

bhyve: Start moving machine-dependent code into subdirectories

In preparation for an arm64 port, make an easy change which puts some
machine-dependent code in its own directory.

Going forward, code

bhyve: Start moving machine-dependent code into subdirectories

In preparation for an arm64 port, make an easy change which puts some
machine-dependent code in its own directory.

Going forward, code which is only used on one platform should live in a
MD directory. We should strive to layer modules in such a way as to
avoid polluting shared code with lots of ifdefs. For some existing
files this will take some effort.

task_switch.c and fwctl.c are an easy place to start: the former is very
x86-specific, and the latter provides an I/O port interface which can't
be used on anything other than x86. (fwcfg as implemented has the same
problem, but QEMU also supports a MMIO fwcfg interface.) So I propose
that we start by simply making those files conditional.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40501

show more ...