On 04.10.19 16:41, Ralf Ramsauer wrote:
On 10/4/19 9:15 AM, Jan Kiszka wrote:
On 02.10.19 16:14, Ralf Ramsauer wrote:
Hi,
On 10/1/19 5:34 PM, Jan Kiszka wrote:
On 01.10.19 17:23, Ralf Ramsauer wrote:
Hi Jan,
On 9/30/19 9:28 PM, Jan Kiszka wrote:
On 30.09.19 21:25, Andrej Utz wrote:
Hi Jan,
On 30.09.19 21:19, Jan Kiszka wrote:
On 30.09.19 21:13, Andrej Utz wrote:
This patch series eases configuration of port I/O devices for x86
plattforms by generating an initial PIO region list. To sustain
previous
behavior, most entries are disabled (commented out). Only whitelisted
device ports are allowed. This includes the peripheral PCI port
space.
Did you also try what explodes when enforcing the generated list? I
mean, if there is no mess like with hidden memory regions, things
just Just Work (TM).
Not yet. Analysis of additional whitelist candidates shall follow.
We probably need a mixture: white-listing know-harmless thing that are
requested in the legacy range, combined with permitting the PCI
device-related regions.
Ack. With a little luck we can rely on entries in /proc/ioports, at
least for PCI ports above 0xd00.
I just compared lspci vs. ioports on some machines: Looks like ioports
contains everything that can be found in PCI config space. But ioports
contains even more.
What are those pnp entries good for? E.g.:
f800-f87f : pnp 00:01
f880-f8ff : pnp 00:01
[...]
Are these reserved areas for PCI devices?
pnp, ACPI, some further platform resources.
Will the root cell touch those ports? So far, it looks like it doesn't.
And on my laptop, I can also find ACPI stuff above 0xd00:
0d00-ffff : PCI Bus 0000:00
1640-164f : pnp 00:01
1800-187f : pnp 00:01
1800-1803 : ACPI PM1a_EVT_BLK
1804-1805 : ACPI PM1a_CNT_BLK
1808-180b : ACPI PM_TMR
1820-182f : ACPI GPE0_BLK
1850-1850 : ACPI PM2_CNT_BLK
How should we deal with that?
PM_TMR is passed through anyway, at least to non-root cells. The rest is
more dangerous, potentially. But a "works by default" setting may have
to include them.
And what about VGA? We whitelist 0x3b0-0x3df on any machine. Shouldn't
VGA be listed in ioports if present? At least for qemu that's the case.
If we can rely on that, then we wouldn't even have to whitelist VGA. [1]
Yes. VGA, if it shall be with the root cell (common case), should be
listed.
Alright.
So here you can find a WIP version of this series that comes with
support for selective whitelisting PCI devices:
https://github.com/lfd/jailhouse/tree/ioports-ralf-v2
So far, I successfully tested this approach on Qemu and on a real
machine. No crashes so far. (which I didn't expect, to be honest ;-) )
Jan, could you please test this approach? Just run it on your local
machine, look at the output, and compare it with /proc/ioports. If this
is the way to go, I'll make a clean series out of it. The head commit is
probably the most interesting one.
Something is broken:
$ jailhouse config create config.c
Traceback (most recent call last):
File "~/jailhouse/tools/jailhouse-config-create", line 260, in <module>
mem_regions, dmar_regions = sysfs_parser.parse_iomem(pcidevices)
File "~/jailhouse/tools/../pyjailhouse/sysfs_parser.py", line 102, in
parse_iomem
tree = IORegionTree.parse_io_file('/proc/iomem', MemRegion)
File "~/jailhouse/tools/../pyjailhouse/sysfs_parser.py", line 976, in
parse_io_file
level, r = IORegionTree.parse_io_line(line, TargetClass)
File "~/jailhouse/tools/../pyjailhouse/sysfs_parser.py", line 967, in
parse_io_line
return level, TargetClass(int(region[0], 16), int(region[1], 16), type)
File "~/jailhouse/tools/../pyjailhouse/sysfs_parser.py", line 869, in
__init__
super(MemRegion, self).__init__(start, stop, typestr)
TypeError: super() argument 1 must be type, not classobj
Argh, seems that's a python2 compat issue, doesn't happen with python3.
Please pull again, should be fixed now.
This now basically works, except where it can't. This is what I had to re-add
manually:
PIO_RANGE(0x61, 0x1), /* pc speaker */
PIO_RANGE(0x1ce, 0x3), /* vbe */
PIO_RANGE(0x402, 0x1), /* invalid but accessed by X */
PIO_RANGE(0x5658, 0x4), /* vmport */
None of these are listed by /proc/ioports or elsewhere in the kernel. Some
because the drivers do not claim the resource, some because they are likely
driven by userspace (X server). But that's the normal set of platform quirks, I
would say.
Jan
--
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/e635cd48-5a0f-183f-6f4d-00c017e40479%40web.de.
