Julien Grall [Sun, 4 Oct 2015 19:33:04 +0000 (20:33 +0100)]
xen: arm: Use __typeof__ rather than typeof
Typeof is not portable:
/usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
of function 'typeof' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
Julien Grall [Sun, 22 Jun 2014 16:13:10 +0000 (17:13 +0100)]
arm: rename intr.h into intr_machdep.h
ARM is the only architecture where the interrupt header is named "intr.h"
rather than "intr_machdep.h". There is numerous place (such as Xen) in the
generic code which need to deal with interrupt management.
Julien Grall [Mon, 26 May 2014 17:29:33 +0000 (18:29 +0100)]
arm: Add zImage support
Currently Xen on ARM is only supported zImage for guest kernel. Adding support
for ARM ELF in the toolstack looks a bit complicate for ARM (though there is
an x86 support).
Returning 0 in probe callback means: the driver can use this device. If by any
chance xencontrol is the first driver, every new device (which driver unset)
will use xencontrol.
Julien Grall [Tue, 14 Jan 2014 01:41:08 +0000 (01:41 +0000)]
xen/xenstore: xs_probe should return BUS_PROBE_NOWILDCARD
Returning 0 in probe callback means: the driver can use this device. If by any
chance xenstore is the first driver, every new device (which driver unset) will
use xenstore.
Julien Grall [Sun, 1 Jun 2014 18:15:40 +0000 (19:15 +0100)]
xen: xen_start_info don't need to be export in common code
HYPERVISOR_start_info has been introduce to be used in code common. The
variable xen_start_info is only used within amd64 and i386 architecture and
is redundant with the former variable.
Julien Grall [Mon, 5 Oct 2015 17:35:54 +0000 (18:35 +0100)]
xen/netfront: Add 2 bytes padding in the rx mbuf
The ethernet header size is not word aligned. Therefore the IP packet and so
on won't be align. On some architecture (such as ARM) unaligned access may
be slower and/or not supported. Therefore we might reveice an alignement
fault. To avoid this case, we need to pull-up the data of ETHER_ALIGN bytes.
I'm not sure how this patch will impact x86, we need to do some benchmarking
without and with it.
Furthermore, I don't know if m_copyup is the rigth function to use here. Can
any expert to the network stack can tell me if there is a better solution?
Julien Grall [Mon, 5 Oct 2015 17:35:43 +0000 (18:35 +0100)]
xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier
For WRITE_BARRIER and FLUSH_DISKCACHE operation, we don't request any cache
operation. This will result to a panic in _bus_dmamap_sync on ARM because the
operation (op = 0) is not supported.
x86 platform doesn't seem to care about this and Xen is always requiring
memory shared with the backend to be cacheable. I'm wondering if we could drop
the call to bus_dmasync_map because the cache maintainance slows down the
process for no appareant reason?
For now, WRITE_BARRIER and FLUSH_DISKCACHE are an extension of the WRITE
command so require BUS_DMASYNC_PREWRITE for the cache maintenance operation.
xen/console: Introduce a new console driver for Xen guest
The current Xen console driver is crashing very quickly when using it on ARM
guest. This is because of the console lock is recursive which may lead to
recurse on the tty lock and/or corrupt the ring pointer.
Furthermore, the console lock is not always taken where it should be and has
to be released too early because of the way the console has been designed.
Over the year, code has been added to support various new feature but the
driver has not been reworked. This brings to have code related to the
hypervisor console in ring specific function...
This new driver has been rewritten with this idea to only
have a small set of specific function to write either via the ring or the
hypercall.
Note that HVM support has been left aside for now because it requires external
feature to be used on ARM which are not yet upstreamed. A follow-up patch will
be sent with the ARM guest support.
This new console driver will be added in the build in the following patch.. It
has been divided to help reviewing.
List of items that may be good to have but not mandatory:
- Avoid to flush for each character written when using the tty.
- Use a ops structure to distinguish hypervisor vs ring helpers
- Support multiple console
adrian [Sat, 3 Oct 2015 05:44:05 +0000 (05:44 +0000)]
rum(4): some non-functional changes / cleanup
* Remove unused sc_txtap_len/sc_rxtap_len fields.
* Remove unused ackrate variable.
* Remove unneded warning in rum_update_mcast().
* Use nitems().
* Replace some hardcoded values for RT2573_MAC_CSR1 register.
* Remove second argument for RUM_LOCK_ASSERT() - it is always the same.
grehan [Fri, 2 Oct 2015 21:09:49 +0000 (21:09 +0000)]
Simple sysctl-like firmware query interface. Similar in operation
to the qemu one, and uses the same i/o ports but with different
messaging. Requires the 'bootrom' option to be enabled.
This is used by UEFI (and potentially other BIOSs/firmware) to
request information from bhyve. Currently, only the number of
vCPUs is made available, with more to follow.
A very large thankyou to Ben Perrault who helped out testing
an earlier version of this, and bhyve/Windows in general.
Reviewed by: tychon
Discussed with: neel
Sponsored by: Nahanni Systems
kib [Fri, 2 Oct 2015 13:25:59 +0000 (13:25 +0000)]
Do not set 'flush to zero' VFPSCR_FZ bit by default. The correct
implementation of IEEE 754 arithmetic depends on denormals operating
correctly. Both perl test suite and paranoia tripped over the
setting.
Reported by: Stefan Parvu <sparvu@kronometrix.org>
Discussed with: andrew
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
kib [Fri, 2 Oct 2015 13:21:08 +0000 (13:21 +0000)]
FreeBSD does not support SMP on ARMv5. Since processor is always
self-consistent, there is no need in anything but compiler barrier in
the implementation of atomic_thread_fence_*() on ARMv5. Split
implementation of fences for ARMv4/5 and ARMv6; the former use
compiler barriers, the later also perform hardware barriers.
An issue which is fixed by the change is the faults from the CP15
coprocessor accesses in the user mode. This was uncovered by the
pthread_once() changes in r287556.
Reported by: Mattia Rossi <mattia.rossi.mailinglists@gmail.com>
Discussed with: alc, cognet, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week