From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 17/21] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
Date: Thu, 26 Nov 2015 17:57:56 +0100 [thread overview]
Message-ID: <56573A14.4010804@citrix.com> (raw)
In-Reply-To: <5644D31F02000078000B466F@prv-mh.provo.novell.com>
El 12/11/15 a les 17.57, Jan Beulich ha escrit:
>>>> On 06.11.15 at 17:05, <roger.pau@citrix.com> wrote:
>> @@ -1183,6 +1184,301 @@ int arch_set_info_guest(
>> #undef c
>> }
>>
>> +static inline int check_segment(struct segment_register reg,
>
> Passed by value?
Hm, right, will pass by reference in next version.
>
>> + enum x86_segment seg)
>> +{
>> +
>> + if ( reg.attr.fields.pad != 0 )
>> + {
>> + gprintk(XENLOG_ERR,
>> + "Attribute bits 12-15 of the segment are not zero\n");
>> + return -EINVAL;
>> + }
>> +
>> + if ( reg.sel == 0 && reg.base == 0 && reg.limit == 0 &&
>
> What's the sel check good for when your only caller only ever calls
> you with it being zero?
I don't mind removing the sel == 0 check but I don't think it hurts either.
> Looking at base or limit here doesn't seem
> right either.
I'm sorry but I'm not following you here, why is this not right? Would
you rather conclude that the user is trying to load a null segment by
just looking at the attributes field (and checking it's 0)?
>> + reg.attr.bytes == 0)
>> + {
>> + if ( seg == x86_seg_cs || seg == x86_seg_ss )
>> + {
>> + gprintk(XENLOG_ERR, "Null selector provided for CS or SS\n");
>> + return -EINVAL;
>> + }
>> + return 0;
>> + }
>> +
>> + if ( reg.attr.fields.p != 1 )
>
> This is effectively a boolean field - no need for "!= 1", should be
> just !.
Ack.
>> + {
>> + gprintk(XENLOG_ERR, "Non-present segment provided\n");
>> + return -EINVAL;
>> + }
>> +
>> + if ( seg == x86_seg_cs && !(reg.attr.fields.type & 0x8) )
>> + {
>> + gprintk(XENLOG_ERR, "CS is missing code type\n");
>> + return -EINVAL;
>> + }
>> +
>> + if ( seg != x86_seg_cs && !!(reg.attr.fields.type & 0x8) )
>
> No need for !! here. Also only SS is disallowed to get code segments
> loaded. For other selector registers they're okay when readable.
>
>> + {
>> + gprintk(XENLOG_ERR, "Non code segment with code type set\n");
>> + return -EINVAL;
>> + }
>
> SS must be writable.
OK, I've fixed both issues and also added a check to make sure the S
attribute bit is set for all segments except TR.
>> +int arch_set_info_hvm_guest(struct vcpu *v, const vcpu_hvm_context_t *ctx)
>> +{
>> + struct cpu_user_regs *uregs = &v->arch.user_regs;
>> + struct segment_register cs, ds, ss, es, tr;
>> + int rc;
>> +
>> + if ( ctx->pad != 0 )
>> + {
>> + gprintk(XENLOG_ERR, "Padding field != 0\n");
>
> Please don't.
OK, I'm also going to remove the other gprintk below regarding non 0
padding.
>
>> + return -EINVAL;
>> + }
>> +
>> + switch ( ctx->mode )
>> + {
>> + default:
>> + return -EINVAL;
>> +
>> + case VCPU_HVM_MODE_32B:
>> + {
>> + const struct vcpu_hvm_x86_32 *regs = &ctx->cpu_regs.x86_32;
>> + uint32_t limit;
>> +
>> + if ( ctx->cpu_regs.x86_32.pad1 != 0 ||
>> + ctx->cpu_regs.x86_32.pad2[0] != 0 ||
>> + ctx->cpu_regs.x86_32.pad2[1] != 0 ||
>> + ctx->cpu_regs.x86_32.pad2[2] != 0 )
>> + {
>> + gprintk(XENLOG_ERR, "Padding field != 0\n");
>> + return -EINVAL;
>> + }
>> +
>> +#define SEG(s, r) \
>> + (struct segment_register){ .sel = 0, .base = (r)->s ## _base, \
>> + .limit = (r)->s ## _limit, .attr.bytes = (r)->s ## _ar }
>> + cs = SEG(cs, regs);
>> + ds = SEG(ds, regs);
>> + ss = SEG(ss, regs);
>> + es = SEG(es, regs);
>> + tr = SEG(tr, regs);
>> +#undef SEG
>> +
>> + rc = check_segment(cs, x86_seg_cs);
>> + rc |= check_segment(ds, x86_seg_ds);
>> + rc |= check_segment(ss, x86_seg_ss);
>> + rc |= check_segment(es, x86_seg_es);
>> + rc |= check_segment(tr, x86_seg_tr);
>> + if ( rc != 0 )
>> + return rc;
>> +
>> + /* Basic sanity checks. */
>> + limit = cs.limit;
>> + if ( cs.attr.fields.g )
>> + limit = (limit << 12) | 0xfff;
>> + if ( regs->eip > limit )
>> + {
>> + gprintk(XENLOG_ERR, "EIP (%#08x) outside CS limit (%#08x)\n",
>> + regs->eip, limit);
>> + return -EINVAL;
>> + }
>> +
>> + if ( ds.attr.fields.p && ds.attr.fields.dpl > cs.attr.fields.dpl )
>> + {
>> + gprintk(XENLOG_ERR, "DS.DPL (%u) is greater than CS.DPL (%u)\n",
>> + ds.attr.fields.dpl, cs.attr.fields.dpl);
>
> Indentation.
Done (and fixed others above and below).
>
>> + return -EINVAL;
>> + }
>> +
>> + if ( ss.attr.fields.p && ss.attr.fields.dpl != cs.attr.fields.dpl )
>> + {
>> + gprintk(XENLOG_ERR, "SS.DPL (%u) is different than CS.DPL (%u)\n",
>> + ss.attr.fields.dpl, cs.attr.fields.dpl);
>> + return -EINVAL;
>> + }
>
> I think this should go ahead of the DS one. Also I don't think
> either CS or SS would be okay with the present bit clear, even
> less so in 32-bit mode.
Yes, CS or SS cannot have the present bit clear, we already make sure of
that in the check_segment function above. This condition can indeed be
simplified.
>> +int arch_initialize_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
>> +{
>> + struct domain *d = v->domain;
>> + int rc;
>> +
>> + if ( is_hvm_vcpu(v) )
>> + {
>> + struct vcpu_hvm_context ctxt;
>> +
>> + if ( copy_from_guest(&ctxt, arg, 1) )
>> + return -EFAULT;
>> +
>> + domain_lock(d);
>> + rc = v->is_initialised ? -EEXIST : arch_set_info_hvm_guest(v, &ctxt);
>> + domain_unlock(d);
>> + }
>> + else
>> + {
>> + struct vcpu_guest_context *ctxt;
>> +
>> + if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
>> + return -ENOMEM;
>> +
>> + if ( copy_from_guest(ctxt, arg, 1) )
>> + {
>> + free_vcpu_guest_context(ctxt);
>> + return -EFAULT;
>> + }
>> +
>> + domain_lock(d);
>> + rc = v->is_initialised ? -EEXIST : arch_set_info_guest(v, ctxt);
>> + domain_unlock(d);
>> +
>> + free_vcpu_guest_context(ctxt);
>> + }
>
> This else branch looks suspiciously like the ARM variant, and iirc I
> had asked already on an earlier version to have this handled in
> common code (with ARM simply using the common function for its
> arch_initialize_vcpu()).
Done, I've created a default_initalize_vcpu that's shared between ARM
and x86 PV guests. The arch_initialize_vcpu implementation on ARM is
just a stub that calls default_initialize_vcpu.
Roger.
next prev parent reply other threads:[~2015-11-26 16:58 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 16:05 [PATCH v8 00/21] Introduce HVM without dm and new boot ABI Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices Roger Pau Monne
2015-11-16 12:18 ` Jan Beulich
2015-11-16 18:33 ` Andrew Cooper
2015-11-17 9:42 ` Jan Beulich
2015-11-17 9:58 ` Juergen Gross
2015-11-17 10:30 ` Andrew Cooper
2015-11-17 10:35 ` Juergen Gross
2015-11-26 10:25 ` Roger Pau Monné
2015-11-06 16:05 ` [PATCH v8 02/21] xen/vlapic: fixes for HVM code when running without a vlapic Roger Pau Monne
2015-11-06 16:10 ` Andrew Cooper
2015-11-26 5:41 ` Tian, Kevin
2015-11-06 16:05 ` [PATCH v8 03/21] xen/x86: allow disabling the emulated local apic Roger Pau Monne
2015-11-26 5:47 ` Tian, Kevin
2015-11-06 16:05 ` [PATCH v8 04/21] xen/x86: allow disabling the emulated HPET Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 05/21] xen/x86: allow disabling power management Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 06/21] xen/x86: allow disabling the emulated RTC Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 07/21] xen/x86: allow disabling the emulated IO APIC Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 08/21] xen/x86: allow disabling the emulated PIC Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 09/21] xen/x86: set the vPMU interface based on the presence of a lapic Roger Pau Monne
2015-11-09 15:04 ` Jan Beulich
2015-11-10 11:30 ` [PATCH v8.1 " Roger Pau Monne
2015-11-10 14:21 ` Boris Ostrovsky
2015-11-06 16:05 ` [PATCH v8 10/21] xen/x86: allow disabling the emulated VGA Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 11/21] xen/x86: allow disabling the emulated IOMMU Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 12/21] xen/x86: allow disabling the emulated PIT Roger Pau Monne
2015-11-09 15:31 ` Jan Beulich
2015-11-06 16:05 ` [PATCH v8 13/21] xen/x86: make sure the HVM callback vector is correctly set Roger Pau Monne
2015-11-10 16:41 ` Jan Beulich
2015-11-06 16:05 ` [PATCH v8 14/21] xen/x86: allow disabling all emulated devices inside of Xen Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 15/21] elfnotes: intorduce a new PHYS_ENTRY elfnote Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 16/21] libxc: allow creating domains without emulated devices Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 17/21] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Roger Pau Monne
2015-11-12 16:57 ` Jan Beulich
2015-11-26 16:57 ` Roger Pau Monné [this message]
2015-11-27 8:00 ` Jan Beulich
2015-11-27 9:47 ` Roger Pau Monné
2015-11-27 10:03 ` Jan Beulich
2015-11-06 16:05 ` [PATCH v8 18/21] libxc/xen: introduce a start info structure for HVMlite guests Roger Pau Monne
2015-11-10 16:53 ` Jan Beulich
2015-11-06 16:05 ` [PATCH v8 19/21] libxc: switch xc_dom_elfloader to be used with HVMlite domains Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 20/21] libxl: allow the creation of HVM domains without a device model Roger Pau Monne
2015-11-06 16:05 ` [PATCH v8 21/21] libxl: add support for migrating HVM guests " Roger Pau Monne
2015-11-11 15:49 ` Wei Liu
2015-11-11 15:55 ` Ian Jackson
2015-11-11 17:14 ` Andrew Cooper
2015-11-26 18:10 ` Roger Pau Monné
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=56573A14.4010804@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xenproject.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 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.