Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: 8fe67f4b743818ef9157685a1fff92b19e704a4e
https://github.com/siemens/jailhouse/commit/8fe67f4b743818ef9157685a1fff92b19e704a4e
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M inmates/lib/include/inmate_common.h
Log Message:
-----------
inmates: lib: Use wider types for time-related constants
Especially when timing is involved, multiplications tend to overflow
32 bit. It's better to use 64 bit variables during the calculation. ULL
for constants ensures the correct width of intermediate results.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: d737a471c71114f53ae0e41d219742c6af9bfe37
https://github.com/siemens/jailhouse/commit/d737a471c71114f53ae0e41d219742c6af9bfe37
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M inmates/lib/x86/timing.c
Log Message:
-----------
inmates: x86: timing: use a wider type for delay_us
As pm_timer_read() + microsecs * NS_PER_USEC may overflow on 32 bit
systems. Use a 64 bit type.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: ecaeadc658705d25cc67553378cd9da609c498f3
https://github.com/siemens/jailhouse/commit/ecaeadc658705d25cc67553378cd9da609c498f3
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M inmates/lib/x86/include/inmate.h
M inmates/lib/x86/timing.c
Log Message:
-----------
inmates: x86: timing: adjust type of apic_timer_set
ulong restricts us to ~4.3sec on 32 bit x86 systems. We do a cast to
ullong in any case, so simply pass a wider type.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 1a054d30bb3f76a64bcdc7883851cd46c8708b8b
https://github.com/siemens/jailhouse/commit/1a054d30bb3f76a64bcdc7883851cd46c8708b8b
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M inmates/lib/x86/include/inmate.h
M inmates/lib/x86/timing.c
Log Message:
-----------
inmates: x86: use correct types for pm_timer_read
If we should ever compile timing.c for 32 bit inmates, then unsigned long is
the wrong type. A 32 bit type (aka unsigned long on 32 bit) is too small to
hold the result.
This ensures that we won't hit a bug when enabling on 32 bit. Once we will
enable timing.c on 32 bit, we will have to implement 64 bit division
intrinsics.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: fd06167340d5da1a8ac216ea42a514faf75b174e
https://github.com/siemens/jailhouse/commit/fd06167340d5da1a8ac216ea42a514faf75b174e
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M inmates/lib/x86/Makefile
Log Message:
-----------
inmates: x86: Don't compile smp.c for 32 bit inmate library
We don't compile timing.c for 32 bit inmates. But it is required for smp.c, as
smp_start_cpu() calls delay_us().
We don't have 32 bit SMP demo inmates, and compiling timing.c for 32 bit is a
tricky task because of 64 bit divisions. Simply deactivate SMP for 32 bit
inmates for the moment.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: e1627b587ee778bdee5effc528747fd3290c81ea
https://github.com/siemens/jailhouse/commit/e1627b587ee778bdee5effc528747fd3290c81ea
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M hypervisor/arch/arm/Kbuild
Log Message:
-----------
Kbuild: Remove the reference to the formerly supported vexpress platform
Just a tiny cosmetic fixup: We don't support vexpress any longer. Remove
the hint to its unit.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 73489e2430f8dc0664f6f9185684f935650ff488
https://github.com/siemens/jailhouse/commit/73489e2430f8dc0664f6f9185684f935650ff488
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M hypervisor/arch/x86/mmio.c
M inmates/tests/x86/mmio-access-32.c
M inmates/tests/x86/mmio-access.c
Log Message:
-----------
x86: mmio: fix preserve mask for instructions with zero-extend
movzx is a move with zero-extend. It will either move 1 byte (0f b6) or
2 bytes (0f b7). The destination are lower 8 or 16 bits. Zero-extend
means that upper bits need to be cleared. The definition of upper bits
depends on the destination register.
We already have a preserve mask that allows us for to clear or preserve
bits when emulating the instruction. In case of movzx, the preserve mask
only depends on the width of the destination register. For the
destination register, we have the following cases:
- rax -- instruction has REX prefix 0x48 (rex_w set)
- eax -- default case, no prefix, nothing
- ax -- instruction has OP SZ override prefix 0x66
- al -- not possible, and doesn't make sense for movzx
Now, rax and eax have the same effect: Always clear all upper bits (IOW,
bits 8-63 if access_size is 1 or bits 16-63 if access_size is 2).
Solution for rax and eax is easy: Simply don't set the preserve mask at
all.
The fun part is if we have the 0x66 operand override size prefix. This
means that the 'visibility' of the destination register is narrowed to
16 bit.
In case of a 1 byte move (0f b6), copy the source to bits 0-7, clear
bits 8-15 and preserve bits 16-63. access_width ensures that we only
copy 8 bit to bits 0-7, and the preserve_mask 0xffff.ffff.ffff.0000 does
the rest: preserve bits 16-63 and implicitely clear bits 8-15.
In case of a 2 byte move (0f b7), copy the source to bits 0-15, clear
nothing and preserve bits 16-63. access_width ensures that we only copy
16 bit to bits 0-15, and the preserve_mask 0xffff.ffff.ffff.0000 does
the rest: preserve bits 16-63.
Once this pattern is clear, the fix in the hypervisor is straight forward.
Amend existing and add new test cases that test correct behaviour.
Signed-off-by: Ralf Ramsauer <[email protected]>
[Jan: minor comment and style massaging]
Signed-off-by: Jan Kiszka <[email protected]>
Compare:
https://github.com/siemens/jailhouse/compare/e0de703fa9f3...73489e2430f8
--
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/next/e0de70-73489e%40github.com.
For more options, visit https://groups.google.com/d/optout.
