On 5/29/2025 6:26 PM, Greg A. Woods wrote: > At Thu, 29 May 2025 17:37:10 -0400, Chuck Zmudzinski <frchu...@gmail.com> > wrote: > Subject: Re: Xen boot strangeness (Was: Re: [SOLVED] Re: Xen > 4.18.5_20250521nb0 not ELF binary (Was: Re: EFI and Xen)) >> >> It seems to me our DOM0 config assumes Xen is not successfully hiding the >> serial console used by Xen from DOM0, not even the normal ISA com ports, >> and that is why we comment out com0 in the XEN3_DOM0 config. If Xen was >> hiding that device from DOM0, we would not need to do that would we? > > Ah ha! Sorry, I forgot to check that, and I didn't twig to what Manuel > meant by "As noted in the kernel config file...". > > So, yes, indeed, Xen is not hiding the device it uses as the serial console. > >> If we could fix this on the Xen side by hiding whatever com device Xen is >> using for its console, whether that be a normal com device, a PCI device, >> AMT device or whatever, that would be great. > > Yes, for sure, I think that's the way to go > > If I'm understanding the code correctly there does seem to be a way to > hide a PCI device from the kernel, so that might be a start.... > > On the other hand the fact that an attempt by the kernel to attach the > device causes a crash suggests that there should be some way to detect > that it is already in use -- i.e. fix the crash by not attaching the > device in that case!
Here is the crash dump: [ 1.0000030] com2 at puc0 port 0 (16850-compatible): panic: Failed to bind physical IRQ 16 [ 1.0000030] cpu0: Begin traceback... [ 1.0000030] vpanic() at netbsd:vpanic+0x177 [ 1.0000030] panic() at netbsd:panic+0x3c [ 1.0000030] bind_pirq_to_evtch() at netbsd:bind_pirq_to_evtch+0xa8 ... So I think logic in the bind_pirq_to_evtch function in dom0 like this could work: If we cannot bind an IRQ to a xen event channel when trying to attach a com device because that IRQ is already in use, log a warning and disable the com device instead of doing a panic and crash. To do this would we need to be sure we can always assume that Xen is using the com device when we cannot bind the pirq to the xen event channel and therefore also assume it would be safe to continue with a warning and disable the device instead of doing a panic? Or to ask the same question in another way, are there any other cases (other than this case when we are using the com device as the xen console and it is safe to continue) in which it would *not* be safe to disable the device and continue with only a warning when the device we are attaching is a com device and we cannot bind the pirq the device is using to a xen event channel? > > -- > Greg A. Woods <gwo...@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca> > Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
