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

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

On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
>> 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?
>
> Having xen_guest_init() on x86 would be nice.  Being able to set
> xen_domain_type to XEN_HVM_DOMAIN if we are running on Xen, regardless
> of XEN_PV/PVH/PVHVM also makes sense from Linux POV.

OK great, thanks for the feedback.

> That said, I don't see much value in removing XEN_PVHVM: why are we even
> doing this? What is the improvement we are seeking?

We would not, the above discussed about the possibility of letting
users enable XEN_PVHVM without XEN_PVH, that's all. As is the only
thing that can enable XEN_PVHVM is if you enable XEN_PVH. If we want
xen_guest_init() alone though we might need the decoupling though at
least at build time so that if XEN_PV or XEN_PVH is not selected we'd
at least have XEN_PVHVM. Thoughts?

 Luis

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