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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel