Move Platform::setup_irq_mode function from x86 platform_support.cc to
x86_64 specific file. This will enable the upcoming x86_64_muen platform
to provide a separate implementation.
The hw_x86_64_muen platform is a x86/64 base-hw kernel which runs as
isolated subject (guest) on the Muen Separation Kernel (SK) [1].
The platform is implemented as an extension to hw_x86_64 replacing the
PIC and timer drivers with paravirtualized variants. The skeleton
contains a dummy PIC and timer implementation for now.
[1] - http://muen.sk
If the guest is not in an interruptible state when the recall handler is
called, an assertion fails. Since the assertion is only relevant if the
recall handler was called during IRQ injection, it should be moved into
the corresponding conditional block which already has the assertion for
the 'IF' flag.
Fixes#1661
By default, the EMT thread of the last vCPU handles expired timers. When
running VirtualBox with 2 vCPUs, it sporadically happens that the EMT
thread of the second CPU clears an 'interrupt pending' flag for the first
vCPU after changing the state of a timer device model, which is not
expected by our Genode-specific code (failed assertion '!_irq_win' in the
recall handler).
The problem did not occur yet when letting the EMT thread of the first
vCPU handle the expired timers, which is done by this commit as an interim
fix until the problem has been further investigated.
Issue #1660
Add spin loop hint by means of the PAUSE instruction since
wait_for_interrupt is called in a busy loop. This should improve processor
performance and reduce power consumption.
Note: HLT cannot be used since it is a privileged instruction and the idle
thread is executed in userspace.
Move the _core_only_mmio_regions function to the
x86_64/platform_support.cc file. This is required to make it overridable
for other platforms deriving from x86.
If a requested report already exists the request is denied with
Invalid_args.
Further, I dusted the report_rom test and added it to the
autopilot list.
There are currently some issue with the mixing/filtering code of vbox.
So instead of using the audio subsystem to do filtering and mixing we
bypass it to get better audio qualitiy. That means that the device
model of the VM has to use the same sample rate as the Audio_out/in
sessions, however.
Issue #1647.
With this commit preliminary audio support in VirtualBox is enabled.
The backend supports playback as well as recording sounds from within
a guest VM. Depending on how the guest configures the device model
the audio output may sound disorted. If the guest uses buffers that
are too small, i.e., 10 ms or less, frequent buffer underruns will
occure.
To get this low-latency one has also to increase vbox' update hz
to 200 (i.e., 5ms).
Fixes#1647.
When a stream was stopped it may still contain valid packets that
will be played automatically when the stream is started again. The
invalidate_all() method may be called after stopping the stream to
prevent this.
Issue #1647.
Run script depending on VFS plugins (i.e., shared objects) like
vfs_jitterentropy.lib.so have to state this dependency rather the actual
binaries linked against libc. The latter introduces a library dependency
that is just not there. For example, the dependency on vfs_jitterentropy
is a result from the config node for libc which automatically loads the
plugin.
The alarm library failed to handle the case properly where an already
scheduled alarm gets rescheduled before it triggered. Even though the
attempt to reschedule the alarm (twice insertion into alarm queue) was
detected, this condition resulted in the mere modification of the
alarm's parameters while keeping the alarm's queue position unchanged.
This, in turn, may violate the invariant that all enqueued alarm objects
are strictly ordered by their deadlines. The patch handles the case by
dequeuing the alarm object before reinserting it into the queue at the
right position.
Fixes#1646
With the introducation of the Audio_in session interface it makes
sense to rename the current available audio drivers. At the moment
only the dde_bsd audio_drv supports Audio_out as well as Audio_in.
The Linux audio_drv only supports Audio_out (there is no demand for
Audio_in support currently) but is renamed nonetheless to make it
easiert to write generic run scripts.
Issue #1644.
The driver is now able to record audio samples. In contrast
to playback it has to be enabled explicitly by setting the
configuration attribute 'recording' to 'yes'. Playback is by
default enabled but may be disabled by setting 'playback' to
'no'. Furthermore it is now possible to configure the mixer
from the configuration. For now, the interface used by vanilla
OpenBSD is just exported.
The following snippet shows how to enable and configure recording
on an Thinkpad X220 where the headset rather than the internal
mic is used as recording source:
! <start name="audio_out_drv">
! <resource name="RAM" quantum="8M"/>
! <provides>
! <service name="Audio_out"/>
! <service name="Audio_in"/>
! </provides>
! <config recording="yes">
! <mixer field="outputs.master" value="255"/>
! <mixer field="record.adc-0:1_source" value="sel2"/>
! <mixer field="record.adc-0:1" value="255"/>
! </config>
! </start>
In addition to selecting the recording source the playback as
well as the recording volume are set to 255 (maximum).
Information about the available mixers and settings in general
may be obtained by setting the 'verbose' to 'yes' in the config
node.
Issue #1644.
Unfortunatly, there is no support for any HDMI/DP based HDA codecs in
this driver. Therefore we try to filter out known devices (normally the
PCI device on 00:03.00). This could also be done in the platform_drv's
configuration by explicitly naming the BDF but for better or worse that
will not work when using a wildcard class like HDAUDIO which is done in
generic run scripts.
Issue #1644.
In line with the Audio_out session a Audio_in session is used to
record audio frames. Like in the Audio_out session shared memory
in form of the Audio_in::Stream is used to transport the frames
from the server to the client. These frames consist of single
channel (mono) samples. An Audio_in::Packet always contains a full
period of frames.
A Audio_in server captures frames and puts them into the
Audio_in::Stream. To do so the server allocates a Audio_in::Packet
from the packet queue embedded in the Audio_in::Stream. If the queue
is already full, the server will override packets and notify the
client by submitting the 'overrun' signal. The client has to cope
with this situation, e.g., by saving packets more frequently.
A client will also receive a 'progress' signal from the server when
a new Audio_in::Packet was submitted to the packet queue.
Fixes#1644.
To archive lower latency the length of a period was reduced from
2048 (~46ms) to 512 (~11.6ms) samples.
It should be noted that this change probably breaks audio in Qemu on
most systems.
Issue #1644.
For most platforms except of NOVA a distinction between pager entrypoint
and pager activation is not needed, and only exists due to historical
reasons. Moreover, the pager thread's execution path is almost identical
between most platforms excluding NOVA, HW, and Fisco.OC. Therefore,
this commit unifies the pager loop for the other platforms, and removes
the pager activation class.
This exit handler is called by the NOVA kernel now when the VM uses PAE
with nested paging and the PDPTE registers need to get updated. With this
commit, an error message is printed if this situation occurs.
Fixes#1640
The reference count get increase to use 2 bytes, so we need the double amount
of selectors as before.
Additionally print a message if we run out of capabilities in a server. Since
our rpc framework is now clever enough to detect that for a printf we don't
need to setup a receive window, we may use a printf instead of a die call.
Eases debugging.
Issue #1601
Showcasing the out of memory kernel issue.
One test triggers oom during memory delegation when talking to core pager
thread. Two other test trigger oom during capability delegation in a
server/client scenario for send and reply phase separately.
Issue #1601
