Re: [Xen-devel] Xen's Linux kernel config options

["Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx>]

On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> On 12/12/14 13:17, Juergen Gross wrote:
>>> XEN_PVHVM
>>
>> Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.
>
> FWIW, although it seems we do not want to let users just build
> XEN_PVHVM hypervisors I have the changes required now to at least get
> this to build so I do know what it takes.
>
>>> XEN_FRONTEND                                            XEN_PV ||
>>>                                                         XEN_PVH ||
>>>                                                         XEN_PVHVM
>>
>> This enables all the basic infrastructure for frontends: event channels,
>> grant tables and Xenbus.
>>
>> Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
>> possible to have frontend drivers without support for any of the
>> PV/PVHVM/PVH guest types.
>
> David, can you elaborate on the type of Xen guest it would be on x86
> its not PV, PVHVM, or PVH? I'm particularly curious about the
> xen_domain_type and how it would end up to selected. As it is we tie
> in XEN_PVHVM at build time with XEN_PVH, in order to have XEN_PVHVM
> completely removed from XEN_PVH we need quite a bit of code changes
> which at least as code exercise I have completed already. If we want
> at the very least xen_domain_type set when XEN_PV, XEN_PVHVM, and
> XEN_PVH are not available we need a bit more work.

OK I think I see the issue. We have nothing quite like
xen_guest_init() on x86 enlighten.c, we do have this for ARM and I
think I can that close the gap I'm observing.

>>  Frontends only need event channels, grant
>> table and xenbus.
>
> Well xenbus_probe_initcall() will check for xen_domain() and that
> won't be set on x86 right now unless we have XEN_PV, XEN_PVHVM or
> XEN_PVH set -- to start off with. Then
> drivers/xen/xenbus/xenbus_client.c will check xen_feature in quite a
> bit of places as well, that won't be set unless xen_setup_features()
> is called which right now is only done on x86 arch/x86/xen/enlighten.c
> which as Juergen pointed out, is not needed if you don't have XEN_PV
> or XEN_PVH. As it turns out this is incorrect though, its needed for
> XEN_PVHVM as well and my split exercise in code addresses this. Now,
> at least in my code if you don't have XEN_PV, XEN_PVHVM, or XEN_PVH we
> don't call xen_setup_features() and its unclear to me where or how
> that should happen in other cases.

Yeah I think having an x86 equivalent of xen_guest_init() would solve
this, Stefano, thoughts?

>> Perhaps have XEN_FRONTEND select XEN instead?
>
> Right now if you enable CONFIG_XEN xen-head.S brings in and assumes a
> big tamale of guest support on x86, there are quite a bit of other
> code that also relies on CONFIG_XEN for similar purposes, and trying
> to remove out XEN_FRONTEND dependency from XEN_PV, XEN_PVHVM, XEN_PVH
> requires quite a bit work, most of which I think I've done, the only
> puzzle remaining to me at least is what we want to do for the setup
> for non XEN_PV, XEN_PVHVM, XEN_PVH Linux systems.

And with a xen_guest_init() this should still need to be resolved, and
I think I have this mostly addressed already in my dev branch, just
have to clean it up.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel