From: Sheng Yang <sheng@linux.intel.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
Ian Pratt <Ian.Pratt@eu.citrix.com>,
xen-devel <xen-devel@lists.xensource.com>,
Keir Fraser <Keir.Fraser@eu.citrix.com>
Subject: Re: [PATCH][v4] PV extension of HVM(hybrid) support in Xen
Date: Mon, 1 Mar 2010 19:40:50 +0800 [thread overview]
Message-ID: <201003011940.50685.sheng@linux.intel.com> (raw)
In-Reply-To: <20100301102127.GA17243@whitby.uk.xensource.com>
On Monday 01 March 2010 18:21:27 Tim Deegan wrote:
> At 09:43 +0000 on 01 Mar (1267436621), Sheng Yang wrote:
> > @@ -3109,6 +3117,36 @@
> > break;
> > }
> >
> > + case HVMOP_enable_pv: {
>
> Why does this have to be explicitly enabled? Can't you just notice that
> a domain is using the evtchnop hypercalls?
The issue is pv timer. It assumed the tsc start from 0, which is different
from HVM. So I'd like to give it a explicit call here. Otherwise it can be
hooked in evtchn binding, but I don't think that's clear...
> > + struct xen_hvm_pv_type a;
> > + struct domain *d;
> > +
> > + if ( copy_from_guest(&a, arg, 1) )
> > + return -EFAULT;
> > +
> > + rc = rcu_lock_target_domain_by_id(a.domid, &d);
>
> Domains do this to each other? It looks like it has surprising
> side-effects.
Should not allowed... I think a.domid should always be the current domain.
Replace it with DOMID_SELF?
> > + if ( rc != 0 )
> > + return rc;
> > +
> > + rc = -EINVAL;
> > + if ( !is_hvm_domain(d) )
> > + goto param_fail5;
> > +
> > + rc = xsm_hvm_param(d, op);
> > + if ( rc )
> > + goto param_fail5;
> > +
> > + if (a.flags & HVM_PV_EVTCHN) {
> > + update_domain_wallclock_time(d);
> > + hvm_funcs.set_tsc_offset(d->vcpu[0], 0);
>
> Only vcpu 0? Doesn't this do horrible things to timekeeping in the guest?
The other vcpus are initialized when it is brought up. TSC started from 0 is a
fundamental assumption for pv clock in Linux...
>
> > + d->hvm_pv_enabled |= XEN_HVM_PV_EVTCHN_ENABLED;
> > + printk("HVM: PV featured evtchn enabled\n");
>
> Please remove your debugging printks.
OK...
--
regards
Yang, Sheng
>
> > + }
> > +param_fail5:
> > + rcu_unlock_domain(d);
> > + break;
> > + }
> > +
> > default:
> > {
> > gdprintk(XENLOG_WARNING, "Bad HVM op %ld.\n", op);
>
> Tim.
>
next prev parent reply other threads:[~2010-03-01 11:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-01 9:43 [PATCH][v4] PV extension of HVM(hybrid) support in Xen Sheng Yang
2010-03-01 10:00 ` Keir Fraser
2010-03-01 10:52 ` Stefano Stabellini
2010-03-01 10:21 ` Tim Deegan
2010-03-01 11:40 ` Sheng Yang [this message]
2010-03-02 1:49 ` Jeremy Fitzhardinge
2010-03-02 3:36 ` Sheng Yang
2010-03-02 4:39 ` Jeremy Fitzhardinge
2010-03-02 5:04 ` Sheng Yang
2010-03-02 5:21 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003011940.50685.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=Ian.Campbell@eu.citrix.com \
--cc=Ian.Pratt@eu.citrix.com \
--cc=Keir.Fraser@eu.citrix.com \
--cc=Tim.Deegan@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.