Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: f6fef92ffabab0772a6da1fd15cf12887a9600fa
https://github.com/siemens/jailhouse/commit/f6fef92ffabab0772a6da1fd15cf12887a9600fa
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-16 (Tue, 16 Jul 2019)
Changed paths:
M pyjailhouse/sysfs_parser.py
M tools/root-cell-config.c.tmpl
Log Message:
-----------
pyjailhouse: sysfs_parser: Add more precise length of some extended caps
I often run into situations where Linux tries to write to some extended
capabilities. E.g., Linux wants to clear Advanced Error Reporting (ERR)
registers when probing for a device.
At the moment, the crash dump of the cell is hard to interprete, as it
remains unclear if the access is inside a capability, or if the device
just accesses some PCI config space (e.g., accesses beyond PCI spec). At
the moment, all extended capabilities have a fixed length of 4, which
supports the confusion. Four bytes only cover the header of the
capability.
This patch calculates the correct length of PCI caps for the
configuration file -- at least of some capabilities. For some extended
caps this is pretty easy, as they have a fixed length.
Nevertheless, other vary in their length. In some cases, it's pretty
easy (VNDR, ACS), in other cases it's not worth it (VC, VC9) due to
their complexity.
Caps that aren't handle still result in a length of 4.
Additionally, switch to a hexadecimal representation of the length of
PCI caps in config files.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: ce87a6afc1de4ffdd10fba9c92ff1c89ec7d34e4
https://github.com/siemens/jailhouse/commit/ce87a6afc1de4ffdd10fba9c92ff1c89ec7d34e4
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/arm/include/asm/bitops.h
M hypervisor/arch/arm64/include/asm/bitops.h
M hypervisor/arch/x86/include/asm/bitops.h
Log Message:
-----------
core: bitops: fix type of clear_bit
I don't see a reason why nr should be unsigned for set_bit, but signed for
clear_bit. This probably got copy&pasted across architectures.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 92c1d1d9948fd0c50d6c5bf4259e1dc9ba0b3d4e
https://github.com/siemens/jailhouse/commit/92c1d1d9948fd0c50d6c5bf4259e1dc9ba0b3d4e
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vmx.c
Log Message:
-----------
x86: use definitions instead of constants
Those definitions are used during allocating, so let's use them during
deallocation as well.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 90f392def0720107d0f0cb17f4d026cfd1c101b2
https://github.com/siemens/jailhouse/commit/90f392def0720107d0f0cb17f4d026cfd1c101b2
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/include/asm/cell.h
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vmx.c
Log Message:
-----------
x86: use the variable io_bitmap for both
Semantically, SVM and VMX don't differ that much in those regards. Let's use
the same variable for both.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 53a55842ef7e9f3695649272b37eed8cec89c271
https://github.com/siemens/jailhouse/commit/53a55842ef7e9f3695649272b37eed8cec89c271
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/include/asm/vcpu.h
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vcpu.c
M hypervisor/arch/x86/vmx.c
Log Message:
-----------
x86: consolidate io_bitmap allocation
It's pretty much the same, besides the number of pages that have to be
allocated.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: c416ff7427f11d51a818bdf8683a75f200f8573d
https://github.com/siemens/jailhouse/commit/c416ff7427f11d51a818bdf8683a75f200f8573d
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vcpu.c
M hypervisor/arch/x86/vmx.c
Log Message:
-----------
x86: consolidate deallocation of IO bitmaps
Same as before - we can now do this in vcpu.c.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: 9ad5ca85ea350eb10dd56a1994183039f5ac13f7
https://github.com/siemens/jailhouse/commit/9ad5ca85ea350eb10dd56a1994183039f5ac13f7
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/vcpu.c
Log Message:
-----------
x86: remove superfluous statement
pio_bitmap already is set to the cell's pio bitmap. No need to repeat the
assignment.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: e4cfe90d48731cf30159d9fb8f9e7283756095f1
https://github.com/siemens/jailhouse/commit/e4cfe90d48731cf30159d9fb8f9e7283756095f1
Author: Ralf Ramsauer <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M hypervisor/arch/x86/i8042.c
M hypervisor/arch/x86/include/asm/cell.h
M hypervisor/arch/x86/vcpu.c
Log Message:
-----------
x86: simplify check if i8042 needs moderation
By adding pio_i8042_allowed boolean flag to arch cell fields.
With this, we don't need to directly access the pio_bitmap in i8042.c. This
does not only simplify (and speed up) the decision, it will also be helpful in
future patches.
Signed-off-by: Ralf Ramsauer <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Commit: e7674ea7425fc3f968c6d50a2bffb9afae861f9f
https://github.com/siemens/jailhouse/commit/e7674ea7425fc3f968c6d50a2bffb9afae861f9f
Author: Jan Kiszka <[email protected]>
Date: 2019-07-25 (Thu, 25 Jul 2019)
Changed paths:
M driver/main.c
Log Message:
-----------
driver: Account for renaming of lapic_timer_frequency in 5.3
"lapic_timer_frequency heißt jetzt lapic_timer_period, sonst ändert sich
nix."
Signed-off-by: Jan Kiszka <[email protected]>
Compare:
https://github.com/siemens/jailhouse/compare/9f233898917f...e7674ea7425f
--
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/9f2338-e7674e%40github.com.
