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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

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.

> 
> 
> > 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?
> > 
> > Luis, sorry for hijacking this thread and expanding the scope of this work!
> > 
> > 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!
>  

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