On Thursday, December 19, 2013 1:54:51 pm Roger Pau Monne wrote:
> Since Xen PVH guests doesn't have ACPI, we need to create a dummy
> pvcpu device that will be used to fill the pcpu->pc_device field.
Rather than have this hang directly off of nexus0, it might be better to
create some sort of 'xenov0' device that takes the place of acpi0 and have the
CPUs hang off of that. This is how the non-ACPI case works in the native case
where the default nexus creates a 'legacy0' device that sits at the same spot
in the device tree as acpi0. In sys/x86/legacy.c we create CPU devices that
are a child of legacy0.
In general the way the native code handes ACPI vs non-ACPI is to have a
different nexus (as you've adopted) create a specific child bus (acpi0 vs
legacy0). Drivers that want to only attach in one of the cases at the top-
level then attach as children of those rather than children of 'nexus0'. This
just adds an extra layer of protection to avoid the possibility of a top-level
driver that is ACPI or non-ACPI specific being probed in the "wrong" case.
Right now, all drivers that attach to 'nexus' aside from the top-level busses
(acpi0 vs legacy0) are intended to work on any machine.
I think the CPU driver itself looks fine, I would just encourage you to
consider a xenpv0 device and to move anything PV specific to hang off of that
rather than directly attaching to nexus0.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"