On 7/23/19 7:58 PM, Jan Kiszka wrote:
> On 23.07.19 19:53, Ralf Ramsauer wrote:
>>
>>
>> On 7/23/19 7:21 PM, Jan Kiszka wrote:
>>> On 23.07.19 18:38, Ralf Ramsauer wrote:
>>>>
>>>>
>>>> On 7/23/19 5:35 PM, Jan Kiszka wrote:
>>>>> On 23.07.19 17:19, Jan Kiszka wrote:
>>>>>> On 23.07.19 16:50, Ralf Ramsauer wrote:
>>>>>>> Two bad news: Linux's 8250 driver needs patching. At least we need some
>>>>>>> parameter like 8250.platform=disable to disable the probing for platform
>>>>>>> uarts. Why?
>>>>>>>
>>>>>>> ATM, we must specify 8250.nr_uarts. Otherwise the kernel will touch
>>>>>>> restricted ports. It does touch those ports, as it lacks ACPI platform
>>>>>>> information and assumes 'any' platform UART is present.
>>>>>>
>>>>>> Yes, nr_uarts is the patch-free approach for now. I once had a hack that
>>>>>> propagated the information "this is Jailhouse, you may not find platform
>>>>>> UARTs"
>>>>>> to the driver. But that was a hack, so I didn't propose that upstream
>>>>>> along with
>>>>>> the other x86 changes. Plus, there are cases where we do want to use a
>>>>>> platform
>>>>>> uart in the non-root cell.
>>>>>>
>>>>>>>
>>>>>>> I.e.:
>>>>>>> 8250.nr_uarts=1 only touches 0x3f8
>>>>>>> 8250.nr_uarts=2 touches 0x3f8 and 0x2f8
>>>>>>> 8250.nr_uarts=3 touches 0x3f8, 0x2f8, 0x3e9 (?)
>>>>>>>
>>>>>>> In addition to that I have a PCI device. And Linux won't probe it until
>>>>>>> it probed all other PIO ports. If I specify 8250.nr_uarts=1 (as I do
>>>>>>> want to restrict access to 0x2f8), it will never probe the PCI device.
>>>>>>>
>>>>>>> So at the moment, the hack is to set 8250.nr_uarts=4 and permit access
>>>>>>> to all ports. Yikes. At least I now know that the PCI device basically
>>>>>>> works, but still, this needs to be patched.
>>>>>>>
>>>>>>
>>>>>> OK, that was probably not yet addressed. We once had a setup with UARTs
>>>>>> on a PCI
>>>>>> card, but that machine also had no platform UARTs IIRC.
>>>>>>
>>>>>> If there no other way to tell Linux the number of platform UARTs, we
>>>>>> will have
>>>>>> to introduce one, for the sake of this use case already.
>>>>>>
>>>>>
>>>>> Maybe we can do something like arch/x86/platform/ce4100/ce4100.c to
>>>>> "tune" the
>>>>
>>>> Thanks for the pointer.
>>>>
>>>>> platform UARTs (ce4100_serial_fixup). But it still takes an extension of
>>>>> the
>>>>> boot protocol to provide Linux with the information about available
>>>>> platform UARTs.
>>>>
>>>> Hm. We do have the comm region... It will hold the config's struct
>>>> jailhouse_console. We could use this in combination with
>>>> serial8250_set_isa_configurator.
>>>>
>>>> This won't enable all platform uarts, but with this we could
>>>> automatically enable at least one platform uart + hypervisor debug
>>>> output. This should be sufficient for most cases.
>>>
>>> This is x86 only: If the well-known legacy ports are open in the config and
>>> also
>>> the related IRQs, cell-linux could set some to-be-defined flags in the
>>
>> Hmm. The config (as well as the comm region) lacks the IRQs of the
>> platform UART. But they should be static for platform UARTs afaict.
>
> The config has this: irqchip at standard address 0xfec00000, pins 3 & 4. If
> set,
> then the UART is passed. The comm region is not needed here, the setup_data is
> filled by the loader.
>
>>
>>> setup_data, and the kernel could tune the platform UART settings
>>> accordingly.
>>> "Should be simple" (TM).
>>
>> Yep, that wouldn't require any invasive modification of the platform
>> drivers.
>>
>> Three flags should be sufficient:
>> - Use 0x2f8
>> - Use 0x3f8
>> - Use dbgcon
>
> Nope, 4: PC-UART0..3. dbgcon has nothing to do with this.
>
> If we want to propagate the comm region settings into some "console=X", that
> would be a pure kernel command line tuning by cell-linux.
Ok, got it. PoC implementation works fine! ATM, I require two patches on
top of jailhouse, and two kernel patches.
I still have to clean them up, but it should be integrated upstream.
Once integrated, we need no more "8250.nr_uarts=..." on x86.
Still have to debug the IOMMU fault events.
Thanks
Ralf
>
> 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/fc1c5074-15e2-6681-dfbb-a1ce22ebe6ae%40oth-regensburg.de.
