Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 3413 bytes --]

On Wed, 24 Jun 2015, Roger Pau Monné wrote:
> El 23/06/15 a les 12.55, Stefano Stabellini ha escrit:
> > On Mon, 22 Jun 2015, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Jun 22, 2015 at 06:55:12PM +0100, Stefano Stabellini wrote:
> >>> Hi Roger,
> >>>
> >>> given that this patch series is actually using the Xen "hvm" builder, I
> >>> take that all the PVH code paths in Xen or the guest kernel are not
> >>> actually used, correct? This is more like PV on HVM without QEMU, right?
> >>
> >> Are you saying it should be called now 'HVM-diet' ? Or 'HVMlite' instead
> >> of PVH since it is looking at this from the HVM perspective instead of PVH?
> >
> > HVMlite doesn't sound bad :-)
> >
> > I don't know if we should introduce a new name for this, but I wanted to
> > point out that this is different from PVH from Xen point of view. In
> > particular most of the outstanding PVH work items (32bit, AMD) on the
> > hypervisor would be redudant if we get this to work, right? If that is
> > the case, then I think it is best we agree on which road we want to take
> > going forward as soon as possible to avoid duplicated or wasted efforts.
> >
> > In fact it is not clear to me if/when we get this to work, what would be
> > the remaining open issues to complete "HVMlite". Roger?
>
> The following items are already working out of the box with the current
> patch set:
>
>  - 32bit* and 64bit guest modes.
>  - Intel support.
>  - AMD support**.
>  - HAP support.
>  - Shadow support.
>
> *  32bit CPU mode works, but I don't think 32bit hypercalls will work,
>    see Jan's reply to patch 11. I plan to fix this in the next
>    iteration.
> ** Untested.
>
>
> What needs to be done (ordered by priority):
>
>  - Clean up the patches, this patch series was done in less than a week.
>  - Finish the boot ABI (this would also be needed for PVH anyway).
>  - Convert the rest of xc_dom_*loaders in order to use the physical
>    entry point when present, right now xc_dom_elfloader is the only one
>    usable with HVMlite. This is quite trivial (see patch 10, it's a 4
>    LOC change).
>  - Dom0 support.

What do you think that Dom0 support is going to entail?


>  - Migration.

This is just HVM migration minus saving/restoring the QEMU state file,
isn't it?


>  - PCI pass-through.

Do we really need PCI pass-through? I see HVMlite mostly useful for
Dom0, but also for higher security Linux and BSD guests. If a user wants
PCI pass-through, she can always use PV on HVM.

Or do you mean allowing PCI pass-through to HVM guests on an HVMlite
Dom0?


> IMHO this is what we agreed to do with PVH, make it an HVM guest without
> a device model and without the emulated devices inside of Xen. Sooner or
> later we would need to make that change anyway in order to properly
> integrate PVH into Xen, and we get a bunch of new features for free as
> compared to PVH.
>
> I don't think of this as "throw PVH out of the window and start
> something completely new from scratch", we are going to reuse some of
> the code paths used by PVH inside of Xen. From a guest POV the changes
> needed to move from PVH into HVMlite are regarding the boot ABI only,
> which we already agreed that should be changed anyway.

Sure, I just wanted to highlight that some work items could become
redundant so that we don't waste any time on those.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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