Hi Guys,
Just a quick status update. I refreshed my trees and then debugged as
the code had changed a lot. I''m again few weeks behind from the latest
tree on both linux and xen. After the refresh, I ran into few issues:
- xenstored is using gnttab interface that will not work for hybrid
For now I just disabled it.
- libxl has changed a lot, so for now, I''m only supporting
disk = [''phy:/dev/loop1,xvda,w'']
- the struct pv_vcpu and hvm_vcpu are into a union now. I added a new
type hyb_vcpu and now going thru the code changing all refs.
- on the linux side I managed to remove all changes to non-xen files,
this should help a alot.
Once I finish the changes for hyb_vcpu union, I should be able to get
things working again. Then I''ll refresh the linux tree, keeping xen the
same, and test it all out and submit linux patch. After that I''ll
refresh xen tree and keeping same linux, test it out, and submit patch.
Thanks,
Mukesh
On Tue, 26 Jun 2012 18:17:07 -0700 Mukesh Rathor <mukesh.rathor@oracle.com> wrote:> Hi Guys, > > Just a quick status update. I refreshed my trees and then debugged as > the code had changed a lot. I''m again few weeks behind from the latest > tree on both linux and xen. After the refresh, I ran into few issues: > > - xenstored is using gnttab interface that will not work for hybrid > For now I just disabled it. > > - libxl has changed a lot, so for now, I''m only supporting > disk = [''phy:/dev/loop1,xvda,w''] > > - the struct pv_vcpu and hvm_vcpu are into a union now. I added a > new type hyb_vcpu and now going thru the code changing all refs.Never mind on this. Adding a new type to union is creating a lot of changes to vmx files, altho it would have been nice to keep a clean hyb_vcpu struct. I guess, I''ll add a few hyb fields to hvm_vcpu and that would keep code change to minimum. thanks, Mukesh
On Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote:> Hi Guys, > > Just a quick status update. I refreshed my trees and then debugged as > the code had changed a lot. I''m again few weeks behind from the latest > tree on both linux and xen. After the refresh, I ran into few issues: > > - xenstored is using gnttab interface that will not work for hybrid > For now I just disabled it.OOI what''s the conflict?> - libxl has changed a lot, so for now, I''m only supporting > disk = [''phy:/dev/loop1,xvda,w'']I''d have thought disk backend would be unrelated to hybrid, other than any backend which uses gnttab I guess (hrm, maybe that''s all except for blkback.). [...]> Once I finish the changes for hyb_vcpu union, I should be able to get > things working again. Then I''ll refresh the linux tree, keeping xen the > same, and test it all out and submit linux patch. After that I''ll > refresh xen tree and keeping same linux, test it out, and submit patch.We''d probably want to have both patches reviewed before accepting either, wouldn''t we? We don''t want to commit to an interface on one side before reviewing the other. (I''m not sure if you mean "submit" as in "RFC" or as in "please commit this"). That needed necessarily mean they come through simultaneously though, although review of one might be limited without the other. Ian.
On Thu, 28 Jun 2012 09:44:05 +0100 Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote: > > Hi Guys, > > > > Just a quick status update. I refreshed my trees and then debugged > > as the code had changed a lot. I''m again few weeks behind from the > > latest tree on both linux and xen. After the refresh, I ran into > > few issues: > > > > - xenstored is using gnttab interface that will not work for > > hybrid For now I just disabled it. > > OOI what''s the conflict?If I recall correctly, the M2P was not setup yet. This will take lot more digging in xl, which is changing fast, so I was hoping to punt it for phase II. Meantime, I''m not sure how to pass hybrid flag to xenstored. Any ideas?> > - libxl has changed a lot, so for now, I''m only supporting > > disk = [''phy:/dev/loop1,xvda,w''] > > I''d have thought disk backend would be unrelated to hybrid, other than > any backend which uses gnttab I guess (hrm, maybe that''s all except > for blkback.). > > [...] > > Once I finish the changes for hyb_vcpu union, I should be able to > > get things working again. Then I''ll refresh the linux tree, keeping > > xen the same, and test it all out and submit linux patch. After > > that I''ll refresh xen tree and keeping same linux, test it out, and > > submit patch. > > We''d probably want to have both patches reviewed before accepting > either, wouldn''t we? We don''t want to commit to an interface on one > side before reviewing the other. (I''m not sure if you mean "submit" > as in "RFC" or as in "please commit this"). > > That needed necessarily mean they come through simultaneously though, > although review of one might be limited without the other.Yup, I''ll post both. But one would be outdated. Refreshing both testing all the combinations is costing me 4-6 weeks of debug and test. Code is changing fast. Lets get something basic working in, as long as it does not break non-hybrid. Then we will keep adding and fixing things. I''ve to be out of the office for the rest of the month, so unfortunately I am not sure if I''ll have all patches submitted before the summit like I was hoping. thanks, Mukesh
On Tue, 3 Jul 2012, Mukesh Rathor wrote:> On Thu, 28 Jun 2012 09:44:05 +0100 > Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > On Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote: > > > Hi Guys, > > > > > > Just a quick status update. I refreshed my trees and then debugged > > > as the code had changed a lot. I''m again few weeks behind from the > > > latest tree on both linux and xen. After the refresh, I ran into > > > few issues: > > > > > > - xenstored is using gnttab interface that will not work for > > > hybrid For now I just disabled it. > > > > OOI what''s the conflict? > > If I recall correctly, the M2P was not setup yet. This will take lot more > digging in xl, which is changing fast, so I was hoping to punt it for > phase II. Meantime, I''m not sure how to pass hybrid flag to xenstored. > Any ideas?xenstored is going to try to open the grant table interface (xc_gnttab_open, implemented via gntdev), if that fails it should fall back to xc_map_foreign_range. That should work out of the box, or at least it does for my "hybrid" ARM dom0.
On Wed, 4 Jul 2012 11:01:40 +0100 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:> On Tue, 3 Jul 2012, Mukesh Rathor wrote: > > On Thu, 28 Jun 2012 09:44:05 +0100 > > Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > > > On Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote: > > > > Hi Guys, > > > > > > > > Just a quick status update. I refreshed my trees and then > > > > debugged as the code had changed a lot. I''m again few weeks > > > > behind from the latest tree on both linux and xen. After the > > > > refresh, I ran into few issues: > > > > > > > > - xenstored is using gnttab interface that will not work for > > > > hybrid For now I just disabled it. > > > > > > OOI what''s the conflict? > > > > If I recall correctly, the M2P was not setup yet. This will take > > lot more digging in xl, which is changing fast, so I was hoping to > > punt it for phase II. Meantime, I''m not sure how to pass hybrid > > flag to xenstored. Any ideas? > > xenstored is going to try to open the grant table interface > (xc_gnttab_open, implemented via gntdev), if that fails it should fall > back to xc_map_foreign_range. That should work out of the box, or at > least it does for my "hybrid" ARM dom0.For hybrid, I''d like it to just use map foreign range for now. I am looking for a way to enforce that. I can''t pass flag to the API. thanks Mukesh
On Thu, 5 Jul 2012, Mukesh Rathor wrote:> > xenstored is going to try to open the grant table interface > > (xc_gnttab_open, implemented via gntdev), if that fails it should fall > > back to xc_map_foreign_range. That should work out of the box, or at > > least it does for my "hybrid" ARM dom0. > > For hybrid, I''d like it to just use map foreign range for now. I am > looking for a way to enforce that. I can''t pass flag to the API.Maybe the best thing to do would be modifying xenstored map_interface to fall back to the old method if gnttab doesn''t work. The basic idea is the following (untested): diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c index bf83d58..14f5cdf 100644 --- a/tools/xenstore/xenstored_domain.c +++ b/tools/xenstore/xenstored_domain.c @@ -167,14 +167,16 @@ static int readchn(struct connection *conn, void *data, unsigned int len) static void *map_interface(domid_t domid, unsigned long mfn) { + void *addr; if (*xcg_handle != NULL) { /* this is the preferred method */ - return xc_gnttab_map_grant_ref(*xcg_handle, domid, + addr = xc_gnttab_map_grant_ref(*xcg_handle, domid, GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE); - } else { - return xc_map_foreign_range(*xc_handle, domid, - getpagesize(), PROT_READ|PROT_WRITE, mfn); + if (addr) + return addr; } + return xc_map_foreign_range(*xc_handle, domid, + getpagesize(), PROT_READ|PROT_WRITE, mfn); } static void unmap_interface(void *interface)
I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name for this feature, mainly for "marketing" reasons. I think it will probably give people the wrong idea about what the technology does. PV domains is one of Xen''s really distinct advantages -- much simpler interface, lighter-weight (no qemu, legacy boot), &c &c. As I understand it, the mode you''ve been calling "hybrid" still has all of these advantages -- it just uses some of the HVM hardware extensions to make the interface even simpler / faster. I''m afraid "hybrid" may be seen as, "Even Xen has had to give up on PV." Can I suggest something like "PVH" instead? That (at least to me) makes it clear that PV domains are still fully PV, but just use some HVM extensions. Thoughts? -George On Wed, Jun 27, 2012 at 2:17 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:> Hi Guys, > > Just a quick status update. I refreshed my trees and then debugged as > the code had changed a lot. I''m again few weeks behind from the latest > tree on both linux and xen. After the refresh, I ran into few issues: > > - xenstored is using gnttab interface that will not work for hybrid > For now I just disabled it. > > - libxl has changed a lot, so for now, I''m only supporting > disk = [''phy:/dev/loop1,xvda,w''] > > - the struct pv_vcpu and hvm_vcpu are into a union now. I added a new > type hyb_vcpu and now going thru the code changing all refs. > > - on the linux side I managed to remove all changes to non-xen files, > this should help a alot. > > Once I finish the changes for hyb_vcpu union, I should be able to get > things working again. Then I''ll refresh the linux tree, keeping xen the > same, and test it all out and submit linux patch. After that I''ll > refresh xen tree and keeping same linux, test it out, and submit patch. > > Thanks, > Mukesh > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote:> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > for this feature, mainly for "marketing" reasons. I think it will > probably give people the wrong idea about what the technology does. > PV domains is one of Xen''s really distinct advantages -- much simpler > interface, lighter-weight (no qemu, legacy boot), &c &c. As I > understand it, the mode you''ve been calling "hybrid" still has all of > these advantages -- it just uses some of the HVM hardware extensions > to make the interface even simpler / faster. I''m afraid "hybrid" may > be seen as, "Even Xen has had to give up on PV." > > Can I suggest something like "PVH" instead? That (at least to me) > makes it clear that PV domains are still fully PV, but just use some > HVM extensions.if (xen_pvh_domain()? if (xen_pv_h_domain()? if (xen_h_domain()) ? if (xen_pvplus_domain()) ? if (xen_pv_ext_domain()) ? I think I like ''pv+''?> > Thoughts? > > -George > > On Wed, Jun 27, 2012 at 2:17 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote: > > Hi Guys, > > > > Just a quick status update. I refreshed my trees and then debugged as > > the code had changed a lot. I''m again few weeks behind from the latest > > tree on both linux and xen. After the refresh, I ran into few issues: > > > > - xenstored is using gnttab interface that will not work for hybrid > > For now I just disabled it. > > > > - libxl has changed a lot, so for now, I''m only supporting > > disk = [''phy:/dev/loop1,xvda,w''] > > > > - the struct pv_vcpu and hvm_vcpu are into a union now. I added a new > > type hyb_vcpu and now going thru the code changing all refs. > > > > - on the linux side I managed to remove all changes to non-xen files, > > this should help a alot. > > > > Once I finish the changes for hyb_vcpu union, I should be able to get > > things working again. Then I''ll refresh the linux tree, keeping xen the > > same, and test it all out and submit linux patch. After that I''ll > > refresh xen tree and keeping same linux, test it out, and submit patch. > > > > Thanks, > > Mukesh > > > > > > _______________________________________________ > > 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
On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name >> for this feature, mainly for "marketing" reasons. I think it will >> probably give people the wrong idea about what the technology does. >> PV domains is one of Xen''s really distinct advantages -- much simpler >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I >> understand it, the mode you''ve been calling "hybrid" still has all of >> these advantages -- it just uses some of the HVM hardware extensions >> to make the interface even simpler / faster. I''m afraid "hybrid" may >> be seen as, "Even Xen has had to give up on PV." >> >> Can I suggest something like "PVH" instead? That (at least to me) >> makes it clear that PV domains are still fully PV, but just use some >> HVM extensions. > > if (xen_pvh_domain()? > > if (xen_pv_h_domain()? > > if (xen_h_domain()) ? > > if (xen_pvplus_domain()) ? > > if (xen_pv_ext_domain()) ? > > I think I like ''pv+''?I could deal with pv+. However, in general I dislike that kind of "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX (Extreme PV!) -- they all sound cool when they come out, but five years later, when they''re not so new or sexy anymore, they all sound lame. PVH is just descriptive -- it will always be PV with HVM extensions, so it will age much better. :-) -George
Wednesday, August 1, 2012, 5:25:01 PM, you wrote:> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > for this feature, mainly for "marketing" reasons. I think it will > probably give people the wrong idea about what the technology does. > PV domains is one of Xen''s really distinct advantages -- much simpler > interface, lighter-weight (no qemu, legacy boot), &c &c. As I > understand it, the mode you''ve been calling "hybrid" still has all of > these advantages -- it just uses some of the HVM hardware extensions > to make the interface even simpler / faster. I''m afraid "hybrid" may > be seen as, "Even Xen has had to give up on PV."Hmm i must say i was indeed under the impression that hybrid was == HVM + PV drivers. But from what i read above it would be much more interesting by avoiding the qemu stuff, but still using the HVM hardware extensions. So i think you have a point for people who don''t dive too deep into what the actual features are. -- Sander> Can I suggest something like "PVH" instead? That (at least to me) > makes it clear that PV domains are still fully PV, but just use some > HVM extensions.> Thoughts?> -George> On Wed, Jun 27, 2012 at 2:17 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote: >> Hi Guys, >> >> Just a quick status update. I refreshed my trees and then debugged as >> the code had changed a lot. I''m again few weeks behind from the latest >> tree on both linux and xen. After the refresh, I ran into few issues: >> >> - xenstored is using gnttab interface that will not work for hybrid >> For now I just disabled it. >> >> - libxl has changed a lot, so for now, I''m only supporting >> disk = [''phy:/dev/loop1,xvda,w''] >> >> - the struct pv_vcpu and hvm_vcpu are into a union now. I added a new >> type hyb_vcpu and now going thru the code changing all refs. >> >> - on the linux side I managed to remove all changes to non-xen files, >> this should help a alot. >> >> Once I finish the changes for hyb_vcpu union, I should be able to get >> things working again. Then I''ll refresh the linux tree, keeping xen the >> same, and test it all out and submit linux patch. After that I''ll >> refresh xen tree and keeping same linux, test it out, and submit patch. >> >> Thanks, >> Mukesh >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote:> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: > >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > >> for this feature, mainly for "marketing" reasons. I think it will > >> probably give people the wrong idea about what the technology does. > >> PV domains is one of Xen''s really distinct advantages -- much simpler > >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I > >> understand it, the mode you''ve been calling "hybrid" still has all of > >> these advantages -- it just uses some of the HVM hardware extensions > >> to make the interface even simpler / faster. I''m afraid "hybrid" may > >> be seen as, "Even Xen has had to give up on PV." > >> > >> Can I suggest something like "PVH" instead? That (at least to me) > >> makes it clear that PV domains are still fully PV, but just use some > >> HVM extensions. > > > > if (xen_pvh_domain()? > > > > if (xen_pv_h_domain()? > > > > if (xen_h_domain()) ? > > > > if (xen_pvplus_domain()) ? > > > > if (xen_pv_ext_domain()) ? > > > > I think I like ''pv+''? > > I could deal with pv+. However, in general I dislike that kind of > "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX > (Extreme PV!) -- they all sound cool when they come out, but five > years later, when they''re not so new or sexy anymore, they all sound > lame. PVH is just descriptive -- it will always be PV with HVM > extensions, so it will age much better. :-)How about pv_with_mmu_in_hvm_container_domain() ? Ok, that is a bit to lengthy. How about then: if (xen_pvhvm_ext_domain()) ? The ''if (xen_pvh_domain())'' is just one characer short of ''xen_pv_domain()'' and one might not notice it. Perhaps then ''if (xen_pv_h_domain()'' ?> > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 01/08/12 16:59, George Dunlap wrote:> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: >> On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: >>> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name >>> for this feature, mainly for "marketing" reasons. I think it will >>> probably give people the wrong idea about what the technology does. >>> PV domains is one of Xen''s really distinct advantages -- much simpler >>> interface, lighter-weight (no qemu, legacy boot), &c &c. As I >>> understand it, the mode you''ve been calling "hybrid" still has all of >>> these advantages -- it just uses some of the HVM hardware extensions >>> to make the interface even simpler / faster. I''m afraid "hybrid" may >>> be seen as, "Even Xen has had to give up on PV." >>> >>> Can I suggest something like "PVH" instead? That (at least to me) >>> makes it clear that PV domains are still fully PV, but just use some >>> HVM extensions. >> if (xen_pvh_domain()? >> >> if (xen_pv_h_domain()? >> >> if (xen_h_domain()) ? >> >> if (xen_pvplus_domain()) ? >> >> if (xen_pv_ext_domain()) ? >> >> I think I like ''pv+''? > I could deal with pv+. However, in general I dislike that kind of > "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX > (Extreme PV!) -- they all sound cool when they come out, but five > years later, when they''re not so new or sexy anymore, they all sound > lame. PVH is just descriptive -- it will always be PV with HVM > extensions, so it will age much better. :-) > > -GeorgeSee for perfect example USB LowSpeed, FullSpeed, HiSpeed and now SuperSpeed ~Andrew> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On Wed, 2012-08-01 at 16:59 +0100, George Dunlap wrote:> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk > > I think I like ''pv+''? > > I could deal with pv+.+ is a bad idea because it is not valid in a C identifier name (or indeed most languages), which means you actually need to call it something else in the code. Plus (no pun intended) the reasons George mentions.
On Wed, Aug 1, 2012 at 5:05 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote: >> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: >> >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name >> >> for this feature, mainly for "marketing" reasons. I think it will >> >> probably give people the wrong idea about what the technology does. >> >> PV domains is one of Xen''s really distinct advantages -- much simpler >> >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I >> >> understand it, the mode you''ve been calling "hybrid" still has all of >> >> these advantages -- it just uses some of the HVM hardware extensions >> >> to make the interface even simpler / faster. I''m afraid "hybrid" may >> >> be seen as, "Even Xen has had to give up on PV." >> >> >> >> Can I suggest something like "PVH" instead? That (at least to me) >> >> makes it clear that PV domains are still fully PV, but just use some >> >> HVM extensions. >> > >> > if (xen_pvh_domain()? >> > >> > if (xen_pv_h_domain()? >> > >> > if (xen_h_domain()) ? >> > >> > if (xen_pvplus_domain()) ? >> > >> > if (xen_pv_ext_domain()) ? >> > >> > I think I like ''pv+''? >> >> I could deal with pv+. However, in general I dislike that kind of >> "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX >> (Extreme PV!) -- they all sound cool when they come out, but five >> years later, when they''re not so new or sexy anymore, they all sound >> lame. PVH is just descriptive -- it will always be PV with HVM >> extensions, so it will age much better. :-) > > How about pv_with_mmu_in_hvm_container_domain() ? > > Ok, that is a bit to lengthy. How about then: > > if (xen_pvhvm_ext_domain()) ? > > The ''if (xen_pvh_domain())'' is just one characer short of ''xen_pv_domain()'' > and one might not notice it. Perhaps then ''if (xen_pv_h_domain()'' ?Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" has already been sort of taken by Stefano''s extensions to allow Linux kernels booted in HVM mode to use some of the PV extensions. I tend to think "xen_pvh_domain()" is probably OK, but maybe calling it "pvext" (or "pvhext") in the code, and "PVH" in documentation / stories? Just using "pvext" everywhere could work as well; it''s a little bit "now even better!", but not as much as pvplus. -George
Wednesday, August 1, 2012, 6:21:57 PM, you wrote:> On Wed, Aug 1, 2012 at 5:05 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: >> On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote: >>> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk >>> <konrad.wilk@oracle.com> wrote: >>> > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: >>> >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name >>> >> for this feature, mainly for "marketing" reasons. I think it will >>> >> probably give people the wrong idea about what the technology does. >>> >> PV domains is one of Xen''s really distinct advantages -- much simpler >>> >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I >>> >> understand it, the mode you''ve been calling "hybrid" still has all of >>> >> these advantages -- it just uses some of the HVM hardware extensions >>> >> to make the interface even simpler / faster. I''m afraid "hybrid" may >>> >> be seen as, "Even Xen has had to give up on PV." >>> >> >>> >> Can I suggest something like "PVH" instead? That (at least to me) >>> >> makes it clear that PV domains are still fully PV, but just use some >>> >> HVM extensions. >>> > >>> > if (xen_pvh_domain()? >>> > >>> > if (xen_pv_h_domain()? >>> > >>> > if (xen_h_domain()) ? >>> > >>> > if (xen_pvplus_domain()) ? >>> > >>> > if (xen_pv_ext_domain()) ? >>> > >>> > I think I like ''pv+''? >>> >>> I could deal with pv+. However, in general I dislike that kind of >>> "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX >>> (Extreme PV!) -- they all sound cool when they come out, but five >>> years later, when they''re not so new or sexy anymore, they all sound >>> lame. PVH is just descriptive -- it will always be PV with HVM >>> extensions, so it will age much better. :-) >> >> How about pv_with_mmu_in_hvm_container_domain() ? >> >> Ok, that is a bit to lengthy. How about then: >> >> if (xen_pvhvm_ext_domain()) ? >> >> The ''if (xen_pvh_domain())'' is just one characer short of ''xen_pv_domain()'' >> and one might not notice it. Perhaps then ''if (xen_pv_h_domain()'' ?> Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" has > already been sort of taken by Stefano''s extensions to allow Linux > kernels booted in HVM mode to use some of the PV extensions. I tend > to think "xen_pvh_domain()" is probably OK, but maybe calling it > "pvext" (or "pvhext") in the code, and "PVH" in documentation / > stories? Just using "pvext" everywhere could work as well; it''s a > little bit "now even better!", but not as much as pvplus.Am i mistaken in saying that both "Hyrbid" and "PVHVM" are both targeting the same, but approaching it from a different base / direction (PV + HVM extensions versus HVM + PV extensions) ? If that''s the case, how far are these apart from meeting each other in the middle, and what would be the fundamental difference ? It seems to be the full qemu container / emulated driver model availability on HVM + PV extensions ? Just wondering if the naming should express that most explicit and fundamental difference (if there is one :-) ) ?> -George
On Wed, Aug 01, 2012 at 09:21:57AM -0700, George Dunlap wrote:> On Wed, Aug 1, 2012 at 5:05 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote: > >> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk > >> <konrad.wilk@oracle.com> wrote: > >> > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: > >> >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > >> >> for this feature, mainly for "marketing" reasons. I think it will > >> >> probably give people the wrong idea about what the technology does. > >> >> PV domains is one of Xen''s really distinct advantages -- much simpler > >> >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I > >> >> understand it, the mode you''ve been calling "hybrid" still has all of > >> >> these advantages -- it just uses some of the HVM hardware extensions > >> >> to make the interface even simpler / faster. I''m afraid "hybrid" may > >> >> be seen as, "Even Xen has had to give up on PV." > >> >> > >> >> Can I suggest something like "PVH" instead? That (at least to me) > >> >> makes it clear that PV domains are still fully PV, but just use some > >> >> HVM extensions. > >> > > >> > if (xen_pvh_domain()? > >> > > >> > if (xen_pv_h_domain()? > >> > > >> > if (xen_h_domain()) ? > >> > > >> > if (xen_pvplus_domain()) ? > >> > > >> > if (xen_pv_ext_domain()) ? > >> > > >> > I think I like ''pv+''? > >> > >> I could deal with pv+. However, in general I dislike that kind of > >> "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX > >> (Extreme PV!) -- they all sound cool when they come out, but five > >> years later, when they''re not so new or sexy anymore, they all sound > >> lame. PVH is just descriptive -- it will always be PV with HVM > >> extensions, so it will age much better. :-) > > > > How about pv_with_mmu_in_hvm_container_domain() ? > > > > Ok, that is a bit to lengthy. How about then: > > > > if (xen_pvhvm_ext_domain()) ? > > > > The ''if (xen_pvh_domain())'' is just one characer short of ''xen_pv_domain()'' > > and one might not notice it. Perhaps then ''if (xen_pv_h_domain()'' ? > > Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" has > already been sort of taken by Stefano''s extensions to allow Linux > kernels booted in HVM mode to use some of the PV extensions. I tend > to think "xen_pvh_domain()" is probably OK, but maybe calling it > "pvext" (or "pvhext") in the code, and "PVH" in documentation / > stories? Just using "pvext" everywhere could work as well; it''s a > little bit "now even better!", but not as much as pvplus.How about HAPV, for "Hardware Assisted Paravirtualization"? It''s nicely pronounceable as "hap-vee" and follows the general "hardware-assisted paging" (HAP) Xen terminology that spans both Intel EPT and AMD RVI. ''if (xen_hapv_domain())'' Matt
On Wed, Aug 01, 2012 at 06:51:56PM +0200, Sander Eikelenboom wrote:> Wednesday, August 1, 2012, 6:21:57 PM, you wrote: > > > On Wed, Aug 1, 2012 at 5:05 PM, Konrad Rzeszutek Wilk > > <konrad.wilk@oracle.com> wrote: > >> On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote: > >>> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk > >>> <konrad.wilk@oracle.com> wrote: > >>> > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote: > >>> >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > >>> >> for this feature, mainly for "marketing" reasons. I think it will > >>> >> probably give people the wrong idea about what the technology does. > >>> >> PV domains is one of Xen''s really distinct advantages -- much simpler > >>> >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I > >>> >> understand it, the mode you''ve been calling "hybrid" still has all of > >>> >> these advantages -- it just uses some of the HVM hardware extensions > >>> >> to make the interface even simpler / faster. I''m afraid "hybrid" may > >>> >> be seen as, "Even Xen has had to give up on PV." > >>> >> > >>> >> Can I suggest something like "PVH" instead? That (at least to me) > >>> >> makes it clear that PV domains are still fully PV, but just use some > >>> >> HVM extensions. > >>> > > >>> > if (xen_pvh_domain()? > >>> > > >>> > if (xen_pv_h_domain()? > >>> > > >>> > if (xen_h_domain()) ? > >>> > > >>> > if (xen_pvplus_domain()) ? > >>> > > >>> > if (xen_pv_ext_domain()) ? > >>> > > >>> > I think I like ''pv+''? > >>> > >>> I could deal with pv+. However, in general I dislike that kind of > >>> "now even better!" marketing. PV+, EPV (Enhanced / extended PV), PVX > >>> (Extreme PV!) -- they all sound cool when they come out, but five > >>> years later, when they''re not so new or sexy anymore, they all sound > >>> lame. PVH is just descriptive -- it will always be PV with HVM > >>> extensions, so it will age much better. :-) > >> > >> How about pv_with_mmu_in_hvm_container_domain() ? > >> > >> Ok, that is a bit to lengthy. How about then: > >> > >> if (xen_pvhvm_ext_domain()) ? > >> > >> The ''if (xen_pvh_domain())'' is just one characer short of ''xen_pv_domain()'' > >> and one might not notice it. Perhaps then ''if (xen_pv_h_domain()'' ? > > > Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" has > > already been sort of taken by Stefano''s extensions to allow Linux > > kernels booted in HVM mode to use some of the PV extensions. I tend > > to think "xen_pvh_domain()" is probably OK, but maybe calling it > > "pvext" (or "pvhext") in the code, and "PVH" in documentation / > > stories? Just using "pvext" everywhere could work as well; it''s a > > little bit "now even better!", but not as much as pvplus. > > Am i mistaken in saying that both "Hyrbid" and "PVHVM" are both targeting the same, but approaching it from a different base / direction (PV + HVM extensions versus HVM + PV extensions) ?Pretty much. HVM is QEMU with emulated devices and then ditching most of them and turning on PV for everything you can. PV ext is starting with PV and using the SVM/VMX container (so no QEMU) to deal with the memory management. The PV functionality is still present except that MMU operations and syscalls'' don''t go through the hypervisor anymore.> If that''s the case, how far are these apart from meeting each other in the middle, and what would be the fundamental difference ?At the end of the day they are pretty similar .. a PVHVM guest tries to use the least amount of QEMU functionality and use PV drivers. For MMU and such it uses VMX/SVM container. The PV ext would be using no QEMU but using VMX/SVM container.> It seems to be the full qemu container / emulated driver model availability on HVM + PV extensions ?Sure, that is the big difference - PVHVM needs QEMU to bootup at least.> > Just wondering if the naming should express that most explicit and fundamental difference (if there is one :-) ) ?"if (xen_fat_domain())'' (so QEMU) and ''if (xen_slim__domain())'' (no QEMU)?
On Wed, 1 Aug 2012 16:25:01 +0100 George Dunlap <George.Dunlap@eu.citrix.com> wrote:> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > for this feature, mainly for "marketing" reasons. I think it will > probably give people the wrong idea about what the technology does. > PV domains is one of Xen''s really distinct advantages -- much simpler > interface, lighter-weight (no qemu, legacy boot), &c &c. As I > understand it, the mode you''ve been calling "hybrid" still has all of > these advantages -- it just uses some of the HVM hardware extensions > to make the interface even simpler / faster. I''m afraid "hybrid" may > be seen as, "Even Xen has had to give up on PV." > > Can I suggest something like "PVH" instead? That (at least to me) > makes it clear that PV domains are still fully PV, but just use some > HVM extensions. > > Thoughts?Hi George, We gave some thought looking for name. I figured pure PV will be around for a while at least. So there''s PV on one side and HVM on the other, hybrid somewhere in between. The issue with PV in HVM is that it limits PV to HVM container only. The vision I had was that hybrid, a PV ops kernel that is somewhere in between PV and HVM, could be configured with options. So, one could run hybrid with say EPT off (altho, won''t be supported this anymore). But generic name like hybrid allows it in future to be flexible, instead of confined to a specific. I suppose a PV guest could just be started with various options. As for name in code, ''pvh'' was confusing, as PVHVM is now routinely used to refer to HVM with PV drivers. ''hpv'' for HVM/hybrid PV, well, thats a certain virus ;). So I just used hybrid in the code to refer to PV guest that runs in HVM container. I suppose I could change the flag to pv_in_hvm or something. In the end, I am flexible on whatever we wanna call it :). thanks, Mukesh
On 01/08/12 23:34, Mukesh Rathor wrote:> On Wed, 1 Aug 2012 16:25:01 +0100 > George Dunlap <George.Dunlap@eu.citrix.com> wrote: > >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name >> for this feature, mainly for "marketing" reasons. I think it will >> probably give people the wrong idea about what the technology does. >> PV domains is one of Xen''s really distinct advantages -- much simpler >> interface, lighter-weight (no qemu, legacy boot), &c &c. As I >> understand it, the mode you''ve been calling "hybrid" still has all of >> these advantages -- it just uses some of the HVM hardware extensions >> to make the interface even simpler / faster. I''m afraid "hybrid" may >> be seen as, "Even Xen has had to give up on PV." >> >> Can I suggest something like "PVH" instead? That (at least to me) >> makes it clear that PV domains are still fully PV, but just use some >> HVM extensions. >> >> Thoughts? > Hi George, > > We gave some thought looking for name. I figured pure PV will be around for > a while at least. So there''s PV on one side and HVM on the other, hybrid > somewhere in between.I understand the idea, but I think it''s not very accurate. I would call Stefano''s "PVHVM" stuff hybrid -- it has the legacy boot and emulated devices, but uses the PV interfaces for event delivery extensively. The mode you''re working on is too far towards the "PV" side to be called "hybrid". (And as we''ve seen, the term has already confused people, who interpreted it as basically PVHVM.)> > The issue with PV in HVM is that it limits PV to HVM container only. The > vision I had was that hybrid, a PV ops kernel that is somewhere in between > PV and HVM, could be configured with options. So, one could run hybrid > with say EPT off (altho, won''t be supported this anymore). But generic name > like hybrid allows it in future to be flexible, instead of confined to a > specific. I suppose a PV guest could just be started with various options.In general, I think "PV" should mean, "Doesn''t use legacy boot, doesn''t need emulated devices". So I don''t think "PVH" places any limitations on what particular subset of HVM hardware you use. For things that specifically depend on knowing whether guest PTs are using mfns or gpfns, I think we should have checks for specific things -- for instance, "xen_mm_translate()" or something like that. Also, don''t confuse EPT (which is Intel-specific) with HAP (which is the generic term for either EPT or RVI); and don''t confuse either of those with what is called "translate" mode. Translate mode (where Xen translates the guest PTs from gpfns to mfns) can be done either with HAP or with shadow; and given the performance issues HAP has with certain workloads, we need to make sure that the HVM container mode can use both.> As for name in code, ''pvh'' was confusing, as PVHVM is now routinely used to > refer to HVM with PV drivers. ''hpv'' for HVM/hybrid PV, well, thats a certain > virus ;). So I just used hybrid in the code to refer to PV guest that runs > in HVM container. I suppose I could change the flag to pv_in_hvm or > something.But is "pvhvm" ever actually used in the code? If not, it''s not a problem. Actually, perhaps it would be better in any case, rather than having checks for "pvh" mode, to have checks for specific things -- e.g., is translation on or off (i.e., are running in classic PV mode, or with HAP)? I''m not sure the other things you''re doing with HVM, but it should be possible to come up with a descriptive name to use in the code for those options, rather than limiting to a specific mode. In ancient days, there used to be options, both within Xen and within the classic Xen kernel, to run a PV guest in fully-translated mode (i.e., the guest PTs contained gpfns, not mfns), and "shadow_translate" was a mode used across guest types (both PV and HVM) to determine whether this was the case or not. -George
George Dunlap
2012-Aug-02 11:41 UTC
Re: HYBRID naming [Was: Re: [HYBRID]: status update...]
On 01/08/12 17:53, Matt Wilson wrote:> On Wed, Aug 01, 2012 at 09:21:57AM -0700, George Dunlap wrote: >> Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" has >> already been sort of taken by Stefano''s extensions to allow Linux >> kernels booted in HVM mode to use some of the PV extensions. I tend >> to think "xen_pvh_domain()" is probably OK, but maybe calling it >> "pvext" (or "pvhext") in the code, and "PVH" in documentation / >> stories? Just using "pvext" everywhere could work as well; it''s a >> little bit "now even better!", but not as much as pvplus. > How about HAPV, for "Hardware Assisted Paravirtualization"? It''s > nicely pronounceable as "hap-vee" and follows the general > "hardware-assisted paging" (HAP) Xen terminology that spans both Intel > EPT and AMD RVI. ''if (xen_hapv_domain())''Wouldn''t "HAPV" make people think more of HAP than of PV? It seems like it would be much more confusing to distinguish "hapv" from "hap" than "pvh" from "pv". :-) -George
On Thu, Aug 02, 2012 at 10:53:16AM +0100, George Dunlap wrote:> On 01/08/12 23:34, Mukesh Rathor wrote: > >On Wed, 1 Aug 2012 16:25:01 +0100 > >George Dunlap <George.Dunlap@eu.citrix.com> wrote: > > > >>I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > >>for this feature, mainly for "marketing" reasons. I think it will > >>probably give people the wrong idea about what the technology does. > >>PV domains is one of Xen''s really distinct advantages -- much simpler > >>interface, lighter-weight (no qemu, legacy boot), &c &c. As I > >>understand it, the mode you''ve been calling "hybrid" still has all of > >>these advantages -- it just uses some of the HVM hardware extensions > >>to make the interface even simpler / faster. I''m afraid "hybrid" may > >>be seen as, "Even Xen has had to give up on PV." > >> > >>Can I suggest something like "PVH" instead? That (at least to me) > >>makes it clear that PV domains are still fully PV, but just use some > >>HVM extensions. > >> > >>Thoughts? > >Hi George, > > > >We gave some thought looking for name. I figured pure PV will be around for > >a while at least. So there''s PV on one side and HVM on the other, hybrid > >somewhere in between. > I understand the idea, but I think it''s not very accurate. I would > call Stefano''s "PVHVM" stuff hybrid -- it has the legacy boot and > emulated devices, but uses the PV interfaces for event delivery > extensively. The mode you''re working on is too far towards the "PV" > side to be called "hybrid". (And as we''ve seen, the term has > already confused people, who interpreted it as basically PVHVM.) > > > >The issue with PV in HVM is that it limits PV to HVM container only. The > >vision I had was that hybrid, a PV ops kernel that is somewhere in between > >PV and HVM, could be configured with options. So, one could run hybrid > >with say EPT off (altho, won''t be supported this anymore). But generic name > >like hybrid allows it in future to be flexible, instead of confined to a > >specific. I suppose a PV guest could just be started with various options. > In general, I think "PV" should mean, "Doesn''t use legacy boot, > doesn''t need emulated devices". So I don''t think "PVH" places any > limitations on what particular subset of HVM hardware you use. For > things that specifically depend on knowing whether guest PTs are > using mfns or gpfns, I think we should have checks for specific > things -- for instance, "xen_mm_translate()" or something like that.I like that.. We currently have ''if (feature(AUTOTRANSLATE)'' .. blah blah sprinkled around. If we altered it to be ''if (xen_mm_translate())'' and replaced a bunch of ''if (xen_pv_domain())'' with that it should make it easier. It might even make the ''xen_hybrid_domain()'' not needed at all. This is good - it would also allow to remove some of the ''xen_hvm_domain()'' with it.> > Also, don''t confuse EPT (which is Intel-specific) with HAP (which is > the generic term for either EPT or RVI); and don''t confuse either of > those with what is called "translate" mode. Translate mode (where > Xen translates the guest PTs from gpfns to mfns) can be done either > with HAP or with shadow; and given the performance issues HAP has > with certain workloads, we need to make sure that the HVM container > mode can use both. > > >As for name in code, ''pvh'' was confusing, as PVHVM is now routinely used to > >refer to HVM with PV drivers. ''hpv'' for HVM/hybrid PV, well, thats a certain > >virus ;). So I just used hybrid in the code to refer to PV guest that runs > >in HVM container. I suppose I could change the flag to pv_in_hvm or > >something. > But is "pvhvm" ever actually used in the code? If not, it''s not a problem. > > Actually, perhaps it would be better in any case, rather than having > checks for "pvh" mode, to have checks for specific things -- e.g., > is translation on or off (i.e., are running in classic PV mode, or > with HAP)? I''m not sure the other things you''re doing with HVM, but > it should be possible to come up with a descriptive name to use in > the code for those options, rather than limiting to a specific mode. > > In ancient days, there used to be options, both within Xen and > within the classic Xen kernel, to run a PV guest in fully-translated > mode (i.e., the guest PTs contained gpfns, not mfns), and > "shadow_translate" was a mode used across guest types (both PV and > HVM) to determine whether this was the case or not.dom0_shadow=true .. And strangly enought it looks to actually boot the pvops kernel (dom0) without much issues. Wow. It must be faking it I think - no bugs??!
Pasi Kärkkäinen
2012-Aug-04 01:06 UTC
Re: HYBRID naming [Was: Re: [HYBRID]: status update...]
On Thu, Aug 02, 2012 at 12:41:19PM +0100, George Dunlap wrote:> On 01/08/12 17:53, Matt Wilson wrote: > >On Wed, Aug 01, 2012 at 09:21:57AM -0700, George Dunlap wrote: > >>Hmm -- that''s an interesting issue I hadn''t thought of. "PVHVM" > >>has already been sort of taken by Stefano''s extensions to allow > >>Linux kernels booted in HVM mode to use some of the PV > >>extensions. I tend to think "xen_pvh_domain()" is probably OK, > >>but maybe calling it "pvext" (or "pvhext") in the code, and > >>"PVH" in documentation / stories? Just using "pvext" everywhere > >>could work as well; it''s a little bit "now even better!", but > >>not as much as pvplus. > >How about HAPV, for "Hardware Assisted Paravirtualization"? It''s > >nicely pronounceable as "hap-vee" and follows the general > >"hardware-assisted paging" (HAP) Xen terminology that spans both Intel > >EPT and AMD RVI. ''if (xen_hapv_domain())'' > Wouldn''t "HAPV" make people think more of HAP than of PV? It seems > like it would be much more confusing to distinguish "hapv" from > "hap" than "pvh" from "pv". :-) >HAPV sounds like Highly Available PV.. not very good :) -- Pasi
On Thu, 2 Aug 2012 10:53:16 +0100 George Dunlap <george.dunlap@eu.citrix.com> wrote:> On 01/08/12 23:34, Mukesh Rathor wrote: > > On Wed, 1 Aug 2012 16:25:01 +0100 > > George Dunlap <George.Dunlap@eu.citrix.com> wrote: > > > >> I hope this isn''t bikeshedding; but I don''t like "Hybrid" as a name > >> for this feature, mainly for "marketing" reasons. I think it will > >> probably give people the wrong idea about what the technology does. > >> PV domains is one of Xen''s really distinct advantages -- much > >> simpler interface, lighter-weight (no qemu, legacy boot), &c &c. > >> As I understand it, the mode you''ve been calling "hybrid" still > >> has all of these advantages -- it just uses some of the HVM > >> hardware extensions to make the interface even simpler / faster. > >> I''m afraid "hybrid" may be seen as, "Even Xen has had to give up > >> on PV." > >> > >> Can I suggest something like "PVH" instead? That (at least to me) > >> makes it clear that PV domains are still fully PV, but just use > >> some HVM extensions. > >> > >> Thoughts? > > Hi George, > > > > We gave some thought looking for name. I figured pure PV will be > > around for a while at least. So there''s PV on one side and HVM on > > the other, hybrid somewhere in between. > I understand the idea, but I think it''s not very accurate. I would > call Stefano''s "PVHVM" stuff hybrid -- it has the legacy boot and > emulated devices, but uses the PV interfaces for event delivery > extensively. The mode you''re working on is too far towards the "PV" > side to be called "hybrid". (And as we''ve seen, the term has already > confused people, who interpreted it as basically PVHVM.) > > > > The issue with PV in HVM is that it limits PV to HVM container > > only. The vision I had was that hybrid, a PV ops kernel that is > > somewhere in between PV and HVM, could be configured with options. > > So, one could run hybrid with say EPT off (altho, won''t be > > supported this anymore). But generic name like hybrid allows it in > > future to be flexible, instead of confined to a specific. I suppose > > a PV guest could just be started with various options. > In general, I think "PV" should mean, "Doesn''t use legacy boot, > doesn''t need emulated devices". So I don''t think "PVH" places any > limitations on what particular subset of HVM hardware you use. For > things that specifically depend on knowing whether guest PTs are > using mfns or gpfns, I think we should have checks for specific > things -- for instance, "xen_mm_translate()" or something like that. > > Also, don''t confuse EPT (which is Intel-specific) with HAP (which is > the generic term for either EPT or RVI); and don''t confuse either of > those with what is called "translate" mode. Translate mode (where > Xen translates the guest PTs from gpfns to mfns) can be done either > with HAP or with shadow; and given the performance issues HAP has > with certain workloads, we need to make sure that the HVM container > mode can use both. > > > As for name in code, ''pvh'' was confusing, as PVHVM is now routinely > > used to refer to HVM with PV drivers. ''hpv'' for HVM/hybrid PV, > > well, thats a certain virus ;). So I just used hybrid in the code > > to refer to PV guest that runs in HVM container. I suppose I could > > change the flag to pv_in_hvm or something. > But is "pvhvm" ever actually used in the code? If not, it''s not a > problem. > > Actually, perhaps it would be better in any case, rather than having > checks for "pvh" mode, to have checks for specific things -- e.g., is > translation on or off (i.e., are running in classic PV mode, or with > HAP)? I''m not sure the other things you''re doing with HVM, but it > should be possible to come up with a descriptive name to use in the > code for those options, rather than limiting to a specific mode. > > In ancient days, there used to be options, both within Xen and within > the classic Xen kernel, to run a PV guest in fully-translated mode > (i.e., the guest PTs contained gpfns, not mfns), and > "shadow_translate" was a mode used across guest types (both PV and > HVM) to determine whether this was the case or not. > > -GeorgeOk, I changed all code references from xen_hybrid_domain to xen_pvh_domain in linux. Changing xen code too. So it''s PVH now. thanks, Mukesh
On Mon, 13 Aug 2012, Mukesh Rathor wrote:> Ok, I changed all code references from xen_hybrid_domain to xen_pvh_domain > in linux. Changing xen code too. So it''s PVH now.What would xen_pv_domain() and xen_hvm_domain() return in an hybrid guest?
On Tue, 14 Aug 2012 11:44:44 +0100 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:> On Mon, 13 Aug 2012, Mukesh Rathor wrote: > > Ok, I changed all code references from xen_hybrid_domain to > > xen_pvh_domain in linux. Changing xen code too. So it''s PVH now. > > What would xen_pv_domain() and xen_hvm_domain() return in an hybrid > guest?xen_pv_domain() == TRUE xen_hvm_domain() == FALSE
On Tue, 14 Aug 2012, Mukesh Rathor wrote:> On Tue, 14 Aug 2012 11:44:44 +0100 > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > > > On Mon, 13 Aug 2012, Mukesh Rathor wrote: > > > Ok, I changed all code references from xen_hybrid_domain to > > > xen_pvh_domain in linux. Changing xen code too. So it''s PVH now. > > > > What would xen_pv_domain() and xen_hvm_domain() return in an hybrid > > guest? > > xen_pv_domain() == TRUE > xen_hvm_domain() == FALSE >good, just as I expected :)
On Tue, 14 Aug 2012 18:42:54 +0100 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:> On Tue, 14 Aug 2012, Mukesh Rathor wrote: > > On Tue, 14 Aug 2012 11:44:44 +0100 > > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > > > > > On Mon, 13 Aug 2012, Mukesh Rathor wrote: > > > > Ok, I changed all code references from xen_hybrid_domain to > > > > xen_pvh_domain in linux. Changing xen code too. So it''s PVH now. > > > > > > What would xen_pv_domain() and xen_hvm_domain() return in an > > > hybrid guest? > > > > xen_pv_domain() == TRUE > > xen_hvm_domain() == FALSE > > > > good, just as I expected :)BTW, being a good hybrid as it is, it uses fields from both pv_domain and hvm_domain structs. Combining into a union created difficulties for me. I experimented creating a new struct, hyb_domain, or adding hvm related fields to pv_domain struct for hybrid, but both involved way too much code change. So back to having them separated again. LMK if there any objections undoing the union. thanks, Mukesh
>>> On 14.08.12 at 19:51, Mukesh Rathor <mukesh.rathor@oracle.com> wrote: > BTW, being a good hybrid as it is, it uses fields from both pv_domain > and hvm_domain structs. Combining into a union created difficulties for > me. I experimented creating a new struct, hyb_domain, or adding hvm > related fields to pv_domain struct for hybrid, but both involved way too > much code change. So back to having them separated again. LMK if there > any objections undoing the union.I suppose there are going to be fields that are used exclusively for PV or HVM, and if so I''d like them to be retained as a union as far as possible. The main point of the change was to shrink the size of struct vcpu (which is required to fit into a page, which you will need to make sure continues to be the case even with all sorts of debugging options turned on). Jan
On Wed, 2012-08-15 at 09:19 +0100, Jan Beulich wrote:> >>> On 14.08.12 at 19:51, Mukesh Rathor <mukesh.rathor@oracle.com> wrote: > > BTW, being a good hybrid as it is, it uses fields from both pv_domain > > and hvm_domain structs. Combining into a union created difficulties for > > me. I experimented creating a new struct, hyb_domain, or adding hvm > > related fields to pv_domain struct for hybrid, but both involved way too > > much code change. So back to having them separated again. LMK if there > > any objections undoing the union. > > I suppose there are going to be fields that are used exclusively > for PV or HVM, and if so I''d like them to be retained as a union > as far as possible.I guess there will be some subset of fields which will be specific to the use of VT-d/SVM generally but not specifically to the emulation of a full PC ("HVM") or hybrid mode. I don''t know what proportion that would be but it might be worth splitting along those lines, e.g. pull HW state out into its own sub-struct and have a union of the true pv-, hvm- and pvh-only fields?> The main point of the change was to shrink > the size of struct vcpu (which is required to fit into a page, > which you will need to make sure continues to be the case even > with all sorts of debugging options turned on). > > Jan >
>>> On 15.08.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-08-15 at 09:19 +0100, Jan Beulich wrote: >> >>> On 14.08.12 at 19:51, Mukesh Rathor <mukesh.rathor@oracle.com> wrote: >> > BTW, being a good hybrid as it is, it uses fields from both pv_domain >> > and hvm_domain structs. Combining into a union created difficulties for >> > me. I experimented creating a new struct, hyb_domain, or adding hvm >> > related fields to pv_domain struct for hybrid, but both involved way too >> > much code change. So back to having them separated again. LMK if there >> > any objections undoing the union. >> >> I suppose there are going to be fields that are used exclusively >> for PV or HVM, and if so I''d like them to be retained as a union >> as far as possible. > > I guess there will be some subset of fields which will be specific to > the use of VT-d/SVM generally but not specifically to the emulation of a > full PC ("HVM") or hybrid mode. I don''t know what proportion that would > be but it might be worth splitting along those lines, e.g. pull HW state > out into its own sub-struct and have a union of the true pv-, hvm- and > pvh-only fields?Yes. Jan