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

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

On Fri, Feb 27, 2015 at 10:27 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> 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).

Interesting, what distros do this? Also when one does not have dom0
what other forms are there to use Linux Xen backend drivers on GPL
kernels (because obviously non-GPL kernels are not an option)?

> Which begs the question - why do we care about DOM0 at all.

For the distros that do care about dom0? Not sure what those..

> 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.

Given we only have non-PAE 32-bit builds (big whoop) to be useful for
non-PV kernels I wonder how many distros are disabling PARAVIRT and if
they do are they going to be putting out PARAVIRT kernels specifically
just for Xen use? If we want traction on Xen we should make it easier
to manage Xen and that should be targeting to fold under one kernel.

> 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.

Sure but if performance is brutally dumb -- and if this is legacy
stuff why care so much about it (32-bit non-PAE)?

> 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.

I was originally echoing this but some folks seem to not believe this
was required, it was only after illustrating the build issues without
PARAVIRT and Stefano jumping in that this is now more or less an
accepted build issue and something we'd need to consider if we do or
not. Your points still don't make a big case for the effort enabling
the thin Xen HVM solutions other than just having them available.

> The idea would be that you would just select four knobs:
>
>  Yes/No Backend PV drivers [and maybe remove the PV part?]

OK this is a new topic and I did not explore to what extend one can
have backend alone without PV.

>  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)

Sure.

> 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.

But for 64-bit systems Stefano pointed out this would be silly to do.
The only good use case combination expressed for this so far would be
32-bit non-PAE systems no?

> 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).

Sure, thin HVM only if it disabled the PV part, maybe a boot param for
it. Again why the trouble?

> And so on.
>
> I hope I hadn't confused the matter?

Correct me if I'm wrong but I only see added to the table here was the
idea of clearing backend driver support also from the PV ties -- and
clarifying that this is all just about the big matrix of all possible
options and having the flexibility to let folks pick and choose. The
challenge I believe is figuring out what options in the matrix we
don't really care to enable or support, for instance it was noted that
distros didn't know what to do with XEN_PVHVM when exposed to them, so
there might be some things to consider also in this big matrix. Since
PVH is the long term, and I'm in no way a kernel hoarder, I'd advocate
only enabling things to let old PV to be compartmentalized well now
and later be ripped out. Personally that's the only reason why I'd
even bother with enabling thin HVM guests / backends / frontends, but
you guys would know better what path to take here.

In any case Juergen has expressed interest to taking this on again so
I'll go focus on some other items at the moment.

  Luis

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