From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: George Dunlap <george.dunlap@eu.citrix.com>,
Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v2] xen: use domid check in is_hardware_domain
Date: Wed, 10 Jul 2013 14:33:32 -0400 [thread overview]
Message-ID: <51DDA8FC.9070308@tycho.nsa.gov> (raw)
In-Reply-To: <51DD3DFC.4090300@eu.citrix.com>
On 07/10/2013 06:57 AM, George Dunlap wrote:
> On 09/07/13 21:28, Daniel De Graaf wrote:
[...]
>> index 874742c..51d0ea6 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1459,7 +1459,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>> }
>> set_cpuid_faulting(!is_hvm_vcpu(next) &&
>> - (next->domain->domain_id != 0));
>> + !is_control_domain(next->domain));
>
> Won't this mean that in your separate hardware/control domain model that the hardware domain *will* fault on cpuid? Is this what we want?
I would expect that if CPUID faulting is turned on for the hardware domain that
no features would be masked (since it can't be migrated, there's no reason to
avoid using an existing feature). Jan commented on a prior version of this patch
(on April 12) that it makes sense for a control domain to see the full features
of the CPU in order to create masks for guests.
In theory, we could enable CPUID faulting for all domains after dom0 and force the
domain builder to copy out the hardware CPUID to its guests - likely unmodified for
hardware and control domains, and then masked as usual for a domU for others.
However, this may require too much knowledge of the behavior of CPUID sub-leaves to
be encoded in the domain builder - this seems like knowledge best left to the
hardware domain (for things like feature bits for power management MSRs) and the
control domain (to see an upper bound on features it exposes to the guest).
So, I think the best solution is to make this condition !hardware && !control.
>> }
>> if (is_hvm_vcpu(next) && (prev != next) )
[...]
>> @@ -1962,7 +1962,7 @@ static void dump_softtsc(unsigned char key)
>> "warp=%lu (count=%lu)\n", tsc_max_warp, tsc_check_count);
>> for_each_domain ( d )
>> {
>> - if ( d->domain_id == 0 && d->arch.tsc_mode == TSC_MODE_DEFAULT )
>> + if ( is_hardware_domain(d) && d->arch.tsc_mode == TSC_MODE_DEFAULT )
>> continue;
>> printk("dom%u%s: mode=%d",d->domain_id,
>> is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
>
> Why have direct access to the tsc for the hardware domain and not the control domain?
This is just excluding output from a printk. It may make sense to exclude more than
the hardware domain, but that's really a matter of taste. We could also just remove
the exclusion, but that should be a separate patch.
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index 57dbd0c..8e8d3d1 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -745,7 +745,7 @@ static void pv_cpuid(struct cpu_user_regs *regs)
>> c = regs->ecx;
>> d = regs->edx;
>> - if ( current->domain->domain_id != 0 )
>> + if ( !is_control_domain(current->domain) )
>> {
>> unsigned int cpuid_leaf = a, sub_leaf = c;
>
> Same as above re cpuid.
Will need to be handled the same if the above is changed.
[...]
>> index 6c264a5..692372a 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -238,7 +238,7 @@ struct domain *domain_create(
>> if ( domcr_flags & DOMCRF_hvm )
>> d->is_hvm = 1;
>> - if ( domid == 0 )
>> + if ( is_hardware_domain(d) )
>> {
>> d->is_pinned = opt_dom0_vcpus_pin;
>> d->disable_migrate = 1;
>
> At some point this will have to be thought about a bit more -- which of the disaggregated domains do we actually want pinned here? But I think this is fine for now.
I would say the hardware domain would be the most likely one to pin, since it would
be in charge of things like CPU frequency, microcode, and so forth. Pinning other
domains for performance reasons is really better done by a scheduler interface,
either at domain creation or at runtime.
> Everything else looks reasonable to me, but obviously needs acks from various maintainers.
>
> -George
>
--
Daniel De Graaf
National Security Agency
prev parent reply other threads:[~2013-07-10 18:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 20:28 [PATCH v2] xen: use domid check in is_hardware_domain Daniel De Graaf
2013-07-10 8:30 ` Jan Beulich
2013-07-10 9:18 ` George Dunlap
2013-07-10 9:38 ` Jan Beulich
2013-07-10 10:10 ` George Dunlap
2013-07-10 10:30 ` Jan Beulich
2013-07-10 18:33 ` Daniel De Graaf
2013-07-10 10:57 ` George Dunlap
2013-07-10 11:43 ` Jan Beulich
2013-07-10 13:00 ` George Dunlap
2013-07-10 13:56 ` Jan Beulich
2013-07-10 15:50 ` George Dunlap
2013-07-11 8:03 ` Jan Beulich
2013-07-10 18:33 ` Daniel De Graaf [this message]
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=51DDA8FC.9070308@tycho.nsa.gov \
--to=dgdegra@tycho.nsa.gov \
--cc=JBeulich@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).