Xen devel - Mar 2010 - [PATCH][v5] PV extension of HVM(hybrid) in support in Xen

Hi Keir

The latest (hybrid) patchset again...

Change from v4:
1. Add support for PV clocksource on HVM. (Replace evtchn enabling with pv 
clock enabling).
2. Update the patch following Tim''s comments.

Change from v3:

1. Minor polish the patchset. Replace several specific 
is_hvm_pv_evtchn_domain() judgement.
2. Name changed...

Change from v2:
 
1. Change the name "hybrid" to "PV featured HVM", as well as
flag and macro
names.
2. Merge the hypercall page with HVM.
3. Clean up VIRQ delivery mechanism, fixing the lock issue.
4. Remove the reserved the region in E820(but another issue remains, I
 can''t get location of grant table elegantly, as I described in Linux
part
 patches)

Please review, thanks!

-- 
regards
Yang, Sheng


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

Given that we now have a similar feature from Stefano I''d like to see
them resolved into a single patchset. 

At 09:37 +0000 on 04 Mar (1267695434), Sheng Yang wrote:
> +	if (a.flags & HVM_PV_CLOCK) {
> +		d->hvm_pv_enabled |= XEN_HVM_PV_CLOCK_ENABLED;
> +		update_domain_wallclock_time(d);
> +		/* Other vcpus are adjusted during the start-up */
> +		hvm_funcs.set_tsc_offset(d->vcpu[0], 0);
> +	}
This still makes no sense to me.  Either it should affect the calling
vcpu (i.e., current) or it should affect all online vcpus.

Also, whatever the semantics, they should be documented in comments in
the header file.

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 04 March 2010 23:04:31 Tim Deegan wrote:
> Hi,
> 
> Given that we now have a similar feature from Stefano I''d like to
see
> them resolved into a single patchset.
I think Stefano''s patch focused on pv_ops dom0? We are focused on
upstream
Linux as domU...

I think we can get dom0 approach step by step. 
> 
> At 09:37 +0000 on 04 Mar (1267695434), Sheng Yang wrote:
> > +	if (a.flags & HVM_PV_CLOCK) {
> > +		d->hvm_pv_enabled |= XEN_HVM_PV_CLOCK_ENABLED;
> > +		update_domain_wallclock_time(d);
> > +		/* Other vcpus are adjusted during the start-up */
> > +		hvm_funcs.set_tsc_offset(d->vcpu[0], 0);
> > +	}
> 
> This still makes no sense to me.  Either it should affect the calling
> vcpu (i.e., current) or it should affect all online vcpus.
Yeah... I would make it affect the calling vcpu.
> 
> Also, whatever the semantics, they should be documented in comments in
> the header file.
Sure.

-- 
regards
Yang, Sheng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-03-05 at 02:01 +0000, Sheng Yang wrote:
> On Thursday 04 March 2010 23:04:31 Tim Deegan wrote:
> > Hi,
> > 
> > Given that we now have a similar feature from Stefano I''d
like to see
> > them resolved into a single patchset.
> 
> I think Stefano''s patch focused on pv_ops dom0? We are focused on
upstream
> Linux as domU...
Stefano''s patches are based on the latest Xen branches which support
dom0 but his work is focused on domU. That is because there is a lot of
similarity between the needs of dom0 and the needs of PVonHVM event
channels so it makes sense to leverage one for the other.
> I think we can get dom0 approach step by step. 
I think we''d be better served in extracting the bits of the domain0
patchset which support/enable Stefano''s patches and pushing that stuff
upstream as a complete series. Otherwise we basically need to
reimplement domain 0 stuff on top of / alongside your patcheset.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 5 Mar 2010, Ian Campbell wrote:
> On Fri, 2010-03-05 at 02:01 +0000, Sheng Yang wrote:
> > On Thursday 04 March 2010 23:04:31 Tim Deegan wrote:
> > > Hi,
> > > 
> > > Given that we now have a similar feature from Stefano
I''d like to see
> > > them resolved into a single patchset.
> > 
> > I think Stefano''s patch focused on pv_ops dom0? We are
focused on upstream
> > Linux as domU...
> 
> Stefano''s patches are based on the latest Xen branches which
support
> dom0 but his work is focused on domU. That is because there is a lot of
> similarity between the needs of dom0 and the needs of PVonHVM event
> channels so it makes sense to leverage one for the other.
> 
> > I think we can get dom0 approach step by step. 
> 
> I think we''d be better served in extracting the bits of the
domain0
> patchset which support/enable Stefano''s patches and pushing that
stuff
> upstream as a complete series. Otherwise we basically need to
> reimplement domain 0 stuff on top of / alongside your patcheset.
> 
Indeed.

If you look at the fourth patch of my series you''ll find that the only
thing needed is the xen_setup_pirqs mechanism, that has been recently
refactored to address the comments from the kernel community, so it
shouldn''t be difficult to upstream.

Besides upstreaming something now that you know has to be changed soon
is certainly not going to help Xen or its users.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel