[HYBRID] : status update...

[HYBRID] : status update...

[Mukesh Rathor]

Hi Guys,


Cheers.... JFYI... I've all combinations working now, for both UP and
MP.

Normal PV dom0: PV domU, Hyb domU, HVM domU
Hybrid dom0: PV domU, Hyb domU, HVM domU.

So, next now:
   - refresh my linux and xen trees to latest. i'm on xen 4.1.3.
   - make sure everything works with latest, and without tons of debug
     code i've there right now ;).
   - test it out a bit.
   - submit patch.
   - once patch is accepted, do more benchmarks and improvements over
     time.

thanks,
Mukesh

Re: [HYBRID] : status update...

[Konrad Rzeszutek Wilk]

On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote:
> Hi Guys,
> 
> 
> Cheers.... JFYI... I've all combinations working now, for both UP and
> MP.

YEEEY!
> 
> Normal PV dom0: PV domU, Hyb domU, HVM domU
> Hybrid dom0: PV domU, Hyb domU, HVM domU.
> 
> So, next now:
>    - refresh my linux and xen trees to latest. i'm on xen 4.1.3.
>    - make sure everything works with latest, and without tons of debug
>      code i've there right now ;).
>    - test it out a bit.
>    - submit patch.
>    - once patch is accepted, do more benchmarks and improvements over
>      time.
> 
> thanks,
> Mukesh
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [HYBRID] : status update...

[Pasi Kärkkäinen]

On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote:
> Hi Guys,
> 
> 
> Cheers.... JFYI... I've all combinations working now, for both UP and
> MP.
> 
> Normal PV dom0: PV domU, Hyb domU, HVM domU
> Hybrid dom0: PV domU, Hyb domU, HVM domU.
> 
> So, next now:
>    - refresh my linux and xen trees to latest. i'm on xen 4.1.3.
>    - make sure everything works with latest, and without tons of debug
>      code i've there right now ;).
>    - test it out a bit.
>    - submit patch.
>    - once patch is accepted, do more benchmarks and improvements over
>      time.
> 

Great! Looking forward to testing the patch :)

Thank you a lot for your hard work!

-- Pasi

Re: [HYBRID] : status update...

[Ian Campbell]

On Fri, 2012-05-11 at 02:40 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote:
> > Hi Guys,
> > 
> > 
> > Cheers.... JFYI... I've all combinations working now, for both UP and
> > MP.
> 
> YEEEY!

What he said!

> > 
> > Normal PV dom0: PV domU, Hyb domU, HVM domU
> > Hybrid dom0: PV domU, Hyb domU, HVM domU.
> > 
> > So, next now:
> >    - refresh my linux and xen trees to latest. i'm on xen 4.1.3.
> >    - make sure everything works with latest, and without tons of debug
> >      code i've there right now ;).
> >    - test it out a bit.
> >    - submit patch.
> >    - once patch is accepted, do more benchmarks and improvements over
> >      time.
> > 
> > thanks,
> > Mukesh
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

[HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Ian Campbell]

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.

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Stefano Stabellini]

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.

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Stefano Stabellini]

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)

Re: [HYBRID]: status update...

[George Dunlap]

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

Re: [HYBRID]: status update...

[Konrad Rzeszutek Wilk]

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

Re: [HYBRID]: status update...

[George Dunlap]

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

Re: [HYBRID]: status update...

[Sander Eikelenboom]

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

Re: [HYBRID]: status update...

[Konrad Rzeszutek Wilk]

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

Re: [HYBRID]: status update...

[Andrew Cooper]

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. :-)
>
>  -George

See 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

Re: [HYBRID]: status update...

[Ian Campbell]

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.

Re: [HYBRID]: status update...

[George Dunlap]

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

Re: [HYBRID]: status update...

[Sander Eikelenboom]

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

HYBRID naming [Was: Re: [HYBRID]: status update...]

[Matt Wilson]

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

Re: [HYBRID]: status update...

[Konrad Rzeszutek Wilk]

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)?

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[George Dunlap]

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

Re: HYBRID naming [Was: Re: [HYBRID]: status update...]

[George Dunlap]

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

Re: [HYBRID]: status update...

[Konrad Rzeszutek Wilk]

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??!

Re: HYBRID naming [Was: Re: [HYBRID]: status update...]

[Pasi Kärkkäinen]

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

Re: [HYBRID]: status update...

[Mukesh Rathor]

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.
> 
>   -George



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.

thanks,
Mukesh

Re: [HYBRID]: status update...

[Stefano Stabellini]

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?

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Stefano Stabellini]

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 :)

Re: [HYBRID]: status update...

[Mukesh Rathor]

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

Re: [HYBRID]: status update...

[Jan Beulich]

>>> 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

Re: [HYBRID]: status update...

[Ian Campbell]

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
> 

Re: [HYBRID]: status update...

[Jan Beulich]

>>> 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