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. BTW: How should we deal with python2 in the future? It's (finally) EOL in ~2 months. Ralf > > This was run inside the qemu x86 instance. > > 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/e9bea12a-1524-6289-db95-f25edc3a3074%40oth-regensburg.de.
