Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
At 07:52 -0400 on 24 Jun (1435132373), Boris Ostrovsky wrote: On 06/24/2015 06:14 AM, Roger Pau Monné wrote: El 24/06/15 a les 12.05, Jan Beulich ha escrit: On 24.06.15 at 11:47, roger@citrix.com wrote: 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. I have to admit that I'm having a hard time making myself a clear picture of what the intention now is, namely with feature freeze being in about 2.5 weeks: If we assume that this series gets ready in time, should we drop Boris' 32-bit support patches? Would then be unfortunate if the series here didn't get ready. TBH I'm not going to make any promises of this being ready before the 4.6 feature freeze, not until I get some feedback from the tools maintainers regarding the libxc changes to unify the PV and HVM domain creation paths. FWIW, I gave this a quick spin on Monday and crashed the hypervisor on a NULL pointer right away in vapic code. Which, I assume, is not surprising since we are not supposed to be there in the first place. I'll try it again later today (I was out yesterday), maybe I messed something up. Otoh I don't think this and Boris' code conflict, and what we got in the tree PVH-wise is kind of a mess right now anyway, so adding to it just a few more bits (actually getting rid of some fixme-s, i.e. reducing messiness), so I'd be inclined to take the rest of Boris' series once ready, and if the series here gets ready too it could then also go in. Which would then mean for someone (perhaps after 4.6 was branched) to clean up any no longer necessary PVH special cases, unifying things towards what we seem to now call HVMlite. I'm not against merging the 32bit support series for PVH, but I'm certainly not going to invest time in adding 32bit PVH entry points to any OSes. What about Tim's proposal (http://lists.xen.org/archives/html/xen-devel/2014-12/msg00596.html)? Can this work be made part of it? At least, make it extendable to that? FWIW, I think this new scheme (start at HVM and remove things) is approaching the same end result from the other direction: Xen itself no longer needs to have a concept of PVH, and the guests get to keep their useful new interface. As such, I heartily approve. :) Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On 06/24/2015 06:14 AM, Roger Pau Monné wrote: El 24/06/15 a les 12.05, Jan Beulich ha escrit: On 24.06.15 at 11:47, roger@citrix.com wrote: 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. I have to admit that I'm having a hard time making myself a clear picture of what the intention now is, namely with feature freeze being in about 2.5 weeks: If we assume that this series gets ready in time, should we drop Boris' 32-bit support patches? Would then be unfortunate if the series here didn't get ready. TBH I'm not going to make any promises of this being ready before the 4.6 feature freeze, not until I get some feedback from the tools maintainers regarding the libxc changes to unify the PV and HVM domain creation paths. FWIW, I gave this a quick spin on Monday and crashed the hypervisor on a NULL pointer right away in vapic code. Which, I assume, is not surprising since we are not supposed to be there in the first place. I'll try it again later today (I was out yesterday), maybe I messed something up. Otoh I don't think this and Boris' code conflict, and what we got in the tree PVH-wise is kind of a mess right now anyway, so adding to it just a few more bits (actually getting rid of some fixme-s, i.e. reducing messiness), so I'd be inclined to take the rest of Boris' series once ready, and if the series here gets ready too it could then also go in. Which would then mean for someone (perhaps after 4.6 was branched) to clean up any no longer necessary PVH special cases, unifying things towards what we seem to now call HVMlite. I'm not against merging the 32bit support series for PVH, but I'm certainly not going to invest time in adding 32bit PVH entry points to any OSes. What about Tim's proposal (http://lists.xen.org/archives/html/xen-devel/2014-12/msg00596.html)? Can this work be made part of it? At least, make it extendable to that? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
El 24/06/15 a les 12.05, Jan Beulich ha escrit: On 24.06.15 at 11:47, roger@citrix.com wrote: 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. I have to admit that I'm having a hard time making myself a clear picture of what the intention now is, namely with feature freeze being in about 2.5 weeks: If we assume that this series gets ready in time, should we drop Boris' 32-bit support patches? Would then be unfortunate if the series here didn't get ready. TBH I'm not going to make any promises of this being ready before the 4.6 feature freeze, not until I get some feedback from the tools maintainers regarding the libxc changes to unify the PV and HVM domain creation paths. Otoh I don't think this and Boris' code conflict, and what we got in the tree PVH-wise is kind of a mess right now anyway, so adding to it just a few more bits (actually getting rid of some fixme-s, i.e. reducing messiness), so I'd be inclined to take the rest of Boris' series once ready, and if the series here gets ready too it could then also go in. Which would then mean for someone (perhaps after 4.6 was branched) to clean up any no longer necessary PVH special cases, unifying things towards what we seem to now call HVMlite. I'm not against merging the 32bit support series for PVH, but I'm certainly not going to invest time in adding 32bit PVH entry points to any OSes. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Wed, Jun 24, 2015 at 02:04:45PM +0200, Roger Pau Monné wrote: El 24/06/15 a les 13.52, Boris Ostrovsky ha escrit: On 06/24/2015 06:14 AM, Roger Pau Monné wrote: El 24/06/15 a les 12.05, Jan Beulich ha escrit: On 24.06.15 at 11:47, roger@citrix.com wrote: 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. I have to admit that I'm having a hard time making myself a clear picture of what the intention now is, namely with feature freeze being in about 2.5 weeks: If we assume that this series gets ready in time, should we drop Boris' 32-bit support patches? Would then be unfortunate if the series here didn't get ready. TBH I'm not going to make any promises of this being ready before the 4.6 feature freeze, not until I get some feedback from the tools maintainers regarding the libxc changes to unify the PV and HVM domain creation paths. FWIW, I gave this a quick spin on Monday and crashed the hypervisor on a NULL pointer right away in vapic code. Which, I assume, is not surprising since we are not supposed to be there in the first place. I'll try it again later today (I was out yesterday), maybe I messed something up. Yes, feature disabling is still not 100% done I'm afraid. For example if your hw supports vAPIC it will be enabled anyway, which can then lead to all kinds of trouble. As said, this is very initial and I've only tested it on one Nehalem box which doesn't have vAPIC. Otoh I don't think this and Boris' code conflict, and what we got in the tree PVH-wise is kind of a mess right now anyway, so adding to it just a few more bits (actually getting rid of some fixme-s, i.e. reducing messiness), so I'd be inclined to take the rest of Boris' series once ready, and if the series here gets ready too it could then also go in. Which would then mean for someone (perhaps after 4.6 was branched) to clean up any no longer necessary PVH special cases, unifying things towards what we seem to now call HVMlite. I'm not against merging the 32bit support series for PVH, but I'm certainly not going to invest time in adding 32bit PVH entry points to any OSes. What about Tim's proposal (http://lists.xen.org/archives/html/xen-devel/2014-12/msg00596.html)? Can this work be made part of it? At least, make it extendable to that? Yes, the aim of this work is to address some of the points expressed in that email, mainly merge PVH into HVM. But as we have already spoken, the entry point of HVMlite or whatever we call it is going to be different from the traditional PV/PVH entry point. Right. If you were to take a sharpie where would you put in the list that Tim had written out? And to my eye - it looks as the HVMLIte boot entry and the old PVH bootpaths can co-exist for some time until they get merged together? This would have the nice benefit of being able to troubleshoot issues easier as you have an existing codepath for 'old-PVH' and new bootup path and can figure out what is missing to make it work (with the Linux kernel at least). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Wed, 24 Jun 2015, Boris Ostrovsky wrote: On 06/24/2015 09:26 AM, Stefano Stabellini wrote: On Wed, 24 Jun 2015, Roger Pau Monné wrote: - 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. Why is this model not useful for a generic domU? I thought that it should eventually become a replacement for what we now have as PVH? It is useful as generic DomU because it provides a smaller surface of attack compared to PV on HVM guests. At the same time using PCI pass-through increases that surface of attack again, decreasing the value of HVMLite/PVH, at least in my view. But you are right that it might be nice to have it for feature completeness, if nothing else.___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote: 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. I think what you are saying is we either want to pursue this path _or_ PVH, but not both, and I would be inclined to agree, it seems to me like duplication of both effort and functionality to do both. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Tue, 23 Jun 2015, Ian Campbell wrote: On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote: 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. I think what you are saying is we either want to pursue this path _or_ PVH, but not both, and I would be inclined to agree, it seems to me like duplication of both effort and functionality to do both. Right, especially given that they both seem to provide similar functionalities. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
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@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On 06/23/2015 09:12 AM, Stefano Stabellini wrote: On Tue, 23 Jun 2015, Ian Campbell wrote: On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote: 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. I think what you are saying is we either want to pursue this path _or_ PVH, but not both, and I would be inclined to agree, it seems to me like duplication of both effort and functionality to do both. Right, especially given that they both seem to provide similar functionalities. Given that 32-bit support of existing PVH model looks pretty simple and required AMD changes are also well understood (right?) and do not appear particularly invasive I would argue for finishing those two while continuing to work on unified boot model. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
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
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
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? Do you think think this can work for Dom0 too? Would that make all the PVH stuff in Xen and Linux effectively useless? 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
