From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
David Vrabel <david.vrabel@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests
Date: Tue, 4 Aug 2015 19:08:19 +0100 [thread overview]
Message-ID: <55C0FF93.70501@citrix.com> (raw)
In-Reply-To: <55BFA569.7050102@citrix.com>
On 03/08/15 18:31, Roger Pau Monné wrote:
> El 03/08/15 a les 18.55, Andrew Cooper ha escrit:
>> On 24/07/15 17:54, Roger Pau Monné wrote:
>>>>> struct vcpu_hvm_context {
>>>>> /* 16bit fields of the strucutre will be used. */
>>>>> #define _VCPUHVM_MODE_16B 0
>>>>> #define VCPUHVM_MODE_16B (1<<_VCPUHVM_MODE_16B)
>>>>> /* 32bit fields of the structure will be used. */
>>>>> #define _VCPUHVM_MODE_32B 1
>>>>> #define VCPUHVM_MODE_32B (1<<_VCPUHVM_MODE_32B)
>>>>> /* 64bit fields of the structure will be used. */
>>>>> #define _VCPUHVM_MODE_64B 2
>>>>> #define VCPUHVM_MODE_64B (1<<_VCPUHVM_MODE_64B)
>>>> As soon as we have three values here, a boolean flag approach
>>>> doesn't make sense anymore.
>>> Yes, taking into account that only _one_ of them can be used at the same
>>> time.
>>>
>>> I have the feeling that we are over engineering this interface. IMHO we
>>> should only allow the user to set the control registers, efer (on amd64)
>>> and the GP registers. Segment selectors would be set by Xen to point to
>>> a flat segment suitable for the mode the guest has selected. I think
>>> that should be enough to get the guest OS into it's entry point, and
>>> then it can do whatever it wants.
>>>
>>> If that's not suitable, then my second option would be to allow the
>>> guest to set the base, limit and AR bytes of the selectors, but not load
>>> a GDT.
>> In an ideal world, it would be nice to pass enough state to be able to
>> point eip at the idle loop and have everything JustWork. However, this
>> makes a lot of assumptions about exactly which state the vcpu wants to
>> set up, which might include MSRs as well.
>>
>> Therefore, an appropriate compromise is to be able to point eip at
>> startup_cpu, running in the correct operating mode to avoid bouncing
>> through trampolines.
> IMHO, allowing OSes to jump straight into the idle loop is putting a
> lot of burden in the Xen side of things. Also all OSes already contain
> AP startup code, we should be able to hook into this code at a suitable
> location, and that's what we should aim for.
>
>> >From that point of view, the minimum quantity of state required is:
>>
>> CR{0,3,4}, EFER, cs/eip, ds, ss/esp, gdt{base,limit}. It would be
>> natural to extend this to all the 8 base GPRs and the user segment
>> selectors. (Note that EFER is needed even for 32bit paged entries if NX
>> is set in the pagetables.)
> Extending this to the rest of the GPR is needed for Linux to boot. The
> AP startup code of PVH Linux places the cpu id in a GPR for the boot
> stub to find it:
>
> http://lxr.free-electrons.com/source/arch/x86/xen/smp.c#L420
>
>> In addition, a hint to Xen as to the eventual mode so it can widen its
>> reads to start with rather than attempting to reverse engineer the
>> operating mode and rereading half the structure later.
>>
>> Specifying the gdt{base,limit} will require Xen to read the GDT to set
>> up the entry attributes for the segment, as simply setting the selector
>> is insufficient. A complicating factor is that VT-x and SVM have
>> different representations for access rights. (For migration, VT-x's
>> representation is mutated to match SVM.)
>>
>> I really undecided between suggesting a gdt{base,limit} and Xen reading
>> the access rights in an unambiguous fashon, vs specifying the internals
>> and avoiding any peeking into domain memory.
>>
>> It would be nice if the new cpus gs base could be set by the caller,
>> which allows the new cpu straight access to its per-cpu data area (if gs
>> is in use). This is not representable using the gdt method and would
>> involve casing the GSBASE MSR if we were to go down the strict
>> architectural route.
> IMHO, this is out of the scope and I would rather allow the caller to
> set the internal (cached) part of the segment selectors.
>
>> Therefore, I am leaning slightly towards the specify the internals side
>> of things, which removes some complexity from the Xen side of the hypercall.
> I've updated the proposed structure, so now it looks like:
>
> (I still need to figure out how to order the bits in the access rights
> (_ar) fields.)
All struct's need a flags register.
>
> struct vcpu_hvm_x86_16 {
> uint16_t ax;
> uint16_t cx;
> uint16_t dx;
> uint16_t bx;
> uint16_t sp;
> uint16_t bp;
> uint16_t si;
> uint16_t di;
> uint16_t ip;
>
> uint32_t cr[8];
Definitely no need for anything other than cr0 and 4 in 16 bit mode.
>
> uint32_t cs_base;
> uint32_t ds_base;
> uint32_t ss_base;
> uint32_t cs_limit;
> uint32_t ds_limit;
> uint32_t ss_limit;
> uint16_t cs_ar;
> uint16_t ds_ar;
> uint16_t ss_ar;
> };
>
> struct vcpu_hvm_x86_32 {
> uint32_t eax;
> uint32_t ecx;
> uint32_t edx;
> uint32_t ebx;
> uint32_t esp;
> uint32_t ebp;
> uint32_t esi;
> uint32_t edi;
> uint32_t eip;
>
> uint32_t cr[8];
Don't need cr's 5-8.
> uint64_t efer;
>
> uint32_t cs_base;
> uint32_t ds_base;
> uint32_t ss_base;
> uint32_t cs_limit;
> uint32_t ds_limit;
> uint32_t ss_limit;
> uint16_t cs_ar;
> uint16_t ds_ar;
> uint16_t ss_ar;
You need selector entries for each segment as well.
> };
>
> struct vcpu_hvm_x86_64 {
> uint64_t rax;
> uint64_t rcx;
> uint64_t rdx;
> uint64_t rbx;
> uint64_t rsp;
> uint64_t rbp;
> uint64_t rsi;
> uint64_t rdi;
> uint64_t r8;
> uint64_t r9;
> uint64_t r10;
> uint64_t r11;
> uint64_t r12;
> uint64_t r13;
> uint64_t r14;
> uint64_t r15;
> uint64_t rip;
>
> uint64_t cr[8];
> uint64_t efer;
What has happened to the segment information? It cannot be omitted
completely, even in 64bit.
> };
>
> typedef enum {
> VCPU_HVM_MODE_16B, /* 16bit fields of the structure will be used. */
> VCPU_HVM_MODE_32B, /* 32bit fields of the structure will be used. */
> VCPU_HVM_MODE_64B, /* 64bit fields of the structure will be used. */
> } vcpu_hvm_mode_t;
>
> struct vcpu_hvm_context {
> vcpu_hvm_mode_t mode;
The width of an enum is implementation defined, which makes them
unsuitable in the public interface.
>
> /* CPU registers. */
> union {
> struct vcpu_hvm_x86_16 x86_16;
> struct vcpu_hvm_x86_32 x86_32;
> struct vcpu_hvm_x86_64 x86_64;
> };
We require C89 compatibility for the public interface, so no anonymous
unions.
~Andrew
> };
> typedef struct vcpu_hvm_context vcpu_hvm_context_t;
> DEFINE_XEN_GUEST_HANDLE(vcpu_hvm_context_t);
>
>
next prev parent reply other threads:[~2015-08-04 18:09 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-03 11:34 [PATCH v3 00/32] Introduce HVM without dm and new boot ABI Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 01/32] libxc: split x86 HVM setup_guest into smaller logical functions Roger Pau Monne
2015-07-06 10:45 ` Andrew Cooper
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 02/32] libxc: unify xc_dom_p2m_{host/guest} Roger Pau Monne
2015-07-06 10:49 ` Andrew Cooper
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 03/32] libxc: introduce the notion of a container type Roger Pau Monne
2015-07-06 12:01 ` Andrew Cooper
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 04/32] libxc: introduce a domain loader for HVM guest firmware Roger Pau Monne
2015-07-06 12:11 ` Andrew Cooper
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 05/32] libxc: make arch_setup_meminit a xc_dom_arch hook Roger Pau Monne
2015-07-06 12:23 ` Andrew Cooper
2015-07-27 10:40 ` Roger Pau Monné
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 06/32] libxc: make arch_setup_boot{init/late} xc_dom_arch hooks Roger Pau Monne
2015-07-06 12:27 ` Andrew Cooper
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests Roger Pau Monne
2015-07-06 12:58 ` Andrew Cooper
2015-07-23 10:14 ` Roger Pau Monné
2015-07-10 18:39 ` Konrad Rzeszutek Wilk
2015-07-10 18:47 ` Konrad Rzeszutek Wilk
2015-07-23 10:17 ` Roger Pau Monné
2015-07-13 14:01 ` Jan Beulich
2015-07-23 10:25 ` Roger Pau Monné
2015-07-23 11:29 ` Jan Beulich
2015-07-23 11:41 ` Ian Campbell
2015-07-23 15:10 ` Roger Pau Monné
2015-07-23 15:32 ` Jan Beulich
2015-07-23 15:48 ` Roger Pau Monné
2015-07-23 15:58 ` Jan Beulich
2015-07-23 16:00 ` Ian Campbell
2015-07-23 16:15 ` Andrew Cooper
2015-07-23 16:19 ` Jan Beulich
2015-07-23 16:49 ` Andrew Cooper
2015-07-23 17:06 ` Roger Pau Monné
2015-07-23 16:56 ` Roger Pau Monné
2015-07-23 17:12 ` Andrew Cooper
2015-07-24 8:22 ` Jan Beulich
2015-07-24 9:59 ` Roger Pau Monné
2015-07-24 10:46 ` Jan Beulich
2015-07-24 12:11 ` Roger Pau Monné
2015-07-24 12:44 ` Jan Beulich
2015-07-24 15:26 ` Roger Pau Monné
2015-07-24 15:49 ` Jan Beulich
2015-07-24 16:54 ` Roger Pau Monné
2015-07-24 17:36 ` Konrad Rzeszutek Wilk
2015-07-27 11:55 ` Roger Pau Monné
2015-08-03 16:55 ` Andrew Cooper
2015-08-03 17:31 ` Roger Pau Monné
2015-08-04 18:08 ` Andrew Cooper [this message]
2015-08-05 9:53 ` Roger Pau Monné
2015-08-05 15:39 ` Andrew Cooper
2015-08-05 16:40 ` Roger Pau Monné
2015-08-05 16:46 ` Andrew Cooper
2015-08-05 17:11 ` Roger Pau Monné
2015-08-05 19:00 ` Andrew Cooper
2015-08-07 12:15 ` Tim Deegan
2015-08-11 7:26 ` Jan Beulich
2015-07-24 11:11 ` Andrew Cooper
2015-07-24 11:28 ` Ian Campbell
2015-07-24 11:49 ` Jan Beulich
2015-07-24 11:46 ` Jan Beulich
2015-07-24 11:49 ` Roger Pau Monné
2015-07-24 12:41 ` Jan Beulich
2015-07-24 15:28 ` Roger Pau Monné
2015-07-03 11:34 ` [PATCH v3 08/32] libxc: introduce a xc_dom_arch for hvm-3.0-x86_32 guests Roger Pau Monne
2015-07-06 13:40 ` Andrew Cooper
2015-07-03 11:34 ` [PATCH v3 09/32] libxl: switch HVM domain building to use xc_dom_* helpers Roger Pau Monne
2015-07-28 11:22 ` Wei Liu
2015-07-28 14:26 ` Roger Pau Monné
2015-07-28 14:29 ` Wei Liu
2015-07-03 11:34 ` [PATCH v3 10/32] libxc: remove dead HVM building code Roger Pau Monne
2015-07-06 13:46 ` Andrew Cooper
2015-07-23 10:27 ` Roger Pau Monné
2015-07-03 11:34 ` [PATCH v3 11/32] xen/x86: add bitmap of enabled emulated devices Roger Pau Monne
2015-07-06 14:10 ` Andrew Cooper
2015-07-07 7:26 ` Jan Beulich
2015-07-23 10:29 ` Roger Pau Monné
2015-07-03 11:34 ` [PATCH v3 12/32] xen/x86: allow disabling the emulated local apic Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 13/32] xen/x86: allow disabling the emulated HPET Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 14/32] xen/x86: allow disabling the pmtimer Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 15/32] xen/x86: allow disabling the emulated RTC Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 16/32] xen/x86: allow disabling the emulated IO APIC Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 17/32] xen/x86: allow disabling the emulated PIC Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 18/32] xen/x86: allow disabling the emulated pmu Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 19/32] xen/x86: allow disabling the emulated VGA Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 20/32] xen/x86: allow disabling the emulated IOMMU Roger Pau Monne
2015-07-03 11:34 ` [PATCH v3 21/32] xen/x86: allow disabling all emulated devices inside of Xen Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 22/32] elfnotes: intorduce a new PHYS_ENTRY elfnote Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 23/32] libxc: allow creating domains without emulated devices Roger Pau Monne
2015-07-28 11:22 ` Wei Liu
2015-07-03 11:35 ` [PATCH v3 24/32] xen: allow HVM guests to use XENMEM_memory_map Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 25/32] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 26/32] xenconsole: try to attach to PV console if HVM fails Roger Pau Monne
2015-07-14 13:46 ` Stefano Stabellini
2015-07-23 10:30 ` Roger Pau Monné
2015-07-03 11:35 ` [PATCH v3 27/32] libxc: change the position of the special pages Roger Pau Monne
2015-07-03 15:36 ` Roger Pau Monné
2015-07-10 19:06 ` Konrad Rzeszutek Wilk
2015-07-23 10:42 ` Roger Pau Monné
2015-07-03 11:35 ` [PATCH v3 28/32] libxc/xen: introduce HVM_PARAM_CMDLINE_PFN Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 29/32] libxc/xen: introduce HVM_PARAM_FIRST_FREE_PFN Roger Pau Monne
2015-07-10 19:05 ` Konrad Rzeszutek Wilk
2015-07-23 10:46 ` Roger Pau Monné
2015-07-03 11:35 ` [PATCH v3 30/32] libxc/xen: introduce HVM_PARAM_MODLIST_PFN Roger Pau Monne
2015-07-03 11:35 ` [PATCH v3 31/32] libxc: switch xc_dom_elfloader to be used with HVMlite domains Roger Pau Monne
2015-07-10 19:07 ` Konrad Rzeszutek Wilk
2015-07-23 10:48 ` Roger Pau Monné
2015-07-03 11:35 ` [PATCH v3 32/32] libxl: allow the creation of HVM domains without a device model Roger Pau Monne
2015-07-28 11:22 ` Wei Liu
2015-07-29 14:43 ` Roger Pau Monné
2015-07-29 14:50 ` Wei Liu
2015-07-29 14:58 ` Andrew Cooper
2015-07-03 16:19 ` [PATCH v3 00/32] Introduce HVM without dm and new boot ABI David Vrabel
2015-07-03 16:36 ` Roger Pau Monné
2015-07-10 17:44 ` Konrad Rzeszutek Wilk
2015-07-10 18:01 ` Konrad Rzeszutek Wilk
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=55C0FF93.70501@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=roger.pau@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 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).