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, 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 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 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? -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
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, 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, 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@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 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, 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. 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 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, 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, 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 24.06.15 at 11:47, 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. 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. Jan ___ 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 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. - 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. 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 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
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 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 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: > > > > > > > > > kernel="/path/to/kernel_no_dm" > > > > > > builder="hvm" > > > device_model_version="none" > > > > > > memory=128 > > > vcpus=1 > > > name = "freebsd" > > > > > > > > > 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
El 22/06/15 a les 20.05, Konrad Rzeszutek Wilk ha escrit: > 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. This is something that we have not discussed, but for HVM domains the vCPU initialize hypercall only allows starting the vCPU in 32bit mode with paging disabled (just like how we are starting the BSP). I'm fine with that and I don't mind implementing a small trampoline for APs also, but would like to hear opinions about it. 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
Hello, El 22/06/15 a les 19.55, Stefano Stabellini ha escrit: > 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? >From a Xen POV this is not a PVH guest (it's an HVM guest), although I'm using some code paths which are shared with PVH. In the guest (in this case FreeBSD) I'm using the same paths as PVH, since the exposed interface is very similar. We probably aim at enabling the same set of hypercalls that are enabled on PVH. > Do you think think this can work for Dom0 too? I don't see why it couldn't be made to work. > Would that make all the PVH stuff in Xen and Linux effectively useless? No, I expect that some code paths inside of Xen will be shared between PVH and this HVM-without-dm guest type. Then from a guest POV the interface is quite similar, so most of the code present in Linux and FreeBSD in order to run as a PVH guest can be reused for this new guest mode. If you take a look at the FreeBSD patch the change is just mostly during early boot in order to set the page tables and jump into long mode, then the rest is quite similar to PVH. Forgot to mention, I've also tested it with hap=0 (so using shadow) and it seems to work fine. 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 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: > > > > > > kernel="/path/to/kernel_no_dm" > > > > builder="hvm" > > device_model_version="none" > > > > memory=128 > > vcpus=1 > > name = "freebsd" > > > > > > 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
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: > > > kernel="/path/to/kernel_no_dm" > > builder="hvm" > device_model_version="none" > > memory=128 > vcpus=1 > name = "freebsd" > > > 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
