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
This was run inside the qemu x86 instance.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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/b4b63fc4-87fc-909f-6b96-fe8f413a198c%40siemens.com.
