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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.
 - Migration.
 - PCI pass-through.

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.

Roger.


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