Branch: refs/heads/master
Home: https://github.com/siemens/jailhouse
Commit: 564f354155a3a21e95041c1b8fb79605356abf65
https://github.com/siemens/jailhouse/commit/564f354155a3a21e95041c1b8fb79605356abf65
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M hypervisor/arch/x86/apic.c
M hypervisor/arch/x86/control.c
Log Message:
-----------
x86: Add proper fence before sending IPIs
Since 2017, the Intel manual suggests to use mfence plus lfence as
barrier to make data changes visible triggering an interrupt via the
x2APIC interface. Jailhouse was so far not using any barrier
consistently in those cases, neither for internal NMI IPIs, nor for
those triggered via the ivshmem doorbell interface.
This adds the recommended mfence;lfence sequence to all IPIs triggered
via apic_send_irq or apic_send_ipi, at the risk of having more than
needed, e.g. when issuing an IPI on behalf of a guest that already used
a barrier itself. Compared to the risk of missing a cases and given the
overhead that the intercepted IPI submission comes with anyway, this is
the preferable option.
Note that this also ensures proper serialization of data writes and
kicks for the ivshmem doorbell interface on x86. Such a property is
going to be demanded by the ivshmem specification.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: cb8d79bbc2caee07fbc2d9ed86af15e040a70c35
https://github.com/siemens/jailhouse/commit/cb8d79bbc2caee07fbc2d9ed86af15e040a70c35
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M hypervisor/arch/arm-common/ivshmem.c
Log Message:
-----------
arm-common: Add memory barrier before ivshmem interrupt submission
This ensures that a guest will not see its data lagging behind the
signal when triggering the ivshmem doorbell. We are going to demand this
property from the ivshmem interface.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: f91c57158100fa0b4586a3271dc2c27570d56be7
https://github.com/siemens/jailhouse/commit/f91c57158100fa0b4586a3271dc2c27570d56be7
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M hypervisor/arch/arm-common/control.c
M hypervisor/arch/arm-common/include/asm/control.h
M hypervisor/arch/arm-common/psci.c
M hypervisor/arch/x86/include/asm/control.h
M hypervisor/include/jailhouse/control.h
Log Message:
-----------
arm-common: Get rid of arm_cpu_kick
Implement arch_send_event directly and switch psci to this. Makes things
more straightforward - and provides the chance to properly document
arch_send_event.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 19cf7a61caaa793bb533d38b531519e703cccf49
https://github.com/siemens/jailhouse/commit/19cf7a61caaa793bb533d38b531519e703cccf49
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M hypervisor/arch/arm-common/psci.c
M hypervisor/control.c
M hypervisor/include/jailhouse/control.h
Log Message:
-----------
core, arm-common: Clarify role of spin_unlock before event submission
On ARM, the spin_unlock is sufficient to provide a memory barrier before
calling arch_send_event. On other archs, the implementation of
arch_send_event has to take care of this. Clarify this at the respective
call sites and the function documentation.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: d2becb4a22a7dc85cb237014796862a50f4cfc6d
https://github.com/siemens/jailhouse/commit/d2becb4a22a7dc85cb237014796862a50f4cfc6d
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M hypervisor/arch/arm-common/include/asm/irqchip.h
M hypervisor/arch/arm-common/irqchip.c
M hypervisor/arch/arm-common/ivshmem.c
Log Message:
-----------
arm-common: Factor out irqchip_trigger_external_irq
This replaces the non-intuitive special case of
irqchip_set_pending(NULL, ...) with an explicit one.
The only case where irqchip_set_pending() was called like this was
arch_ivshmem_trigger_interrupt(). All others already passed in a
cpu_public pointer guaranteed to be non-NULL.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 368ff6b2acb3f24ec5903db328d73f2c9d986601
https://github.com/siemens/jailhouse/commit/368ff6b2acb3f24ec5903db328d73f2c9d986601
Author: Jan Kiszka <[email protected]>
Date: 2020-03-06 (Fri, 06 Mar 2020)
Changed paths:
M Documentation/ivshmem-v2-specification.md
Log Message:
-----------
Documentation: ivshmem: Require that doorbell writes act as memory barriers
This avoids that the guest has to be aware of how the doorbell interrupt
is internally sent to the target CPU because to add the corresponding
memory barrier explicitly. The implementation in Jailhouse already
fulfills this new requirement.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 421fcb1f99cd1fa59a4494368550b2288cbfcd25
https://github.com/siemens/jailhouse/commit/421fcb1f99cd1fa59a4494368550b2288cbfcd25
Author: Ralf Ramsauer <[email protected]>
Date: 2020-03-08 (Sun, 08 Mar 2020)
Changed paths:
M configs/arm64/espressobin.c
Log Message:
-----------
configs: arm64: espressobin: tune comment
This is probably a c&p artefact from macchiatobin.c: Memory on the espressobin,
1G variant, ranges from 0x0 - 0x40000000, and reservation can be done via
cmdline. Adjust the comment.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 37101f166e71d712644b107c77a0a694f0959f96
https://github.com/siemens/jailhouse/commit/37101f166e71d712644b107c77a0a694f0959f96
Author: Jan Kiszka <[email protected]>
Date: 2020-03-10 (Tue, 10 Mar 2020)
Changed paths:
M hypervisor/ivshmem.c
Log Message:
-----------
core: ivshmem: Clear state table on first peer setup
So far we only reset the state of the added device of a link, not that
of to-be added ones. This could expose random state value of upcoming
peers until their cells were actually created.
Fix this by clearing the complete state table when the first peer is
initialized.
Reported-by: Philipp Rosenberger <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: f76b0e89ed89a64c2d22bde114e20abd0e18ce38
https://github.com/siemens/jailhouse/commit/f76b0e89ed89a64c2d22bde114e20abd0e18ce38
Author: Jan Kiszka <[email protected]>
Date: 2020-03-10 (Tue, 10 Mar 2020)
Changed paths:
M hypervisor/ivshmem.c
Log Message:
-----------
core: ivshmem: Clean up variable initialization
We can use the local id variable also here.
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 1f16ea47d9d99f7f6fde1aad65c8ab7ed77d54ca
https://github.com/siemens/jailhouse/commit/1f16ea47d9d99f7f6fde1aad65c8ab7ed77d54ca
Author: Philipp Rosenberger <[email protected]>
Date: 2020-03-10 (Tue, 10 Mar 2020)
Changed paths:
M Documentation/inter-cell-communication.md
Log Message:
-----------
Documentation: use virtio-ivshmem-block for block backend
The example for the virtio-ivshmem-block shows virtio-ivshmem-console
not virtio-ivshmem-block as backend.
Signed-off-by: Philipp Rosenberger <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 2e4d71f66439f8f6223b129b1b8f19062a851342
https://github.com/siemens/jailhouse/commit/2e4d71f66439f8f6223b129b1b8f19062a851342
Author: Jan Kiszka <[email protected]>
Date: 2020-03-10 (Tue, 10 Mar 2020)
Changed paths:
M hypervisor/arch/x86/ioapic.c
Log Message:
-----------
x86: ioapic: Fix programming of to-be-masked pin
The unconditional writing of both redirection table words created an
invalid intermediate state when masking a previously unmasked pin: As
the entry was to be masked, the index in result was set to 0xffff. This
value was then programmed into the upper word while the pin was still
unmasked.
QEMU detected this invalid redirection table entry but only a message
was logged on the host terminal because QEMU does not emulate error
reporting for VT-d. If an interrupt had come in on real hardware right
at this point, we would have seen a VT-d fault. Still, no kitten would
have been harmed.
Fix this by only writing the upper half when we are unmasking the pin
(or keeping it unmasked). And the goal of bac03e4d5f54 is still achieved
this way.
Fixes: bac03e4d5f54 ("x86: ioapic: Rework and fix redir entry programming")
Signed-off-by: Jan Kiszka <[email protected]>
Compare:
https://github.com/siemens/jailhouse/compare/ca7123a5c58d...2e4d71f66439
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/siemens/jailhouse/push/refs/heads/master/ca7123-2e4d71%40github.com.
