We implicitly know that the value range will not exceed access_t despite
the integer-based arithmetics, i.e., negation and shift operations.
Fixes#1524
Avoids the need to have per IRQ a thread that blocks synchronously for next
interrupt. Now a thread may wait for multiple IRQs as other signals
simultaneously.
In core no threads are required anymore for IRQs/MSI - the clients (either
the pci_drv or in case of MSI the driver) gets the IRQ delivered directly as
a ordinary Genode signal.
Useful since #1216 and #1487 is now available.
Commit applies feature of #1446 also to IRQ/MSIs.
The base-hw kernel on x86_64 currently assumes 254 MiB of RAM. The RAM
region is subtracted from the I/O mem allocator and therefore this range
is not available for device I/O.
If qemu is started with -m 128, the region for (emulated) PCI config
space access lies within this region and I/O mem allocation in the
pci_drv will fail. Giving qemu more RAM moves the PCI config space out
of the 254 MiB region, making the run/libc_ffat scenario with acpi work.
The assumption that IRQs in the legacy ISA range are always
edge-triggered is wrong. For the free-for-use IRQs it depends on the
actual device which uses the specific IRQ. Therefore, treat IRQs 9, 10
and 11 as level-triggered.
Currently, libc_noux includes the 'base/src/base/env/platform_env.h' file
to be able to reinitialize the environment using the 'Platform_env'
interface. For base-linux, a special version of this file exists and the
inclusion of the generic version in libc_noux causes GCC 4.9 to make wrong
assumptions about the memory layout of the 'Env' object returned by
'Genode::env()'.
This commit moves the reinitialization functions to the 'Env' interface to
avoid the need to include the 'platform_env.h' file in libc_noux.
Fixes#1510
Some functions in the kernel, which create a static object and return its
address, are declared with a GCC 'const' attribute, which can cause GCC
4.9 to optimize the function call out and use the static object's address
without calling the constructor.
Fixes#1509
The information about connected devices is obtained from a ROM file named
'usb_devices', which is supposed to contain a device list as in the device
report generated by the USB driver (see issue #1506).
A policy for 'report_rom' would look like:
<policy label="vbox -> usb_devices" report="usb_drv -> devices"/>
If the 'usb_devices' ROM file is not available, a warning message gets
printed and VirtualBox continues without USB pass-through support.
The devices to be passed-through need to have a matching device filter in
the '.vbox' file. Example:
<USB>
<DeviceFilters>
<DeviceFilter name="USB Scanner" active="true" vendorId="04a9"
productId="2220" remote="0"/>
</DeviceFilters>
</USB>
The feature was tested with HID devices (mouse, keyboard) and a flatbed
scanner. Mass storage devices didn't work correctly (they also didn't work
with VirtualBox on Linux without the closed-source extension pack).
It should be made sure that the USB driver does not try to control the
devices to be passed-through itself, for example, when passing-through
a HID device, the '<hid/>' config option should not be set.
Fixes#1507
The report lists all connected devices and gets updated when devices are
added or removed.
Example report:
<devices>
<device vendor_id="0x17ef" product_id="0x4816"/>
<device vendor_id="0x0a5c" product_id="0x217f"/>
<device vendor_id="0x8087" product_id="0x0020"/>
<device vendor_id="0x8087" product_id="0x0020"/>
<device vendor_id="0x1d6b" product_id="0x0002"/>
<device vendor_id="0x1d6b" product_id="0x0002"/>
</devices>
There is no distinction yet for multiple devices of the same type.
The report is named "devices" and an example policy for 'report_rom' would
look like:
<policy label="vbox -> usb_devices" report="usb_drv -> devices"/>
The report only gets generated if enabled in the 'usb_drv' configuration:
<config>
<raw>
<report devices="yes"/>
</raw>
</config>
Fixes#1506
On NOVA, a Genode thread currently cannot destroy itself by destroying its
own 'Thread' object, because in 'Thread_base::_deinit_platform_thread()'
it cannot call 'Cpu_session::kill_thread()' anymore after it has revoked
its own UTCB.
As solution, the revocation of the UTCB can be delayed until its location
in the context area is needed by a new thread.
Fixes#1505
