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.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to