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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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?


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