|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen's Linux kernel config options
On Wed, Feb 25, 2015 at 02:27:08PM +0000, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, Stefano Stabellini wrote:
> > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > > 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.
> >
> > OK, that makes sense.
> >
> >
> > > As is the only thing that can enable XEN_PVHVM is if you enable
> > > XEN_PVH.
> >
> > This is the bit that we need to change but it shouldn't be difficult.
> >
> >
> > > 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?
> >
> > Today pv(h) and pvhvm have very different boot paths already: pv and pvh
> > initialize via xen_start_kernel while pvhvm via xen_hvm_guest_init.
> > They are already very decoupled. You just need to make sure that
> > init_hvm_pv_info() is called regardless on any XEN_PV/PVH/PVHVM configs.
>
> Sorry for not replying to the point earlier -- I missed your v1
> patch series submission.
>
> After reading your series, I think we should get rid of XEN_PVHVM on x86
> entirely: if XEN and XEN_FRONTEND are chosen by the user, what is the
> point of one more separate option for XEN_PVHVM?
Sure, agreed.
> XEN_PVHVM only gives you vector callback, pv timers,
> HVMOP_pagetable_dying and irq remapping support. I don't think it is
> worth introducing one more option for those. They should be always built
> and available if XEN_FRONTEND.
>
> I suggest we remove XEN_PVHVM and we fold the few little remain features
> offered by XEN_PVHVM in XEN_FRONTEND directly.
OK since currently XEN_PVH selects XEN_PVHVM that would mean
XEN_PVH will now select XEN_FRONTEND. We also decided that
XEN_FRONTEND would select:
XEN
XEN_XENBUS_FRONTEND
INPUT_XEN_KBDDEV_FRONTEND
So that would go in as collateral by having XEN_PVH select XEN_FRONTEND.
The only new one implicated here would be INPUT_XEN_KBDDEV_FRONTEND.
Also as per our agreed upon changes XEN_PVHVM should select:
PARAVIRT
PARAVIRT_CLOCK
So XEN_FRONTEND would select these as well then, the only new one being
PARAVIRT_CLOCK. XEN_PVHVM would depend on PCI && X86_LOCAL_APIC, so that
goes as a dependency on XEN_FRONTEND as well.
If we are OK with all this I will proceed with this.
> In terms of xen_domain types, it is still good idea to set xen_domain
> to the right value no matter what. I think we should call
> init_hvm_pv_info() even if XEN_FRONTEND/XEN_PVHVM is not selected.
Well so we currently do not call init_hvm_pv_info() without XEN_PVHVM,
the XEN_PVHVM -> XEN_FRONTEND change would implicate:
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 36ce402..83a53c0 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -27,7 +27,7 @@
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_XEN_FRONTEND
&x86_hyper_xen_hvm,
#endif
&x86_hyper_vmware,
Striving towards this change alone should get us what we need I think
for enabling us to build front end drivers. In fact doing a wide change
on the delta I had prepared so far I get front end drivers now compiling
happily with this change. I am not sure if we need then init_hvm_pv_info()
called elsewhere if this change is made as the only possibility would
be is if the guest is a XEN_PV or XEN_PVH. Let me know.
Luis
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |