Re: [Xen-devel] RFC: xen config changes v4

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

On Mon, Mar 02, 2015 at 11:07:02AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > >> I would prefer to hide it on PAE and x86_64.
> > > > >
> > > > >
> > > > > Okay, as long as it is still _possible_ somehow to configure it.
> > > > 
> > > > That begs the question, all this just for 32-bit non-PAE ?
> > > 
> > > There was another reason. Some distros remove the CONFIG_XEN_DOM0 
> > > altogether
> > > even thought they do enable the rest of the pieces (backends, frontends, 
> > > etc).
> > > 
> > > Which begs the question - why do we care about DOM0 at all.
> > > 
> > > What we care about is drivers - either frontend or backend. If we want
> > > backends and we want PV - then we want to build an kernel that can boot as
> > > a normal PV or as an dom0 PV.
> > > 
> > > Ditto for HVM - if you want to build an kernel that won't do PV but
> > > can do backends - we should be able to do that.
> > > 
> > > Or PVH  - we want an domain that can be an backend (or frontend).
> > > 
> > > That does mean the "PV" gets broken down further to be concrete
> > > pieces and have nothing to do with drivers. 
> > > 
> > > The idea would be that you would just select four knobs:
> > > 
> > >  Yes/No Backend PV drivers [and maybe remove the PV part?]
> > >  Yes/No Frontend PV drivers [and maybe remove the PV part?]
> > >  Yes/No PV support (so utilizing the PV ABI)
> > >  Yes/No PVH support (a stricter subset of PV ABI - with less pieces)
> > > 
> > > The HVM support would automatically be picked if the config had
> > > the 'baremetal' type support - like IOAPIC, APIC, ACPI, etc.
> > > 
> > > So if you said Y, N, N, N, the kernel would only be able to
> > > boot in HVM mode but still have pciback, netback, scsiback, blkback, and 
> > > usbback.
> > > (good for an device backend). And it could be an PAE or non-PAE kernel.
> > > 
> > > If you said N,Y,Y,Y then it could boot under HVM, PV, PVH, and only
> > > have pcifront, netfront, scsifront, blkfront, and usbfront.
> > > (not very good for an initial domain).
> > > 
> > > And so on.
> > 
> > It makes sense.
> > 
> > 
> > > I hope I hadn't confused the matter?
> > 
> > Nope, I think it clarifies things, thanks.
> 
> Thought it does mean that it would add more #ifdery or cleanups
> to the existing drivers so that they can be compiled under
> different platforms without any assumptions.
> 
> > 
> > In this context the issue we were discussing is what to do with the
> > other PV interfaces for PV on HVM guests, such as HVMOP_pagetable_dying.
> > I think it would be natural to enable them when Frontend PV drivers are
> > enabled, without any additional Kconfig options.
> 
> I would put this in 'Enlightment support for Xen' - which would be
> the basic foundation to make any kernel work under Xen. This would
> pull in some _infrastructure_. Regardless of it being a backend
> or frontend we need grant ops,event channels, support for migration.
>
> 
> Perhaps add that as a new option under CONFIG_HYPERVISOR. And not
> depend on CONFIG_PARAVIRT - as in theory you can have an non-PARAVIRT HVM
> guest running with PV drivers (I haven't tried it, but I would think
> it can be done?)

It was noted that that it was decided to hide XEN_PVHVM from being user
selectable, if so since thin HVM support hasn't been supported before
and since PVH is the way of the future -- why even bother enabling it?
It'd just add the option of a new type of guest, perhaps confuse things
more and then make it harder to remove support for if we wanted to.

> Regarding the 'HVMOP_pagetable_drying' - If it is part of foundation
> 'enlightment for Xen' - then it would be folded in. If it is not, but
> the platform looks to be a non-PV kernel (APIC, ACPI, IOPAPIC, MSI,
> PCI, etc) then it would be automatically enabled.
> 
> BTW, when I think PV kernel - it is an non-APIC, non-ACPI, non.. a lot
> of stuff. I did build one like that way back for 3.0 and it was quite
> slim. lHm, maybe we should even provide an 'defconfig' just to make sure
> we can test this kind of build?

This relates to the 'dead code' topic and BTW it is my next goal to address
while Juergen takes this Kconfig changes back on. If you are interested
in this topic I can send you my initial thoughts.

> Luis, sorry for hijacking this thread and expanding the scope of this work!

No worries, its what it is. Since Juergen is taking this on now the only
thing I'd caution against here is kernel hoarding. I see potential for it
and I was more in the hopes to get things here to be an opportunity to
pave the way for easy clean up later of things we likely do want to remove.
The removal topic probably should come to the table if we really are
serious about it.

> I think it would fantastical to make this work and would help a lot in
> the future - but right now it is a bit of complex riddle to untangle!

Since I'm new here I can only chime in here with a hope that we just
simplify things further and tie them in with more long term goals:

  * dynamic run time PVness - striving towards single build kernels
    without performance impact for non PV kernels

  * pave the way to nuke code we really are serious about removing,
    that might entail actually annotating things as obsolete now
    and to be removed later (note: 9c0ece069b32e8e1a Linus removed
    Documentation/feature-removal-schedule.txt so really its up
    to us and good judgement)

  Luis

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