[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |