[Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH

Roger Pau Monné roger.pau at citrix.com
Thu Jan 9 16:30:56 UTC 2014


On 07/01/14 15:27, Julien Grall wrote:
> On 01/07/2014 08:29 AM, Roger Pau Monné wrote:
>> On 06/01/14 12:33, Julien Grall wrote:
>>>
>>>
>>> On 01/06/2014 09:35 AM, Roger Pau Monné wrote:
>>>> On 05/01/14 22:55, Julien Grall wrote:
>>>>>
>>>>>
>>>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote:
>>>>>> Introduce a Xen specific nexus that is going to be in charge for
>>>>>> attaching Xen specific devices.
>>>>>
>>>>> Now that we have a xenpv bus, do we really need a specific nexus for
>>>>> Xen?
>>>>> We should be able to use the identify callback of xenpv to create the
>>>>> bus.
>>>>>
>>>>> The other part of this patch can be merged in the patch #14 "Introduce
>>>>> xenpv bus and a dummy pvcpu device".
>>>>
>>>> On x86 at least we need the Xen specific nexus, or we will fall back to
>>>> use the legacy nexus which is not what we really want.
>>>>
>>>
>>> Oh right, in any case can we use the identify callback of xenpv to add
>>> the bus?
>>
>> AFAICT this kind of bus devices don't have a identify routine, and they
>> are usually added manually from the specific nexus, see acpi or legacy.
>> Could you add the device on ARM when you detect that you are running as
>> a Xen guest, or in the generic ARM nexus if Xen is detected?
> 
> Is there any reason to not add identify callback? If it's possible, I
> would like to avoid as much as possible #ifdef XENHVM in ARM code.

Maybe the x86 world is really different from the ARM world in how nexus
works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD
that attaches the xenpv bus in the generic ARM nexus rather than having
something that completely diverges from what buses usually do in
FreeBSD. It's going to be much more difficult to track in case of bugs,
and it's not what people expects, but that's just my opinion. I can
certainly add the identify routine if there's an agreement that it's the
best way to deal with it.

Roger.


More information about the freebsd-current mailing list