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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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?


> > Do you think think this can work for Dom0 too?
> > 
> > Would that make all the PVH stuff in Xen and Linux effectively useless?
> 
> No. The AP bootup is still the same. So would all the hypercalls I think.
> > 
> > Thanks,
> > 
> > Stefano
> > 
> > On Mon, 22 Jun 2015, Roger Pau Monne wrote:
> > > Before reading any further, keep in mind this is a VERY inital RFC 
> > > prototype series. Many things are not finished, and those that are done 
> > > make heavy use of duck tape in order to keep things into place.
> > > 
> > > Now that you are warned, this series is split in the following order:
> > > 
> > >  - Patches from 1 to 7 switch HVM domain contruction to use the xc_dom_* 
> > >    family of functions, like they are used to build PV domains. 
> > >  - Patches from 8 to 13 introduce the creation of HVM domains without 
> > >    firmware, which is replaced by directly loading a kernel like it's 
> > > done 
> > >    for PV guests. A new boot ABI based on the discussion in the thread 
> > > "RFC: 
> > >    making the PVH 64bit ABI as stable" is also introduced, although it's 
> > > not 
> > >    finished.
> > > 
> > > Some things that are missing from the new boot ABI:
> > > 
> > >  - Although it supports loading a ramdisk, there's still now defined way 
> > >    into how to pass this ramdisk to the guest. I'm thinking of using a 
> > >    HVMPARAM or simply setting a GP register to contain the address of the 
> > >    ramdisk. Ideally I would like to support loading more than one ramdisk.
> > > 
> > > Some patches contain comments after the SoB, which in general describe 
> > > the 
> > > shortcommings of the implementation. The aim of those is to initiate 
> > > discussion about whether the aproach taken is TRTTD.
> > > 
> > > I've only tested this on Intel hw, but I see no reason why it shouldn't 
> > > work 
> > > on AMD. I've managed to boot FreeBSD up to the point were it should 
> > > jump into user-space (I just didn't have a VBD attached to the VM so it 
> > > just 
> > > sits waiting for a valid disk). I have not tried to boot it any further 
> > > since I think that's fine for the purpose of this series. 
> > > 
> > > The series can also be found in the following git repo:
> > > 
> > > git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v1
> > > 
> > > And for the FreeBSD part:
> > > 
> > > git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v1
> > > 
> > > In case someone wants to give it a try, I've uploaded a FreeBSD kernel 
> > > that 
> > > should work when booted into this mode:
> > > 
> > > https://people.freebsd.org/~royger/kernel_no_dm
> > > 
> > > The config file that I've used is:
> > > 
> > > <config>
> > > kernel="/path/to/kernel_no_dm"
> > > 
> > > builder="hvm"
> > > device_model_version="none"
> > > 
> > > memory=128
> > > vcpus=1
> > > name = "freebsd"
> > > </config>
> > > 
> > > Thanks, Roger.
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-devel
> > > 
> 

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