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

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

On Mon, Mar 02, 2015 at 12:30:02PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 02, 2015 at 05:07:00PM +0000, Stefano Stabellini wrote:
> > On Mon, 2 Mar 2015, 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.
> > 
> > Sounds good.
> > 
> > 
> > > 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?)
> > 
> > That is the bit I disagree with: not depending on CONFIG_PARAVIRT means
> > that many good optimizations for PV on HVM guests won't be enabled.
> > Doing so will cause a performance regression compared to the PV on HVM
> > guests of today.
> > 
> > Most x86_64 distro kernels have CONFIG_PARAVIRT and CONFIG_XEN, I
> > wouldn't want them to switch to CONFIG_XEN_FRONTEND without
> > CONFIG_PARAVIRT in the future as a consequence of this work.
> 
> The CONFIG_PARAVIRT is a giant umbrella for everything 'virt' nowadays.
> It has runtime patches for the low-level functions, clock functions,
> spinlocks, etc.
> 
> Unraveling that to be simpler (clock functions can be in their own
> indirect structure that would be wrapped by CONFIG_VIRT_CLOCK for example?)
> would be nice but an headache to unravel.

IMHO this is the sort of thing that needs to be addressed for a run time
dynamic change, thereby making it less of an issue for folks to consider
to enable / disable CONFIG_PARAVIRT. The split you mentioned *should* be
addressed cleanly as well.

> Hence your point is valid and correct - we need to select CONFIG_PARAVIRT - 
> even
> if we just end up using an fraction of it. The unravelling of
> CONFIG_PARAVIRT can be done in the future.

I think it should have been done yesterday, addressing this would make
make this discussion simply about how thin you want your kernel rather
than one way avenues as they are now.

  Luis

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