From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Date: Wed, 24 Jun 2015 14:26:51 +0100 Message-ID: References: <1434989487-74940-1-git-send-email-roger.pau@citrix.com> <20150622180544.GA9175@l.oracle.com> <558A7CC5.7060400@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-63987763-1435151568=:18681" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z7kiO-0002q3-Gz for xen-devel@lists.xenproject.org; Wed, 24 Jun 2015 13:27:44 +0000 In-Reply-To: <558A7CC5.7060400@citrix.com> Content-ID: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com, Ian Campbell , andrew.cooper3@citrix.com, Stefano Stabellini , ian.jackson@eu.citrix.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org --1342847746-63987763-1435151568=:18681 Content-Type: text/plain; charset="UTF-8" Content-Length: 3449 Content-Transfer-Encoding: quoted-printable Content-ID: On Wed, 24 Jun 2015, Roger Pau Monn=C3=A9 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=3F This is more like PV on HVM without QEMU, right=3F > >> > >> Are you saying it should be called now 'HVM-diet' =3F Or 'HVMlite' instead > >> of PVH since it is looking at this from the HVM perspective instead of PVH=3F > > > > 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=3F 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=3F > > 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=3F > - Migration. This is just HVM migration minus saving/restoring the QEMU state file, isn't it=3F > - PCI pass-through. Do we really need PCI pass-through=3F 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=3F > 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. --1342847746-63987763-1435151568=:18681 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --1342847746-63987763-1435151568=:18681--